原文出處——>[Android應用程序啟動過程源代碼分析](http://blog.csdn.net/luoshengyang/article/details/6689748)
前文簡要介紹了Android應用程序的Activity的啟動過程。在Android系統中,應用程序是由Activity組成的,因此,應用程序的啟動過程實際上就是應用程序中的默認Activity的啟動過程,本文將詳細分析應用程序框架層的源代碼,了解Android應用程序的啟動過程。
在上一篇文章Android應用程序的Activity啟動過程簡要介紹和學習計劃中,我們舉例子說明了啟動Android應用程序中的Activity的兩種情景,其中,在手機屏幕中點擊應用程序圖標的情景就會引發Android應用程序中的默認Activity的啟動,從而把應用程序啟動起來。這種啟動方式的特點是會啟動一個新的進程來加載相應的Activity。這里,我們繼續以這個例子為例來說明Android應用程序的啟動過程,即MainActivity的啟動過程。
MainActivity的啟動過程如下圖所示:
:-: 
圖1 根Activity的啟動過程
上面的圖太小了,可以看我在老羅的系統源代碼書中的插圖
[點擊看大圖](https://box.kancloud.cn/51d2ff0baa74f1871a56ff5355931a9c_1501x2356.jpg)
:-: 
圖2 根Activity的完整啟動過程圖
下面詳細分析每一步是如何實現的。
#### **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) {
......
}
}
......
}
~~~
回憶一下前面一篇文章Android應用程序的Activity啟動過程簡要介紹和學習計劃說到的應用程序Activity,它的默認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是一個非常復雜的概念,有興趣的讀者可以到官網http://developer.android.com/guide/topics/manifest/activity-element.html 查看相關的資料。這里,我們只要知道,這個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,它代表的是應用程序的主線程,我們在Android系統在新進程中啟動自定義服務過程(startService)的原理分析一文中已經介紹過了。這里通過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接口,具體可以參考Android系統在新進程中啟動自定義服務過程(startService)的原理分析一文。
這里的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。
接下去就調用startActivityLocked進一步處理了。
**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 (onlyIfNeeded) {
......
}
if (sourceRecord == null) {
......
} else if (sourceRecord.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
......
} else if (r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE
|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK) {
......
}
if (r.resultTo != null && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
......
}
boolean addingToTask = false;
if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 &&
(launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0)
|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK
|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
// If bring to front is requested, and no result is requested, and
// we can find a task that was started with this same
// component, then instead of launching bring that one to the front.
if (r.resultTo == null) {
// See if there is a task to bring to the front. If this is
// a SINGLE_INSTANCE activity, there can be one and only one
// instance of it in the history, and it is always in its own
// unique task, so we do a special search.
ActivityRecord taskTop = r.launchMode != ActivityInfo.LAUNCH_SINGLE_INSTANCE
? findTaskLocked(intent, r.info)
: findActivityLocked(intent, r.info);
if (taskTop != null) {
......
}
}
}
......
if (r.packageName != null) {
// If the activity being launched is the same as the one currently
// at the top, then we need to check if it should only be launched
// once.
ActivityRecord top = topRunningNonDelayedActivityLocked(notTop);
if (top != null && r.resultTo == null) {
if (top.realActivity.equals(r.realActivity)) {
......
}
}
} else {
......
}
boolean newTask = false;
// Should this be considered a new task?
if (r.resultTo == null && !addingToTask
&& (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
// todo: should do better management of integers.
mService.mCurTask++;
if (mService.mCurTask <= 0) {
mService.mCurTask = 1;
}
r.task = new TaskRecord(mService.mCurTask, r.info, intent,
(r.info.flags&ActivityInfo.FLAG_CLEAR_TASK_ON_LAUNCH) != 0);
......
newTask = true;
if (mMainStack) {
mService.addRecentTaskLocked(r.task);
}
} else if (sourceRecord != null) {
......
} else {
......
}
......
startActivityLocked(r, newTask, doResume);
return START_SUCCESS;
}
......
}
~~~
函數首先獲得intent的標志值,保存在launchFlags變量中。
這個intent的標志值的位Intent.FLAG_ACTIVITY_NO_USER_ACTION沒有置位,因此 ,成員變量mUserLeaving的值為true。
這個intent的標志值的位Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP也沒有置位,因此,變量notTop的值為null。
由于在這個例子的AndroidManifest.xml文件中,MainActivity沒有配置launchMode屬值,因此,這里的r.launchMode為默認值0,表示以標準(Standard,或者稱為ActivityInfo.LAUNCH_MULTIPLE)的方式來啟動這個Activity。Activity的啟動方式有四種,其余三種分別是ActivityInfo.LAUNCH_SINGLE_INSTANCE、ActivityInfo.LAUNCH_SINGLE_TASK和ActivityInfo.LAUNCH_SINGLE_TOP,具體可以參考官方網站http://developer.android.com/reference/android/content/pm/ActivityInfo.html。
傳進來的參數r.resultTo為null,表示Launcher不需要等這個即將要啟動的MainActivity的執行結果。
由于這個intent的標志值的位Intent.FLAG_ACTIVITY_NEW_TASK被置位,而且Intent.FLAG_ACTIVITY_MULTIPLE_TASK沒有置位,因此,下面的if語句會被執行:
~~~
if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 &&
(launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0)
|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK
|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
// If bring to front is requested, and no result is requested, and
// we can find a task that was started with this same
// component, then instead of launching bring that one to the front.
if (r.resultTo == null) {
// See if there is a task to bring to the front. If this is
// a SINGLE_INSTANCE activity, there can be one and only one
// instance of it in the history, and it is always in its own
// unique task, so we do a special search.
ActivityRecord taskTop = r.launchMode != ActivityInfo.LAUNCH_SINGLE_INSTANCE
? findTaskLocked(intent, r.info)
: findActivityLocked(intent, r.info);
if (taskTop != null) {
......
}
}
}
~~~
這段代碼的邏輯是查看一下,當前有沒有Task可以用來執行這個Activity。由于r.launchMode的值不為ActivityInfo.LAUNCH_SINGLE_INSTANCE,因此,它通過findTaskLocked函數來查找存不存這樣的Task,這里返回的結果是null,即taskTop為null,因此,需要創建一個新的Task來啟動這個Activity。
接著往下看:
~~~
if (r.packageName != null) {
// If the activity being launched is the same as the one currently
// at the top, then we need to check if it should only be launched
// once.
ActivityRecord top = topRunningNonDelayedActivityLocked(notTop);
if (top != null && r.resultTo == null) {
if (top.realActivity.equals(r.realActivity)) {
......
}
}
}
~~~
這段代碼的邏輯是看一下,當前在堆棧頂端的Activity是否就是即將要啟動的Activity,有些情況下,如果即將要啟動的Activity就在堆棧的頂端,那么,就不會重新啟動這個Activity的別一個實例了,具體可以參考官方網站http://developer.android.com/reference/android/content/pm/ActivityInfo.html。現在處理堆棧頂端的Activity是Launcher,與我們即將要啟動的MainActivity不是同一個Activity,因此,這里不用進一步處理上述介紹的情況。
執行到這里,我們知道,要在一個新的Task里面來啟動這個Activity了,于是新創建一個Task:
~~~
if (r.resultTo == null && !addingToTask
&& (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
// todo: should do better management of integers.
mService.mCurTask++;
if (mService.mCurTask <= 0) {
mService.mCurTask = 1;
}
r.task = new TaskRecord(mService.mCurTask, r.info, intent,
(r.info.flags&ActivityInfo.FLAG_CLEAR_TASK_ON_LAUNCH) != 0);
......
newTask = true;
if (mMainStack) {
mService.addRecentTaskLocked(r.task);
}
}
~~~
新建的Task保存在r.task域中,同時,添加到mService中去,這里的mService就是ActivityManagerService了。
最后就進入startActivityLocked(r, newTask, doResume)進一步處理了。這個函數定義在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:
~~~
public class ActivityStack {
......
private final void startActivityLocked(ActivityRecord r, boolean newTask,
boolean doResume) {
final int NH = mHistory.size();
int addPos = -1;
if (!newTask) {
......
}
// Place a new activity at top of stack, so it is next to interact
// with the user.
if (addPos < 0) {
addPos = NH;
}
// If we are not placing the new activity frontmost, we do not want
// to deliver the onUserLeaving callback to the actual frontmost
// activity
if (addPos < NH) {
......
}
// Slot the activity into the history stack and proceed
mHistory.add(addPos, r);
r.inHistory = true;
r.frontOfTask = newTask;
r.task.numActivities++;
if (NH > 0) {
// We want to show the starting preview window if we are
// switching to a new task, or the next activity's process is
// not currently running.
......
} else {
// If this is the first activity, don't do any fancy animations,
// because there is nothing for it to animate on top of.
......
}
......
if (doResume) {
resumeTopActivityLocked(null);
}
}
......
}
~~~
這里的NH表示當前系統中歷史任務的個數,這里肯定是大于0,因為Launcher已經跑起來了。當NH>0時,并且現在要切換新任務時,要做一些任務切的界面操作,這段代碼我們就不看了,這里不會影響到下面啟Activity的過程,有興趣的讀取可以自己研究一下。
這里傳進來的參數doResume為true,于是調用resumeTopActivityLocked進一步操作。
**Step 10. Activity.resumeTopActivityLocked**
這個函數定義在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:
~~~
public class ActivityStack {
......
/**
* Ensure that the top activity in the stack is resumed.
*
* @param prev The previously resumed activity, for when in the process
* of pausing; can be null to call from elsewhere.
*
* @return Returns true if something is being resumed, or false if
* nothing happened.
*/
final boolean resumeTopActivityLocked(ActivityRecord prev) {
// Find the first activity that is not finishing.
ActivityRecord next = topRunningActivityLocked(null);
// Remember how we'll process this pause/resume situation, and ensure
// that the state is reset however we wind up proceeding.
final boolean userLeaving = mUserLeaving;
mUserLeaving = false;
if (next == null) {
......
}
next.delayedResume = false;
// If the top activity is the resumed one, nothing to do.
if (mResumedActivity == next && next.state == ActivityState.RESUMED) {
......
}
// If we are sleeping, and there is no resumed activity, and the top
// activity is paused, well that is the state we want.
if ((mService.mSleeping || mService.mShuttingDown)
&& mLastPausedActivity == next && next.state == ActivityState.PAUSED) {
......
}
......
// If we are currently pausing an activity, then don't do anything
// until that is done.
if (mPausingActivity != null) {
......
}
......
// We need to start pausing the current activity so the top one
// can be resumed...
if (mResumedActivity != null) {
......
startPausingLocked(userLeaving, false);
return true;
}
......
}
......
}
~~~
函數先通過調用topRunningActivityLocked函數獲得堆棧頂端的Activity,這里就是MainActivity了,這是在上面的Step 9設置好的,保存在next變量中。
接下來把mUserLeaving的保存在本地變量userLeaving中,然后重新設置為false,在上面的Step 9中,mUserLeaving的值為true,因此,這里的userLeaving為true。
這里的mResumedActivity為Launcher,因為Launcher是當前正被執行的Activity。
當我們處理休眠狀態時,mLastPausedActivity保存堆棧頂端的Activity,因為當前不是休眠狀態,所以mLastPausedActivity為null。
有了這些信息之后,下面的語句就容易理解了:
~~~
// If the top activity is the resumed one, nothing to do.
if (mResumedActivity == next && next.state == ActivityState.RESUMED) {
......
}
// If we are sleeping, and there is no resumed activity, and the top
// activity is paused, well that is the state we want.
if ((mService.mSleeping || mService.mShuttingDown)
&& mLastPausedActivity == next && next.state == ActivityState.PAUSED) {
......
}
~~~
它首先看要啟動的Activity是否就是當前處理Resumed狀態的Activity,如果是的話,那就什么都不用做,直接返回就可以了;否則再看一下系統當前是否休眠狀態,如果是的話,再看看要啟動的Activity是否就是當前處于堆棧頂端的Activity,如果是的話,也是什么都不用做。
上面兩個條件都不滿足,因此,在繼續往下執行之前,首先要把當處于Resumed狀態的Activity推入Paused狀態,然后才可以啟動新的Activity。但是在將當前這個Resumed狀態的Activity推入Paused狀態之前,首先要看一下當前是否有Activity正在進入Pausing狀態,如果有的話,當前這個Resumed狀態的Activity就要稍后才能進入Paused狀態了,這樣就保證了所有需要進入Paused狀態的Activity串行處理。
這里沒有處于Pausing狀態的Activity,即mPausingActivity為null,而且mResumedActivity也不為null,于是就調用startPausingLocked函數把Launcher推入Paused狀態去了。
**Step 11. ActivityStack.startPausingLocked**
這個函數定義在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:
~~~
public class ActivityStack {
......
private final void startPausingLocked(boolean userLeaving, boolean uiSleeping) {
if (mPausingActivity != null) {
......
}
ActivityRecord prev = mResumedActivity;
if (prev == null) {
......
}
......
mResumedActivity = null;
mPausingActivity = prev;
mLastPausedActivity = prev;
prev.state = ActivityState.PAUSING;
......
if (prev.app != null && prev.app.thread != null) {
......
try {
......
prev.app.thread.schedulePauseActivity(prev, prev.finishing, userLeaving,
prev.configChangeFlags);
......
} catch (Exception e) {
......
}
} else {
......
}
......
}
......
}
~~~
函數首先把mResumedActivity保存在本地變量prev中。在上一步Step 10中,說到mResumedActivity就是Launcher,因此,這里把Launcher進程中的ApplicationThread對象取出來,通過它來通知Launcher這個Activity它要進入Paused狀態了。當然,這里的prev.app.thread是一個ApplicationThread對象的遠程接口,通過調用這個遠程接口的schedulePauseActivity來通知Launcher進入Paused狀態。
參數prev.finishing表示prev所代表的Activity是否正在等待結束的Activity列表中,由于Laucher這個Activity還沒結束,所以這里為false;參數prev.configChangeFlags表示哪些config發生了變化,這里我們不關心它的值。
**Step 12. ApplicationThreadProxy.schedulePauseActivity**
這個函數定義在frameworks/base/core/java/android/app/ApplicationThreadNative.java文件中:
~~~
class ApplicationThreadProxy implements IApplicationThread {
......
public final void schedulePauseActivity(IBinder token, boolean finished,
boolean userLeaving, int configChanges) throws RemoteException {
Parcel data = Parcel.obtain();
data.writeInterfaceToken(IApplicationThread.descriptor);
data.writeStrongBinder(token);
data.writeInt(finished ? 1 : 0);
data.writeInt(userLeaving ? 1 :0);
data.writeInt(configChanges);
mRemote.transact(SCHEDULE_PAUSE_ACTIVITY_TRANSACTION, data, null,
IBinder.FLAG_ONEWAY);
data.recycle();
}
......
}
~~~
這個函數通過Binder進程間通信機制進入到ApplicationThread.schedulePauseActivity函數中。
**Step 13. ApplicationThread.schedulePauseActivity**
這個函數定義在frameworks/base/core/java/android/app/ActivityThread.java文件中,它是ActivityThread的內部類:
~~~
public final class ActivityThread {
......
private final class ApplicationThread extends ApplicationThreadNative {
......
public final void schedulePauseActivity(IBinder token, boolean finished,
boolean userLeaving, int configChanges) {
queueOrSendMessage(
finished ? H.PAUSE_ACTIVITY_FINISHING : H.PAUSE_ACTIVITY,
token,
(userLeaving ? 1 : 0),
configChanges);
}
......
}
......
}
~~~
這里調用的函數queueOrSendMessage是ActivityThread類的成員函數。
上面說到,這里的finished值為false,因此,queueOrSendMessage的第一個參數值為H.PAUSE_ACTIVITY,表示要暫停token所代表的Activity,即Launcher。
**Step 14. ActivityThread.queueOrSendMessage**
這個函數定義在frameworks/base/core/java/android/app/ActivityThread.java文件中:
~~~
public final class ActivityThread {
......
private final void queueOrSendMessage(int what, Object obj, int arg1) {
queueOrSendMessage(what, obj, arg1, 0);
}
private final void queueOrSendMessage(int what, Object obj, int arg1, int arg2) {
synchronized (this) {
......
Message msg = Message.obtain();
msg.what = what;
msg.obj = obj;
msg.arg1 = arg1;
msg.arg2 = arg2;
mH.sendMessage(msg);
}
}
......
}
~~~
這里首先將相關信息組裝成一個msg,然后通過mH成員變量發送出去,mH的類型是H,繼承于Handler類,是ActivityThread的內部類,因此,這個消息最后由H.handleMessage來處理。
**Step 15. H.handleMessage**
這個函數定義在frameworks/base/core/java/android/app/ActivityThread.java文件中:
~~~
public final class ActivityThread {
......
private final class H extends Handler {
......
public void handleMessage(Message msg) {
......
switch (msg.what) {
......
case PAUSE_ACTIVITY:
handlePauseActivity((IBinder)msg.obj, false, msg.arg1 != 0, msg.arg2);
maybeSnapshot();
break;
......
}
......
}
......
}
~~~
這里調用ActivityThread.handlePauseActivity進一步操作,msg.obj是一個ActivityRecord對象的引用,它代表的是Launcher這個Activity。
**Step 16. ActivityThread.handlePauseActivity**
這個函數定義在frameworks/base/core/java/android/app/ActivityThread.java文件中:
~~~
public final class ActivityThread {
......
private final void handlePauseActivity(IBinder token, boolean finished,
boolean userLeaving, int configChanges) {
ActivityClientRecord r = mActivities.get(token);
if (r != null) {
//Slog.v(TAG, "userLeaving=" + userLeaving + " handling pause of " + r);
if (userLeaving) {
performUserLeavingActivity(r);
}
r.activity.mConfigChangeFlags |= configChanges;
Bundle state = performPauseActivity(token, finished, true);
// Make sure any pending writes are now committed.
QueuedWork.waitToFinish();
// Tell the activity manager we have paused.
try {
ActivityManagerNative.getDefault().activityPaused(token, state);
} catch (RemoteException ex) {
}
}
}
......
}
~~~
函數首先將Binder引用token轉換成ActivityRecord的遠程接口ActivityClientRecord,然后做了三個事情:1. 如果userLeaving為true,則通過調用performUserLeavingActivity函數來調用Activity.onUserLeaveHint通知Activity,用戶要離開它了;2. 調用performPauseActivity函數來調用Activity.onPause函數,我們知道,在Activity的生命周期中,當它要讓位于其它的Activity時,系統就會調用它的onPause函數;3. 它通知ActivityManagerService,這個Activity已經進入Paused狀態了,ActivityManagerService現在可以完成未竟的事情,即啟動MainActivity了。
**Step 17. ActivityManagerProxy.activityPaused**
這個函數定義在frameworks/base/core/java/android/app/ActivityManagerNative.java文件中:
~~~
class ActivityManagerProxy implements IActivityManager
{
......
public void activityPaused(IBinder token, Bundle state) throws RemoteException
{
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IActivityManager.descriptor);
data.writeStrongBinder(token);
data.writeBundle(state);
mRemote.transact(ACTIVITY_PAUSED_TRANSACTION, data, reply, 0);
reply.readException();
data.recycle();
reply.recycle();
}
......
}
~~~
這里通過Binder進程間通信機制就進入到ActivityManagerService.activityPaused函數中去了。
**Step 18. ActivityManagerService.activityPaused**
這個函數定義在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中:
~~~
public final class ActivityManagerService extends ActivityManagerNative
implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
......
public final void activityPaused(IBinder token, Bundle icicle) {
......
final long origId = Binder.clearCallingIdentity();
mMainStack.activityPaused(token, icicle, false);
......
}
......
}
~~~
這里,又再次進入到ActivityStack類中,執行activityPaused函數。
**Step 19. ActivityStack.activityPaused**
這個函數定義在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:
~~~
public class ActivityStack {
......
final void activityPaused(IBinder token, Bundle icicle, boolean timeout) {
......
ActivityRecord r = null;
synchronized (mService) {
int index = indexOfTokenLocked(token);
if (index >= 0) {
r = (ActivityRecord)mHistory.get(index);
if (!timeout) {
r.icicle = icicle;
r.haveState = true;
}
mHandler.removeMessages(PAUSE_TIMEOUT_MSG, r);
if (mPausingActivity == r) {
r.state = ActivityState.PAUSED;
completePauseLocked();
} else {
......
}
}
}
}
......
}
~~~
這里通過參數token在mHistory列表中得到ActivityRecord,從上面我們知道,這個ActivityRecord代表的是Launcher這個Activity,而我們在Step 11中,把Launcher這個Activity的信息保存在mPausingActivity中,因此,這里mPausingActivity等于r,于是,執行completePauseLocked操作。
**Step 20. ActivityStack.completePauseLocked**
這個函數定義在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:
~~~
public class ActivityStack {
......
private final void completePauseLocked() {
ActivityRecord prev = mPausingActivity;
......
if (prev != null) {
......
mPausingActivity = null;
}
if (!mService.mSleeping && !mService.mShuttingDown) {
resumeTopActivityLocked(prev);
} else {
......
}
......
}
......
}
~~~
函數首先把mPausingActivity變量清空,因為現在不需要它了,然后調用resumeTopActivityLokced進一步操作,它傳入的參數即為代表Launcher這個Activity的ActivityRecord。
**Step 21. ActivityStack.resumeTopActivityLokced**
這個函數定義在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:
~~~
public class ActivityStack {
......
final boolean resumeTopActivityLocked(ActivityRecord prev) {
......
// Find the first activity that is not finishing.
ActivityRecord next = topRunningActivityLocked(null);
// Remember how we'll process this pause/resume situation, and ensure
// that the state is reset however we wind up proceeding.
final boolean userLeaving = mUserLeaving;
mUserLeaving = false;
......
next.delayedResume = false;
// If the top activity is the resumed one, nothing to do.
if (mResumedActivity == next && next.state == ActivityState.RESUMED) {
......
return false;
}
// If we are sleeping, and there is no resumed activity, and the top
// activity is paused, well that is the state we want.
if ((mService.mSleeping || mService.mShuttingDown)
&& mLastPausedActivity == next && next.state == ActivityState.PAUSED) {
......
return false;
}
.......
// We need to start pausing the current activity so the top one
// can be resumed...
if (mResumedActivity != null) {
......
return true;
}
......
if (next.app != null && next.app.thread != null) {
......
} else {
......
startSpecificActivityLocked(next, true, true);
}
return true;
}
......
}
~~~
通過上面的Step 9,我們知道,當前在堆棧頂端的Activity為我們即將要啟動的MainActivity,這里通過調用topRunningActivityLocked將它取回來,保存在next變量中。之前最后一個Resumed狀態的Activity,即Launcher,到了這里已經處于Paused狀態了,因此,mResumedActivity為null。最后一個處于Paused狀態的Activity為Launcher,因此,這里的mLastPausedActivity就為Launcher。前面我們為MainActivity創建了ActivityRecord后,它的app域一直保持為null。有了這些信息后,上面這段代碼就容易理解了,它最終調用startSpecificActivityLocked進行下一步操作。
**Step 22. ActivityStack.startSpecificActivityLocked**
這個函數定義在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:
~~~
public class ActivityStack {
......
private final void startSpecificActivityLocked(ActivityRecord r,
boolean andResume, boolean checkConfig) {
// Is this activity's application already running?
ProcessRecord app = mService.getProcessRecordLocked(r.processName,
r.info.applicationInfo.uid);
......
if (app != null && app.thread != null) {
try {
realStartActivityLocked(r, app, andResume, checkConfig);
return;
} catch (RemoteException e) {
......
}
}
mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0,
"activity", r.intent.getComponent(), false);
}
......
}
~~~
注意,這里由于是第一次啟動應用程序的Activity,所以下面語句:
~~~
ProcessRecord app = mService.getProcessRecordLocked(r.processName,
r.info.applicationInfo.uid);
~~~
取回來的app為null。在Activity應用程序中的AndroidManifest.xml配置文件中,我們沒有指定Application標簽的process屬性,系統就會默認使用package的名稱,這里就是"shy.luo.activity"了。每一個應用程序都有自己的uid,因此,這里uid + process的組合就可以為每一個應用程序創建一個ProcessRecord。當然,我們可以配置兩個應用程序具有相同的uid和package,或者在AndroidManifest.xml配置文件的application標簽或者activity標簽中顯式指定相同的process屬性值,這樣,不同的應用程序也可以在同一個進程中啟動。
函數最終執行ActivityManagerService.startProcessLocked函數進行下一步操作。
**Step 23. ActivityManagerService.startProcessLocked**
這個函數定義在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中:
~~~
public final class ActivityManagerService extends ActivityManagerNative
implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
......
final ProcessRecord startProcessLocked(String processName,
ApplicationInfo info, boolean knownToBeDead, int intentFlags,
String hostingType, ComponentName hostingName, boolean allowWhileBooting) {
ProcessRecord app = getProcessRecordLocked(processName, info.uid);
......
String hostingNameStr = hostingName != null
? hostingName.flattenToShortString() : null;
......
if (app == null) {
app = new ProcessRecordLocked(null, info, processName);
mProcessNames.put(processName, info.uid, app);
} else {
// If this is a new package in the process, add the package to the list
app.addPackage(info.packageName);
}
......
startProcessLocked(app, hostingType, hostingNameStr);
return (app.pid != 0) ? app : null;
}
......
}
~~~
這里再次檢查是否已經有以process + uid命名的進程存在,在我們這個情景中,返回值app為null,因此,后面會創建一個ProcessRecord,并存保存在成員變量mProcessNames中,最后,調用另一個startProcessLocked函數進一步操作:
~~~
public final class ActivityManagerService extends ActivityManagerNative
implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
......
private final void startProcessLocked(ProcessRecord app,
String hostingType, String hostingNameStr) {
......
try {
int uid = app.info.uid;
int[] gids = null;
try {
gids = mContext.getPackageManager().getPackageGids(
app.info.packageName);
} catch (PackageManager.NameNotFoundException e) {
......
}
......
int debugFlags = 0;
......
int pid = Process.start("android.app.ActivityThread",
mSimpleProcessManagement ? app.processName : null, uid, uid,
gids, debugFlags, null);
......
} catch (RuntimeException e) {
......
}
}
......
}
~~~
這里主要是調用Process.start接口來創建一個新的進程,新的進程會導入android.app.ActivityThread類,并且執行它的main函數,這就是為什么我們前面說每一個應用程序都有一個ActivityThread實例來對應的原因。
**Step 24. ActivityThread.main**
這個函數定義在frameworks/base/core/java/android/app/ActivityThread.java文件中:
~~~
public final class ActivityThread {
......
private final void attach(boolean system) {
......
mSystemThread = system;
if (!system) {
......
IActivityManager mgr = ActivityManagerNative.getDefault();
try {
mgr.attachApplication(mAppThread);
} catch (RemoteException ex) {
}
} else {
......
}
}
......
public static final void main(String[] args) {
.......
ActivityThread thread = new ActivityThread();
thread.attach(false);
......
Looper.loop();
.......
thread.detach();
......
}
}
~~~
這個函數在進程中創建一個ActivityThread實例,然后調用它的attach函數,接著就進入消息循環了,直到最后進程退出。
函數attach最終調用了ActivityManagerService的遠程接口ActivityManagerProxy的attachApplication函數,傳入的參數是mAppThread,這是一個ApplicationThread類型的Binder對象,它的作用是用來進行進程間通信的。
**Step 25. ActivityManagerProxy.attachApplication**
這個函數定義在frameworks/base/core/java/android/app/ActivityManagerNative.java文件中:
~~~
class ActivityManagerProxy implements IActivityManager
{
......
public void attachApplication(IApplicationThread app) throws RemoteException
{
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IActivityManager.descriptor);
data.writeStrongBinder(app.asBinder());
mRemote.transact(ATTACH_APPLICATION_TRANSACTION, data, reply, 0);
reply.readException();
data.recycle();
reply.recycle();
}
......
}
~~~
這里通過Binder驅動程序,最后進入ActivityManagerService的attachApplication函數中。
**Step 26. ActivityManagerService.attachApplication**
這個函數定義在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中:
~~~
public final class ActivityManagerService extends ActivityManagerNative
implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
......
public final void attachApplication(IApplicationThread thread) {
synchronized (this) {
int callingPid = Binder.getCallingPid();
final long origId = Binder.clearCallingIdentity();
attachApplicationLocked(thread, callingPid);
Binder.restoreCallingIdentity(origId);
}
}
......
}
~~~
這里將操作轉發給attachApplicationLocked函數。
**Step 27. ActivityManagerService.attachApplicationLocked**
這個函數定義在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中:
~~~
public final class ActivityManagerService extends ActivityManagerNative
implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
......
private final boolean attachApplicationLocked(IApplicationThread thread,
int pid) {
// Find the application record that is being attached... either via
// the pid if we are running in multiple processes, or just pull the
// next app record if we are emulating process with anonymous threads.
ProcessRecord app;
if (pid != MY_PID && pid >= 0) {
synchronized (mPidsSelfLocked) {
app = mPidsSelfLocked.get(pid);
}
} else if (mStartingProcesses.size() > 0) {
......
} else {
......
}
if (app == null) {
......
return false;
}
......
String processName = app.processName;
try {
thread.asBinder().linkToDeath(new AppDeathRecipient(
app, pid, thread), 0);
} catch (RemoteException e) {
......
return false;
}
......
app.thread = thread;
app.curAdj = app.setAdj = -100;
app.curSchedGroup = Process.THREAD_GROUP_DEFAULT;
app.setSchedGroup = Process.THREAD_GROUP_BG_NONINTERACTIVE;
app.forcingToForeground = null;
app.foregroundServices = false;
app.debugging = false;
......
boolean normalMode = mProcessesReady || isAllowedWhileBooting(app.info);
......
boolean badApp = false;
boolean didSomething = false;
// See if the top visible activity is waiting to run in this process...
ActivityRecord hr = mMainStack.topRunningActivityLocked(null);
if (hr != null && normalMode) {
if (hr.app == null && app.info.uid == hr.info.applicationInfo.uid
&& processName.equals(hr.processName)) {
try {
if (mMainStack.realStartActivityLocked(hr, app, true, true)) {
didSomething = true;
}
} catch (Exception e) {
......
}
} else {
......
}
}
......
return true;
}
......
}
~~~
在前面的Step 23中,已經創建了一個ProcessRecord,這里首先通過pid將它取回來,放在app變量中,然后對app的其它成員進行初始化,最后調用mMainStack.realStartActivityLocked執行真正的Activity啟動操作。這里要啟動的Activity通過調用mMainStack.topRunningActivityLocked(null)從堆棧頂端取回來,這時候在堆棧頂端的Activity就是MainActivity了。
**Step 28. ActivityStack.realStartActivityLocked**
這個函數定義在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:
~~~
public class ActivityStack {
......
final boolean realStartActivityLocked(ActivityRecord r,
ProcessRecord app, boolean andResume, boolean checkConfig)
throws RemoteException {
......
r.app = app;
......
int idx = app.activities.indexOf(r);
if (idx < 0) {
app.activities.add(r);
}
......
try {
......
List<ResultInfo> results = null;
List<Intent> newIntents = null;
if (andResume) {
results = r.results;
newIntents = r.newIntents;
}
......
app.thread.scheduleLaunchActivity(new Intent(r.intent), r,
System.identityHashCode(r),
r.info, r.icicle, results, newIntents, !andResume,
mService.isNextTransitionForward());
......
} catch (RemoteException e) {
......
}
......
return true;
}
......
}
~~~
這里最終通過app.thread進入到ApplicationThreadProxy的scheduleLaunchActivity函數中,注意,這里的第二個參數r,是一個ActivityRecord類型的Binder對象,用來作來這個Activity的token值。
**Step 29. ApplicationThreadProxy.scheduleLaunchActivity**
這個函數定義在frameworks/base/core/java/android/app/ApplicationThreadNative.java文件中:
~~~
class ApplicationThreadProxy implements IApplicationThread {
......
public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
ActivityInfo info, Bundle state, List<ResultInfo> pendingResults,
List<Intent> pendingNewIntents, boolean notResumed, boolean isForward)
throws RemoteException {
Parcel data = Parcel.obtain();
data.writeInterfaceToken(IApplicationThread.descriptor);
intent.writeToParcel(data, 0);
data.writeStrongBinder(token);
data.writeInt(ident);
info.writeToParcel(data, 0);
data.writeBundle(state);
data.writeTypedList(pendingResults);
data.writeTypedList(pendingNewIntents);
data.writeInt(notResumed ? 1 : 0);
data.writeInt(isForward ? 1 : 0);
mRemote.transact(SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION, data, null,
IBinder.FLAG_ONEWAY);
data.recycle();
}
......
}
~~~
這個函數最終通過Binder驅動程序進入到ApplicationThread的scheduleLaunchActivity函數中。
**Step 30. ApplicationThread.scheduleLaunchActivity**
這個函數定義在frameworks/base/core/java/android/app/ActivityThread.java文件中:
~~~
public final class ActivityThread {
......
private final class ApplicationThread extends ApplicationThreadNative {
......
// we use token to identify this activity without having to send the
// activity itself back to the activity manager. (matters more with ipc)
public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
ActivityInfo info, Bundle state, List<ResultInfo> pendingResults,
List<Intent> pendingNewIntents, boolean notResumed, boolean isForward) {
ActivityClientRecord r = new ActivityClientRecord();
r.token = token;
r.ident = ident;
r.intent = intent;
r.activityInfo = info;
r.state = state;
r.pendingResults = pendingResults;
r.pendingIntents = pendingNewIntents;
r.startsNotResumed = notResumed;
r.isForward = isForward;
queueOrSendMessage(H.LAUNCH_ACTIVITY, r);
}
......
}
......
}
~~~
函數首先創建一個ActivityClientRecord實例,并且初始化它的成員變量,然后調用ActivityThread類的queueOrSendMessage函數進一步處理。
**Step 31. ActivityThread.queueOrSendMessage**
這個函數定義在frameworks/base/core/java/android/app/ActivityThread.java文件中:
~~~
public final class ActivityThread {
......
private final class ApplicationThread extends ApplicationThreadNative {
......
// if the thread hasn't started yet, we don't have the handler, so just
// save the messages until we're ready.
private final void queueOrSendMessage(int what, Object obj) {
queueOrSendMessage(what, obj, 0, 0);
}
......
private final void queueOrSendMessage(int what, Object obj, int arg1, int arg2) {
synchronized (this) {
......
Message msg = Message.obtain();
msg.what = what;
msg.obj = obj;
msg.arg1 = arg1;
msg.arg2 = arg2;
mH.sendMessage(msg);
}
}
......
}
......
}
~~~
函數把消息內容放在msg中,然后通過mH把消息分發出去,這里的成員變量mH我們在前面已經見過,消息分發出去后,最后會調用H類的handleMessage函數。
**Step 32. H.handleMessage**
這個函數定義在frameworks/base/core/java/android/app/ActivityThread.java文件中:
~~~
public final class ActivityThread {
......
private final class H extends Handler {
......
public void handleMessage(Message msg) {
......
switch (msg.what) {
case LAUNCH_ACTIVITY: {
ActivityClientRecord r = (ActivityClientRecord)msg.obj;
r.packageInfo = getPackageInfoNoCheck(
r.activityInfo.applicationInfo);
handleLaunchActivity(r, null);
} break;
......
}
......
}
......
}
~~~
這里最后調用ActivityThread類的handleLaunchActivity函數進一步處理。
**Step 33. ActivityThread.handleLaunchActivity**
這個函數定義在frameworks/base/core/java/android/app/ActivityThread.java文件中:
~~~
public final class ActivityThread {
......
private final void handleLaunchActivity(ActivityClientRecord r, Intent customIntent) {
......
Activity a = performLaunchActivity(r, customIntent);
if (a != null) {
r.createdConfig = new Configuration(mConfiguration);
Bundle oldState = r.state;
handleResumeActivity(r.token, false, r.isForward);
......
} else {
......
}
}
......
}
~~~
這里首先調用performLaunchActivity函數來加載這個Activity類,即shy.luo.activity.MainActivity,然后調用它的onCreate函數,最后回到handleLaunchActivity函數時,再調用handleResumeActivity函數來使這個Activity進入Resumed狀態,即會調用這個Activity的onResume函數,這是遵循Activity的生命周期的。
**Step 34. ActivityThread.performLaunchActivity**
這個函數定義在frameworks/base/core/java/android/app/ActivityThread.java文件中:
~~~
public final class ActivityThread {
......
private final Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
ActivityInfo aInfo = r.activityInfo;
if (r.packageInfo == null) {
r.packageInfo = getPackageInfo(aInfo.applicationInfo,
Context.CONTEXT_INCLUDE_CODE);
}
ComponentName component = r.intent.getComponent();
if (component == null) {
component = r.intent.resolveActivity(
mInitialApplication.getPackageManager());
r.intent.setComponent(component);
}
if (r.activityInfo.targetActivity != null) {
component = new ComponentName(r.activityInfo.packageName,
r.activityInfo.targetActivity);
}
Activity activity = null;
try {
java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
r.intent.setExtrasClassLoader(cl);
if (r.state != null) {
r.state.setClassLoader(cl);
}
} catch (Exception e) {
......
}
try {
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
......
if (activity != null) {
ContextImpl appContext = new ContextImpl();
appContext.init(r.packageInfo, r.token, this);
appContext.setOuterContext(activity);
CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager());
Configuration config = new Configuration(mConfiguration);
......
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstance,
r.lastNonConfigurationChildInstances, config);
if (customIntent != null) {
activity.mIntent = customIntent;
}
r.lastNonConfigurationInstance = null;
r.lastNonConfigurationChildInstances = null;
activity.mStartedActivity = false;
int theme = r.activityInfo.getThemeResource();
if (theme != 0) {
activity.setTheme(theme);
}
activity.mCalled = false;
mInstrumentation.callActivityOnCreate(activity, r.state);
......
r.activity = activity;
r.stopped = true;
if (!r.activity.mFinished) {
activity.performStart();
r.stopped = false;
}
if (!r.activity.mFinished) {
if (r.state != null) {
mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state);
}
}
if (!r.activity.mFinished) {
activity.mCalled = false;
mInstrumentation.callActivityOnPostCreate(activity, r.state);
if (!activity.mCalled) {
throw new SuperNotCalledException(
"Activity " + r.intent.getComponent().toShortString() +
" did not call through to super.onPostCreate()");
}
}
}
r.paused = true;
mActivities.put(r.token, r);
} catch (SuperNotCalledException e) {
......
} catch (Exception e) {
......
}
return activity;
}
......
}
~~~
函數前面是收集要啟動的Activity的相關信息,主要package和component信息:
~~~
ActivityInfo aInfo = r.activityInfo;
if (r.packageInfo == null) {
r.packageInfo = getPackageInfo(aInfo.applicationInfo,
Context.CONTEXT_INCLUDE_CODE);
}
ComponentName component = r.intent.getComponent();
if (component == null) {
component = r.intent.resolveActivity(
mInitialApplication.getPackageManager());
r.intent.setComponent(component);
}
if (r.activityInfo.targetActivity != null) {
component = new ComponentName(r.activityInfo.packageName,
r.activityInfo.targetActivity);
}
~~~
然后通過ClassLoader將shy.luo.activity.MainActivity類加載進來:
~~~
Activity activity = null;
try {
java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
r.intent.setExtrasClassLoader(cl);
if (r.state != null) {
r.state.setClassLoader(cl);
}
} catch (Exception e) {
......
}
~~~
接下來是創建Application對象,這是根據AndroidManifest.xml配置文件中的Application標簽的信息來創建的:
~~~
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
~~~
后面的代碼主要創建Activity的上下文信息,并通過attach方法將這些上下文信息設置到MainActivity中去:
~~~
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstance,
r.lastNonConfigurationChildInstances, config);
~~~
最后還要調用MainActivity的onCreate函數:
~~~
mInstrumentation.callActivityOnCreate(activity, r.state);
~~~
這里不是直接調用MainActivity的onCreate函數,而是通過mInstrumentation的callActivityOnCreate函數來間接調用,前面我們說過,mInstrumentation在這里的作用是監控Activity與系統的交互操作,相當于是系統運行日志。
**Step 35. MainActivity.onCreate**
這個函數定義在packages/experimental/Activity/src/shy/luo/activity/MainActivity.java文件中,這是我們自定義的app工程文件:
~~~
public class MainActivity extends Activity implements OnClickListener {
......
@Override
public void onCreate(Bundle savedInstanceState) {
......
Log.i(LOG_TAG, "Main Activity Created.");
}
......
}
~~~
這樣,MainActivity就啟動起來了,整個應用程序也啟動起來了。
整個應用程序的啟動過程要執行很多步驟,但是整體來看,主要分為以下五個階段:
* 一. Step1 - Step 11:Launcher通過Binder進程間通信機制通知ActivityManagerService,它要啟動一個Activity;
* 二. Step 12 - Step 16:ActivityManagerService通過Binder進程間通信機制通知Launcher進入Paused狀態;
* 三. Step 17 - Step 24:Launcher通過Binder進程間通信機制通知ActivityManagerService,它已經準備就緒進入Paused狀態,于是ActivityManagerService就創建一個新的進程,用來啟動一個ActivityThread實例,即將要啟動的Activity就是在這個ActivityThread實例中運行;
* 四. Step 25 - Step 27:ActivityThread通過Binder進程間通信機制將一個ApplicationThread類型的Binder對象傳遞給ActivityManagerService,以便以后ActivityManagerService能夠通過這個Binder對象和它進行通信;
* 五. Step 28 - Step 35:ActivityManagerService通過Binder進程間通信機制通知ActivityThread,現在一切準備就緒,它可以真正執行Activity的啟動操作了。
這里不少地方涉及到了Binder進程間通信機制,相關資料請參考Android進程間通信(IPC)機制Binder簡要介紹和學習計劃一文。
這樣,應用程序的啟動過程就介紹完了,它實質上是啟動應用程序的默認Activity,在下一篇文章中,我們將介紹在應用程序內部啟動另一個Activity的過程,即新的Activity與啟動它的Activity將會在同一個進程(Process)和任務(Task)運行,敬請關注。
- 前言
- Android組件設計思想
- Android源代碼開發和調試環境搭建
- Android源代碼下載和編譯
- Android源代碼情景分析法
- Android源代碼調試分析法
- 手把手教你為手機編譯ROM
- 在Ubuntu上下載、編譯和安裝Android最新源代碼
- 在Ubuntu上下載、編譯和安裝Android最新內核源代碼(Linux Kernel)
- 如何單獨編譯Android源代碼中的模塊
- 在Ubuntu上為Android系統編寫Linux內核驅動程序
- 在Ubuntu上為Android系統內置C可執行程序測試Linux內核驅動程序
- 在Ubuntu上為Android增加硬件抽象層(HAL)模塊訪問Linux內核驅動程序
- 在Ubuntu為Android硬件抽象層(HAL)模塊編寫JNI方法提供Java訪問硬件服務接口
- 在Ubuntu上為Android系統的Application Frameworks層增加硬件訪問服務
- 在Ubuntu上為Android系統內置Java應用程序測試Application Frameworks層的硬件服務
- Android源代碼倉庫及其管理工具Repo分析
- Android編譯系統簡要介紹和學習計劃
- Android編譯系統環境初始化過程分析
- Android源代碼編譯命令m/mm/mmm/make分析
- Android系統鏡像文件的打包過程分析
- 從CM刷機過程和原理分析Android系統結構
- Android系統架構概述
- Android系統整體架構
- android專用驅動
- Android硬件抽象層HAL
- Android應用程序組件
- Android應用程序框架
- Android用戶界面架構
- Android虛擬機之Dalvik虛擬機
- Android硬件抽象層
- Android硬件抽象層(HAL)概要介紹和學習計劃
- Android專用驅動
- Android Logger驅動系統
- Android日志系統驅動程序Logger源代碼分析
- Android應用程序框架層和系統運行庫層日志系統源代碼分析
- Android日志系統Logcat源代碼簡要分析
- Android Binder驅動系統
- Android進程間通信(IPC)機制Binder簡要介紹和學習計劃
- 淺談Service Manager成為Android進程間通信(IPC)機制Binder守護進程之路
- 淺談Android系統進程間通信(IPC)機制Binder中的Server和Client獲得Service Manager接口之路
- Android系統進程間通信(IPC)機制Binder中的Server啟動過程源代碼分析
- Android系統進程間通信(IPC)機制Binder中的Client獲得Server遠程接口過程源代碼分析
- Android系統進程間通信Binder機制在應用程序框架層的Java接口源代碼分析
- Android Ashmem驅動系統
- Android系統匿名共享內存Ashmem(Anonymous Shared Memory)簡要介紹和學習計劃
- Android系統匿名共享內存Ashmem(Anonymous Shared Memory)驅動程序源代碼分析
- Android系統匿名共享內存Ashmem(Anonymous Shared Memory)在進程間共享的原理分析
- Android系統匿名共享內存(Anonymous Shared Memory)C++調用接口分析
- Android應用程序進程管理
- Android應用程序進程啟動過程的源代碼分析
- Android系統進程Zygote啟動過程的源代碼分析
- Android系統默認Home應用程序(Launcher)的啟動過程源代碼分析
- Android應用程序消息機制
- Android應用程序消息處理機制(Looper、Handler)分析
- Android應用程序線程消息循環模型分析
- Android應用程序輸入事件分發和處理機制
- Android應用程序鍵盤(Keyboard)消息處理機制分析
- Android應用程序UI架構
- Android系統的開機畫面顯示過程分析
- Android幀緩沖區(Frame Buffer)硬件抽象層(HAL)模塊Gralloc的實現原理分析
- SurfaceFlinger
- Android系統Surface機制的SurfaceFlinger服務
- SurfaceFlinger服務簡要介紹和學習計劃
- 啟動過程分析
- 對幀緩沖區(Frame Buffer)的管理分析
- 線程模型分析
- 渲染應用程序UI的過程分析
- Android應用程序與SurfaceFlinger服務的關系
- 概述和學習計劃
- 連接過程分析
- 共享UI元數據(SharedClient)的創建過程分析
- 創建Surface的過程分析
- 渲染Surface的過程分析
- Android應用程序窗口(Activity)
- 實現框架簡要介紹和學習計劃
- 運行上下文環境(Context)的創建過程分析
- 窗口對象(Window)的創建過程分析
- 視圖對象(View)的創建過程分析
- 與WindowManagerService服務的連接過程分析
- 繪圖表面(Surface)的創建過程分析
- 測量(Measure)、布局(Layout)和繪制(Draw)過程分析
- WindowManagerService
- WindowManagerService的簡要介紹和學習計劃
- 計算Activity窗口大小的過程分析
- 對窗口的組織方式分析
- 對輸入法窗口(Input Method Window)的管理分析
- 對壁紙窗口(Wallpaper Window)的管理分析
- 計算窗口Z軸位置的過程分析
- 顯示Activity組件的啟動窗口(Starting Window)的過程分析
- 切換Activity窗口(App Transition)的過程分析
- 顯示窗口動畫的原理分析
- Android控件TextView的實現原理分析
- Android視圖SurfaceView的實現原理分析
- Android應用程序UI硬件加速渲染
- 簡要介紹和學習計劃
- 環境初始化過程分析
- 預加載資源地圖集服務(Asset Atlas Service)分析
- Display List構建過程分析
- Display List渲染過程分析
- 動畫執行過程分析
- Android應用程序資源管理框架
- Android資源管理框架(Asset Manager)
- Asset Manager 簡要介紹和學習計劃
- 編譯和打包過程分析
- Asset Manager的創建過程分析
- 查找過程分析
- Dalvik虛擬機和ART虛擬機
- Dalvik虛擬機
- Dalvik虛擬機簡要介紹和學習計劃
- Dalvik虛擬機的啟動過程分析
- Dalvik虛擬機的運行過程分析
- Dalvik虛擬機JNI方法的注冊過程分析
- Dalvik虛擬機進程和線程的創建過程分析
- Dalvik虛擬機垃圾收集機制簡要介紹和學習計劃
- Dalvik虛擬機Java堆創建過程分析
- Dalvik虛擬機為新創建對象分配內存的過程分析
- Dalvik虛擬機垃圾收集(GC)過程分析
- ART虛擬機
- Android ART運行時無縫替換Dalvik虛擬機的過程分析
- Android運行時ART簡要介紹和學習計劃
- Android運行時ART加載OAT文件的過程分析
- Android運行時ART加載類和方法的過程分析
- Android運行時ART執行類方法的過程分析
- ART運行時垃圾收集機制簡要介紹和學習計劃
- ART運行時Java堆創建過程分析
- ART運行時為新創建對象分配內存的過程分析
- ART運行時垃圾收集(GC)過程分析
- ART運行時Compacting GC簡要介紹和學習計劃
- ART運行時Compacting GC堆創建過程分析
- ART運行時Compacting GC為新創建對象分配內存的過程分析
- ART運行時Semi-Space(SS)和Generational Semi-Space(GSS)GC執行過程分析
- ART運行時Mark-Compact( MC)GC執行過程分析
- ART運行時Foreground GC和Background GC切換過程分析
- Android安全機制
- SEAndroid安全機制簡要介紹和學習計劃
- SEAndroid安全機制框架分析
- SEAndroid安全機制中的文件安全上下文關聯分析
- SEAndroid安全機制中的進程安全上下文關聯分析
- SEAndroid安全機制對Android屬性訪問的保護分析
- SEAndroid安全機制對Binder IPC的保護分析
- 從NDK在非Root手機上的調試原理探討Android的安全機制
- APK防反編譯
- Android視頻硬解穩定性問題探討和處理
- Android系統的智能指針(輕量級指針、強指針和弱指針)的實現原理分析
- Android應用程序安裝過程源代碼分析
- Android應用程序啟動過程源代碼分析
- 四大組件源代碼分析
- Activity
- Android應用程序的Activity啟動過程簡要介紹和學習計劃
- Android應用程序內部啟動Activity過程(startActivity)的源代碼分析
- 解開Android應用程序組件Activity的"singleTask"之謎
- Android應用程序在新的進程中啟動新的Activity的方法和過程分析
- Service
- Android應用程序綁定服務(bindService)的過程源代碼分析
- ContentProvider
- Android應用程序組件Content Provider簡要介紹和學習計劃
- Android應用程序組件Content Provider應用實例
- Android應用程序組件Content Provider的啟動過程源代碼分析
- Android應用程序組件Content Provider在應用程序之間共享數據的原理分析
- Android應用程序組件Content Provider的共享數據更新通知機制分析
- BroadcastReceiver
- Android系統中的廣播(Broadcast)機制簡要介紹和學習計劃
- Android應用程序注冊廣播接收器(registerReceiver)的過程分析
- Android應用程序發送廣播(sendBroadcast)的過程分析