Android apk動態加載機制的研究（二）：資源加載和activity生命週期管理

轉載請註明出處：http://blog.csdn.net/singwhatiwanna/article/details/23387079 （來自singwhatiwanna的csdn博客）

前言

爲了更好地閱讀本文，你需要先閱讀Android apk動態加載機制的研究這篇文章，在此文中，博主分析了Android中apk的動態加載機制，並在文章的最後指出需要解決的兩個複雜問題：資源的訪問和activity生命週期的管理，而本文將會分析這兩個複雜問題的解決方法。需要說明的一點是，我們不可能調起任何一個未安裝的apk，這在技術上是無法實現的，我們調起的apk必須受某種規範的約束，只有在這種約束下開發的apk，我們才能將其調起。另外，本文給出的解決方案也不是完美的，但是邏輯已經可以正常地跑通了，剩下的極個別細節問題是可以優化的。

資源管理

我們知道，宿主程序調起未安裝的apk，一個很大的問題就是資源如何訪問，具體來說就是，凡是以R開頭的資源都不能訪問了，因爲宿主程序中並沒有apk中的資源，所以通過R來加載資源是行不通的，程序會報錯：無法找到某某id所對應的資源。針對這個問題，有人提出了將apk中的資源在宿主程序中也copy一份，這雖然能解決問題，可以一聽起來就很奇怪，首先這樣會持有兩份資源，會增加宿主程序包的大小，其次，沒發佈一個插件都需要將資源copy到宿主程序中，這樣就意味着每發佈一個插件都要更新一下宿主程序，這和插件化的思想是相悖的，插件化的目的就是要減小宿主程序apk包的大小同時降低宿主程序的更新頻率並做到自由裝載模塊。所以這種方法並不可行。還有人提供了一種方式：將apk中的資源解壓出來，然後通過文件流去讀取資源，這樣做理論上是可行的，但是實際操作起來還是有很大難度的，首先不同資源有不同的文件流格式，比如圖片、xml等，還有就是針對不同設備加載的資源可能是不一樣的，如果選擇合適的資源也是一個需要解決的問題，基於這兩點，這種方法不建議使用，因爲它實現起來有難度。下面說說本文所採用的方法。

我們知道，activity的工作主要是由ContextImpl來完成的， 它在activity中是一個叫做mBase的成員變量。注意到Context中有如下兩個抽象方法，看起來是和資源有關的，實際上context就是通過它們來獲取資源的，這兩個抽象方法的真正實現在ContextImpl中。也即是說，只要我們自己實現這兩個方法，就可以解決資源問題了。

    /** Return an AssetManager instance for your application's package. */
    public abstract AssetManager getAssets();

    /** Return a Resources instance for your application's package. */
    public abstract Resources getResources();

下面看一下如何實現這兩個方法

首先要加載apk中的資源：

[java] view plaincopy

1. protected void loadResources() {  
2.     try {  
3.         AssetManager assetManager = AssetManager.class.newInstance();  
4.         Method addAssetPath = assetManager.getClass().getMethod("addAssetPath", String.class);  
5.         addAssetPath.invoke(assetManager, mDexPath);  
6.         mAssetManager = assetManager;  
7.     } catch (Exception e) {  
8.         e.printStackTrace();  
9.     }  
10.     Resources superRes = super.getResources();  
11.     mResources = new Resources(mAssetManager, superRes.getDisplayMetrics(),  
12.             superRes.getConfiguration());  
13.     mTheme = mResources.newTheme();  
14.     mTheme.setTo(super.getTheme());  
15. }  

說明：加載的方法是通過反射，通過調用AssetManager中的addAssetPath方法，我們可以將一個apk中的資源加載到Resources中，由於addAssetPath是隱藏api我們無法直接調用，所以只能通過反射，下面是它的聲明，通過註釋我們可以看出，傳遞的路徑可以是zip文件也可以是一個資源目錄，而apk就是一個zip，所以直接將apk的路徑傳給它，資源就加載到AssetManager中了，然後再通過AssetManager來創建一個新的Resources對象，這個對象就是我們可以使用的apk中的資源了，這樣我們的問題就解決了。

[java] view plaincopy

1. /** 
2.  * Add an additional set of assets to the asset manager.  This can be 
3.  * either a directory or ZIP file.  Not for use by applications.  Returns 
4.  * the cookie of the added asset, or 0 on failure. 
5.  * {@hide} 
6.  */  
7. public final int addAssetPath(String path) {  
8.     int res = addAssetPathNative(path);  
9.     return res;  
10. }  

其次是要實現那兩個抽象方法

[java] view plaincopy

1. @Override  
2. public AssetManager getAssets() {  
3.     return mAssetManager == null ? super.getAssets() : mAssetManager;  
4. }  
5.   
6. @Override  
7. public Resources getResources() {  
8.     return mResources == null ? super.getResources() : mResources;  
9. }  

okay，問題搞定。這樣一來，在apk中就可以通過R來訪問資源了。

activity生命週期的管理

這是本文開頭提到的另一個需要解決的難題。爲什麼會有這個問題，其實很好理解，apk被宿主程序調起以後，apk中的activity其實就是一個普通的對象，不具有activity的性質，因爲系統啓動activity是要做很多初始化工作的，而我們在應用層通過反射去啓動activity是很難完成系統所做的初始化工作的，所以activity的大部分特性都無法使用包括activity的生命週期管理，這就需要我們自己去管理。談到activity生命週期，其實就是那幾個常見的方法：onCreate、onStart、onResume、onPause等，由於apk中的activity不是真正意義上的activity（沒有在宿主程序中註冊且沒有完全初始化），所以這幾個生命週期的方法系統就不會去自動調用了。針對此類問題，採用Fragment是一個不錯的方法，Fragment從3.0引入，通過support-v4包，可以兼容3.0以下的android版本。Fragment既有類似於Activity的生命週期，又有類似於View的界面，將Fragment加入到Activity中，activity會自動管理Fragment的生命週期，通過第一篇文章我們知道，apk中的activity是通過宿主程序中的代理activity啓動的，將Fragment加入到代理activity內部，其生命週期將完全由代理activity來管理，但是採用這種方法，就要求apk儘量採用Fragment來實現，還有就是在做頁面跳轉的時候有點麻煩，當然關於Fragment相關的內容我將在後面再做研究，本文不採用Fragment而是通過反射去手動管理activity的生命週期。

我們要在代理activity中去反射apk中activity的所有生命週期的方法，然後將activity的生命週期和代理activity的生命週期進行同步。首先，反射activity生命週期的所有方法，還反射了onActivityResult這個方法，儘管它不是典型的生命週期方法，但是它很有用。

[java] view plaincopy

1. protected void instantiateLifecircleMethods(Class<?> localClass) {  
2.     String[] methodNames = new String[] {  
3.             "onRestart",  
4.             "onStart",  
5.             "onResume",  
6.             "onPause",  
7.             "onStop",  
8.             "onDestory"  
9.     };  
10.     for (String methodName : methodNames) {  
11.         Method method = null;  
12.         try {  
13.             method = localClass.getDeclaredMethod(methodName, new Class[] { });  
14.             method.setAccessible(true);  
15.         } catch (NoSuchMethodException e) {  
16.             e.printStackTrace();  
17.         }  
18.         mActivityLifecircleMethods.put(methodName, method);  
19.     }  
20.   
21.     Method onCreate = null;  
22.     try {  
23.         onCreate = localClass.getDeclaredMethod("onCreate", new Class[] { Bundle.class });  
24.         onCreate.setAccessible(true);  
25.     } catch (NoSuchMethodException e) {  
26.         e.printStackTrace();  
27.     }  
28.     mActivityLifecircleMethods.put("onCreate", onCreate);  
29.   
30.     Method onActivityResult = null;  
31.     try {  
32.         onActivityResult = localClass.getDeclaredMethod("onActivityResult",  
33.                 new Class[] { int.class, int.class, Intent.class });  
34.         onActivityResult.setAccessible(true);  
35.     } catch (NoSuchMethodException e) {  
36.         e.printStackTrace();  
37.     }  
38.     mActivityLifecircleMethods.put("onActivityResult", onActivityResult);  
39. }  

其次，同步生命週期，主要看一下onResume和onPause，其他方法是類似的。看如下代碼，很好理解，就是當系統調用代理activity生命週期方法的時候，就通過反射去顯式調用apk中activity的對應方法。

[java] view plaincopy

1. @Override  
2. protected void onResume() {  
3.     super.onResume();  
4.     Method onResume = mActivityLifecircleMethods.get("onResume");  
5.     if (onResume != null) {  
6.         try {  
7.             onResume.invoke(mRemoteActivity, new Object[] { });  
8.         } catch (Exception e) {  
9.             e.printStackTrace();  
10.         }  
11.     }  
12. }  
13.   
14. @Override  
15. protected void onPause() {  
16.     Method onPause = mActivityLifecircleMethods.get("onPause");  
17.     if (onPause != null) {  
18.         try {  
19.             onPause.invoke(mRemoteActivity, new Object[] { });  
20.         } catch (Exception e) {  
21.             e.printStackTrace();  
22.         }  
23.     }  
24.     super.onPause();  
25. }  

插件apk的開發規範

文章開頭提到，要想成爲一個插件apk，是要滿足一定條件的，如下是採用本文機制開發插件apk所需要遵循的規範：

1. 不能用this：因爲this指向的是當前對象，即apk中的activity，但是由於activity已經不是常規意義上的activity，所以this是沒有意義的。

2. 使用that：既然this不能用，那就用that，that是apk中activity的基類BaseActivity中的一個成員，它在apk安裝運行的時候指向this，而在未安裝的時候指向宿主程序中的代理activity，anyway，that is better than this。

3. 不能直接調用activity的成員方法：而必須通過that去調用，由於that的動態分配特性，通過that去調用activity的成員方法，在apk安裝以後仍然可以正常運行。

4. 啓動新activity的約束：啓動外部activity不受限制，啓動apk內部的activity有限制，首先由於apk中的activity沒註冊，所以不支持隱式調用，其次必須通過BaseActivity中定義的新方法startActivityByProxy和startActivityForResultByProxy，還有就是不支持LaunchMode。

5. 目前暫不支持Service、BroadcastReceiver等需要註冊才能使用的組件。

後續工作

1. DLIntent的定義，通過自定義的intent，來完成activity的無約束調起

2. 採用Fragment的生命週期管理

3. Service、BroadcastReceiver等組件的調起

4. 性能優化

效果

首先宿主程序運行後，會把位於/mnt/sdcard/DynamicLoadHost目錄下的所有apk都加載進來，然後點擊列表就可以調起對應的apk，本文中的demo和第一篇文章中的demo看起來差不多，實際是有區別的，區別有兩點：activity具有生命週期、加載資源可以用R，具體的代碼實現請大家參見源碼。

源碼下載：https://github.com/singwhatiwanna/dynamic-load-apk