2. 程式人生 > >Android應用程式的啟動過程

Android應用程式的啟動過程

阿新 • • 發佈：2018-12-30

前言

在Android系統中，Activity和Service是應用程式的核心元件，它們以鬆藕合的方式組合在一起構成了一個完整的應用程式，這得益於應用程式框架層提供了一套完整的機制來協助應用程式啟動這些Activity和Service，以及提供Binder機制幫助它們相互間進行通訊。

在Android系統中，有兩種操作會引發Activity的啟動，一種使用者點選應用程式圖示時，Launcher會為我們啟動應用程式的主Activity；應用程式的預設Activity啟動起來後，它又可以在內部通過呼叫startActvity介面啟動新的Activity，依此類推，每一個Activity都可以在內部啟動新的Activity。通過這種連鎖反應，按需啟動Activity，從而完成應用程式的功能。

這裡，我們通過一個具體的例子來說明如何啟動Android應用程式的Activity。Activity的啟動方式有兩種，一種是顯式的，一種是隱式的，隱式啟動可以使得Activity之間的藕合性更加鬆散，因此，這裡只關注隱式啟動Activity的方法。

  • MainActivity的啟動過程如下圖所示：.

這裡寫圖片描述

簡要流程

在這裡插入圖片描述
① 點選桌面App圖示，Launcher程序採用Binder IPC向system_server程序發起startActivity請求；

② system_server程序接收到請求後，向zygote程序傳送建立程序的請求；

③ Zygote程序fork出新的子程序，即App程序；

④ App程序，通過Binder IPC向sytem_server程序發起attachApplication請求；

⑤ system_server程序在收到請求後，進行一系列準備工作後，再通過binder IPC向App程序傳送scheduleLaunchActivity請求；

⑥ App程序的binder執行緒（ApplicationThread）在收到請求後，通過handler向主執行緒傳送LAUNCH_ACTIVITY訊息；

⑦ 主執行緒在收到Message後，通過發射機制建立目標Activity，並回調Activity.onCreate()等方法。

⑧ 到此，App便正式啟動，開始進入Activity生命週期，執行完onCreate/onStart/onResume方法，UI渲染結束後便可以看到App的主介面。

具體流程

Step 1. Launcher.startActivitySafely

在Android系統中，應用程式是由Launcher啟動起來的，其實，Launcher本身也是一個應用程式，其它的應用程式安裝後，就會Launcher的介面上出現一個相應的圖示，點選這個圖示時，Launcher就會對應的應用程式啟動起來。

Launcher的原始碼工程在packages/apps/Launcher2目錄下，負責啟動其它應用程式的原始碼實現在src/com/android/launcher2/Launcher.java檔案中：

/**
* Default launcher application.
*/
public final class Launcher extends Activity
		implements View.OnClickListener, OnLongClickListener, LauncherModel.Callbacks, AllAppsView.Watcher {
 
	......
 
	/**
	* Launches the intent referred by the clicked shortcut.
	*
	* @param v The view representing the clicked shortcut.
	*/
	public void onClick(View v) {
		Object tag = v.getTag();
		if (tag instanceof ShortcutInfo) {
			// Open shortcut
			final Intent intent = ((ShortcutInfo) tag).intent;
			int[] pos = new int[2];
			v.getLocationOnScreen(pos);
			intent.setSourceBounds(new Rect(pos[0], pos[1],
				pos[0] + v.getWidth(), pos[1] + v.getHeight()));
			startActivitySafely(intent, tag);
		} else if (tag instanceof FolderInfo) {
			......
		} else if (v == mHandleView) {
			......
		}
	}
 
	void startActivitySafely(Intent intent, Object tag) {
		intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
		try {
			startActivity(intent);
		} catch (ActivityNotFoundException e) {
			......
		} catch (SecurityException e) {
			......
		}
	}
 
	......
 
}

它的預設Activity是MainActivity，這裡是AndroidManifest.xml檔案中配置的：

<activity android:name=".MainActivity"  
      android:label="@string/app_name">  
       <intent-filter>  
        <action android:name="android.intent.action.MAIN" />  
        <category android:name="android.intent.category.LAUNCHER" />  
    </intent-filter>  
</activity>

因此，這裡的intent包含的資訊為：action = “android.intent.action.Main”，category=“android.intent.category.LAUNCHER”, cmp=“shy.luo.activity/.MainActivity”，表示它要啟動的Activity為shy.luo.activity.MainActivity。Intent.FLAG_ACTIVITY_NEW_TASK表示要在一個新的Task中啟動這個Activity，注意，Task是Android系統中的概念，它不同於程序Process的概念。簡單地說，一個Task是一系列Activity的集合，這個集合是以堆疊的形式來組織的，遵循後進先出的原則。事實上，Task是一個非常複雜的概念，有興趣的讀者可以到官網檢視相關的資料。這裡，我們只要知道，這個MainActivity要在一個新的Task中啟動就可以了。

Step 2. Activity.startActivity

在Step 1中，我們看到，Launcher繼承於Activity類，而Activity類實現了startActivity函式，因此，這裡就呼叫了Activity.startActivity函式，它實現在frameworks/base/core/java/android/app/Activity.java檔案中：


public class Activity extends ContextThemeWrapper
		implements LayoutInflater.Factory,
		Window.Callback, KeyEvent.Callback,
		OnCreateContextMenuListener, ComponentCallbacks {
 
	......
 
	@Override
	public void startActivity(Intent intent) {
		startActivityForResult(intent, -1);
	}
 
	......
 
}

這個函式實現很簡單，它呼叫startActivityForResult來進一步處理，第二個引數傳入-1表示不需要這個Actvity結束後的返回結果。

Step 3. Activity.startActivityForResult

這個函式也是實現在frameworks/base/core/java/android/app/Activity.java檔案中：


public class Activity extends ContextThemeWrapper
		implements LayoutInflater.Factory,
		Window.Callback, KeyEvent.Callback,
		OnCreateContextMenuListener, ComponentCallbacks {
 
	......
 
	public void startActivityForResult(Intent intent, int requestCode) {
		if (mParent == null) {
			Instrumentation.ActivityResult ar =
				mInstrumentation.execStartActivity(
				this, mMainThread.getApplicationThread(), mToken, this,
				intent, requestCode);
			......
		} else {
			......
		}
 
 
	......
 
}

這裡的mInstrumentation是Activity類的成員變數，它的型別是Intrumentation，定義在frameworks/base/core/java/android/app/Instrumentation.java檔案中，它用來監控應用程式和系統的互動。

這裡的mMainThread也是Activity類的成員變數，它的型別是ActivityThread，它代表的是應用程式的主執行緒。這裡通過mMainThread.getApplicationThread獲得它裡面的ApplicationThread成員變數，它是一個Binder物件，後面我們會看到，ActivityManagerService會使用它來和ActivityThread來進行程序間通訊。這裡我們需注意的是，這裡的mMainThread代表的是Launcher應用程式執行的程序。

這裡的mToken也是Activity類的成員變數，它是一個Binder物件的遠端介面。

Step 4. Instrumentation.execStartActivity

這個函式定義在frameworks/base/core/java/android/app/Instrumentation.java檔案中：

public class Instrumentation {
 
	......
 
	public ActivityResult execStartActivity(
	Context who, IBinder contextThread, IBinder token, Activity target,
	Intent intent, int requestCode) {
		IApplicationThread whoThread = (IApplicationThread) contextThread;
		if (mActivityMonitors != null) {
			......
		}
		try {
			int result = ActivityManagerNative.getDefault()
				.startActivity(whoThread, intent,
				intent.resolveTypeIfNeeded(who.getContentResolver()),
				null, 0, token, target != null ? target.mEmbeddedID : null,
				requestCode, false, false);
			......
		} catch (RemoteException e) {
		}
		return null;
	}
 
	......
 
}

這裡的ActivityManagerNative.getDefault返回ActivityManagerService的遠端介面，即ActivityManagerProxy介面。

這裡的intent.resolveTypeIfNeeded返回這個intent的MIME型別，在這個例子中，沒有AndroidManifest.xml設定MainActivity的MIME型別，因此，這裡返回null。

這裡的target不為null，但是target.mEmbddedID為null，我們不用關注。

Step 5. ActivityManagerProxy.startActivity

這個函式定義在frameworks/base/core/java/android/app/ActivityManagerNative.java檔案中：

class ActivityManagerProxy implements IActivityManager
{
 
	......
 
	public int startActivity(IApplicationThread caller, Intent intent,
			String resolvedType, Uri[] grantedUriPermissions, int grantedMode,
			IBinder resultTo, String resultWho,
			int requestCode, boolean onlyIfNeeded,
			boolean debug) throws RemoteException {
		Parcel data = Parcel.obtain();
		Parcel reply = Parcel.obtain();
		data.writeInterfaceToken(IActivityManager.descriptor);
		data.writeStrongBinder(caller != null ? caller.asBinder() : null);
		intent.writeToParcel(data, 0);
		data.writeString(resolvedType);
		data.writeTypedArray(grantedUriPermissions, 0);
		data.writeInt(grantedMode);
		data.writeStrongBinder(resultTo);
		data.writeString(resultWho);
		data.writeInt(requestCode);
		data.writeInt(onlyIfNeeded ? 1 : 0);
		data.writeInt(debug ? 1 : 0);
		mRemote.transact(START_ACTIVITY_TRANSACTION, data, reply, 0);
		reply.readException();
		int result = reply.readInt();
		reply.recycle();
		data.recycle();
		return result;
	}
 
	......
 
}

這裡的引數比較多，我們先整理一下。從上面的呼叫可以知道，這裡的引數resolvedType、grantedUriPermissions和resultWho均為null；引數caller為ApplicationThread型別的Binder實體；引數resultTo為一個Binder實體的遠端介面，我們先不關注它；引數grantedMode為0，我們也先不關注它；引數requestCode為-1；引數onlyIfNeeded和debug均空false。

Step 6. ActivityManagerService.startActivity

上一步Step 5通過Binder驅動程式就進入到ActivityManagerService的startActivity函式來了，它定義在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java檔案中：

public final class ActivityManagerService extends ActivityManagerNative
		implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
 
	......
 
	public final int startActivity(IApplicationThread caller,
			Intent intent, String resolvedType, Uri[] grantedUriPermissions,
			int grantedMode, IBinder resultTo,
			String resultWho, int requestCode, boolean onlyIfNeeded,
			boolean debug) {
		return mMainStack.startActivityMayWait(caller, intent, resolvedType,
			grantedUriPermissions, grantedMode, resultTo, resultWho,
			requestCode, onlyIfNeeded, debug, null, null);
	}
 
 
	......
 
}

這裡只是簡單地將操作轉發給成員變數mMainStack的startActivityMayWait函式，這裡的mMainStack的型別為ActivityStack。

Step 7. ActivityStack.startActivityMayWait

這個函式定義在frameworks/base/services/java/com/android/server/am/ActivityStack.java檔案中：


public class ActivityStack {
 
	......
 
	final int startActivityMayWait(IApplicationThread caller,
			Intent intent, String resolvedType, Uri[] grantedUriPermissions,
			int grantedMode, IBinder resultTo,
			String resultWho, int requestCode, boolean onlyIfNeeded,
			boolean debug, WaitResult outResult, Configuration config) {
 
		......
 
		boolean componentSpecified = intent.getComponent() != null;
 
		// Don't modify the client's object!
		intent = new Intent(intent);
 
		// Collect information about the target of the Intent.
		ActivityInfo aInfo;
		try {
			ResolveInfo rInfo =
				AppGlobals.getPackageManager().resolveIntent(
				intent, resolvedType,
				PackageManager.MATCH_DEFAULT_ONLY
				| ActivityManagerService.STOCK_PM_FLAGS);
			aInfo = rInfo != null ? rInfo.activityInfo : null;
		} catch (RemoteException e) {
			......
		}
 
		if (aInfo != null) {
			// Store the found target back into the intent, because now that
			// we have it we never want to do this again.  For example, if the
			// user navigates back to this point in the history, we should
			// always restart the exact same activity.
			intent.setComponent(new ComponentName(
				aInfo.applicationInfo.packageName, aInfo.name));
			......
		}
 
		synchronized (mService) {
			int callingPid;
			int callingUid;
			if (caller == null) {
				......
			} else {
				callingPid = callingUid = -1;
			}
 
			mConfigWillChange = config != null
				&& mService.mConfiguration.diff(config) != 0;
 
			......
 
			if (mMainStack && aInfo != null &&
				(aInfo.applicationInfo.flags&ApplicationInfo.FLAG_CANT_SAVE_STATE) != 0) {
				  
		              ......
 
			}
 
			int res = startActivityLocked(caller, intent, resolvedType,
				grantedUriPermissions, grantedMode, aInfo,
				resultTo, resultWho, requestCode, callingPid, callingUid,
				onlyIfNeeded, componentSpecified);
 
			if (mConfigWillChange && mMainStack) {
				......
			}
 
			......
 
			if (outResult != null) {
				......
			}
 
			return res;
		}
 
	}
 
	......
 
}

注意，從Step 6傳下來的引數outResult和config均為null，此外，表示式(aInfo.applicationInfo.flags&ApplicationInfo.FLAG_CANT_SAVE_STATE) != 0為false，因此，這裡忽略了無關程式碼。

下面語句對引數intent的內容進行解析，得到MainActivity的相關資訊，儲存在aInfo變數中：

 ActivityInfo aInfo;
    try {
	ResolveInfo rInfo =
	AppGlobals.getPackageManager().resolveIntent(
		intent, resolvedType,
		PackageManager.MATCH_DEFAULT_ONLY
		| ActivityManagerService.STOCK_PM_FLAGS);
	aInfo = rInfo != null ? rInfo.activityInfo : null;
    } catch (RemoteException e) {
		......
    }

解析之後，得到的aInfo.applicationInfo.packageName的值為"shy.luo.activity"，aInfo.name的值為"shy.luo.activity.MainActivity"，這是在這個例項的配置檔案AndroidManifest.xml裡面配置的。

此外，函式開始的地方呼叫intent.getComponent()函式的返回值不為null，因此，這裡的componentSpecified變數為true。

Step 8. ActivityStack.startActivityLocked

這個函式定義在frameworks/base/services/java/com/android/server/am/ActivityStack.java檔案中：

public class ActivityStack {
 
	......
 
	final int startActivityLocked(IApplicationThread caller,
		    Intent intent, String resolvedType,
		    Uri[] grantedUriPermissions,
		    int grantedMode, ActivityInfo aInfo, IBinder resultTo,
	            String resultWho, int requestCode,
		    int callingPid, int callingUid, boolean onlyIfNeeded,
		    boolean componentSpecified) {
	        int err = START_SUCCESS;
 
		ProcessRecord callerApp = null;
		if (caller != null) {
			callerApp = mService.getRecordForAppLocked(caller);
			if (callerApp != null) {
				callingPid = callerApp.pid;
				callingUid = callerApp.info.uid;
			} else {
				......
			}
		}
 
		......
 
		ActivityRecord sourceRecord = null;
		ActivityRecord resultRecord = null;
		if (resultTo != null) {
			int index = indexOfTokenLocked(resultTo);
			
			......
				
			if (index >= 0) {
				sourceRecord = (ActivityRecord)mHistory.get(index);
				if (requestCode >= 0 && !sourceRecord.finishing) {
					......
				}
			}
		}
 
		int launchFlags = intent.getFlags();
 
		if ((launchFlags&Intent.FLAG_ACTIVITY_FORWARD_RESULT) != 0
			&& sourceRecord != null) {
			......
		}
 
		if (err == START_SUCCESS && intent.getComponent() == null) {
			......
		}
 
		if (err == START_SUCCESS && aInfo == null) {
			......
		}
 
		if (err != START_SUCCESS) {
			......
		}
 
		......
 
		ActivityRecord r = new ActivityRecord(mService, this, callerApp, callingUid,
			intent, resolvedType, aInfo, mService.mConfiguration,
			resultRecord, resultWho, requestCode, componentSpecified);
 
		......
 
		return startActivityUncheckedLocked(r, sourceRecord,
			grantedUriPermissions, grantedMode, onlyIfNeeded, true);
	}
 
 
	......
 
}

從傳進來的引數caller得到呼叫者的程序資訊，並儲存在callerApp變數中，這裡就是Launcher應用程式的程序資訊了。

前面說過，引數resultTo是Launcher這個Activity裡面的一個Binder物件，通過它可以獲得Launcher這個Activity的相關資訊，儲存在sourceRecord變數中。

再接下來，建立即將要啟動的Activity的相關資訊，並儲存在r變數中：

ActivityRecord r = new ActivityRecord(mService, this, callerApp, callingUid,
	intent, resolvedType, aInfo, mService.mConfiguration,
	resultRecord, resultWho, requestCode, componentSpecified);

接著呼叫startActivityUncheckedLocked函式進行下一步操作。

Step 9. ActivityStack.startActivityUncheckedLocked

這個函式定義在frameworks/base/services/java/com/android/server/am/ActivityStack.java檔案中：

 public class ActivityStack {
 
	......
 
	final int startActivityUncheckedLocked(ActivityRecord r,
		ActivityRecord sourceRecord, Uri[] grantedUriPermissions,
		int grantedMode, boolean onlyIfNeeded, boolean doResume) {
		final Intent intent = r.intent;
		final int callingUid = r.launchedFromUid;
 
		int launchFlags = intent.getFlags();
 
		// We'll invoke onUserLeaving before onPause only if the launching
		// activity did not explicitly state that this is an automated launch.
		mUserLeaving = (launchFlags&Intent.FLAG_ACTIVITY_NO_USER_ACTION) == 0;
		
		......
 
		ActivityRecord notTop = (launchFlags&Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP)
			!= 0 ? r : null;
 
		// If the onlyIfNeeded flag is set, then we can do this if the activity
		// being launched is the same as the one making the call...  or, as
		// a special case, if we do not know the caller then we count the
		// current top activity as the caller.
		if (onlyI

相關推薦

Android應用程式啟動過程原始碼分析(2)

Step 9. ActivityStack.startActivityUncheckedLocked         這個函式定義在frameworks/base/services/java/com/android/server/am/ActivityStack.java檔案中： view plain pu

Android應用程式啟動過程原始碼分析

        前文簡要介紹了Android應用程式的Activity的啟動過程。在Android系統中，應用程式是由Activity組成的，因此，應用程式的啟動過程實際上就是應用程式中的預設Activity的啟動過程，本文將詳細分析應用程式框架層的原始碼，瞭解Android

Android應用程式啟動過程

// --runtime-init, --setuid=, --setgid=,             // and --setgroups= must go first             argsForZygote.add("--runtime-init");             argsFor

Android應用程式啟動過程上

Android應用程式啟動是一個比較複雜的過程，就著系統原始碼一步步走，明白啟動流程。 做過app開發的都知道，我們離不開activity，所有的頁面顯示都必須有一個activity承載著，那麼我們系統的桌面（Launcher）也是一樣的，請看下面大螢幕，我們

Android應用程式啟動詳解（二）從原始碼瞭解App的啟動過程

本文承接《Android應用程式啟動詳解（一）》繼續來學習應用程式的啟動的那些事。上文提到startActivity()方法啟動一個app後經過一翻過程就到了app的入口方法ActivityThread.main()。其實我們在之前的文章中《Android的訊息機制（二）之L

Android深入四大元件（一）應用程式啟動過程

前言 在此前的文章中，我講過了Android系統啟動流程和Android應用程序啟動過程，這一篇順理成章來學習Android 7.0的應用程式的啟動過程。分析應用程式的啟動過程其實就是分析根Activity的啟動過程。 1.Launcher請求A

SpringBoot 應用程式啟動過程

概述 說到接觸 SpringBoot 伊始，給我第一映像最深的是有兩個關鍵元素： 對照上面的典型程式碼，這個兩個元素分別是： @SpringBootApplication SpringApplication 以及 run() 方法

SpringBoot 應用程式啟動過程探祕

概述 說到接觸 SpringBoot 伊始，給我第一映像最深的是有兩個關鍵元素： 對照上面的典型程式碼，這個兩個元素分別是： @SpringBootApplication SpringApplication 以及 run() 方法 關於 @SpringBootAp

Android應用冷啟動過程分析和優化方案你瞭解多少

你有沒有發現，點選安卓手機桌面上的App圖示時，有時候應用馬上進入主介面，有時候要經歷好幾秒甚至更久的白屏（也可能是黑屏）時間才能進入主介面呢？這其實是安卓應用常見的冷熱啟動問題。本文就和大家一起聊聊冷熱啟動方式和啟動頁的體驗優化方案。 啟動方式 安卓應用的啟動方式分為三種：冷啟動

Android程式入口ActivityThread和Android應用程式啟動流程詳解

          大家初學java時候都知道java的程式入口是從main方法進入,那麼Android是基於java編寫的,那Android的程式入口做了哪些操作呢?還有Android的應用程式到底是怎樣啟動的呢?我們一起來看一下. 首先附上ActivityThread.

android應用程式啟動詳情之程序相關

        當某個應用元件啟動且該應用沒有執行其他任何元件時，Android 系統會使用單個執行執行緒為應用啟動新的 Linux 程序。 預設情況下，同一應用的所有元件在相同的程序和執行緒（稱為“主”執行緒）中執行。 如果某個應用元件啟動且該應用已存在程序（因為存在

android應用冷啟動過程分析與優化過程

http://yifeng.studio/2016/11/15/android-optimize-for-cold-start/?utm_source=tuicool&utm_medium=referral 你有沒有發現，點選安卓手機桌面上的App圖示時，有時候應用馬上進入主介面，有時候要經歷好幾秒甚

android應用程式啟動時短暫白屏或者黑屏的解決處理方案

         最近在研究使用app的過程中發現有的app首次啟動的時候會有短暫的白屏,而有些app則不會出現這樣的情況.起初我以為是手機的問題.但是當我換了幾個手機進行測試的時候仍然會出現這樣的狀況.當然出現白屏這樣的效果肯定是不會給使用者行雲流水般的感覺了,接下來我們

Android應用程式內部啟動Activity過程 startActivity 的原始碼分析

                        上文介紹了Android應用程式的啟動過程，即應用程式預設Activity的啟動過程，一般來說，這種預設Activity是在新的程序和任務中啟動的；本文將繼續分析在應用程式內部啟動非預設Activity的過程的原始碼，這種非預設Activity一般是在原來的程序

Android應用程式程序啟動過程（前篇）

前言 在此前我講過Android系統的啟動流程，系統啟動後，我們就比較關心應用程式是如何啟動的，這一篇我們來一起學習Android7.0 應用程式程序啟動過程，需要注意的是“應用程式程序啟動過程”，而不是應用程式啟動過程。關於應用程式啟動過程，我會在後

Android應用程式的啟動過程

前言 在Android系統中，Activity和Service是應用程式的核心元件，它們以鬆藕合的方式組合在一起構成了一個完整的應用程式，這得益於應用程式框架層提供了一套完整的機制來協助應用程式啟動這些Activity和Service，以及提供Binder機制幫

Android應用程式程序啟動過程（後篇）

前言 在前篇中我們講到了Android應用程式程序啟動過程，這一篇我們來講遺留的知識點：在應用程式程序建立過程中會啟動Binder執行緒池以及在應用程式程序啟動後會建立訊息迴圈。 1.Binder執行緒池啟動過程 我們首先來看RuntimeInit

Android應用程式的Activity啟動過程簡要介紹和學習計劃

        在Android系統中，Activity和Service是應用程式的核心元件，它們以鬆藕合的方式組合在一起構成了一個完整的應用程式，這得益於應用程式框架層提供了一套完整的機制來協助應用程式啟動這些Activity和Service，以及提供Binder機制幫助它

[筆記]Android應用程式程序啟動過程的理解

疑問： 1.Process.fork是啥意思？類似new嗎？ 2.接著1問，新APP程序和ActivityThread類是怎麼關聯起來的？是zygote程序呼叫執行的ActivityThread類的main方法，怎麼就執行在了新APP程序中？ 3.UI主執行緒是啥時候建

Android應用程式管理服務啟動過程淺析（PackageManagerService）

       我們知道安卓應用程式的安裝最終都是通過應用程式管理服務PackageManagerService來管理安裝的，系統在啟動時就會啟動該服務，在之前的 Android應用程式安裝過程淺析文章中分析了應用程式的安裝的過程，當時只是使用該服務，並沒有講到該