Android App 啟動時的操作之 ClassLoader 和 Application 初始化

摘要： Android App 啟動時的操作之 ClassLoader 和 Application 初始化 公共部分 ActivityManagerService.startProcessLocked()當 app 啟動時, ActivityManagerService.st...

Android App 啟動時的操作之 ClassLoader 和 Application 初始化

公共部分

1. ActivityManagerService.startProcessLocked()

   當 app 啟動時, ActivityManagerService.startProcessLocked() 是 app 啟動時啟動程序的地方。

2. ZygoteInit.java 的過程

   startSystemServer() 方法 -> Zygote.forkSystemServer()

3. RuntimeInit.invokeStaticMain() 反射調回到 ActivityThread.main(...)

   //反射呼叫 ActivityThread.main(...) 
   m = cl.getMethod("main", new Class[] { String[].class });

上面做了一個簡述。

Application 和 ClassLoader 部分

1. 補充部分-有關 ClassLoader

在 app 裡，系統類載入器有三種： BootClassLoader , PathClassLoader , DexClassLoader 。

1. BootClassLoader 是用來載入系統 framework 層級的類載入器， 同時它也是 app 中所有 ClassLoader 的最頂層的 parent

   Android系統啟動時會使用 BootClassLoader 來預載入常用類

   是個單例。是 ClassLoader 的一個私有內部類

2. PathClassLoader 是用來載入應用程式的類， 通常是載入已經安裝好的 apk 檔案

3. DexClassLoader 可以載入 dex 檔案以及包含 dex 的 apk 檔案（安裝好的程式和未安裝的 dex 檔案）

   實際上 DexClassLoader 的載入範圍比 PathClassLoader 的載入範圍要大, 它可以載入在 SD 上面的 .jar 和 .apk 檔案。

   在一些動態修復，補丁包上面，是利用 DexClassLoader 去實現的。

現在引出一個問題，Application 的 類載入器 是哪個？？

程式碼檢驗一下：

ClassLoader classLoader = baseContext.getClassLoader();
if (classLoader != null) {

Log.i(TAG, "classLoader is " + classLoader.toString() + " --->from Log");

while (classLoader.getParent() != null) {
classLoader = classLoader.getParent();
Log.i(TAG, "classLoader is " + classLoader.toString() + " --->from Login while");
}
}

列印結果為:

ThemeLayoutContainer: classLoader is dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.example.chenzhao.thememaintest-1/base.apk"],nativeLibraryDirectories=[/data/app/com.example.chenzhao.thememaintest-1/lib/arm, /data/app/com.example.chenzhao.thememaintest-1/base.apk!/lib/armeabi-v7a, /vendor/lib, /system/lib]]] --->from Log
ThemeLayoutContainer: classLoader is java.lang.BootClassLoader@f42ce93 --->from Login while

從上面可以看到， 載入 application 的類載入器為 dalvik.system.PathClassLoader , 並且它與包名 com.example.chenzhao.thememaintest-1/base.apk 是相關的，也就是一對一對應的。

為什麼會有 parent 這個屬性？

ClassLoader 的 loadclass() 採用的是 （雙）父親委託模型， 在 BootClassLoader 是 PathClassLoader 的父親，同時它也是最頂層的一個 classLoader .（腦補樹的圖）

loadclass() 的步驟：載入類 ATest.class

1. 會先查詢當前 ClassLoader ( AClassLoader ) 是否 載入過 ATest ，載入過就返回；

   注： 注意是 載入過 !!

2. 如果沒有，查詢 它 ( AClassLoader ) 的 parent 是否已經載入過 ATest ，如果有，就直接返回 parent 載入過的類, 如果沒有，依次向上去尋找它的 parent ；

3. 如果繼承路線上的 ClassLoader 都沒有載入，則會用它 ( AClassLoader ) 去載入該類 ATest ;

4. 當一個類被位於樹根 的 ClassLoader 載入過，那麼， 在以後整個系統的生命週期內，這個類永遠不會被重新載入

   樹根的 ClassLoader 在 Android 系統中是 BootClassLoader

2. 正式開始，那麼，PathClassLoader 是什麼時候初始化的呢？

一切都需要從 ActivityThread.main(...) 說起

當一個程序被建立成功後，會走到 ActivityThread.main(...) ,

//ActivityThread.java
public static void main(String[] args) {

...

Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
thread.attach(false);
...

Looper.loop();

throw new RuntimeException("Main thread loop unexpectedly exited");
}

上述程式碼，主要的操作在 thread.attach(false);

呼叫次序：

1. thread.attach(false) ;

   這是第一步，如圖上所示 1. thread.attach(false) : 大致程式碼如下：

   final IActivityManager mgr = ActivityManager.getService();
   //在這裡 mgr 是 AMS(ActivityManagerService)
   try {
   mgr.attachApplication(mAppThread);
   } catch (RemoteException ex) {
   throw ex.rethrowFromSystemServer();
   }

   關鍵程式碼：呼叫了 mgr.attachApplication(...) ;

2. mgr.attachApplication(mAppThread) ;

   mgr 是 IActivityManager ，在這裡是 ActivityManagerService , 即 ActivityManagerService.attachApplication(mAppThread) ；

   那麼需要去 AMS 裡面尋找對應相關程式碼.

3. ActivityManagerService.attachApplicationLocked(thread, callingPid);

   在它的裡面，會呼叫 thread.bindApplication()

   thread 為傳過來的引數，是在 ActivityThread 裡面的一個成員變數, 它的賦值是在初始化時完成的，程式碼如下：

   // ActivityThread 裡面
   final ApplicationThread mAppThread = new ApplicationThread();

   是 ApplicationThread 的一個物件，它是 ActivityThread 的內部類，再次回到 ActivityThread , 去找 thread.bindApplication() 這個方法，進入第 4 步;

4. ApplicationThread.bindApplication()

   在這方法裡面，最主要的程式碼就是 sendMessage(H.BIND_APPLICATION, data);

   發了一條 message （是主執行緒的 handler 傳送的訊息）， 在 handleMessage(Message) 裡面處理了該訊息。

   AppBindData data = (AppBindData)msg.obj;
   handleBindApplication(data);

   注：在 handleMessage(Message) 這個方法裡面可以看到，是主執行緒的處理位置，裡面有很多管理 activity 生命週期的方法和引數， 它便是主執行緒處理訊息的地方。

5. ActivityThread.handleBindApplication(data)

   這個方法太長了，太長了！主要程式碼看下面的部分：

   Application app = data.info.makeApplication(data.restrictedBackupMode, null);
   mInitialApplication = app;
   ...
   //其實這一步是呼叫的 application的 onCreate() 方法. 如時序圖中的
   mInstrumentation.callApplicationOnCreate(app);

   data.info 是什麼？ 在這裡是 LoadedApk 這個物件, 這個類是一個比較重要的類，可以多關注下.

   注：這裡稍微注意一下 mInitialApplication 賦值的操作

6. LoadedApk.makeApplication(..., null);

   在 LoadedApk.makeApplication() 裡面的程式碼會去獲取 ClassLoader , 並且建立 appContext , 再通過 ClassLoader 和 appContext 去建立 application 物件;

   try {
   java.lang.ClassLoader cl = getClassLoader();
   if (!mPackageName.equals("android")) {
   Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER,
   "initializeJavaContextClassLoader");
   initializeJavaContextClassLoader();
   Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
   }
   ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
   app = mActivityThread.mInstrumentation.newApplication(
   cl, appClass, appContext);
   appContext.setOuterContext(app);
   } catch (Exception e) {
   ...

   終於看到了有關 ClassLoader 的部分。下面具體看 ClassLoader 是如何建立的。 如圖上右上角。

7. LoadedApk.getClassLoader()

   首先假設這個時候 mClassLoader 是空的，然後去看一下 ClassLoader 的建立：（其實這個時候已經被創建出來了）

   public ClassLoader getClassLoader() {
   synchronized (this) {
   if (mClassLoader == null) {
   createOrUpdateClassLoaderLocked(null /*addedPaths*/);
   }
   
   return mClassLoader;
   }
    }

   注：實際上 LoadedApk.getClassLoader() 在這裡並不為 null, ClassLoader 真正建立是在程式的前面，這裡暫不做分析.

8. LoadedApk.createOrUpdateClassLoaderLocked(null)

   在這個方法裡面， LoadedApk 的 mIncludeCode = true;

   會走到:

   if (mClassLoader == null) {
   // Temporarily disable logging of disk reads on the Looper thread
   // as this is early and necessary.
   StrictMode.ThreadPolicy oldPolicy = StrictMode.allowThreadDiskReads();
   
   mClassLoader = ApplicationLoaders.getDefault().getClassLoader(zip,
   mApplicationInfo.targetSdkVersion, isBundledApp, librarySearchPath,
   libraryPermittedPath, mBaseClassLoader);
   
   StrictMode.setThreadPolicy(oldPolicy);
   // Setup the class loader paths for profiling.
   needToSetupJitProfiles = true;
   }

   那麼接下來，看一下 ApplicationLoaders.getDefault().getClassLoader(...)

   注： mIncludeCode 是一個標誌位，去載入 APK 時是否需要載入它的原始碼。 mIncludeCode 在一些比較 hack 的方式去獲取其他 apk 的 context 時, true 和 false 是有區別的。

9. ApplicationLoaders 這個類

   對於 ApplicationLoaders 這個類，是個單例，它裡面維護了一個 mLoaders ， 它是一個 map ， key 為 string （可以看做是 包名）， value 為 ClassLoader (類載入器)，

   看一下 getClassLoader() 的實現：

   public ClassLoader getClassLoader(String zip, ... ) {
   
   ...
   // 首先 檢查 mLoaders map 裡 是否有該 loader， 有即返回，
   //沒有則建立一個新的 pathClassLoader, 並把新建的 loader 加入 mLoaders
   
   ClassLoader loader = mLoaders.get(zip);
   if (loader != null) {
   return loader;
   }
   
   PathClassLoader pathClassloader = PathClassLoaderFactory.createClassLoader(...);
   ...
   mLoaders.put(zip, pathClassloader);
   
   return pathClassloader;
   
   ... 
   }

   到這裡為止，一個 app 對應的程序的 ClassLoader 才被建立成功.

   注：這裡應該注意到 ApplicationLoaders 裡面是可以對應儲存多個 APK 的 ClassLoader 的

上述 1～9 是 app 啟動時的一系列動作，7～9 分析的是 ClassLoader 的建立過程。下面我們看一下 Application 的建立過程。

從第 6 條開始：

app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);

如圖上右邊 Application 建立時序圖 ：

1. Instrumentation 是什麼？

   Instrumentation 是 android 系統裡面的一套控制方法或者“鉤子”，我理解的是，它可以在正常的生命週期（正常是有系統控制的）之外控制 android 的執行， 拿到一些流程控制的時機，然後我們就可以在這些時機裡面寫一些處理我們想要的東西。它提供了各種流程控制方法，例如下面的方法：

   callActivityOnCreate()-----> 對應著系統的 onCreate();
   
   callActivityOnStart()-----> 對應著系統的 onStart();
   
   callActivityOnDestroy()-----> 對應著系統的 onDestroy();

   所以 當我們去新建一個類， 繼承與 Instrumentation , 重寫一些方法，在這些方法裡面我們就可以自由的做一些控制的事情，例如，新增自動測試模組等。

   Instrumentation.newApplication(cl, appClass, appContext) 的三個引數：

   • cl 根據上面可知道，它是 ClassLoader

   • appClass 當前 app application 的名字:

     appClass = mApplicationInfo.className;

   • appContext: 是當前這個 app 對應的 context

     作為引數去建立 application 時， 在 application.attach(context), 把該 context 作為 application 的 context.

2. Instrumentation.newApplication(...)

   程式碼：

   return newApplication(cl.loadClass(className), context);

   本質上是通過 ClassLoader 根據路徑名去 loadClass(className) 。

   結合 ClassLoader 的 loadClass() 的邏輯.

   VMClassLoader
   

3. Instrumentation.newApplication(clazz, context);

   程式碼：

   Application app = (Application)clazz.newInstance();
   app.attach(context);
   return app;

   例項話 application 物件，然後賦值給 app , return .

   上述實際上已經完成了 application 物件的建立

4. Application 的 app.attach(context) 是做什麼？

   跳轉到 Application 中，進入到程式碼裡可以看到：

   /* package */ final void attach(Context context) {
   attachBaseContext(context);
   mLoadedApk = ContextImpl.getImpl(context).mPackageInfo;
   }

   手動呼叫了 attachBaseContext(context) 這個方法。

   注：手動跳轉到 ContextWrapper.attachBaseContext()

   在 Application 的回撥方法裡面，我們通常會用到的兩個方法：

   • attachBaseContext(context)

   • onCreate()

   當一個 Application 建立起時， 會首先呼叫 attachBaseContext() 這個方法。那麼什麼時候，才會呼叫 onCreate() 呢？

   接著去尋找呼叫 onCreate() 的時機。

5. Application 呼叫 onCreate()

   回到上面的第 5 步： ActivityThread.handleBindApplication(data)

   在其方法裡面：

   Application app = data.info.makeApplication(data.restrictedBackupMode, null);
   
   mInitialApplication = app;
   ...
   
    try {
   mInstrumentation.callApplicationOnCreate(app);
    } catch (Exception e) {
    ...

   這個時候，呼叫了 mInstrumentation.callApplicationOnCreate(app)； , 呼叫位置標註為 C 處

   注： makeApplication(...) 呼叫時，傳入的第二個引數為 instrumentation = null , 在 makeApplication(...) 下有關於 instrumentation 的判斷

6. Instrumentation.callApplicationOnCreate(app)

   這個方法裡面比較簡單：

   // app 為 application 物件
   app.onCreate();

   所以在 Application 裡面 attachBaseContext() 是早於 onCreate() 的呼叫的。

   如圖所示：呼叫 application.attachBaseContext() 的位置是 A, 呼叫 application.onCreate() 的位置是 C.

Application 中 getApplicationContext() 與上述兩個方法的關係

在程式碼呼叫中，

• 在 attachBaseContext() 裡呼叫 getApplicationContext() 返回的為 null ;

• 在 onCreate() 裡呼叫 getApplicationContext() 返回的不為 null ;

為什麼呢？ 圖示如左下角：

看一下 getApplicationContext() 呼叫棧:

1. 會首先在 ContextWrapper.java 裡面 getApplicationContext() :

   return mBase.getApplicationContext();

2. mBase 是什麼？

   是一個 Context 物件，在 Application.attachBaseContext() 時被賦值的。

   去 ContextImpl.java 裡面去看。

3. ContextImpl.getApplicationContext()

   程式碼如下：

   return (mPackageInfo != null) ?
   mPackageInfo.getApplication() : mMainThread.getApplication();

   梳理一下邏輯：

   1. mPackageInfo 什麼時候賦值的？是否為 null

      mPackageInfo 是 LoadedApk 的物件

      該 mBase 是在 LoadedApk 通過 ContextImpl.createAppContext(mActivityThread, this) 裡建立的，

      mPackageInfo = packageInfo; 出現在 ContextImpl 的建構函式裡面，不為 null ， 為 this( 為 LoadedApk)

   2. mPackageInfo.getApplication()

      返回的是 return mApplication;

      mApplication 是什麼時候賦值的呢？

4. 在 mPackageInfo.getApplication() 裡 mApplication 的賦值

   在 LoadedApk.getApplication() 裡面 對 mApplication 的賦值只有一處, 出現在 LoadedApk.makeApplication() 裡面

   app = mActivityThread.mInstrumentation.newApplication(
   cl, appClass, appContext);
   ...
   mApplication = app;

   我們已經知道，在 mActivityThread.mInstrumentation.newApplication(...) 的時候， Application 已經呼叫了 attachBaseContext() 所以當在 attachBaseContext() 裡面呼叫 getApplicationContext() 時，返回的值為 null .

   而 mApplication = app; 之後，才執行了 Application.onCreate() .

總結：

從上述步驟，總結一下，可以看到：

1. ClassLoader 的建立要早於這個 Apk 裡所有的 Class ;

2. PathClassLoader 是和 APK 相互對應的， PathClassLoader 的 DexPathList 是與 APK 的安裝路徑一一對應的;

3. 一個程序是可以對應多個 ClassLoader 的。 在 ApplicationLoader 裡面有一個 ArrayMap<String, ClassLoader> mLoaders ;

4. Application 的建立是利用 ClassLoader 的 loadclass() 實現的

5. Application 的 attachBaseContext() 是早於 onCreate() 的呼叫的

6. getApplicationContext() 不為 null 是晚於 attachBaseContext() ， 早於 onCreate() 方法的

坑邊閒話

關於這部分的內容，有些枯燥，檢視原始碼的過程比較枯燥，這裡面的原始碼具體 api 是 26 還是多少，暫時不定，因為後面你如果自己看原始碼可能會發現 api 已經修改了，但大體是這樣一個流程。

希望能在檢視這個流程中得到意外的收穫～

當然文中不可避免可能會出現錯誤，我的一些理解可能不足夠準確，希望不會對看到文章的同學造成困擾。

參考連結：

1. 以 ClassLoader 為視角看 Android 應用的啟動過程

2. ClassLoader的來源

3. 理解Android程序建立流程

4. Android 原始碼, Zygote.java , ActivityManagerServer.java , Process , ZygoteInit.java , ActivityThread.java , LoadedApk.java , ApplicationLoaders.java