詳解Android中的ActivityThread和APP啟動過程
ActiviryThread
ActivityThread的初始化
ActivityThread即Android的主線程,也就是UI線程,ActivityThread的main方法是一個(gè)APP的真正入口,MainLooper在它的main方法中被創(chuàng)建。
//ActivityThread的main方法 public static void main(String[] args) { ... Looper.prepareMainLooper(); ActivityThread thread = new ActivityThread(); //在attach方法中會完成Application對象的初始化,然后調(diào)用Application的onCreate()方法 thread.attach(false); if (sMainThreadHandler == null) { sMainThreadHandler = thread.getHandler(); } ... Looper.loop(); throw new RuntimeException("Main thread loop unexpectedly exited"); }
接下來從主線程Looper的初始化和ApplicationThread及Activity的創(chuàng)建啟動兩方面,通過源碼了解學(xué)習(xí)下大致的流程。
主線程Looper的初始化
Looper.prepareMainLooper();相關(guān)的代碼如下
//主線程Looper的初始化 public static void prepareMainLooper() { prepare(false); synchronized (Looper.class) { if (sMainLooper != null) { throw new IllegalStateException("The main Looper has already been prepared."); } sMainLooper = myLooper(); } } //普通線程Looper的初始化 public static void prepare() { prepare(true); } private static void prepare(boolean quitAllowed) { if (sThreadLocal.get() != null) { throw new RuntimeException("Only one Looper may be created per thread"); } sThreadLocal.set(new Looper(quitAllowed)); }
看過Handler源碼就知道,主線程Looper的初始化和普通線程Looper的初始化很相似,但還是有以下幾個(gè)區(qū)別
1.普通線程的Prepare()默認(rèn)quitAllowed參數(shù)為true,表示允許退出,而主線程也就是ActivityThread的Looper參數(shù)為false,不允許退出。這里的quitAllowed參數(shù),最終會傳遞給MessageQueue,當(dāng)調(diào)用MessageQueue的quit方法時(shí),會判斷這個(gè)參數(shù),如果是主線程,也就是quitAllowed參數(shù)為false時(shí),會拋出異常。
//Looper的退時(shí)會判斷quitAllowed void quit(boolean safe) { if (!mQuitAllowed) { throw new IllegalStateException("Main thread not allowed to quit."); } synchronized (this) { ... } }
2.我們注意到主線程Looper初始化之后,賦值給了成員變量sMainLooper,這個(gè)成員的作用就是向其他線程提供主線程的Looper對象。這下我們就應(yīng)該知道為什么Looper.getMainLooper()方法能獲取主線程的Looper對象了
public static Looper getMainLooper() { synchronized (Looper.class) { return sMainLooper; } }
主線程Handler的初始化
在ActivityThread的main方法中我們注意到一行代碼:
ActivityThread thread = new ActivityThread(); thread.attach(false); if (sMainThreadHandler == null) { sMainThreadHandler = thread.getHandler(); }
見名知意,這是獲取主線程的Handler,那么主線程的Handler是在什么時(shí)候初始化的呢?
//與之相關(guān)的代碼如下: //ActivityThread的成員變量 final H mH = new H(); final Handler getHandler() { return mH; }
從以上代碼中可以看到,主線程的Handler作為ActivityThread的成員變量,是在ActivityThread的main方法被執(zhí)行,ActivityThread被創(chuàng)建時(shí)而初始化,而接下來要說的ApplicationThread中的方法執(zhí)行以及Activity的創(chuàng)建都依賴于主線程Handler。至此我們也就明白了,主線程(ActivityThread)的初始化是在它的main方法中,主線程的Handler以及MainLooper的初始化時(shí)機(jī)都是在ActivityThread創(chuàng)建的時(shí)候。
ApplicationThread及Activity的創(chuàng)建和啟動
以上的代碼和流程,就是對 MainLooper 和 ActivityThread 的初始化,我們接下來看一下 ActivityThread 的初始化及其對應(yīng)的 attach 方法,在thread.attach方法中,ActivityManagerService通過attachApplication方法,將ApplicationThread對象綁定到ActivityManagerService,ApplicationThread是ActivityThread的私有內(nèi)部類,實(shí)現(xiàn)了IBinder接口,用于ActivityThread和ActivityManagerService的所在進(jìn)程間通信。
//ActivityThread的attach方法: private void attach(boolean system) { ... if (!system) { final IActivityManager mgr = ActivityManager.getService(); try { mgr.attachApplication(mAppThread); } catch (RemoteException ex) { throw ex.rethrowFromSystemServer(); }else{ ... } } } //ActivityManagerService中的方法: public final void attachApplication(IApplicationThread thread) { synchronized (this) { int callingPid = Binder.getCallingPid(); final long origId = Binder.clearCallingIdentity(); attachApplicationLocked(thread, callingPid); Binder.restoreCallingIdentity(origId); } }
這里的個(gè)人理解是:在每個(gè)ActivityThread(APP)被創(chuàng)建的時(shí)候,都需要向ActivityManagerService綁定(或者說是向遠(yuǎn)程服務(wù)AMS注冊自己),用于AMS管理ActivityThread中的所有四大組件的生命周期。
上述AMS的代碼中attachApplicationLocked方法比較復(fù)雜,主要功能有兩個(gè),詳見注釋,這里忽略了很多代碼細(xì)節(jié),具體的流程可以看源碼
//AMS中的方法,主要功能有以下兩步 private final boolean attachApplicationLocked(IApplicationThread thread, int pid) { ... //主要用于創(chuàng)建Application,用調(diào)用onCreate方法 thread.bindApplication(...); ... //主要用于創(chuàng)建Activity if (mStackSupervisor.attachApplicationLocked(app)) { ... } }
1.thread.bindApplication:主要用于創(chuàng)建Application,這里的thread對象是ApplicationThread在AMS中的代理對象,所以這里的bindApplication方法最終會調(diào)用ApplicationThread.bindApplication()方法,該方法會向ActivityThread的消息對應(yīng)發(fā)送BIND_APPLICATION的消息,消息的處理最終會調(diào)用Application.onCreate()方法,這也說明Application.onCreate()方法的執(zhí)行時(shí)機(jī)比任何Activity.onCreate()方法都早。
//ActivityThread中的bindApplication方法 public final void bindApplication(...) { ... // 該消息的處理,會調(diào)用handleBindApplication方法 sendMessage(H.BIND_APPLICATION, data); } //ActivityThread中的handleBindApplication方法 private void handleBindApplication(AppBindData data) { ... try { Application app = data.info.makeApplication(data.restrictedBackupMode, null); mInitialApplication = app; ... try { mInstrumentation.callApplicationOnCreate(app); } catch (Exception e) { } } finally { } } //LoadedApk中的方法,用于創(chuàng)建Application public Application makeApplication(boolean forceDefaultAppClass, Instrumentation instrumentation) { //如果存在Application的實(shí)例,則直接返回,這也說明Application是個(gè)單例 if (mApplication != null) { return mApplication; } Application app = null; //...這里通過反射初始化Application if (instrumentation != null) { try { //調(diào)用Application的onCreate方法 instrumentation.callApplicationOnCreate(app); } catch (Exception e) { } } return app; }
2.mStackSupervisor.attachApplicationLocked(app):用于創(chuàng)建Activity,mStackSupervisor是AMS的成員變量,為Activity堆棧管理輔助類實(shí)例,該方法最終會調(diào)用ApplicationThread類的scheduleLaunchActivity方法,該方法也是類似于第一步,向ActivityThread的消息隊(duì)列發(fā)送創(chuàng)建Activity的消息,最終在ActivityThread中完成創(chuàng)建Activity的操作。
boolean attachApplicationLocked(ProcessRecord app) throws RemoteException { ... if (realStartActivityLocked(hr, app, true, true)) { ... } ... } final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app, boolean andResume, boolean checkConfig) throws RemoteException { ... try { //調(diào)用ApplicationThread的scheduleLaunchActivity用于啟動一個(gè)Activity app.thread.scheduleLaunchActivity(...); } catch (RemoteException e) { } }
ApplicationThread的scheduleLaunchActivity方法會向ActivityThread發(fā)送LAUNCH_ACTIVITY信息,用于啟動一個(gè)Activity,該消息的處理會調(diào)用ActivityThread的handleLaunchActivity方法,最終啟動一個(gè)Activity
以上就是從ActivityThread的main方法執(zhí)行到Activity的創(chuàng)建之間的流程,至于ActivityThread的main方法執(zhí)行時(shí)機(jī),以及執(zhí)行前的流程和Activity的具體創(chuàng)建過程,可以接著看APP的啟動過程
APP的啟動
系統(tǒng)的啟動過程
在學(xué)習(xí)APP的啟動之前先簡單了解下系統(tǒng)的啟動,有助于我們更好的學(xué)習(xí)APP的啟動。系統(tǒng)的啟動過程很復(fù)雜,這里簡單化,只關(guān)心大致流程和涉及到的一些名詞以及相關(guān)類的作用
APP的啟動可以簡單總結(jié)為一下幾個(gè)流程:
加載BootLoader --> 初始化內(nèi)核 --> 啟動init進(jìn)程 --> init進(jìn)程fork出Zygote進(jìn)程 --> Zygote進(jìn)程fork出SystemServer進(jìn)程
- 系統(tǒng)中的所有經(jīng)常進(jìn)程都是由Zygote進(jìn)程fork出來的
- SystemServer進(jìn)程是系統(tǒng)進(jìn)程,很多系統(tǒng)服務(wù),例如ActivityManagerService、PackageManagerService、WindowManagerService…都是存在該進(jìn)程被創(chuàng)建后啟動
- ActivityManagerServices(AMS):是一個(gè)服務(wù)端對象,負(fù)責(zé)所有的Activity的生命周期,AMS通過Binder與Activity通信,而AMS與Zygote之間是通過Socket通信
- ActivityThread:本篇的主角,UI線程/主線程,它的main()方法是APP的真正入口
- ApplicationThread:一個(gè)實(shí)現(xiàn)了IBinder接口的ActivityThread內(nèi)部類,用于ActivityThread和AMS的所在進(jìn)程間通信
- Instrumentation:可以理解為ActivityThread的一個(gè)工具類,在ActivityThread中初始化,一個(gè)進(jìn)程只存在一個(gè)Instrumentation對象,在每個(gè)Activity初始化時(shí),會通過Activity的Attach方法,將該引用傳遞給Activity。Activity所有生命周期的方法都有該類來執(zhí)行
APP的啟動過程
APP的啟動,我們使用一張圖來說明這個(gè)啟動過程,順便也總結(jié)下上面所說的ActivityThread的main方法執(zhí)行到Activity的創(chuàng)建之間的流程。
1.點(diǎn)擊桌面APP圖標(biāo)時(shí),Launcher的startActivity()方法,通過Binder通信,調(diào)用system_server進(jìn)程中AMS服務(wù)的startActivity方法,發(fā)起啟動請求
2.system_server進(jìn)程接收到請求后,向Zygote進(jìn)程發(fā)送創(chuàng)建進(jìn)程的請求
3.Zygote進(jìn)程fork出App進(jìn)程,并執(zhí)行ActivityThread的main方法,創(chuàng)建ActivityThread線程,初始化MainLooper,主線程Handler,同時(shí)初始化ApplicationThread用于和AMS通信交互
4.App進(jìn)程,通過Binder向sytem_server進(jìn)程發(fā)起attachApplication請求,這里實(shí)際上就是APP進(jìn)程通過Binder調(diào)用sytem_server進(jìn)程中AMS的attachApplication方法,上面我們已經(jīng)分析過,AMS的attachApplication方法的作用是將ApplicationThread對象與AMS綁定
5.system_server進(jìn)程在收到attachApplication的請求,進(jìn)行一些準(zhǔn)備工作后,再通過binder IPC向App進(jìn)程發(fā)送handleBindApplication請求(初始化Application并調(diào)用onCreate方法)和scheduleLaunchActivity請求(創(chuàng)建啟動Activity)
6.App進(jìn)程的binder線程(ApplicationThread)在收到請求后,通過handler向主線程發(fā)送BIND_APPLICATION和LAUNCH_ACTIVITY消息,這里注意的是AMS和主線程并不直接通信,而是AMS和主線程的內(nèi)部類ApplicationThread通過Binder通信,ApplicationThread再和主線程通過Handler消息交互。 ( 這里猜測這樣的設(shè)計(jì)意圖可能是為了統(tǒng)一管理主線程與AMS的通信,并且不向AMS暴露主線程中的其他公開方法)
7.主線程在收到Message后,創(chuàng)建Application并調(diào)用onCreate方法,再通過反射機(jī)制創(chuàng)建目標(biāo)Activity,并回調(diào)Activity.onCreate()等方法
8.到此,App便正式啟動,開始進(jìn)入Activity生命周期,執(zhí)行完onCreate/onStart/onResume方法,UI渲染后顯示APP主界面
APP啟動過程的部分代碼思考
在上面學(xué)習(xí)APP的啟動過程中,看源碼的同時(shí)注意到一個(gè)代碼,就是主線程Handler在接收到LAUNCH_ACTIVITY創(chuàng)建Activity的消息后,創(chuàng)建Activity的部分代碼如下:
//主線程Handler接收到創(chuàng)建Activity的消息LAUNCH_ACTIVITY后,最終會調(diào)用performLaunchActivity方法 //performLaunchActivity方法會通過反射去創(chuàng)建一個(gè)Activity,然后會調(diào)用Activity的各個(gè)生命周期方法 private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) { ... ContextImpl appContext = createBaseContextForActivity(r); Activity activity = null; try { //這里是反射創(chuàng)建Activity java.lang.ClassLoader cl = appContext.getClassLoader(); activity = mInstrumentation.newActivity( cl, component.getClassName(), r.intent); StrictMode.incrementExpectedActivityCount(activity.getClass()); r.intent.setExtrasClassLoader(cl); r.intent.prepareToEnterProcess(); if (r.state != null) { r.state.setClassLoader(cl); } } try { //這里注意,又調(diào)用了一次Application的創(chuàng)建方法,但是前面分析過,Application是個(gè)單例,所以這里的實(shí)際上是獲取Application實(shí)例,但是這里為什么會再次調(diào)用創(chuàng)建Application的方法呢? Application app = r.packageInfo.makeApplication(false, mInstrumentation); ... } ... return activity; }
在上面的代碼中,簡單注釋了一下在Activity的創(chuàng)建方法中,會再次調(diào)用Application的創(chuàng)建方法(第一次調(diào)用是在接收到BIND_APPLICATION消息的時(shí)候),個(gè)人覺得這里再次調(diào)用Application的創(chuàng)建方法,除了獲取已經(jīng)存在的Application實(shí)例這種情況,另外一種情況還有可能是要創(chuàng)建的這個(gè)Activity屬于另外一個(gè)進(jìn)程,當(dāng)去啟動這個(gè)新進(jìn)程中的Activity時(shí),會先去創(chuàng)建新進(jìn)程和Application實(shí)例,因?yàn)槲覀冎酪粋€(gè)常識:
1.APP中有幾個(gè)進(jìn)程,Application會被創(chuàng)建幾次
2.新進(jìn)程中所有變量和單例會失效,因?yàn)樾逻M(jìn)程有一塊新的內(nèi)存區(qū)域
那么這兩點(diǎn)的關(guān)系就是,因?yàn)樾逻M(jìn)程中Application實(shí)例會為空,所以會再次去創(chuàng)建Application實(shí)例,這也就是第一點(diǎn)中我們所說的常識:APP中有幾個(gè)進(jìn)程,Application會被創(chuàng)建幾次
//創(chuàng)建Application的方法 public Application makeApplication(boolean forceDefaultAppClass, Instrumentation instrumentation) { //如果存在Application的實(shí)例,則直接返回,這也說明Application是個(gè)單例 if (mApplication != null) { return mApplication; } Application app = null; //...創(chuàng)建Application return app; }
那么依次類推,Service作為四大組件之一,類似于Activity的創(chuàng)建和啟動,創(chuàng)建Service的方法中會不會也調(diào)用了創(chuàng)建Application的方法(makeApplication方法),答案是肯定的!和Activity的創(chuàng)建類似,當(dāng)我們調(diào)用startService的時(shí)候,也是通過Binder向AMS發(fā)送創(chuàng)建Service的請求,AMS準(zhǔn)備后再向APP進(jìn)程發(fā)送scheduleCreateService的請求,然后主線程handle收到CREATE_SERVICE的消息,調(diào)用handleCreateService創(chuàng)建Service的方法。在創(chuàng)建Service的方法handleCreateService中也調(diào)用了創(chuàng)建Application的方法,具體代碼看源碼吧。所以我們也徹底明白了為什么APP中有幾個(gè)進(jìn)程,Application會被創(chuàng)建幾次,以及Application為什么是個(gè)單例。
總結(jié)
APP的啟動過程很復(fù)雜,代碼錯(cuò)綜交橫,這里分析了大概流程,學(xué)習(xí)這部分的過程中還是有很多收獲,例如知道了AMS與主線程的關(guān)系,主線程main方法中就是APP的入口,Binder通信機(jī)制和handler消息機(jī)制在這個(gè)過程中的重要作用,Application的創(chuàng)建時(shí)機(jī)以及Application為什么是單例,為什么有幾個(gè)進(jìn)程就創(chuàng)建幾個(gè)Application…等等 。
以上就是詳解Android中的ActivityThread和APP啟動過程的詳細(xì)內(nèi)容,更多關(guān)于Android ActivityThread APP啟動過程的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Android 4.4以上"沉浸式"狀態(tài)欄效果的實(shí)現(xiàn)方法
Android與ios效果互仿早已不是什么稀奇的事,我猜大概這個(gè)效果來自ios吧,有爭議說這種效果不能叫做沉浸式,叫透明狀態(tài)欄更合適,我也感覺這和沉浸式的含義不太一致。但是大家都這么叫了,那就這樣唄。下面來一起看看關(guān)于Android 4.4以上"沉浸式"效果的實(shí)現(xiàn)方法。2016-09-09Android開發(fā)中MotionEvent坐標(biāo)獲取方法分析
這篇文章主要介紹了Android開發(fā)中MotionEvent坐標(biāo)獲取方法,結(jié)合實(shí)例形式分析了MotionEvent獲取坐標(biāo)的相關(guān)函數(shù)使用方法與相關(guān)注意事項(xiàng),需要的朋友可以參考下2016-02-02Android 個(gè)人理財(cái)工具一:項(xiàng)目概述與啟動界面的實(shí)現(xiàn)
本文主要介紹Android 開發(fā)個(gè)人理財(cái)工具項(xiàng)目概述與啟動界面的實(shí)現(xiàn),這里主要對實(shí)現(xiàn)項(xiàng)目的流程做了詳細(xì)概述,并對啟動界面簡單實(shí)現(xiàn),有需要的小伙伴可以參考下2016-08-08flutter實(shí)現(xiàn)磨砂玻璃效果實(shí)例詳解
這篇文章主要為大家介紹了flutter實(shí)現(xiàn)磨砂玻璃效果實(shí)例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-11-11Android App實(shí)現(xiàn)應(yīng)用內(nèi)部自動更新的最基本方法示例
這篇文章主要介紹了實(shí)現(xiàn)Android App內(nèi)部自動更新的最基本方法示例,包括IIS服務(wù)器端的簡單布置,需要的朋友可以參考下2016-03-03Android開發(fā)組件flutter的20個(gè)常用技巧示例總結(jié)
這篇文章主要為大家介紹了Android開發(fā)組件flutter的20個(gè)常用技巧示例總結(jié),有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-05-05Kotlin1.6.20新功能Context?Receivers使用技巧揭秘
這篇文章主要為大家介紹了Kotlin1.6.20功能Context?Receivers使用揭秘,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-06-06