插件化、模塊化、組件化、熱修復、增量更新、Gradle
1.對熱修復和插件化的理解
2.插件化原理分析
3.模塊化實現（好處，原因）
4.熱修復、插件化
5.項目組件化的理解
6.描述清點擊 Android Studio 的 build 按鈕後發生了什麼
參考答案：
1.對熱修復和插件化的理解
Android 類加載器
PathClassLoader.java
DexClassLoader.java
BaseDexClassLoader.java
DexPathList.java
（1）PathClassLoader：只能加載已經安裝到Android系統中的apk文件（/data/app目錄），是Android默認使用的類加載器。
（2）DexClassLoader：可以加載任意目錄下的dex/jar/apk/zip文件，比PathClassLoader更靈活，是實現熱修復的重點。
// PathClassLoader
public class PathClassLoader extends BaseDexClassLoader {
public PathClassLoader(String dexPath, ClassLoader parent) {
super(dexPath, null, null, parent);
}
public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent) {
super(dexPath, null, librarySearchPath, parent);
}
}
// DexClassLoaderpublic
class DexClassLoader extends BaseDexClassLoader {
public DexClassLoader(String dexPath, String optimizedDirectory,
String librarySearchPath, ClassLoader parent) {
super(dexPath, new File(optimizedDirectory), librarySearchPath, parent);
}
}
BaseDexClassLoader
dexPath：要加載的程序文件（一般是dex文件，也可以是jar/apk/zip文件）所在目錄。
optimizedDirectory：dex文件的輸出目錄（因爲在加載jar/apk/zip等壓縮格式的程序文件時會解壓出其中的dex文件，該目錄就是專門用於存放這些被解壓出來的dex文件的）。
libraryPath：加載程序文件時需要用到的庫路徑。
parent：父加載器
阿里系：DeXposed、andfix：從底層二進制入手（c語言）。阿里andFix hook 方法在native的具體字段。
art虛擬機上是一個叫ArtMethod的結構體。通過修改該結構體上有bug的字段來達到修復bug方法的目的，
但這個artMethod是根據安卓原生的結構寫死的，國內很多第三方廠家會改寫ArtMethod結構，導致替換失效。
騰訊系：tinker：從java加載機制入手。qq的dex插裝就類似上面分析的那種。通過將修復的dex文件插入到app的dexFileList的前面，達到更新bug的效果，但是不能及時生效，需要重啓。
但虛擬機在安裝期間會爲類打上CLASS_ISPREVERIFIED標誌，是爲了提高性能的，我們強制防止類被打上標誌是否會有些影響性能
美團robust：是在編譯器爲每個方法插入了一段邏輯代碼，併爲每個類創建了一個ChangeQuickRedirect靜態成員變量，當它不爲空會轉入新的代碼邏輯達到修復bug的目的。
優點是兼容性高,但是會增加應用體積
PathClassLoader和DexClassLoader都繼承自BaseDexClassLoader
1、Android使用PathClassLoader作爲其類加載器，只能去加載已經安裝到Android系統中的apk文件；
2、DexClassLoader可以從.jar和.apk類型的文件內部加載classes.dex文件就好了。熱修復也用到這個類。
（1）動態改變BaseDexClassLoader對象間接引用的dexElements；
（2）在app打包的時候，阻止相關類去打上CLASS_ISPREVERIFIED標誌。
（3）我們使用 hook 思想代理 startActivity 這個方法，使用佔坑的方式。
1\. startActivity 的時候最終會走到 AMS 的 startActivity 方法
2\. 系統會檢查一堆的信息驗證這個 Activity 是否合法。
3\. 然後會回調 ActivityThread 的 Handler 裏的 handleLaunchActivity
4\. 在這裏走到了 performLaunchActivity 方法去創建 Activity 並回調一系列生命週期的方法
5\. 創建 Activity 的時候會創建一個 LoaderApk對象，然後使用這個對象的 getClassLoader 來創建 Activity
6\. 我們查看 getClassLoader() 方法發現返回的是 PathClassLoader，然後他繼承自 BaseDexClassLoader
7\. 然後我們查看 BaseDexClassLoader 發現他創建時創建了一個 DexPathList 類型的 pathList對象，然後在 findClass 時調用了 pathList.findClass 的方法
8\. 然後我們查看 DexPathList類 中的 findClass 發現他內部維護了一個 Element[] dexElements的dex 數組，findClass 時是從數組中遍歷查找的
2.插件化原理分析
cloud.tencent.com/developer/a…
DexClassLoader和PathClassLoader，它們都繼承於BaseDexClassLoader。
DexClassloader多傳了一個optimizedDirectory
DexPathList
多DexClassLoader
每個插件單獨一個DexClassLoader，相對隔離，RePlugin採用該方案
單DexClassLoader
將插件的DexClassLoader中的pathList合併到主工程的DexClassLoader中。方便插件與宿主(插件)之間的調用，Small採用該方案
插件調用主工程
主工程的ClassLoader作爲插件ClassLoader的父加載器
主工程調用插件
若使用多ClassLoader機制，通過插件的ClassLoader先加載類，再通過反射調用
若使用單ClassLoader機制，直接通過類名去訪問插件中的類，弊端是庫的版本可能不一致，需要規範
資源加載
//創建AssetManager對象
AssetManager assets = new AssetManager();
//將apk路徑添加到AssetManager中
if (assets.addAssetPath(resDir) == 0){
return null;
}
//創建Resource對象
r = new Resources(assets, metrics, getConfiguration(), compInfo);
插件apk的路徑加入到AssetManager中
通過反射去創建，並且部分Rom對創建的Resource類進行了修改，所以需要考慮不同Rom的兼容性。
資源路徑的處理
Context的處理
// 第一步：創建Resource
if (Constants.COMBINE_RESOURCES) {
//插件和主工程資源合併時需要hook住主工程的資源
Resources resources = ResourcesManager.createResources(context, apk.getAbsolutePath());
ResourcesManager.hookResources(context, resources);
return resources;
} else {
//插件資源獨立，該resource只能訪問插件自己的資源
Resources hostResources = context.getResources();
AssetManager assetManager = createAssetManager(context, apk);
return new Resources(assetManager, hostResources.getDisplayMetrics(), hostResources.getConfiguration());
}
//第二步：hook主工程的Resource
//對於合併式的資源訪問方式，需要替換主工程的Resource，下面是具體替換的代碼。
public static void hookResources(Context base, Resources resources) {
try {
ReflectUtil.setField(base.getClass(), base, "mResources", resources);
Object loadedApk = ReflectUtil.getPackageInfo(base);
ReflectUtil.setField(loadedApk.getClass(), loadedApk, "mResources", resources);
Object activityThread = ReflectUtil.getActivityThread(base);
Object resManager = ReflectUtil.getField(activityThread.getClass(), activityThread, "mResourcesManager");
if (Build.VERSION.SDK_INT < 24) {
Map<Object, WeakReference<Resources>> map = (Map<Object, WeakReference<Resources>>) ReflectUtil.getField(resManager.getClass(), resManager, "mActiveResources");
Object key = map.keySet().iterator().next();
map.put(key, new WeakReference<>(resources));
} else {
// still hook Android N Resources, even though it's unnecessary, then nobody will be strange.
Map map = (Map) ReflectUtil.getFieldNoException(resManager.getClass(), resManager, "mResourceImpls");
Object key = map.keySet().iterator().next();
Object resourcesImpl = ReflectUtil.getFieldNoException(Resources.class, resources, "mResourcesImpl");
map.put(key, new WeakReference<>(resourcesImpl));
}
} catch (Exception e) {
e.printStackTrace();
}
替換了主工程context中LoadedApk的mResource對象
將新的Resource添加到主工程ActivityThread的mResourceManager中，並且根據Android版本做了不同處理
//第三步：關聯resource和Activity
Activity activity = mBase.newActivity(plugin.getClassLoader(), targetClassName, intent);
activity.setIntent(intent);
//設置Activity的mResources屬性，Activity中訪問資源時都通過mResources
ReflectUtil.setField(ContextThemeWrapper.class, activity, "mResources", plugin.getResources());
資源衝突
資源id是由8位16進制數表示，表示爲0xPPTTNNNN， 由三部分組成：PackageId+TypeId+EntryId
修改aapt源碼，編譯期修改PP段。
修改resources.arsc文件，該文件列出了資源id到具體資源路徑的映射。
// Main.cpp
result = handleCommand(&bundle);
case kCommandPackage: return doPackage(bundle);
// Command.cpp
int doPackage(Bundle* bundle) {
if (bundle->getResourceSourceDirs().size() || bundle->getAndroidManifestFile()) {
err = buildResources(bundle, assets, builder);
if (err != 0) {
goto bail;
}
}
}
Resource.cpp
buildResources
ResourceTable.cpp
switch(mPackageType) {
case App:
case AppFeature:
packageId = 0x7f;
break;
case System:
packageId = 0x01;
break;
case SharedLibrary:
packageId = 0x00;
break;
}
首先找到入口類：Main.cpp：main函數，解析參數，然後調用handleCommand函數處理參數對應的邏輯，我們看到了有一個函數doPackage。
然後就搜索到了Command.cpp：在他內部的doPackage函數中進行編譯工具的一個函數：buildResources函數，在全局搜索，發現了Resource.cpp：發現這裏就是處理編譯工作，構建ResourceTable的邏輯，在ResourceTable.cpp中，也是獲取PackageId的地方，下面我們就來看看如何修改呢？
其實最好的方法是，能夠修改aapt源碼，添加一個參數，把我們想要編譯的PackageId作爲輸入值，傳進來最好了，那就是Bundle類型，他是從Main.cpp中的main函數傳遞到了最後的buildResources函數中，那麼我們就可以把這個參數用Bundle進行攜帶。
juejin.im/entry/5c008… www.jianshu.com/p/8d691b6bf…
————————————————————————————————————————————————
cloud.tencent.com/developer/a…
在整個過程中，需要修改到R文件、resources.arsc和二進制的xml文件
四大組件支持
ProxyActivity代理
代理方式的關鍵總結起來有下面兩點：
ProxyActivity中需要重寫getResouces，getAssets，getClassLoader方法返回插件的相應對象。生命週期函數以及和用戶交互相關函數，如onResume，onStop，onBackPressedon，KeyUponWindow，FocusChanged等需要轉發給插件。
PluginActivity中所有調用context的相關的方法，如setContentView，getLayoutInflater，getSystemService等都需要調用ProxyActivity的相應方法。
該方式有幾個明顯缺點：
插件中的Activity必須繼承PluginActivity，開發侵入性強。
如果想支持Activity的singleTask，singleInstance等launchMode時，需要自己管理Activity棧，實現起來很繁瑣。
插件中需要小心處理Context，容易出錯。
如果想把之前的模塊改造成插件需要很多額外的工作。
複製代碼
預埋StubActivity，hook系統啓動Activity的過程
VirtualAPK通過替換了系統的Instrumentation，hook了Activity的啓動和創建，省去了手動管理插件Activity生命週期的繁瑣，讓插件Activity像正常的Activity一樣被系統管理，並且插件Activity在開發時和常規一樣，即能獨立運行又能作爲插件被主工程調用。
其他插件框架在處理Activity時思想大都差不多，無非是這兩種方式之一或者兩者的結合。在hook時，不同的框架可能會選擇不同的hook點。如360的RePlugin框架選擇hook了系統的ClassLoader，即構造Activity2的ClassLoader，在判斷出待啓動的Activity是插件中的時，會調用插件的ClassLoader構造相應對象。另外RePlugin爲了系統穩定性，選擇了儘量少的hook，因此它並沒有選擇hook系統的startActivity方法來替換intent，而是通過重寫Activity的startActivity，因此其插件Activity是需要繼承一個類似PluginActivity的基類的。不過RePlugin提供了一個Gradle插件將插件中的Activity的基類換成了PluginActivity，用戶在開發插件Activity時也是沒有感知的。
Service插件化總結
初始化時通過ActivityManagerProxy Hook住了IActivityManager。
服務啓動時通過ActivityManagerProxy攔截，判斷是否爲遠程服務，如果爲遠程服務，啓動RemoteService，如果爲同進程服務則啓動LocalService。
如果爲LocalService，則通過DexClassLoader加載目標Service，然後反射調用attach方法綁定Context，然後執行Service的onCreate、onStartCommand方法
如果爲RemoteService，則先加載插件的遠程Service，後續跟LocalService一致。
3.模塊化實現（好處，原因）
1、模塊間解耦，複用。
（原因：對業務進行模塊化拆分後，爲了使各業務模塊間解耦，因此各個都是獨立的模塊，它們之間是沒有依賴關係。
每個模塊負責的功能不同，業務邏輯不同，模塊間業務解耦。模塊功能比較單一，可在多個項目中使用。）
2、可單獨編譯某個模塊，提升開發效率。
（原因：每個模塊實際上也是一個完整的項目，可以進行單獨編譯，調試）
3、可以多團隊並行開發，測試。
原因：每個團隊負責不同的模塊，提升開發，測試效率。
組件化與模塊化
組件化是指以重用化爲目的，將一個系統拆分爲一個個單獨的組件
避免重複造輪子，節省開發維護成本；
降低項目複雜性，提升開發效率；
多個團隊公用同一個組件，在一定層度上確保了技術方案的統一性。
模塊化業務分層：由下到上
基礎組件層：
底層使用的庫和封裝的一些工具庫（libs），比如okhttp,rxjava,rxandroid,glide等
業務組件層：
與業務相關，封裝第三方sdk，比如封裝後的支付，即時通行等
業務模塊層：
按照業務劃分模塊，比如說IM模塊，資訊模塊等
Library Module開發問題
在把代碼抽取到各個單獨的Library Module中，會遇到各種問題。
最常見的就是R文件問題，Android開發中，各個資源文件都是放在res目錄中，在編譯過程中，會生成R.java文件。
R文件中包含有各個資源文件對應的id，這個id是靜態常量，但是在Library Module中，這個id不是靜態常量，那麼在開發時候就要避開這樣的問題。
舉個常見的例子，同一個方法處理多個view的點擊事件，有時候會使用switch(view.getId())這樣的方式，
然後用case R.id.btnLogin這樣進行判斷，這時候就會出現問題，因爲id不是經常常量，那麼這種方式就用不了。
4.熱修復、插件化
宿主： 就是當前運行的APP
插件： 相對於插件化技術來說，就是要加載運行的apk類文件
補丁： 相對於熱修復技術來說，就是要加載運行的.patch,.dex,*.apk等一系列包含dex修復內容的文件。
QQ 空間超級補丁方案
Tinker
HotFix
當然就熱修復的實現，各個大廠還有各自的實現，比如餓了嗎的Amigo,美團的Robust,實現及優缺點各有差異，但總的來說就是兩大類
ClassLoader 加載方案
Native層替換方案
或者是參考Android Studio Instant Run 的思路實現代碼整體的增量更新。但這樣勢必會帶來性能的影響。
Sophix
底層替換方案
原理：在已經加載的類中直接替換掉原有方法，是在原有類的結構基礎上進行修改的。在hook方法入口ArtMethod時，通過構造一個新的ArtMethod實現替換方法入口的跳轉。
應用：能即時生效，Andfix採用此方案。
缺點：底層替換穩定性不好，適用範圍存在限制，通過改造代碼繞過限制既不優雅也不方便，並且還沒提供資源及so的修復。
類加載方案
原理：讓app重新啓動後讓ClassLoader去加載新的類。如果不重啓，原來的類還在虛擬機中無法重複加載。
優點：修復範圍廣，限制少。
應用：騰訊系包括QQ空間，手QFix，Tinker採用此方案。
QQ空間會侵入打包流程。
QFix需要獲取底層虛擬機的函數，不穩定。
Tinker是完整的全量dex加載。
Tinker與Sophix方案不同之處
Tinker採用dex merge生成全量DEX方案。反編譯爲smali，然後新apk跟基線apk進行差異對比，最後得到補丁包。
Dalvik下Sophix和Tinker相同，在Art下，Sophix不需要做dex merge，因爲Art下本質上虛擬機已經支持多dex的加載，要做的僅僅是把補丁dex作爲主dex(classes.dex)加載而已：
將補丁dex命名爲classes.dex，原apk中的dex依次命名爲classes(2, 3, 4...).dex就好了，然後一起打包爲一個壓縮文件。然後DexFile.loadDex得到DexFile對象，最後把該DexFile對象整個替換舊的dexElements數組就好了。
資源修復方案
基本參考InstantRun的實現：構造一個包含所有新資源的新的AssetManager。並在所有之前引用到原來的AssetManager通過反射替換掉。
Sophix不修改AssetManager的引用，構造的補丁包中只包含有新增或有修改變動的資源，在原AssetManager中addAssetPath這個包就可以了。資源包不需要在運行時合成完整包。
so庫修復方案
本質是對native方法的修復和替換。類似類修復反射注入方式，將補丁so庫的路徑插入到nativeLibraryDirectories數據最前面。
Method Hook
www.jianshu.com/p/7dcb32f8a… pqpo.me/2017/07/07/…
5.項目組件化的理解
總結
組件化相較於單一工程，在組件模式下可以提高編譯速度，方便單元測試，提高開發效率。
開發人員分工更加明確，基本上做到互不干擾。
業務組件的架構也可以自由選擇，不影響同伴之間的協作。
降低維護成本，代碼結構更加清晰。
6.描述清點擊 Android Studio 的 build 按鈕後發生了什麼
blog.csdn.net/u011026779/… blog.csdn.net/github_3713…
apply plugin : 'com.android.application'
apply plugin : 'com.android.library'
編譯五階段
1.準備依賴包 Preparation of dependecies
2.合併資源並處理清單 Merging resources and proccesssing Manifest
3.編譯 Compiling
4.後期處理 Postprocessing
5.包裝和出版 Packaging and publishing
簡單構建流程：
1\. Android編譯器（5.0之前是Dalvik，之後是ART）將項目的源代碼（包括一些第三方庫、jar包和aar包）轉換成DEX文件，將其他資源轉換成已編譯資源。
2\. APK打包器將DEX文件和已編譯資源在使用祕鑰簽署後打包。
3\. 在生成最終 APK 之前，打包器會使用zipalign 等工具對應用進行優化，減少其在設備上運行時的內存佔用。
構建流程結束後獲得測試或發佈用的apk。
複製代碼
圖中的矩形表示用到或者生成的文件，橢圓表示工具。
1\. 通過aapt打包res資源文件，生成R.java、resources.arsc和res文件
2\. 處理.aidl文件，生成對應的Java接口文件
3\. 通過Java Compiler編譯R.java、Java接口文件、Java源文件，生成.class文件
4\. 通過dex命令，將.class文件和第三方庫中的.class文件處理生成classes.dex
5\. 通過apkbuilder工具，將aapt生成的resources.arsc和res文件、assets文件和classes.dex一起打包生成apk
6\. 通過Jarsigner工具，對上面的apk進行debug或release簽名
7\. 通過zipalign工具，將簽名後的apk進行對齊處理。
這樣就得到了一個可以安裝運行的Android程序。
複製代碼
7.徹底搞懂Gradle、Gradle Wrapper與Android Plugin for Gradle的區別和聯繫
zhuanlan.zhihu.com/p/32714369 blog.csdn.net/LVXIANGAN/a…
`Offline work`時可能出現"No cached version of com.android.tools.build:gradle:xxx available for offline mode"問題
Gradle： gradle-wrapper.properties中的distributionUrl=https/://services.gradle.org/distributions/gradle-2.10-all.zip
Gradle插件：build.gradle中依賴的classpath 'com.android.tools.build:gradle:2.1.2'
Gradle：
一個構建系統，構建項目的工具，用來編譯Android app，能夠簡化你的編譯、打包、測試過程。
Gradle是一個基於Apache Ant和Apache Maven概念的項目自動化建構工具。它使用一種基於Groovy的特定領域語言來聲明項目設置，而不是傳統的XML。當前其支持的語言限於Java、Groovy和Scala
Gradle插件：
我們在AS中用到的Gradle被叫做Android Plugin for Gradle，它本質就是一個AS的插件，它一邊調用 Gradle本身的代碼和批處理工具來構建項目，一邊調用Android SDK的編譯、打包功能。
Gradle插件跟 Android SDK BuildTool有關聯，因爲它還承接着AS裏的編譯相關的功能，在項目的 local.properties 文件裏寫明 Android SDK 路徑、在build.gradle 裏寫明 buildToolsVersion 的原因。
| 插件版本 | Gradle 版本 |
|---|---|
| 1.0.0 - 1.1.3 | 2.2.1 - 2.3 |
| 1.2.0 - 1.3.1 | 2.2.1 - 2.9 |
| 1.5.0 | 2.2.1 - 2.13 |
| 2.0.0 - 2.1.2 | 2.10 - 2.13 |
| 2.1.3 - 2.2.3 | 2.14.1+ |
| 2.3.0+ | 3.3+ |
| 3.0.0+ | 4.1+ |
| 3.1.0+ | 4.4+ |
| 3.2.0 - 3.2.1 | 4.6+ |
| 3.3.0 - 3.3.2 | 4.10.1+ |
| 3.4.0+ | 5.1.1+ |