android系統(tǒng)從systemserver開始的launcher啟動(dòng)詳細(xì)流程

1、android系統(tǒng)啟動(dòng)流程android系統(tǒng)啟動(dòng)流程 從systemserver開始的launcher 目錄1 概述:22 systemserver工作內(nèi)容分析32.1 SystemServer類簡述42.2 ServerThread類簡述43 ActivityManagerService工作內(nèi)容分析63.1 ActivityManagerService之main73.1.1創(chuàng)建ActivityManagerService實(shí)例73.1.2 創(chuàng)建ActivityThread實(shí)例，獲取全局Context83.1.3創(chuàng)建ActivityStackSupervisor實(shí)例103.1.4調(diào)用startR

2、unning103.2 ActivityManagerService之setSystemProcess113.3. ActivityManagerService之setWindowManager123.4 ActivityManagerService之systemready123.4.1 啟動(dòng)所有Persistent屬性的APK133.4.2 啟動(dòng)launcher144 ActivityStackSupervisor啟動(dòng)launcher154.1首先回顧一下ActivityStackSupervisor實(shí)例的初始化154.2 進(jìn)入ActivityStackSupervisor.resumeTo

3、pActivitiesLocked164.3 進(jìn)入ActivityStack.resumeTopActivityLocked164.4 回到ActivityStackSupervisor.resumeHomeActivity。174.5 ActivityStackSupervisor.mProbeThread174.6 ActivityStackSupervisor.mProbeHandler184.7 回到ActivityManagerService.startHomeActivityLocked184.8 ActivityStackSupervisor.startHomeActivity1

4、94.9 ActivityStackSupervisor.startActivityUncheckedLocked204.10 ActivityStack.startActivityLocked214.11 ActivityStackSupervisor.resumeTopActivitiesLocked224.12 ActivityStack.resumeTopActivityLocked224.13 ActivityStackSupervisor.startSpecificActivityLocked244.14 ActivityStackSupervisor.realStartActiv

5、ityLocked244.15 ActivityManagerService.startProcessLocked255 Process類管理創(chuàng)建activity進(jìn)程275.1 Process.start:275.2Process.startViaZygote285.3 zygoteSendArgsAndGetResult和 openZygoteSocketIfNeeded286 ActivityThread線程類分析306.1 ActivityThread.main分析306.1.1創(chuàng)建了looper對象和本線程綁定。306.1.2創(chuàng)建了ActivityThread對象實(shí)例306.1.3進(jìn)行

6、attach回調(diào)316.1.4 ActivityStackSupervisor.attachApplicationLocked346.1.5 ActivityStackSupervisor. ensureActivitiesVisibleLocked346.2 ApplicationThread內(nèi)部類346.2.1 ActivityThread.ApplicationThread. scheduleLaunchActivity356.2.2 ActivityThread.ApplicationThread.scheduleResumeActivity376.2.3 發(fā)出開機(jī)完成通知387 總結(jié)

7、407.1 luancher啟動(dòng)流程總結(jié)407.2 luancher黑屏問題分析411 概述: android系統(tǒng)啟動(dòng)到zygote后，系統(tǒng)就真正進(jìn)入java世界了；而zygote啟動(dòng)的第一個(gè)進(jìn)程是systemserver.而用戶看到的第一個(gè)程序是launcher. 本文要分析的正是從systemserver道launcher的啟動(dòng)流程.分析過程涉及到PowerManagerService,ActivityManagerService, PackageManagerService, DisplayManagerService, WindowManagerService , InputManag

8、erService ,ServiceManager等一系列相關(guān)知識(shí)，必要的地方會(huì)做一些簡單分析。這些service的詳細(xì)分析，在另外的筆記中再做闡述。流程圖:黑線：途徑1；藍(lán)線：途徑2；紅線：途徑3； 部分流程重疊。systemserver:ServerThread.initAndLoopPersistent屬性apk啟動(dòng):getPersistentApplicationsActivityManagerService:1)attachApplication2)startProcessLocked3)startHomeActivityLocked4)systemreadyActivityStac

9、kSupervisor:1)realStartActivityLocked2)startSpecificActivityLocked3)attachApplicationLocked4)startHomeActivity5)resumeHomeActivity mProbeThread mProbeHandler6)resumeTopActivitiesLockedActivityStack:resumeTopActivityLockedtopRunningActivity=NULL?activity resumed?activity進(jìn)程已啟動(dòng)Process:startstartViaZygo

10、teActivityThread:mainattachzygoteinit(zygotesocket):runSelectLoop顯示launcher:1)WindowManagerServicesetAppVisibility2) ActivityThread . ApplicationThreadscheduleResumeActivityscheduleResumeActivity設(shè)置Activity resumedYNYdo nothingreturnNYN2 systemserver工作內(nèi)容分析源代碼路徑: frameworksbaseservicesjavacomandroidse

11、rverSystemServer.javasystemserver最主要的作用： 1)就是初始化framework層各種service和其對應(yīng)的特定servicemanager，并將他們注冊到全局servicemanager類,以便其他地方只需要通過servicemanager.getService(String servicename)就可以取得該service的實(shí)例。 2)調(diào)用各service的systemready接口，啟動(dòng)service。這些service基本都是單例類，所以這種注冊也是方便全局調(diào)用。下面分析其代碼流程2.1 SystemServer類簡述這里啟動(dòng)了ServerThre

12、ad類，并調(diào)用其initAndLoop函數(shù)。2.2 ServerThread類簡述源代碼路徑: frameworksbaseservicesjavacomandroidserverSystemServer.java進(jìn)入同樣在SystemServer.java下的ServerThread類:可見systemsever的工作基本都是在ServerThread內(nèi)完成的.其中我們所需要關(guān)注的是ActivityManagerService，正是這個(gè)類的啟動(dòng)，最終完成了launcher的啟動(dòng)；下面接著分析ActivityManagerService在ServerThread內(nèi)的5個(gè)主要步驟。3 Activ

13、ityManagerService工作內(nèi)容分析這個(gè)分析，對應(yīng)其在ServerThread內(nèi)的5個(gè)步驟，重點(diǎn)是其如何systemReady完成launcher的啟動(dòng)。從上面systemserver的分析可以看到，systemserver最后也調(diào)用了ActivityManagerService的systemReady，那么systemReady到底 是如何啟動(dòng)launcher的?源代碼路徑:frameworksbaseservicesjavacomandroidserveramActivityManagerService.java3.1 ActivityManagerService之main回顧下

14、ActivityManagerService在systemserver中的第一個(gè)動(dòng)作:下面進(jìn)入ActivityManagerService的main方法: ActivityManagerService的main方法完成以下幾個(gè)事情:3.1.1創(chuàng)建ActivityManagerService實(shí)例 ActivityManagerService實(shí)例是通過AThread這個(gè)內(nèi)部類創(chuàng)建的；這里我們看下AThread是如何創(chuàng)建這個(gè)實(shí)例的。 AThread是在其run方法中創(chuàng)建的ActivityManagerService實(shí)例，AThread. start被執(zhí)行的時(shí)候，run方法就被調(diào)用，從而完成創(chuàng)建Act

15、ivityManagerService實(shí)例。ActivityManagerService在創(chuàng)建了實(shí)例后，self函數(shù)就直接返回該實(shí)例：3.1.2 創(chuàng)建ActivityThread實(shí)例，獲取全局Context調(diào)用ActivityThread類的systemMain創(chuàng)建ActivityThread實(shí)例，再調(diào)用getSystemContext獲得contextframeworksbasecorejavaandroidappActivityThread.java 這個(gè)context是ActivityThread下的全局context，所有的上下文都繼承于此。擴(kuò)展一:為什么這里要?jiǎng)?chuàng)建一個(gè)Activity

16、Thread線程? ActivityThread類故名思議是處理activity生命周期內(nèi)的活動(dòng)的線程，ActivityManagerService運(yùn)行在systemserver進(jìn)程內(nèi)，為什么需要?jiǎng)?chuàng)建ActivityThread線程？實(shí)際上systemserver.java下有一個(gè)startSystemUi，這個(gè)函數(shù)本身啟動(dòng)一個(gè)service處理了很多系統(tǒng)級的臨時(shí)彈出消息，這些有一部分也處理為activity，他們的運(yùn)行同樣需要ActivityThread;同時(shí)其他aitivity的一些善后的工作也需要ActivityManagerService來處理;所以這個(gè)systemserver進(jìn)程就需

17、要 這么一個(gè)ActivityThread線程，換句話說，這個(gè)線程放在systemsever內(nèi)創(chuàng)建也是可以的。ActivityManagerService實(shí)際需要的是ActivityThread下的全局conntext(即getSystemContext的結(jié)果).擴(kuò)展二: ActivityThread類是如何工作的? 這個(gè)知識(shí)點(diǎn)較多，放到后面再分析.但是這里需要提前講一下的是ActivityThread的基本原理和意義： ActivityThread是所有應(yīng)用層activity啟動(dòng)時(shí)所創(chuàng)建的進(jìn)程所啟動(dòng)的專門管理activity生命周期事務(wù)的線程；有一個(gè)activity運(yùn)行 就有一個(gè)進(jìn)程，就有一個(gè)

18、ActivityThread； ActivityThread有一個(gè)main方法，這是app層activity創(chuàng)建該線程的入口，最后通過attach方法進(jìn)行回調(diào)，通知上層進(jìn)程和線程都創(chuàng)建起來了（你可以顯示了）。 而ActivityManagerService是通過systemMain來創(chuàng)建的線程，進(jìn)程則不需要?jiǎng)?chuàng)建了，因位他本來就是zygote拉起的systemserver進(jìn)程的一部分。 可見，本質(zhì)上是一樣的，只是ActivityManagerService和app層activity創(chuàng)建線程的入口不同，權(quán)限不同。 以上其實(shí)就是所謂的android運(yùn)行時(shí)環(huán)境，把進(jìn)程的處理放在后臺(tái)，普通java程序員

19、根本不需要知道進(jìn)程概念，只需要知道android環(huán)境就夠了。3.1.3創(chuàng)建ActivityStackSupervisor實(shí)例記錄到mStackSupervisor，ActivityStackSupervisor是啟動(dòng)launcher的直接起點(diǎn)，放到后面講.3.1.4調(diào)用startRunning這里的systemReady(null)不會(huì)被執(zhí)行. ,這里完成初始化的參數(shù)值得注意:mTopComponent:棧頂Component為空mTopAction:棧頂動(dòng)作是: Intent.ACTION_MAINmTopData:棧頂activity數(shù)據(jù)為空3.2 ActivityManagerServi

20、ce之setSystemProcess回顧下ActivityManagerService在systemserver中的第二個(gè)動(dòng)作:下面看下setSystemProcess的實(shí)現(xiàn)Context.ACTIVITY_SERVICE在frameworksbasecorejavaandroidcontentContext.java中的定義: 則其他地方可以通過ServiceManager.getService("activity"/*或Context.ACTIVITY_SERVICE*/)來使用ActivityManagerService的單例mSelf。另外framework-re

21、s.apk的包名是android，可以查看frameworksbasecoreres下的Android.mk和AndroidManifest.xml。3.3. ActivityManagerService之setWindowManager回顧下ActivityManagerService在systemserver中的第4個(gè)動(dòng)作:(第三個(gè)動(dòng)作是installSystemProviders，偏離主題太遠(yuǎn),跳過)這樣一來ActivityManagerService和ActivityStackSupervisor都得到了全局WindowManagerService的實(shí)例.3.4 ActivityMan

22、agerService之systemready回顧下ActivityManagerService在systemserver中的第5個(gè)動(dòng)作: systemready方法在ActivityManagerService的main方法中調(diào)用startRunning的時(shí)候被調(diào)用了一次，但是并沒有執(zhí)行，所以真正執(zhí)行systemready還是要按看這里。下面分析systemready的具體實(shí)現(xiàn)3.4.1 啟動(dòng)所有Persistent屬性的APK進(jìn)入frameworksbaseservicesjavacomandroidserverpmPackageManagerService.java：這個(gè)函數(shù)將遍歷所有a

23、pk，具備Persistent屬性，且當(dāng)前不是安全模式啟動(dòng)，或者這個(gè)apk同時(shí)是system屬性，就會(huì)被load加入list列表回到ActivityManagerService.java看下addAppLocked如何拉起這些apk的進(jìn)程:3.4.2 啟動(dòng)launcher調(diào)用mStackSupervisor.resumeTopActivitiesLocked();真正開始啟動(dòng)luancher.注意如果luancher具備了persistent屬性，則顯然luancher的進(jìn)程已經(jīng)先于activity的調(diào)用被拉起來了。這里產(chǎn)生了一個(gè)問題： mStackSupervisor.resumeTopAc

24、tivitiesLocked()這個(gè)動(dòng)作在拉起所有persistent屬性的apk之后，如果luancher也具備這個(gè)屬性，是不是意味著luancher的進(jìn)程一定會(huì)先于后面這個(gè)動(dòng)作先啟動(dòng)？ 答案是不一定，這里先解答一下。啟動(dòng)進(jìn)程的startProcessLocked是通過socket通訊去通知底層zygote進(jìn)程創(chuàng)建子進(jìn)程，而這個(gè)通知發(fā)出后，該函數(shù)就直接返回了，連執(zhí)行結(jié)果都不需要等待，所以下面到底何時(shí)能創(chuàng)建這個(gè)子進(jìn)程，要看子進(jìn)程有多少，排在第幾位，何時(shí)socket得到響應(yīng)。所以不排除，真正啟動(dòng)luancher進(jìn)程的動(dòng)作比后面這個(gè)mStackSupervisor.resumeTopActivit

25、iesLocked要慢。4 ActivityStackSupervisor啟動(dòng)launcher相關(guān)源代碼路徑:frameworksbaseservicesjavacomandroidserveramActivityStackSupervisor.javaframeworksbaseservicesjavacomandroidserveram ActivityStack.java4.1首先回顧一下ActivityStackSupervisor實(shí)例的初始化1) ActivityStackSupervisor實(shí)例構(gòu)造:systemserver調(diào)用ActivityManagerService的main

26、,后者在最后創(chuàng)建了ActivityStackSupervisor實(shí)例ActivityManagerService.mainActivityStackSupervisor的構(gòu)造函數(shù):這里ActivityStackSupervisor在構(gòu)造時(shí)記錄了ActivityManagerService創(chuàng)建的service實(shí)例，全局context,和looper.2) setWindowManager設(shè)置窗口管理systemserver自己創(chuàng)建了WindowManagerService實(shí)例:systemserver調(diào)用ActivityManagerService的setWindowManager，后者則內(nèi)部調(diào)

27、用了ActivityStackSupervisor的setWindowManagerActivityManagerService. setWindowManager:ActivityStackSupervisor. setWindowManager:注意這里不僅僅是記錄了這個(gè)全局的WindowManagerService,還創(chuàng)建了一個(gè)home屬性的activity?？臻g，mHomeStack，并加入到mStacks，但這里僅僅是mStacks這個(gè)ArrayList<ActivityStack>中加入了這個(gè)數(shù)據(jù)，僅此而已。4.2 進(jìn)入ActivityStackSupervisor.r

28、esumeTopActivitiesLocked這里最終執(zhí)行的是resumeTopActivitiesLocked(null, null, null);mStacks在setWindowManager的時(shí)候已經(jīng)加入了mhomeStack,所以此時(shí)mStacks.size()為1，stack即為mHomeStack，進(jìn)入分支stack.resumeTopActivityLocked(null);4.3 進(jìn)入ActivityStack.resumeTopActivityLocked顯然這時(shí)，topRunningActivityLocked一定返回null,程序回到mStackSupervisor.

29、resumeHomeActivity(prev);prev為NULL。注意： 這里的mStackSupervisor正是ActivityManagerService.main中初始化的 ActivityStackSupervisor，在ActivityStackSupervisor. setWindowManager 內(nèi)部創(chuàng)建ActivityStack實(shí)例mHomeStack被創(chuàng)建的時(shí)候傳進(jìn)來4.4 回到ActivityStackSupervisor.resumeHomeActivity。mHomeStack這個(gè)空間被movetop,但是此時(shí)launcher的activity并沒有運(yùn)行，.to

30、pRunningActivityLocked(null);自然還是null，mIsHomeActivityStarted為false，程序進(jìn)入mProbeThread.start();。注意： mProbeThread是final變量，性質(zhì)是線程，定義時(shí)就初始化，但是并沒有start，所以mProbeThread.isAlive()必為false，mProbeThread.getState() != Thread.State.TERMINATED為true。4.5 ActivityStackSupervisor.mProbeThread mProbeThread為ActivityStackSu

31、pervisor的內(nèi)部類，run方法給handler發(fā)出START_HOME_MSG消息。4.6 ActivityStackSupervisor.mProbeHandlermProbeHandler為私有final成員變量。他的工作只有一個(gè)就是調(diào)用ActivityServiceManger的startHomeActivityLocked，執(zhí)行這一步后mIsHomeActivityStarted變?yōu)閠rue。特別注意：這一步是消息發(fā)送，可能存在調(diào)度問題而導(dǎo)致startHomeActivityLocked實(shí)際調(diào)用慢。前面已經(jīng)分析過，ActivityStackSupervisor中的mService

32、就是ActivityManagerService。4.7 回到ActivityManagerService.startHomeActivityLocked 首先調(diào)用getHomeIntent構(gòu)造一個(gè)intent為CATEGORY_HOME類型，然后通過resolveActivityInfo函數(shù)向PackageManagerService查詢Category類型為HOME的Activity，此時(shí)aInfo即luancher的ActivityInfo。 通過getProcessRecordLocked,進(jìn)一步查詢該app的執(zhí)行情況，如果查不到則表明進(jìn)程都沒啟動(dòng)，如果app進(jìn)程查到了但是instru

33、mentationClass為空則表明activity未啟動(dòng),此時(shí)調(diào)用mStackSupervisor.startHomeActivity(intent, aInfo);4.8 ActivityStackSupervisor.startHomeActivity傳入startActivityLocked的參數(shù)只有intent和aInfo不為空，程序很容易判斷進(jìn)入 err = startActivityUncheckedLocked(r, sourceRecord, startFlags, true, options);r正是根據(jù)intent和ainfo創(chuàng)建的ActivityRecord,直到這時(shí)

34、才有了實(shí)際的Activity準(zhǔn)備啟動(dòng),但是此時(shí)還沒有加入到activityStack的棧頂。4.9 ActivityStackSupervisor.startActivityUncheckedLocked這個(gè)函數(shù)很長，仔細(xì)梳理并通過加打印，確認(rèn)其會(huì)進(jìn)入最后ActivityStack類的的startActivityLocked，而targetStack為之前創(chuàng)建的homestack。特別注意: doResume參數(shù)為true., newTask為true(因?yàn)閱?dòng)方式為Intent.FLAG_ACTIVITY_NEW_TASK)4.10 ActivityStack.startActivityLo

35、cked1）直到這里，launcher的activity才真正加到到activitystack的棧頂。2）正常情況應(yīng)該進(jìn)入第二個(gè)分支的mWindowManager.addAppToken，并最后執(zhí)行if (doResume) mStackSupervisor.resumeTopActivitiesLocked(); 注意：mWindowManager.addAppToken的調(diào)用將當(dāng)前acitivity的apptoken加入到window管理里面去，后面才能把他顯示出來。4.11 ActivityStackSupervisor.resumeTopActivitiesLocked 和前面一樣，這

36、里傳入的參數(shù)為空：程序再回到ActivityStack. resumeTopActivityLocked。4.12 ActivityStack.resumeTopActivityLocked程序走到這里，才終于走到了顯示出launcher的邊緣。下面的resumeTopActivityLocked需要仔細(xì)分析： 這個(gè)函數(shù)的層次：1）if (next = null) ，啟動(dòng)home: resumeHomeActivity2) 目標(biāo)next已經(jīng)是mResumedActivity，直接return3）目標(biāo)next的app和app.thread都已經(jīng)建立，直接進(jìn)入顯示，調(diào)用mWindowManager

37、.setAppVisibility(next.appToken, true)和next.app.thread.scheduleResumeActivity；否則調(diào)用mStackSupervisor.startSpecificActivityLocked(next, true, true)進(jìn)入繼續(xù)做其他處理.顯然此時(shí)不會(huì)走1）；如果能走2），一定是被別的地方已經(jīng)調(diào)用了顯示；那么正常啟動(dòng)應(yīng)該走3）。對于層次3），做下分析： 如果不是persistent屬性的launcher，顯然從前面的分析看，一直走到這里也不會(huì)有人拉起他的進(jìn)程；那么就是說正常情況下，普通不帶persistent屬性的launch

38、er應(yīng)該 會(huì)走到調(diào)用startSpecificActivityLocked，跟蹤也多是如此。 之所以說多是如此，是因?yàn)閷?shí)際上系統(tǒng)上還有其他方法來保證launcher這個(gè)activity進(jìn)程被盡快拉起，所以有時(shí)會(huì)走到“if (next.app != null && next.app.thread != null) ”這個(gè)分支下。問題：有沒有可能走到層次2）上面去？假設(shè)有別的地方還調(diào)用了顯示，何嘗不會(huì)？4.13 ActivityStackSupervisor.startSpecificActivityLocked 此時(shí)，如果滿足條件if (app != null &&

39、; app.thread != null)，則會(huì)調(diào)用realStartActivityLocked。 而如果系統(tǒng)沒有其他地方啟動(dòng)launcher的進(jìn)程，顯然就會(huì)進(jìn)入mService.startProcessLocked(cessName, .applicationInfo, true, 0,"activity", ent.getComponent(), false, false, true);來自己拉起進(jìn)程，那么這個(gè)時(shí)候，誰去顯示？似乎都沒人去顯示launcher了？4.14 ActivityStackSupervisor.realStart

40、ActivityLocked函數(shù)里面: 調(diào)用mWindowManager.setAppVisibility(r.appToken, true);設(shè)置窗口可見； 調(diào)用app.thread.scheduleLaunchActivity啟動(dòng)LaunchActivity的繪制，即oncreate+onresume. 調(diào)用stack.minimalResumeActivityLocked(r);記錄該app為resumed狀態(tài)：走到這里，正常的launcher啟動(dòng)流程就講完了，但卻留下2個(gè)問題：問題1： 如果launcher不帶persistemt屬性，也沒有別的地方會(huì)主動(dòng)創(chuàng)建launcher的進(jìn)程，那

41、么startSpecificActivityLocked會(huì)走入mService.startProcessLocked，而不是realStartActivityLocked，這種情況下誰來顯示？問題2： 假設(shè)有別的地方調(diào)用了realStartActivityLocked，而這時(shí)apptoken沒準(zhǔn)備好，顯然光scheduleLaunchActivity畫好了ui還是顯示不出來，但是這時(shí)卻仍然執(zhí)行了：r.state = ActivityState.RESUMED; 這個(gè)時(shí)候上面的ActivityStack.resumeTopActivityLocked就會(huì)走入層次2，什么都不做就直接return了

42、，導(dǎo)致launcher不顯示。因此我們還有必要跟著mService.startProcessLocked這個(gè)分支再繼續(xù)看看。4.15 ActivityManagerService.startProcessLocked回顧下startSpecificActivityLocked走mService.startProcessLocked的情況： 這段代碼也可以看出，ProcessRecord app由startProcessLocked產(chǎn)生，并同時(shí)創(chuàng)建了一個(gè)app.thread，也就是說每創(chuàng)建一個(gè)進(jìn)程就一定有一個(gè)thread線程，至少對于activity而言是這樣。 (注意:ActivityMana

43、gerService.SystemReady里面在主動(dòng)啟動(dòng)persistent屬性的apk時(shí)，也是調(diào)用的該函數(shù))。繼續(xù)ActivityManagerService.startProcessLocked,繼續(xù)進(jìn)入重載的ActivityManagerService. startProcessLocked（只有3個(gè)參數(shù)）這里有3個(gè)信息值得關(guān)注:1) Process.start: 進(jìn)程啟動(dòng)，Process是進(jìn)程管理類，一直跟蹤下去，會(huì)發(fā)現(xiàn)他最后和zygote進(jìn)程啟動(dòng)的服務(wù)端socket進(jìn)行了通訊，通知zygote分化出一個(gè)子進(jìn)程來。2) android.app.ActivityThread Proce

44、ss.start的時(shí)候，傳入的class名稱是android.app.ActivityThread，這里就是之前說的activity的進(jìn)程一定對應(yīng)著一個(gè)后臺(tái)activitythread進(jìn)程的，activity的所有生命周期動(dòng)作都是activitythread處理的，所以前面真正讓activity顯示的是app.thread的schedule名稱的相關(guān)函數(shù)，后面再分析3)后面的打印信息 這里專門截取這個(gè)打印信息，是為了讓大家看到這種打印數(shù)據(jù)組織方式，同時(shí)知道進(jìn)程創(chuàng)建后，android系統(tǒng)一定有這么一個(gè)打印，我們在看log的時(shí)候就可以關(guān)注這個(gè)信息。 搜索log的時(shí)候也注意，直接搜索整句log，在代

45、碼中是搜索不到的，因?yàn)楹芏嗟胤蕉枷裆厦姹唤財(cái)嗔?，需要搜索單個(gè)字符串。5 Process類管理創(chuàng)建activity進(jìn)程源代碼路徑:frameworksbasecorejavaandroidos Process.java5.1 Process.start:重點(diǎn)關(guān)注前4個(gè)參數(shù)，具體到我們追蹤的luancher:第一個(gè)參數(shù): processclass,android.app.ActivityThread第二個(gè)參數(shù):nicename對應(yīng)著進(jìn)程名稱launcher.第三個(gè)參數(shù):uid,用戶id第四個(gè)參數(shù):gid:用戶組id5.2 Process.startViaZygote5.3 zygoteSendAr

46、gsAndGetResult和 openZygoteSocketIfNeeded1）openZygoteSocketIfNeeded方法：完成了java層LocalSocket 的創(chuàng)建得到sZygoteSocket ，并繼續(xù)完成和zygote進(jìn)程的服務(wù)端zygote這個(gè)socket的連接，繼續(xù)創(chuàng)建sZygoteSocket收發(fā)數(shù)據(jù)用的stream對象和buffer。2)zygoteSendArgsAndGetResult：利用sZygoteWriter發(fā)送創(chuàng)建進(jìn)程需要的參數(shù),包括進(jìn)程名稱nicename(即luancher),進(jìn)程要啟動(dòng)的第一個(gè)class(android.app.Activit

47、yThread),uid和gid等3)底層響應(yīng)參考android系統(tǒng)從init進(jìn)程開始到systemserver啟動(dòng)詳細(xì)流程.docx的6.3.4和6.3.5此時(shí)frameworksbasecorejavacomandroidinternalosZygoteInit.java下的ZygoteInit .runSelectLoop()接收到socket連接請求，繼續(xù)接收參數(shù)列表，開始fork子進(jìn)程，并最終執(zhí)行該進(jìn)程的入口函數(shù)；繼續(xù)進(jìn)入到frameworksbasecorejavacomandroidinternalosZygoteConnection.java的ZygoteConnection

48、.handleChildProc方法。在android系統(tǒng)從init進(jìn)程開始到systemserver啟動(dòng)詳細(xì)流程.docx的6.3.5節(jié)已經(jīng)分析過，ZygoteConnection .handleChildProc執(zhí)行的入口函數(shù)，是app層創(chuàng)建進(jìn)程是傳遞的第一個(gè)參數(shù)所代表的class的main函數(shù)，所以這里就是android.app.ActivityThread的main函數(shù)。到此為止，luancher運(yùn)行需要的子進(jìn)程創(chuàng)建完畢，名稱為launcher,第一個(gè)要執(zhí)行的函數(shù)是android.app.ActivityThread的main。6 ActivityThread線程類分析源代碼路徑: f

49、rameworksbasecorejavaandroidappActivityThread.java6.1 ActivityThread.main分析ActivityThread這個(gè)線程是專門管理activity運(yùn)行生命周期的各種動(dòng)作的封裝。當(dāng)然他實(shí)際還包含了對systemserver這個(gè)進(jìn)程創(chuàng)建管理線程的工作，之前分析過其入口是systemmain，而普通的activity的入口是main；這二者本質(zhì)是一樣的，只是處理的權(quán)限等屬性不同。main做3個(gè)主要的任務(wù)，分析如下:6.1.1創(chuàng)建了looper對象和本線程綁定。 原來我們在activity或service或dialog中可以隨便使用ha

50、ndler是這個(gè)線程在后臺(tái)付出的努力。 關(guān)于handler,looper,messagequeue之間的關(guān)系可以百度或參考深入理解Android 卷1，比較簡單，這里不討論。6.1.2創(chuàng)建了ActivityThread對象實(shí)例注意，當(dāng)new ActivityThread()的時(shí)候，其成員變量 final ApplicationThread mAppThread = new ApplicationThread();同時(shí)被創(chuàng)建。ApplicationThread是內(nèi)部類,繼承自ApplicationThreadNativeApplicationThreadNative繼承自接口IApplicati

51、onThread這意味著mAppThread變量可以直接轉(zhuǎn)換為IApplicationThread。6.1.3進(jìn)行attach回調(diào)ActivityThread.attach注意，這里正是把mAppThread轉(zhuǎn)換為IApplicationThread，再調(diào)用了mgr.attachApplication(mAppThread);。1) ActivityManagerNative. getDefault源代碼路徑frameworksbasecorejavaandroidappActivityManagerNative.java注意，這里有2個(gè)知識(shí)點(diǎn)：a) binder通訊最終調(diào)用到Activity

52、ManagerService.attachApplication gDefault中return的am是ActivityManagerProxy類，傳入的參數(shù)b是一個(gè)binder客戶端(從ServiceManager.getService("activity")可以知道他是ActivityManagerService的ibinder)，該參數(shù)被賦值給mRemote變量。 這時(shí)ActivityThread.attach實(shí)際進(jìn)入ActivityManagerProxy. attachApplicationtransact通訊會(huì)使得服務(wù)端ActivityManagerServic

53、e執(zhí)行onTransact。而ActivityManagerService自己繼承自ActivityManagerNative，也沒有重載onTransact，所以這里會(huì)執(zhí)行ActivityManagerNative.onTransact，進(jìn)入到調(diào)用ActivityManagerService自己的attachApplication方法。b 模板類 gDefault方法返回是一個(gè)模板類Singleton：可以看到，這個(gè)模板類的作用就是將他的模板T統(tǒng)統(tǒng)搞成單例類，以保證ActivityManagerNative. getDefault即使被反復(fù)調(diào)用，都始終只有一個(gè)binder客戶端。2)回到Ac

54、tivityManagerService. attachApplication繼續(xù)看attachApplicationLocked這里有兩件事要關(guān)注：第一：makeActive這個(gè)方法將當(dāng)前thread記錄到了ProcessRecord下，這就是我們之前說的ProcessRecord.thread的來源。第二：程序最終進(jìn)入了mStackSupervisor.attachApplicationLocked，可見如果完全由調(diào)用lucnher的流程自己來拉起他的進(jìn)程的話，最后轉(zhuǎn)了一圈還是回到了mStackSupervisor。mStackSupervisor.attachApplicationLocked到底做了什么？6.1.4 ActivityStackSupervisor.attachApplicationLocked一目了然，這個(gè)時(shí)候會(huì)走到調(diào)用realStartActivityLocked，而這個(gè)函數(shù)在前面4.1.4分析過了，會(huì)調(diào)用ActivityThread.ApplicationThread.scheduleResumeActivity觸發(fā)顯示。6.1.5 ActivityStackSupervisor. ensureActivitiesVisib