Android apk動態載入機制的研究（二） 資源載入和activity生命週期管理
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow
也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！
轉載請註明出處：http://blog.csdn.net/singwhatiwanna/article/details/23387079 （來自singwhatiwanna的csdn部落格）
前言
為了更好地閱讀本文，你需要先閱讀
資源管理
我們知道，宿主程式調起未安裝的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中的資源：
protected void loadResources() { try { AssetManager assetManager = AssetManager.class.newInstance(); Method addAssetPath = assetManager.getClass().getMethod("addAssetPath", String.class); addAssetPath.invoke(assetManager, mDexPath); mAssetManager = assetManager; } catch (Exception e) { e.printStackTrace(); } Resources superRes = super.getResources(); mResources = new Resources(mAssetManager, superRes.getDisplayMetrics(), superRes.getConfiguration()); mTheme = mResources.newTheme(); mTheme.setTo(super.getTheme()); }說明：載入的方法是通過反射，通過呼叫AssetManager中的addAssetPath方法，我們可以將一個apk中的資源載入到Resources中，由於addAssetPath是隱藏api我們無法直接呼叫，所以只能通過反射，下面是它的宣告，通過註釋我們可以看出，傳遞的路徑可以是zip檔案也可以是一個資源目錄，而apk就是一個zip，所以直接將apk的路徑傳給它，資源就載入到AssetManager中了，然後再通過AssetManager來建立一個新的Resources物件，這個物件就是我們可以使用的apk中的資源了，這樣我們的問題就解決了。
/** * Add an additional set of assets to the asset manager. This can be * either a directory or ZIP file. Not for use by applications. Returns * the cookie of the added asset, or 0 on failure. * {@hide} */ public final int addAssetPath(String path) { int res = addAssetPathNative(path); return res; }其次是要實現那兩個抽象方法
@Override public AssetManager getAssets() { return mAssetManager == null ? super.getAssets() : mAssetManager; } @Override public Resources getResources() { return mResources == null ? super.getResources() : mResources; }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這個方法，儘管它不是典型的生命週期方法，但是它很有用。
protected void instantiateLifecircleMethods(Class<?> localClass) { String[] methodNames = new String[] { "onRestart", "onStart", "onResume", "onPause", "onStop", "onDestory" }; for (String methodName : methodNames) { Method method = null; try { method = localClass.getDeclaredMethod(methodName, new Class[] { }); method.setAccessible(true); } catch (NoSuchMethodException e) { e.printStackTrace(); } mActivityLifecircleMethods.put(methodName, method); } Method onCreate = null; try { onCreate = localClass.getDeclaredMethod("onCreate", new Class[] { Bundle.class }); onCreate.setAccessible(true); } catch (NoSuchMethodException e) { e.printStackTrace(); } mActivityLifecircleMethods.put("onCreate", onCreate); Method onActivityResult = null; try { onActivityResult = localClass.getDeclaredMethod("onActivityResult", new Class[] { int.class, int.class, Intent.class }); onActivityResult.setAccessible(true); } catch (NoSuchMethodException e) { e.printStackTrace(); } mActivityLifecircleMethods.put("onActivityResult", onActivityResult); }其次，同步生命週期，主要看一下onResume和onPause，其他方法是類似的。看如下程式碼，很好理解，就是當系統呼叫代理activity生命週期方法的時候，就通過反射去顯式呼叫apk中activity的對應方法。
@Override protected void onResume() { super.onResume(); Method onResume = mActivityLifecircleMethods.get("onResume"); if (onResume != null) { try { onResume.invoke(mRemoteActivity, new Object[] { }); } catch (Exception e) { e.printStackTrace(); } } } @Override protected void onPause() { Method onPause = mActivityLifecircleMethods.get("onPause"); if (onPause != null) { try { onPause.invoke(mRemoteActivity, new Object[] { }); } catch (Exception e) { e.printStackTrace(); } } super.onPause(); }外掛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
給我老師的人工智慧教程打call！http://blog.csdn.net/jiangjunshow
