Android進程絕殺技--forceStop
一.概述
1.1 引言
話說Android開源系統(tǒng)擁有著App不計其數(shù)，百家爭鳴，都想在這“大爭之世”尋得系統(tǒng)存活的一席之地。然則系統(tǒng)資源有限，如若都割據(jù)為王，再強勁的CPU也會忙不過來，再龐大的內(nèi)存終會消耗殆盡，再大容量的電池續(xù)航終會曇花一現(xiàn)。
面對蕓蕓眾生，無盡變數(shù)，系統(tǒng)以不變應(yīng)萬變，一招絕殺神技forceStop騰空出世，此處以adb指令的方式為例來說說其內(nèi)部機理：
force-stop命令殺掉所有用戶空間下的包名pkgName相關(guān)的信息，也可以通過--user來指定用戶Id。 當(dāng)執(zhí)行上述am指令時，則會觸發(fā)調(diào)用Am.java的main()方法，接下來從main方法開始說起。
1.2 Am.main
[-> Am.java]
1.3 Am.run
[-> Am.java]
1.4 Am.onRun
[-> Am.java]
1.***m.runForceStop
[-> Am.java]
當(dāng)不指定userId時，則默認(rèn)為UserHandle.USER_ALL。
1.6 AMP.forceStopPackage
[-> ActivityManagerNative.java ::AMP]
1.7 AMN.onTransact
[-> ActivityManagerNative.java]
MP.forceStopPackage來運行在執(zhí)行adb時所創(chuàng)建的進程，經(jīng)過Binder Driver后，進入system_server進程的一個binder線程來執(zhí)行AMN.forceStopPackage，從這開始的操作(包括當(dāng)前操作)便都運行在system_server系統(tǒng)進程。
1.8 小節(jié)
進程絕殺技force-stop，并非任意app可直接調(diào)用, 否則App間可以相互停止對方，則豈非天下大亂。該方法的存在便是供系統(tǒng)差遣。一般地，點擊home彈出的清理用戶最近使用app采取的策略便是force-stop.
至于force-stop的觸發(fā)方式，除了adb的方式，還可通過獲取ActivityManager再調(diào)用其方法forceStopPackage()，不過這是@hide隱藏方法，同樣是需要具有FORCE_STOP_PACKAGES權(quán)限。雖然第三方普通app不能直接調(diào)用，但對于深入理解Android，還是很有必要知道系統(tǒng)是如何徹底清理進程的過程。接下來，進入AMS來深入探查force-stop的內(nèi)部機理。
二. force-stop內(nèi)部機理
2.1 AMS.forceStopPackage
[-> ActivityManagerService.java]
這里有一個過程非常重要，那就是setPackageStoppedState()將包的狀態(tài)設(shè)置為stopped，那么所有廣播都無法接收，除非帶有標(biāo)記FLAG_INCLUDE_STOPPED_PACKAGES的廣播，系統(tǒng)默認(rèn)的廣播幾乎都是不帶有該標(biāo)志，也就意味著被force-stop的應(yīng)用是無法通過建立手機網(wǎng)絡(luò)狀態(tài)或者亮滅的廣播來拉起進程。
當(dāng)使用force stop方式來結(jié)束進程時, reason一般都是”from pid “ + callingPid. 當(dāng)然也有另外,那就是AMS.clearApplicationUserData方法調(diào)用forceStopPackageLocked的reason為”clear data”.
2.2 AMS.forceStopPackageLocked
清理跟該包名相關(guān)的進程和四大組件之外，還會發(fā)送廣播ACTION_PACKAGE_RESTARTED，用于清理已注冊的alarm,notification信息。
2.3 AMS.forceStopPackageLocked
對于didSomething只指當(dāng)方法中所有行為,則返回true.比如killPackageProcessesLocked(),只要殺過一個進程則代表didSomething為true.
該方法的主要功能:
Process: 調(diào)用AMS.killPackageProcessesLocked()清理該package所涉及的進程;
Activity: 調(diào)用ASS.finishDisabledPackageActivitiesLocked()清理該package所涉及的Activity;
Service: 調(diào)用AS.bringDownDisabledPackageServicesLocked()清理該package所涉及的Service;
Provider: 調(diào)用AMS.removeDyingProviderLocked()清理該package所涉及的Provider;
BroadcastRecevier: 調(diào)用BQ.cleanupDisabledPackageReceiversLocked()清理該package所涉及的廣播
接下來,從這5個角度來分別說說force-stop的執(zhí)行過程.
三. Process
3.1 AMS.killPackageProcessesLocked
一般地force-stop會指定包名，該方法會遍歷當(dāng)前所有運行中的進程mProcessNames，以下條件同時都不滿足的進程，則會成為被殺的目標(biāo)進程：(也就是說滿足以下任一條件都可以免死)
persistent進程：
進程setAdj < minOomAdj(默認(rèn)為-100)：
非UserHandle.USER_ALL同時, 且進程的userId不相等：多用戶模型下，不同用戶下不能相互殺;
進程沒有依賴該packageName, 且進程的AppId不相等;
進程沒有依賴該packageName, 且該packageName沒有運行在該進程.
通俗地來說就是：
forceStop不殺系統(tǒng)persistent進程;
當(dāng)指定用戶userId時，不殺其他用戶空間的進程;
除此之外，以下情況則必然會成為被殺進程：
進程已標(biāo)記remove=true的進程，則會被殺;
進程的pkgDeps中包含該packageName，則會被殺;
進程的pkgList中包含該packageName，且該進程與包名所指定的AppId相等則會被殺;
進程的pkgList是在啟動組件或者創(chuàng)建進程的過程向該隊列添加的，代表的是該應(yīng)用下有組件運行在該進程。那么pkgDeps是指該進程所依賴的包名，調(diào)用ClassLoader的過程添加。
3.2 AMS.removeProcessLocked
該方法的主要功能:
從mProcessNames, mPidsSelfLocked隊列移除該進程;
移除進程啟動超時的消息PROC_START_TIMEOUT_MSG;
調(diào)用app.kill()來殺進程會同時調(diào)用Process.kill和Process.killProcessGroup, 該過程詳見理解殺進程的實現(xiàn)原理
調(diào)用handleAppDiedLocked()來清理進程相關(guān)的信息, 該過程詳見binderDied()過程分析
四. Activity
4.1 ASS.finishDisabledPackageActivitiesLocked
[-> ActivityStackSupervisor.java]
4.2 AS.finishDisabledPackageActivitiesLocked
[-> ActivityStack.java]
4.3 AS.finishActivityLocked
[-> ActivityStack.java]
4.3.1 AR.makeFinishingLocked
[-> ActivityRecord.java]
4.3.2 ASS.requestVisibleBehindLocked
4.3.3 TaskRecord.setFrontOfTask
[-> TaskRecord.java]
將該Task中從底部往上查詢, ***個處于非finishing狀態(tài)的ActivityRecord,則設(shè)置為根Activity(即r.frontOfTask = true),其他都為false;
當(dāng)所有的activity都處于finishing狀態(tài),則把***部的activity設(shè)置成跟Activity.
4.3.4 AS.adjustFocusedActivityLocked
[-> ActivityStack.java]
4.3.***S.finishCurrentActivityLocked
滿足下面其中之一的條件,則會執(zhí)行finish以及destroy Activity.
模式為FINISH_IMMEDIATELY
模式為FINISH_AFTER_PAUSE, 且Activity狀態(tài)已處于PAUSED;
Activity的狀態(tài)為STOPPED或INITIALIZING.
4.3.6 AS.destroyActivityLocked
五. Service
5.1 bringDownDisabledPackageServicesLocked
[-> ActiveServices.java]
5.2 collectPackageServicesLocked
[-> ActiveServices.java]
該方法的主要功能就是收集該滿足條件service放入mTmpCollectionResults.
5.3 bringDownServiceLocked
[-> ActiveServices.java]
5.4 unscheduleServiceRestartLocked
六. Provider
6.1 PM.collectPackageProvidersLocked
[-> ProviderMap.java]
當(dāng)userId = UserHandle.USER_ALL時, 則會mSingletonByClass和mProvidersByClassPerUser結(jié)構(gòu)中查詢所有屬于該package的providers.
當(dāng)userId = UserHandle.USER_OWNER時,則會從mSingletonByClass和mProvidersByClassPerUser中userId相等的 數(shù)據(jù)結(jié)構(gòu)中查詢所有屬于該package的providers.
當(dāng)userId不屬于上述兩者之一時,則會從mProvidersByClassPerUser中userId相等的查詢所有屬于該package的providers.
6.2 PM.collectPackageProvidersLocked
[-> ProviderMap.java]
6.3 AMS.removeDyingProviderLocked
當(dāng)其他app使用該provider, 且建立stable的連接, 那么對于非persistent進程,則會由于依賴該provider的緣故而被殺.
七. Broadcast
7.1 BQ.cleanupDisabledPackageReceiversLocked
[-> BroadcastQueue.java]
該方法主要功能：
清理并行廣播隊列mParallelBroadcasts;
清理有序廣播隊列mOrderedBroadcasts
7.2 BR.cleanupDisabledPackageReceiversLocked
[-> BroadcastRecord.java]
八. Alarm和Notification
在前面[小節(jié)2.2]介紹到處理完forceStopPackageLocked()，緊接著便是發(fā)送廣播ACTION_PACKAGE_RESTARTED，經(jīng)過Broadcast廣播分發(fā)，最終調(diào)用到注冊過該廣播的接收者。
8.1 Alarm清理
[-> AlarmManagerService.java]
調(diào)用AlarmManagerService中的removeLocked()方法，從mAlarmBatches和mPendingWhileIdleAlarms隊列中移除包所相關(guān)的alarm.
8.2 Notification清理
[-> NotificationManagerService.java]
mNotificationList隊列中移除包所相關(guān)的Notification.
九. 級聯(lián)誅殺
這里就跟大家分享一段經(jīng)歷吧，記得之前有BAT的某瀏覽器大廠(具體名稱就匿了)，瀏覽器會因為另一個app被殺而導(dǎo)致自己無辜被牽連所殺，并懷疑是ROM定制化導(dǎo)致的bug，于是發(fā)郵件向我廠請教緣由。
遇到這個問題，首先將兩個app安裝到Google原生系統(tǒng)，結(jié)果是依然會被級聯(lián)誅殺，很顯然可以排除廠商ROM定制的緣故，按常理說bug應(yīng)該可以讓app自行解決。出于好奇，幫他們進一步調(diào)查了下這個問題，發(fā)現(xiàn)并非無辜被殺，而是force-stop的級聯(lián)誅殺所導(dǎo)致的。
簡單來說就是App1調(diào)用了getClassLoader()來加載App2，那么App1所運行的進程便會在其pkgDeps隊列中增加App2的包名，在前面[小節(jié)3.2]已經(jīng)提到pkgDeps，殺進程的過程中會遍歷該隊列，當(dāng)App2被forceStop所殺時，便是級聯(lián)誅殺App1。App1既然會調(diào)用App2的ClassLoader來加載其方法，那么就建立了一定的聯(lián)系，這是Google有意賦予forceStop這個強力殺的功能。
這個故事是想告訴大家在插件化或者反射的過程中要注意這種情況，防止不必要的誤傷。接下來具體說說這個過程是如何建立依賴的。
9.1 CI.getClassLoader
[-> ContextImpl.java]
9.2 LA.getClassLoader
[-> LoadedApk.java]
9.3 AMS.addPackageDependency
調(diào)用ClassLoader來加載啟動包名時，則會將該包名加入到進程的pkgDeps。
十. 總結(jié)
forceStop的功能如下：
Process: 調(diào)用AMS.killPackageProcessesLocked()清理該package所涉及的進程;
Activity: 調(diào)用ASS.finishDisabledPackageActivitiesLocked()清理該package所涉及的Activity;
Service: 調(diào)用AS.bringDownDisabledPackageServicesLocked()清理該package所涉及的Service;
Provider: 調(diào)用AMS.removeDyingProviderLocked()清理該package所涉及的Provider;
BroadcastRecevier: 調(diào)用BQ.cleanupDisabledPackageReceiversLocked()清理該package所涉及的廣播
發(fā)送廣播ACTION_PACKAGE_RESTARTED，用于停止已注冊的alarm,notification.
功能點歸納：
force-stop并不會殺persistent進程;
當(dāng)app被force-stop后，無法接收到任何普通廣播，那么也就常見的監(jiān)聽手機網(wǎng)絡(luò)狀態(tài)的變化或者屏幕亮滅的廣播來拉起進程肯定是不可行;
當(dāng)app被force-stop后，那么alarm鬧鐘一并被清理，無法實現(xiàn)定時響起的功能;
app被force-stop后，四大組件以及相關(guān)進程都被一一剪除清理，即便多進程架構(gòu)的app也無法拉起自己;
級聯(lián)誅殺：當(dāng)app通過ClassLoader加載另一個app，則會在force-stop的過程中會被級聯(lián)誅殺;
生死與共：當(dāng)app與另個app使用了share uid，則會在force-stop的過程，任意一方被殺則另一方也被殺，建立起生死與共的強關(guān)系。
既然force-stop多次提到殺進程，那***簡單說兩句關(guān)于保活：正確的保活姿態(tài)，應(yīng)該是在用戶需要時保證千萬別被殺，用戶不需要時別強保活，一切以用戶為出發(fā)點。
進程是否需要存活，系統(tǒng)上層有AMS來管理緩存進程和空進程，底層有LowMemoryKiller來根據(jù)系統(tǒng)可用內(nèi)存的情況來管理進程是否存活，這樣的策略是從系統(tǒng)整體性角度考慮，為了是給用戶提供更好更流暢的用戶體驗。
用戶需要的時候千萬別被殺：謹(jǐn)慎使用插件化和共享uid，除非愿意接受級聯(lián)誅殺和生死與共的場景;還有就是提高自身app的穩(wěn)定性，減少crash和anr的發(fā)生頻率，這才是正道。
用戶不需要的時候別強保活：為了保活，多進程架構(gòu)，利用各種小技巧來提升優(yōu)先級等都是不可取的，一招force-stop足以干掉90%以上的保活策略，當(dāng)然還有一些其他手段及漏洞來保活，系統(tǒng)層面往往還會采取一些特別的方法來禁止保活。博主曾經(jīng)干過手機底層的性能與功耗優(yōu)化工作，深知不少app的流氓行徑，嚴(yán)重系統(tǒng)的流暢度與手機續(xù)航能力。
為了Android有更好的用戶體驗，為了不影響手機系統(tǒng)性能，為了不降低手機續(xù)航能力，建議大家花更多時間精力在如何提高app的穩(wěn)健性，如何優(yōu)化app性能，共同打造Android的良好生態(tài)圈。
【本文是51CTO專欄“小米開放平臺”原創(chuàng)文章，“小米開放平臺”微信公眾號xiaomideveloper】
