溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“App的啟動流程是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
首先，new一個女兒，
var mDdaughter = new 女兒("6歲"，“漂亮可愛”，“健康乖巧”，“最喜歡玩小天才電話手表和她的爸爸”)女兒，你可以把手表里面想象成一個幼兒園，里面有一個老師，一個班長，一個班干部，以及一大堆小朋友。
一個老師：Z老師（Zygote進程）
一個班長：小A（ActivityManagerService）
一個班干部：小L（Launcher桌面應用）
一大堆小朋友：所有應用，包括音樂小朋友，聊天小朋友，日歷小朋友等等。
應用啟動過程就像一個小朋友被叫醒一樣，開機之后呢，Z老師會依次叫醒班長和班干部（SystemServer#ActivityManagerService，Launcher），小L醒了之后就會去了解手表里有哪些小朋友，長什么樣（icon，name），家庭信息（包名，androidmanifest）等等，然后一個個把小朋友的照片（icon）貼到自己的身上。比如有音樂小朋友，聊天小朋友，日歷小朋友，其實也就是你手表上這個桌面啦。
這時候你要點開一個音樂小朋友呢（startActivity），小L就會通知班長小A（Binder），小A知道了之后，讓小L自己休息下（Paused），然后就去找Z老師了。Z老師就負責叫音樂小朋友起床了（fork進程，啟動ActivityThread），音樂小朋友起來后就又找小A帶她去洗臉刷牙（啟動ApplicationThread，Activity），都弄完了就可以進行各種表演了，唱歌啊，跳舞啊
mDdaughter.grow(15)
mDdaughter.study("Android")
過了十五年，女兒已經21歲了，正在學習Android，考慮要不要女從父業。
這天，她一臉疑惑的來找我：“爸，這個app啟動到底是怎么個流程啊，我看了好久還是不大明白，要不你再跟我詳細講一遍吧？” “好嘞，別擔心，我這次詳細跟你說說”
還記得我小時候跟你說過的故事嗎，Android系統就像一個幼兒園，有一個大朋友叫Launcher，身上會貼很多其他小朋友的名片。這個Launcher就是我們的桌面了，它通過PackageManagerService獲知了系統里所有應用的信息，并展示了出來，當然它本身也是一個應用。
通過點擊一個應用圖標，也就是觸發了點擊事件，最后會執行到startActivity方法。這里也就和啟動Activity步驟重合上了。
那么這個startActivity干了啥？是怎么通過重重關卡喚醒這個應用的？
首先，介紹下系統中那些重要的成員,他們在app啟動流程中都擔任了重要的角色.
init進程，Android系統啟動后，Zygote并不是第一個進程，而是linux的根進程init進程，然后init進程才會啟動Zygote進程。Zygote進程，所有android進程的父進程，當然也包括SystemServer進程SystemServer進程，正如名字一樣，系統服務進程，負責系統中大大小小的事物，為此也是啟動了三員大將（ActivityManagerService，PackageManagerService，WindowManagerService）以及binder線程池。ActivityManagerService，主要負責系統中四大組件的啟動、切換、調度及應用進程的管理和調度等工作，對于一些進程的啟動，都會通過Binder通信機制傳遞給AMS，再處理給Zygote。PackageManagerService，主要負責應用包的一些操作，比如安裝，卸載，解析AndroidManifest.xml，掃描文件信息等等。WindowManagerService，主要負責窗口相關的一些服務，比如窗口的啟動，添加，刪除等。Launcher，桌面應用，也是屬于應用，也有自己的Activity，一開機就會默認啟動，通過設置Intent.CATEGORY_HOME的Category隱式啟動。搞清楚這些成員，就跟隨我一起看看怎么過五關斬六將，最終啟動了一個App。
首先,要告訴系統，我Launcher要啟動一個應用了，調用Activity.startActivityForResult方法，最終會轉到mInstrumentation.execStartActivity方法。由于Launcher自己處在一個單獨的進程，所以它需要跨進程告訴系統服務我要啟動App的需求。找到要通知的Service，名叫ActivityTaskManagerService，然后使用AIDL，通過Binder與他進行通信。
這里的簡單說下ActivityTaskManagerService（簡稱ATMS）。原來這些通信工作都是屬于ActivityManagerService，現在分了一部分工作給到ATMS，主要包括四大組件的調度工作。也是由SystemServer進程直接啟動的，相關源碼可見ActivityManagerService.Lifecycle.startService方法，感興趣朋友可以自己看看。
接著說跨進程通信，相關代碼如下：
//Instrumentation.java
int result = ActivityTaskManager.getService()
.startActivity(whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target != null ? target.mEmbeddedID : null,
requestCode, 0, null, options);
//ActivityTaskManager.java
public static IActivityTaskManager getService() {
return IActivityTaskManagerSingleton.get();
}
private static final Singleton<IActivityTaskManager> IActivityTaskManagerSingleton =
new Singleton<IActivityTaskManager>() {
@Override
protected IActivityTaskManager create() {
final IBinder b = ServiceManager.getService(Context.ACTIVITY_TASK_SERVICE);
return IActivityTaskManager.Stub.asInterface(b);
}
};
//ActivityTaskManagerService.java
public class ActivityTaskManagerService extends IActivityTaskManager.Stub
public static final class Lifecycle extends SystemService {
private final ActivityTaskManagerService mService;
public Lifecycle(Context context) {
super(context);
mService = new ActivityTaskManagerService(context);
}
@Override
public void onStart() {
publishBinderService(Context.ACTIVITY_TASK_SERVICE, mService);
mService.start();
}
}
startActivity我們都很熟悉，平時啟動Activity都會使用，啟動應用也是從這個方法開始的，也會同樣帶上intent信息，表示要啟動的是哪個Activity。
另外要注意的一點是，startActivity之后有個checkStartActivityResult方法，這個方法是用作檢查啟動Activity的結果。當啟動Activity失敗的時候，就會通過這個方法拋出異常，比如有我們常見的問題：未在AndroidManifest.xml注冊。
public static void checkStartActivityResult(int res, Object intent) {
switch (res) {
case ActivityManager.START_INTENT_NOT_RESOLVED:
case ActivityManager.START_CLASS_NOT_FOUND:
if (intent instanceof Intent && ((Intent)intent).getComponent() != null)
throw new ActivityNotFoundException(
"Unable to find explicit activity class "
+ ((Intent)intent).getComponent().toShortString()
+ "; have you declared this activity in your AndroidManifest.xml?");
throw new ActivityNotFoundException(
"No Activity found to handle " + intent);
case ActivityManager.START_PERMISSION_DENIED:
throw new SecurityException("Not allowed to start activity "
+ intent);
case ActivityManager.START_FORWARD_AND_REQUEST_CONFLICT:
throw new AndroidRuntimeException(
"FORWARD_RESULT_FLAG used while also requesting a result");
case ActivityManager.START_NOT_ACTIVITY:
throw new IllegalArgumentException(
"PendingIntent is not an activity");
//...
}
} ATMS收到要啟動的消息后，就會通知上一個應用，也就是Launcher可以休息會了，進入Paused狀態。
//ActivityStack.java
private boolean resumeTopActivityInnerLocked(ActivityRecord prev, ActivityOptions options) {
//...
ActivityRecord next = topRunningActivityLocked(true /* focusableOnly */);
//...
boolean pausing = getDisplay().pauseBackStacks(userLeaving, next, false);
if (mResumedActivity != null) {
if (DEBUG_STATES) Slog.d(TAG_STATES,
"resumeTopActivityLocked: Pausing " + mResumedActivity);
pausing |= startPausingLocked(userLeaving, false, next, false);
}
//...
if (next.attachedToProcess()) {
//應用已經啟動
try {
//...
transaction.setLifecycleStateRequest(
ResumeActivityItem.obtain(next.app.getReportedProcState(),
getDisplay().mDisplayContent.isNextTransitionForward()));
mService.getLifecycleManager().scheduleTransaction(transaction);
//...
} catch (Exception e) {
//...
mStackSupervisor.startSpecificActivityLocked(next, true, false);
return true;
}
//...
// From this point on, if something goes wrong there is no way
// to recover the activity.
try {
next.completeResumeLocked();
} catch (Exception e) {
// If any exception gets thrown, toss away this
// activity and try the next one.
Slog.w(TAG, "Exception thrown during resume of " + next, e);
requestFinishActivityLocked(next.appToken, Activity.RESULT_CANCELED, null,
"resume-exception", true);
return true;
}
} else {
//冷啟動流程
mStackSupervisor.startSpecificActivityLocked(next, true, true);
}
} 這里有兩個類沒有見過：
ActivityStack，是Activity的棧管理，相當于我們平時項目里面自己寫的Activity管理類，用于管理Activity的狀態啊，如棧出棧順序等等。ActivityRecord，代表具體的某一個Activity，存放了該Activity的各種信息。startPausingLocked方法就是讓上一個應用，這里也就是Launcher進入Paused狀態。然后就會判斷應用是否啟動，如果已經啟動了，就會走ResumeActivityItem的方法，看這個名字，結合應用已經啟動的前提，是不是已經猜到了它是干嗎的？沒錯，這個就是用來控制Activity的onResume生命周期方法的，不僅是onResume還有onStart方法，具體可見ActivityThread的handleResumeActivity方法源碼。
如果應用沒啟動就會接著走到startSpecificActivityLocked方法，接著看。
Launcher進入Paused之后，ActivityTaskManagerService就會判斷要打開的這個應用進程是否已經啟動，如果已經啟動，則直接啟動Activity即可，這也就是應用內的啟動Activity流程。如果進程沒有啟動，則需要創建進程。
這里有兩個問題：
WindowProcessController信息，這個信息包括processName和uid，uid則是應用程序的id，可以通過applicationInfo.uid獲取。processName則是進程名，一般為程序包名。所以判斷是否存在應用進程，則是根據processName和uid去判斷是否有對應的WindowProcessController，并且
WindowProcessController里面的線程不為空。代碼如下： //ActivityStackSupervisor.java
void startSpecificActivityLocked(ActivityRecord r, boolean andResume, boolean checkConfig) {
// Is this activity's application already running?
final WindowProcessController wpc =
mService.getProcessController(r.processName, r.info.applicationInfo.uid);
boolean knownToBeDead = false;
if (wpc != null && wpc.hasThread()) {
//應用進程存在
try {
realStartActivityLocked(r, wpc, andResume, checkConfig);
return;
}
}
}
//WindowProcessController.java
IApplicationThread getThread() {
return mThread;
}
boolean hasThread() {
return mThread != null;
}
Zygote去fork一個新的進程，服務于這個應用。 //ZygoteProcess.java
private Process.ProcessStartResult attemptUsapSendArgsAndGetResult(
ZygoteState zygoteState, String msgStr)
throws ZygoteStartFailedEx, IOException {
try (LocalSocket usapSessionSocket = zygoteState.getUsapSessionSocket()) {
final BufferedWriter usapWriter =
new BufferedWriter(
new OutputStreamWriter(usapSessionSocket.getOutputStream()),
Zygote.SOCKET_BUFFER_SIZE);
final DataInputStream usapReader =
new DataInputStream(usapSessionSocket.getInputStream());
usapWriter.write(msgStr);
usapWriter.flush();
Process.ProcessStartResult result = new Process.ProcessStartResult();
result.pid = usapReader.readInt();
// USAPs can't be used to spawn processes that need wrappers.
result.usingWrapper = false;
if (result.pid >= 0) {
return result;
} else {
throw new ZygoteStartFailedEx("USAP specialization failed");
}
}
}
可以看到，這里其實是通過socket和Zygote進行通信，BufferedWriter用于讀取和接收消息。這里將要新建進程的消息傳遞給Zygote，由Zygote進行fork進程，并返回新進程的pid。
可能又會有人問了？fork是啥？為啥這里又變成socket進行IPC通信，而不是Bindler了？
fork()是一個方法，是類Unix操作系統上創建進程的主要方法。用于創建子進程(等同于當前進程的副本)。不允許存在多線程，Binder通訊偏偏就是多線程。問題總是在不斷產生，總有好奇的朋友會接著問，為什么fork不允許存在多線程？
lock，另外一個線程B調用fork創建了子進程，但是子進程卻沒有了線程A，但是鎖本身卻被
fork了出來，那么這個鎖沒人可以打開了。一旦子進程中另外的線程又對這個鎖進行
lock，就死鎖了。 剛才說到由Zygote進行fork進程，并返回新進程的pid。其實這過程中也實例化ActivityThread對象。一起看看是怎么實現的：
//RuntimeInit.java
protected static Runnable findStaticMain(String className, String[] argv,
ClassLoader classLoader) {
Class<?> cl;
try {
cl = Class.forName(className, true, classLoader);
} catch (ClassNotFoundException ex) {
throw new RuntimeException(
"Missing class when invoking static main " + className,
ex);
}
Method m;
try {
m = cl.getMethod("main", new Class[] { String[].class });
} catch (NoSuchMethodException ex) {
throw new RuntimeException(
"Missing static main on " + className, ex);
} catch (SecurityException ex) {
throw new RuntimeException(
"Problem getting static main on " + className, ex);
}
//...
return new MethodAndArgsCaller(m, argv);
} 原來是反射！通過反射調用了ActivityThread 的 main 方法。ActivityThread大家應該都很熟悉了，代表了Android的主線程，而main方法也是app的主入口。這不對上了！新建進程的時候就調用了，可不是主入口嘛。來看看這個主入口。
public static void main(String[] args) {
//...
Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
thread.attach(false, startSeq);
//...
if (false) {
Looper.myLooper().setMessageLogging(new
LogPrinter(Log.DEBUG, "ActivityThread"));
}
//...
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
main方法主要創建了ActivityThread，創建了主線程的Looper對象，并開始loop循環。除了這些，還要告訴AMS，我醒啦，進程創建好了！也就是上述代碼中的attach方法，最后會轉到AMSattachApplicationLocked方法，一起看看這個方法干了啥：
//ActivitymanagerService.java
private final boolean attachApplicationLocked(IApplicationThread thread,
int pid, int callingUid, long startSeq) {
//...
ProcessRecord app;
//...
thread.bindApplication(processName, appInfo, providers, null, profilerInfo,
null, null, null, testMode,
mBinderTransactionTrackingEnabled, enableTrackAllocation,
isRestrictedBackupMode || !normalMode, app.isPersistent(),
new Configuration(app.getWindowProcessController().getConfiguration()),
app.compat, getCommonServicesLocked(app.isolated),
mCoreSettingsObserver.getCoreSettingsLocked(),
buildSerial, autofillOptions, contentCaptureOptions);
//...
app.makeActive(thread, mProcessStats);
//...
// See if the top visible activity is waiting to run in this process...
if (normalMode) {
try {
didSomething = mAtmInternal.attachApplication(app.getWindowProcessController());
} catch (Exception e) {
Slog.wtf(TAG, "Exception thrown launching activities in " + app, e);
badApp = true;
}
}
//...
}
//ProcessRecord.java
public void makeActive(IApplicationThread _thread, ProcessStatsService tracker) {
//...
thread = _thread;
mWindowProcessController.setThread(thread);
} 這里主要做了三件事：
bindApplication方法，主要用來啟動Application。makeActive方法，設定WindowProcessController里面的線程，也就是上文中說過判斷進程是否存在所用到的。attachApplication方法，啟動根Activity。接著上面看，按照我們所熟知的，應用啟動后，應該就是啟動Applicaiton，啟動Activity。看看是不是怎么回事：
//ActivityThread#ApplicationThread
public final void bindApplication(String processName, ApplicationInfo appInfo,
List<ProviderInfo> providers, ComponentName instrumentationName,
ProfilerInfo profilerInfo, Bundle instrumentationArgs,
IInstrumentationWatcher instrumentationWatcher,
IUiAutomationConnection instrumentationUiConnection, int debugMode,
boolean enableBinderTracking, boolean trackAllocation,
boolean isRestrictedBackupMode, boolean persistent, Configuration config,
CompatibilityInfo compatInfo, Map services, Bundle coreSettings,
String buildSerial, AutofillOptions autofillOptions,
ContentCaptureOptions contentCaptureOptions) {
AppBindData data = new AppBindData();
data.processName = processName;
data.appInfo = appInfo;
data.providers = providers;
data.instrumentationName = instrumentationName;
data.instrumentationArgs = instrumentationArgs;
data.instrumentationWatcher = instrumentationWatcher;
data.instrumentationUiAutomationConnection = instrumentationUiConnection;
data.debugMode = debugMode;
data.enableBinderTracking = enableBinderTracking;
data.trackAllocation = trackAllocation;
data.restrictedBackupMode = isRestrictedBackupMode;
data.persistent = persistent;
data.config = config;
data.compatInfo = compatInfo;
data.initProfilerInfo = profilerInfo;
data.buildSerial = buildSerial;
data.autofillOptions = autofillOptions;
data.contentCaptureOptions = contentCaptureOptions;
sendMessage(H.BIND_APPLICATION, data);
}
public void handleMessage(Message msg) {
if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
switch (msg.what) {
case BIND_APPLICATION:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindApplication");
AppBindData data = (AppBindData)msg.obj;
handleBindApplication(data);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
}
}
可以看到這里有個H，H是主線程的一個Handler類，用于處理需要主線程處理的各類消息，包括BIND_SERVICE，LOW_MEMORY，DUMP_HEAP等等。接著看handleBindApplication：
private void handleBindApplication(AppBindData data) {
//...
try {
final ClassLoader cl = instrContext.getClassLoader();
mInstrumentation = (Instrumentation)
cl.loadClass(data.instrumentationName.getClassName()).newInstance();
}
//...
Application app;
final StrictMode.ThreadPolicy savedPolicy = StrictMode.allowThreadDiskWrites();
final StrictMode.ThreadPolicy writesAllowedPolicy = StrictMode.getThreadPolicy();
try {
// If the app is being launched for full backup or restore, bring it up in
// a restricted environment with the base application class.
app = data.info.makeApplication(data.restrictedBackupMode, null);
mInitialApplication = app;
// don't bring up providers in restricted mode; they may depend on the
// app's custom Application class
if (!data.restrictedBackupMode) {
if (!ArrayUtils.isEmpty(data.providers)) {
installContentProviders(app, data.providers);
}
}
// Do this after providers, since instrumentation tests generally start their
// test thread at this point, and we don't want that racing.
try {
mInstrumentation.onCreate(data.instrumentationArgs);
}
//...
try {
mInstrumentation.callApplicationOnCreate(app);
} catch (Exception e) {
if (!mInstrumentation.onException(app, e)) {
throw new RuntimeException(
"Unable to create application " + app.getClass().getName()
+ ": " + e.toString(), e);
}
}
}
//...
} 這里信息量就多了，一點點的看：
Instrumentation，也就是上文一開始startActivity的第一步。每個應用程序都有一個
Instrumentation，用于管理這個進程，比如要創建Activity的時候，首先就會執行到這個類里面。attach方法。 public Application newApplication(ClassLoader cl, String className, Context context)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
Application app = getFactory(context.getPackageName())
.instantiateApplication(cl, className);
app.attach(context);
return app;
}
attach方法有了，onCreate方法又是何時調用的呢？馬上來了：
instrumentation.callApplicationOnCreate(app);
public void callApplicationOnCreate(Application app) {
app.onCreate();
} 也就是創建Application->attach->onCreate調用順序。
等等，在onCreate之前還有一句重要的代碼：
installContentProviders
這里就是啟動Provider的相關代碼了，具體邏輯就不分析了。
說完bindApplication，該說說后續了，上文第五關說到，bindApplication方法之后執行的是attachApplication方法，最終會執行到ActivityThread的handleLaunchActivity方法：
public Activity handleLaunchActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions, Intent customIntent) {
//...
WindowManagerGlobal.initialize();
//...
final Activity a = performLaunchActivity(r, customIntent);
//...
return a;
}
首先，初始化了WindowManagerGlobal，這是個啥呢？沒錯，就是WindowManagerService了，也為后續窗口顯示等作了準備。
繼續看performLaunchActivity：
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
//創建ContextImpl
ContextImpl appContext = createBaseContextForActivity(r);
Activity activity = null;
try {
java.lang.ClassLoader cl = appContext.getClassLoader();
//創建Activity
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
}
try {
if (activity != null) {
//完成activity的一些重要數據的初始化
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.referrer, r.voiceInteractor, window, r.configCallback,
r.assistToken);
if (customIntent != null) {
activity.mIntent = customIntent;
}
//設置activity的主題
int theme = r.activityInfo.getThemeResource();
if (theme != 0) {
activity.setTheme(theme);
}
//調用activity的onCreate方法
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
}
}
return activity;
}
哇，終于看到onCreate方法了。穩住，還是一步步看看這段代碼。
首先，創建了ContextImpl對象，ContextImpl可能有的朋友不知道是啥，ContextImpl繼承自Context,其實就是我們平時用的上下文。有的同學可能表示，這不對啊，獲取上下文明明獲取的是Context對象。來一起跟隨源碼看看。
//Activity.java
Context mBase;
@Override
public Executor getMainExecutor() {
return mBase.getMainExecutor();
}
@Override
public Context getApplicationContext() {
return mBase.getApplicationContext();
}
這里可以看到，我們平時用的上下文就是這個mBase，那么找到這個mBase是啥就行了：
protected void attachBaseContext(Context base) {
if (mBase != null) {
throw new IllegalStateException("Base context already set");
}
mBase = base;
}
//一層層往上找
final void attach(Context context, ActivityThread aThread,
Instrumentation instr, IBinder token, int ident,
Application application, Intent intent, ActivityInfo info,
CharSequence title, Activity parent, String id,
NonConfigurationInstances lastNonConfigurationInstances,
Configuration config, String referrer, IVoiceInteractor voiceInteractor) {
attachBaseContext(context);
mWindow = new PhoneWindow(this, window, activityConfigCallback);
mWindow.setWindowControllerCallback(this);
mWindow.setCallback(this);
mWindow.setOnWindowDismissedCallback(this);
mWindow.getLayoutInflater().setPrivateFactory(this);
if (info.softInputMode != WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED) {
mWindow.setSoftInputMode(info.softInputMode);
}
}
這不就是，剛才一開始performLaunchActivity方法里面的attach嗎？太巧了，所以這個ContextImpl就是我們平時所用的上下文。
順便看看attach還干了啥？新建了PhoneWindow，建立自己和Window的關聯，并設置了setSoftInputMode等等。
ContextImpl創建完之后，會通過類加載器創建Activity的對象，然后設置好activity的主題，最后調用了activity的onCreate方法。
“App的啟動流程是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
