工作多年,首次寫文章,确實有些汗顔,作為一個Android系統開發人員,還是應該覺得記錄點心得和經驗,否則感覺從來沒踏入過這個領域一般.
廢話不多說,直接上正題:
作為Android四大元件之一的Activity想必大家知道它的重要性,那麼大家知道它如何建立,怎麼出現生命周期的,如何呈現在大家眼前,以及如何與使用者事件互動等等一系列的問題,這篇先從它如何被建立以及如何出現生命周期,怎麼管理開始.
啟動Activity的方式:
1.adb shell am start -n ｛包(package)名｝/｛包名｝.{活動(activity)名稱} 可以打開相應的Activity
2.使用者點選Launcher應用圖示啟動一個應用的入口Activity(android.intent.action.main所指的Activity) ,這個動作會最終調用Launcher的startActivity方法.檢視源碼可知道
Launcher#startActivity-------->Activity#startActivity--------->Activity#startActivityForResult---------->Instrumentation#execStartActivity方法
這裡講下Instrumentation#execStartActivity方法Instrumentation.execStartActivity(this, mMainThread.getApplicationThread(), mToken, this,intent, requestCode, options);可以發現mMainThread.getApplicationThread() 該參數是個IBinder類型,mToken也是個IBinder類型,這裡主要關注一下mMainThread.getApplicationThread(),有Binder即有程序間互動,目前還是處于launcher程序,因為是launcher啟動的App,目前App程序還沒建立出來,繼續看源碼可以看到
Instrumentation#execStartActivity---------->ActivityManager.getService()#startActivity--------->ActivityManager.getService()#startActivity 這裡面第一個參數為whoThread即是launcher程序.再看ActivityManager.getService()這條線
ActivityManager.getService()------------->IActivityManagerSingleton.get()單例模式具體可以看Singleton這個類get方法---------->
可以發現這裡就是我們所熟悉的獲得系統服務的步驟,即可以通過binder機制獲得服務端的Ibinder轉成用戶端的IActivityManager,其實對應的還是服務端的ActivityManagerService在處理.如果有了解Binder機制的同學可以知道服務端和用戶端都有對應的Manager，比如ActivityManagerService和ActivityManager,他們基本上名字多了個Service除外,方法基本一模一樣,調用用戶端的方法會通過binder機制傳到服務端去處理(這裡的用戶端服務端都是相對的,可以自行檢視binder機制,此處不做擴充).即目前從launcher程序轉到了AMS所在程序也就是系統程序.
也就是ActivityManager.getService()#startActivityAsUser---------------->AMS#startActivityAsUser方法,接下來AMS#startActivityAsUser-------------------->ActivityStarter#startActivityMayWait------------------>ActivityStarter#startActivityLocked-------------------->ActivityStarter#startActivity(ActivityStarter裡面重載方法太多,找準對應的參數= =)------------->ActivityStarter#startActivityUnchecked-------->ActivityStackSupervisor#resumeFocusedStackTopActivityLocked---------------->ActivityStack#resumeTopActivityUncheckedLocked------------>ActivityStack#resumeTopActivityInnerLocked
這裡大緻講下resumeTopActivityInnerLocked該方法主要判斷next.app和next.app.thread(這裡就是我們新的app程序)是否被建立,
如果沒被建立則走下面流程
接着ActivityStack#resumeTopActivityInnerLocked----------------->ActivityStackSupervisor#startSpecificActivityLocked----------------->AMS#startProcessLocked(由于是第一次啟動新的app,此時app線程(也就是ActivityThread)沒有建立,最終還是由底層的zygote程序孵化,具體請參照源碼)等到app程序建立好之後再到ActivityStackSupervisor#realStartActivityLocked方法中.
ActivityStackSupervisor#realStartActivityLocked--------->app.thread.scheduleLaunchActivity(app.thread==ProcessRecord.IApplicationThread這裡有"I"大家明白了吧,此處是個binder)
那麼看下IApplication的實作類是在ActivityThread中(通過binder機制已經轉回到新的app程序中)
app.thread.scheduleLaunchActivity-------->ApplicationThread#scheduleLaunchActivity------>
通過LAUNCH_ACTIVITY找到對應的處理方法ActivityThread#handleLaunchActivity------>ActivityThread#performLaunchActivity
看performLaunchActivity該方法可以知道通過反射建立所需的Activity類
之後就調用我們熟悉的onCreate方法了.到此Activity源碼啟動過程分析結束了..
對于以上知識總結如下:
1.前一個程序調用.2.建立新的Activity資訊.3.建立新的app程序.4.将activity生命周期進行管理是在ApplicationThread中,Handler來接收消息通過Instrument輔助類處理.4.整個流程用了三次跨程序通信,一個是launcher程序通知系統程序,一個是系統程序通知zygote程序,另一個是系統程序通知新的app程序.
最後本文涉及到遺留問題說明:
1.Binder機制沒有詳細寫出
2.系統程序如何建立的沒有寫出
3.系統如何通過AMS#startProcessLocked該方法把要啟動的app程序建立的,沒有深入探究
4.一些Activity的相關類沒有詳細介紹比如ActivityStack,ActivityStack,ProcessRecord,ActivityStackSupervisor,ActivityStarter
至此,一個大緻流程已經出來,僅供參考.如發現有任何問題,歡迎指正.