繼續(xù)我們的源碼解析，上一篇文章我們介紹了Activity的啟動(dòng)流程，一個(gè)典型的場景就是Activity a 啟動(dòng)了一個(gè)Activity b，他們的生命周期回調(diào)方法是：
onPause(a) –> onCreate(b) –> onStart(b) –> onResume(b) –> onStop(a)
而我們根據(jù)源碼也驗(yàn)證了這樣的生命周期調(diào)用序列，那么Activity的銷毀流程呢？它的生命周期的調(diào)用順序又是這樣的呢？
這里我們我做一個(gè)簡單的demo，讓一個(gè)Activity a啟動(dòng)Activity b，然后在b中調(diào)用finish()方法，它們的生命周期執(zhí)行順序是：
onPause(b)
onRestart(a)
onStart(a)
onResume(a)
onStop(b)
onDestory(b)
好吧，根據(jù)我們測試的生命周期方法的回調(diào)過程開始對(duì)Activity銷毀流程的分析，一般而言當(dāng)我們需要銷毀Activity的時(shí)候都會(huì)調(diào)用其自身的finish方法，所以我們的流程開始是以finish方法開始的。
一：請(qǐng)求銷毀當(dāng)前Activity
MyActivity.finish()
Activity.finish()
ActivityManagerNative.getDefault().finishActivity()
ActivityManagerService.finishActivity()
ActivityStack.requestFinishActivityLocked()
ActivityStack.finishActivityLocked()
ActivityStack.startPausingLocked()
首先我們?cè)谧约旱腁ctivity調(diào)用了finish方法，它實(shí)際上調(diào)用的是Activity的finish方法：
|
1
2
3
|
public void finish() { finish(false);} |
然后我們可以發(fā)現(xiàn)其調(diào)用了finish方法的重載方法，并且傳遞了一個(gè)參數(shù)值：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
private void finish(boolean finishTask) { if (mParent == null) { int resultCode; Intent resultData; synchronized (this) { resultCode = mResultCode; resultData = mResultData; } if (false) Log.v(TAG, "Finishing self: token=" + mToken); try { if (resultData != null) { resultData.prepareToLeaveProcess(); } if (ActivityManagerNative.getDefault() .finishActivity(mToken, resultCode, resultData, finishTask)) { mFinished = true; } } catch (RemoteException e) { // Empty } } else { mParent.finishFromChild(this); } } |
好吧，這個(gè)參數(shù)值似乎并沒什么用。。。這里就不在討論了，然后調(diào)用了ActivityManagerNative.getDefault().finishActivity方法，好吧，根據(jù)上一篇文章的介紹，我們知道了ActivityManagerNative是一個(gè)Binder對(duì)象，這里調(diào)用的方法最終會(huì)被ActivityManagerService執(zhí)行，所以這了的finishActivity最終被執(zhí)行的是ActivityManagerService.finishActivity方法，好吧，我們來看一下ActivityManagerService的finishActivity方法的執(zhí)行邏輯。。。
|
1
2
3
4
5
6
|
@Overridepublic final boolean finishActivity(IBinder token, int resultCode, Intent resultData, boolean finishTask) { ... res = tr.stack.requestFinishActivityLocked(token, resultCode,resultData, "app-request", true); ...} |
這里我們可以發(fā)現(xiàn)，經(jīng)過一系列邏輯判斷之后，最終調(diào)用了ActivityStack的requestFinishActivityLocked方法，這里應(yīng)該就是執(zhí)行finish Activity的邏輯了。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
final boolean requestFinishActivityLocked(IBinder token, int resultCode, Intent resultData, String reason, boolean oomAdj) { ActivityRecord r = isInStackLocked(token); if (DEBUG_RESULTS || DEBUG_STATES) Slog.v(TAG_STATES, "Finishing activity token=" + token + " r=" + ", result=" + resultCode + ", data=" + resultData + ", reason=" + reason); if (r == null) { return false; } finishActivityLocked(r, resultCode, resultData, reason, oomAdj); return true; } |
這個(gè)方法體里面又調(diào)用了finishActivityLocked方法，那我們繼續(xù)看一下finishActivityLocked方法的實(shí)現(xiàn)：
|
1
2
3
4
5
6
7
|
final boolean finishActivityLocked(ActivityRecord r, int resultCode, Intent resultData, String reason, boolean oomAdj) { ... startPausingLocked(false, false, false, false); ... return false; } |
好吧，在這里調(diào)用了startPausingLocked方法，看名字應(yīng)該是開始要執(zhí)行Activity的onPause方法請(qǐng)求了，然后我們看一下startPausingLocked方法的實(shí)現(xiàn)：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
final boolean startPausingLocked(boolean userLeaving, boolean uiSleeping, boolean resuming, boolean dontWait) { ... try { EventLog.writeEvent(EventLogTags.AM_PAUSE_ACTIVITY, prev.userId, System.identityHashCode(prev), prev.shortComponentName); mService.updateUsageStats(prev, false); prev.app.thread.schedulePauseActivity(prev.appToken, prev.finishing, userLeaving, prev.configChangeFlags, dontWait); } catch (Exception e) { // Ignore exception, if process died other code will cleanup. Slog.w(TAG, "Exception thrown during pause", e); mPausingActivity = null; mLastPausedActivity = null; mLastNoHistoryActivity = null; } ... } |
這樣從應(yīng)用程序調(diào)用finish方法，ActivityManagerService接收請(qǐng)求并執(zhí)行startPausingLocked方法。
二：執(zhí)行當(dāng)前Activity的onPause方法
IApplicationThread.schedulePauseActivity()
ActivityThread.schedulePauseActivity()
ActivityThread.sendMessage()
ActivityThread.H.sendMessage()
ActivityThread.H.handleMessage()
ActivityThread.handlePauseActivity()
ActivityThread.performPauseActivity()
Instrumentation.callActivityOnPause()
Activity.performPause()
Activity.onPause()
ActivityManagerNative.getDefault().activityPaused()
ActivityManagerService.activityPaused()
ActivityStack.activityPausedLocked()
ActivityStack.completePauseLocked()
在方法startPausingLocked中我們調(diào)用了：prev.app.thread.schedulePauseActivity這里實(shí)際上調(diào)用的是IApplicationThread的schedulePauseActivity方法，IApplicationThread也是一個(gè)Binder對(duì)象，它是ActivityThread中ApplicationThread的Binder client端，所以最終會(huì)調(diào)用的是ApplicationThread的schedulePauseActivity方法，好吧我們看一下ActivityThread的schedulePauseActivity方法的具體實(shí)現(xiàn)：
|
1
2
3
4
5
6
|
public final void schedulePauseActivity(IBinder token, boolean finished, boolean userLeaving, int configChanges, boolean dontReport) { sendMessage( finished ? H.PAUSE_ACTIVITY_FINISHING : H.PAUSE_ACTIVITY, token, (userLeaving ? 1 : 0) | (dontReport ? 2 : 0), configChanges);} |
然后調(diào)用了ActivityThread的sendMessage方法：
|
1
2
3
|
private void sendMessage(int what, Object obj, int arg1, int arg2) { sendMessage(what, obj, arg1, arg2, false); } |
然后又回調(diào)了sendMessage的重載方法。。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
private void sendMessage(int what, Object obj, int arg1, int arg2, boolean async) { if (DEBUG_MESSAGES) Slog.v( TAG, "SCHEDULE " + what + " " + mH.codeToString(what) + ": " + arg1 + " / " + obj); Message msg = Message.obtain(); msg.what = what; msg.obj = obj; msg.arg1 = arg1; msg.arg2 = arg2; if (async) { msg.setAsynchronous(true); } mH.sendMessage(msg); } |
最終調(diào)用mH發(fā)送異步消息，然后在mH的handleMessge方法中處理異步消息并調(diào)用handlePauseActivity方法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
private void handlePauseActivity(IBinder token, boolean finished, boolean userLeaving, int configChanges, boolean dontReport) { 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; performPauseActivity(token, finished, r.isPreHoneycomb()); // Make sure any pending writes are now committed. if (r.isPreHoneycomb()) { QueuedWork.waitToFinish(); } // Tell the activity manager we have paused. if (!dontReport) { try { ActivityManagerNative.getDefault().activityPaused(token); } catch (RemoteException ex) { } } mSomeActivitiesChanged = true; } } |
好吧，這里回調(diào)了performPauseActivity方法，上篇文章中我們已經(jīng)分析過了這段代碼：
performPauseActivity()
Instrumentation.callActivityOnPause()
Activity.performPause()
Activity.onPause()
這樣我們就回調(diào)了第一個(gè)生命周期方法：onPause。。。
在handlePauseActivity方法中我們調(diào)用了ActivityManagerNative.getDefault().activityPaused(token)方法，好吧又是回調(diào)ActivityManagerService的方法，這樣最終會(huì)調(diào)用ActivityManagerService的activityPaused方法：
|
1
2
3
4
5
6
7
8
9
10
11
|
@Override public final void activityPaused(IBinder token) { final long origId = Binder.clearCallingIdentity(); synchronized(this) { ActivityStack stack = ActivityRecord.getStackLocked(token); if (stack != null) { stack.activityPausedLocked(token, false); } } Binder.restoreCallingIdentity(origId); } |
這樣，我們繼續(xù)看一下activityPausedLocked方法的實(shí)現(xiàn)：
|
1
2
3
4
5
|
final void activityPausedLocked(IBinder token, boolean timeout) { ... completePauseLocked(true); ...} |
里面又經(jīng)過一系列的邏輯判斷之后，開始執(zhí)行completePauseLocked方法：
|
1
2
3
4
|
private void completePauseLocked(boolean resumeNext) { ... mStackSupervisor.resumeTopActivitiesLocked(topStack, null, null); ... } |
這樣棧頂Activity的onPause操作就執(zhí)行完成了，接下來就就是開始執(zhí)行上一個(gè)Activity的onResume操作了。。。
三：執(zhí)行上一個(gè)Activity的onResume操作
這樣調(diào)用了ActivityStackSupervisor.resumeTopActivitiesLocked方法。。，又開始調(diào)用這個(gè)方法，通過上一篇文章的介紹，我們知道這個(gè)方法實(shí)際上是執(zhí)行Activity的初始化，我們看一下其具體的調(diào)用過程：
ActivityStack.resumeTopActivityLocked()
ActivityStack.resumeTopInnerLocked()
IApplicationThread.scheduleResumeActivity()
ActivityThread.scheduleResumeActivity()
ActivityThread.sendMessage()
ActivityTherad.H.sendMessage()
ActivityThread.H.handleMessage()
ActivityThread.H.handleResumeMessage()
Activity.performResume()
Activity.performRestart()
Instrumentation.callActivityOnRestart()
Activity.onRestart()
Activity.performStart()
Instrumentation.callActivityOnStart()
Activity.onStart()
Instrumentation.callActivityOnResume()
Activity.onResume()
好吧，這個(gè)過程其實(shí)上一篇文章中已經(jīng)做了介紹，這里不做過多的分析了，通過這樣調(diào)用過程我們最終執(zhí)行了當(dāng)前棧頂Activity上一個(gè)Activity的onRestart方法，onStart方法，onResume方法等，下面我們將調(diào)用棧頂Activity的onStop方法，onDestory方法。
四：執(zhí)行棧頂Activity的銷毀操作
Looper.myQueue().addIdleHandler(new Idler())
ActivityManagerNative.getDefault().activityIdle()
ActivityManagerService.activityIdle()
ActivityStackSupervisor.activityIdleInternalLocked()
ActivityStack.destroyActivityLocked()
IApplicationThread.scheduleDestoryActivity()
ActivityThread.scheduleDestoryActivity()
ActivityThread.sendMessage()
ActivityThread.H.sendMessage()
ActivityThread.H.handleMessage()
ActivityThread.handleDestoryActivity()
ActivityThread.performDestoryActivity()
Activity.performStop()
Instrumentation.callActivityOnStop()
Activity.onStop()
Instrumentation.callActivityOnDestory()
Activity.performDestory()
Acitivity.onDestory()
ActivityManagerNative.getDefault().activityDestoryed()
ActivityManagerService.activityDestoryed()
ActivityStack.activityDestoryedLocked()
我們?cè)贏ctivityThread.handleResumeActivity方法中調(diào)用了Looper.myQueue().addIdleHandler(new Idler())，下面看一下這個(gè)方法的實(shí)現(xiàn)：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
private class Idler implements MessageQueue.IdleHandler { @Override public final boolean queueIdle() { ActivityClientRecord a = mNewActivities; boolean stopProfiling = false; if (mBoundApplication != null && mProfiler.profileFd != null && mProfiler.autoStopProfiler) { stopProfiling = true; } if (a != null) { mNewActivities = null; IActivityManager am = ActivityManagerNative.getDefault(); ActivityClientRecord prev; do { if (localLOGV) Slog.v( TAG, "Reporting idle of " + a + " finished=" + (a.activity != null && a.activity.mFinished)); if (a.activity != null && !a.activity.mFinished) { try { am.activityIdle(a.token, a.createdConfig, stopProfiling); a.createdConfig = null; } catch (RemoteException ex) { // Ignore } } prev = a; a = a.nextIdle; prev.nextIdle = null; } while (a != null); } if (stopProfiling) { mProfiler.stopProfiling(); } ensureJitEnabled(); return false; } } |
內(nèi)部有一個(gè)queueIdle的回調(diào)方法，當(dāng)它被添加到MessageQueue之后就會(huì)回調(diào)該方法，我們可以發(fā)現(xiàn)在這個(gè)方法體中調(diào)用了ActivityManagerNative.getDefault.activityIdle方法，通過上一篇文章以及上面的講解，我們應(yīng)該知道這了最終調(diào)用的是ActivityManagerService.activityIdle方法，好吧，這里看一下activityIdle方法的具體實(shí)現(xiàn)：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
public final void activityIdle(IBinder token, Configuration config, boolean stopProfiling) { final long origId = Binder.clearCallingIdentity(); synchronized (this) { ActivityStack stack = ActivityRecord.getStackLocked(token); if (stack != null) { ActivityRecord r = mStackSupervisor.activityIdleInternalLocked(token, false, config); if (stopProfiling) { if ((mProfileProc == r.app) && (mProfileFd != null)) { try { mProfileFd.close(); } catch (IOException e) { } clearProfilerLocked(); } } } } Binder.restoreCallingIdentity(origId); } |
可以發(fā)現(xiàn)這里又調(diào)用了ActivityStackSupervisor.activityIdleInternalLocked方法，然后我們看一下activityIdleInternalLocked方法的具體實(shí)現(xiàn)：
|
1
2
3
4
5
|
final ActivityRecord activityIdleInternalLocked(final IBinder token, boolean fromTimeout, Configuration config) { .... stack.destroyActivityLocked(r, true, "finish-idle"); .... } |
可以看到這里調(diào)用ActivityStack.destroyActivityLocked方法，可以看一下其具體實(shí)現(xiàn)：
|
1
2
3
4
5
|
final boolean destroyActivityLocked(ActivityRecord r, boolean removeFromApp, String reason) { ... r.app.thread.scheduleDestroyActivity(r.appToken, r.finishing, r.configChangeFlags); ... } |
好吧，這里又開始執(zhí)行IApplicationThread.scheduleDestoryActivity方法，上文已經(jīng)做了說明這里最終調(diào)用的是ActivityThread.scheduleDestroyActivity方法，好吧，看一下ActivityThread.scheduleDestryActivity方法的實(shí)現(xiàn)：
|
1
2
3
4
|
public final void scheduleDestroyActivity(IBinder token, boolean finishing, int configChanges) { sendMessage(H.DESTROY_ACTIVITY, token, finishing ? 1 : 0, configChanges);} |
這里有開始執(zhí)行sendMessage方法，通過一系列的調(diào)用sendMessage方法最終調(diào)用了handleDestroyActivity方法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
private void handleDestroyActivity(IBinder token, boolean finishing, int configChanges, boolean getNonConfigInstance) { ActivityClientRecord r = performDestroyActivity(token, finishing, configChanges, getNonConfigInstance); if (r != null) { cleanUpPendingRemoveWindows(r); WindowManager wm = r.activity.getWindowManager(); View v = r.activity.mDecor; if (v != null) { if (r.activity.mVisibleFromServer) { mNumVisibleActivities--; } IBinder wtoken = v.getWindowToken(); if (r.activity.mWindowAdded) { if (r.onlyLocalRequest) { // Hold off on removing this until the new activity's // window is being added. r.mPendingRemoveWindow = v; r.mPendingRemoveWindowManager = wm; } else { wm.removeViewImmediate(v); } } if (wtoken != null && r.mPendingRemoveWindow == null) { WindowManagerGlobal.getInstance().closeAll(wtoken, r.activity.getClass().getName(), "Activity"); } r.activity.mDecor = null; } if (r.mPendingRemoveWindow == null) { // If we are delaying the removal of the activity window, then // we can't clean up all windows here. Note that we can't do // so later either, which means any windows that aren't closed // by the app will leak. Well we try to warning them a lot // about leaking windows, because that is a bug, so if they are // using this recreate facility then they get to live with leaks. WindowManagerGlobal.getInstance().closeAll(token, r.activity.getClass().getName(), "Activity"); } // Mocked out contexts won't be participating in the normal // process lifecycle, but if we're running with a proper // ApplicationContext we need to have it tear down things // cleanly. Context c = r.activity.getBaseContext(); if (c instanceof ContextImpl) { ((ContextImpl) c).scheduleFinalCleanup( r.activity.getClass().getName(), "Activity"); } } if (finishing) { try { ActivityManagerNative.getDefault().activityDestroyed(token); } catch (RemoteException ex) { // If the system process has died, it's game over for everyone. } } mSomeActivitiesChanged = true; } |
可以看到這里調(diào)用了performDestroyActivity方法，用來執(zhí)行Avtivity的onDestroy方法：
|
1
2
3
4
5
6
7
8
|
private ActivityClientRecord performDestroyActivity(IBinder token, boolean finishing, int configChanges, boolean getNonConfigInstance) { ... r.activity.performStop(); ... mInstrumentation.callActivityOnDestroy(r.activity); ... } |
然后調(diào)用了Activity.performStop()方法，查看performStop方法：
|
1
2
3
4
5
|
final void performStop() { ... mInstrumentation.callActivityOnStop(this); ...} |
然后調(diào)用了Instrumentation.callActivityOnStop()方法：
|
1
2
3
|
public void callActivityOnStop(Activity activity) { activity.onStop(); } |
好吧，終于調(diào)用了Activity的onStop方法。。。
我們繼續(xù)看一下Instrumentation.callActivityOnDestroy()。。。。又是通過Instrumentation來調(diào)用Activity的onDestroy方法：
|
1
2
3
4
5
|
public void callActivityOnDestroy(Activity activity) { ... activity.performDestroy(); ...} |
然后看一下Activity的performDestroy()方法的實(shí)現(xiàn)：
|
1
2
3
4
5
6
7
8
9
10
|
final void performDestroy() { mDestroyed = true; mWindow.destroy(); mFragments.dispatchDestroy(); onDestroy(); mFragments.doLoaderDestroy(); if (mVoiceInteractor != null) { mVoiceInteractor.detachActivity(); } } |
O(∩_∩)O哈哈~，終于回調(diào)了Activity的onDestroy方法。。。。
總結(jié)：
Activity的銷毀流程是從finish方法開始的
Activity銷毀過程是：onPause –> onRestart –> onStart –> onResume –> onStop –> onDestroy
Activity的銷毀流程是ActivityThread與ActivityManagerService相互配合銷毀的
以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持服務(wù)器之家。
原文鏈接：https://blog.csdn.net/qq_23547831/article/details/51232309
