2020 Android 大廠面試（五）插件化、模塊化、組件化、熱修復、增量更新、Gradle

時間  2021-08-13
標籤 html java android c++ git github 數組 bash markdown 架構 欄目 Android 简体版
原文   原文鏈接

5、插件化、模塊化、組件化、熱修復、增量更新、Gradlehtml

1.對熱修復和插件化的理解
2.插件化原理分析
3.模塊化實現（好處，緣由）
4.熱修復、插件化
5.項目組件化的理解
6.描述清點擊 Android Studio 的 build 按鈕後發生了什麼
複製代碼

參考答案：java

1.對熱修復和插件化的理解

blog.csdn.net/github_3713…android

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);
    }
}
複製代碼

BaseDexClassLoaderc++

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

一、Android使用PathClassLoader做爲其類加載器，只能去加載已經安裝到Android系統中的apk文件；

二、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…git

DexClassLoader和PathClassLoader，它們都繼承於BaseDexClassLoader。
DexClassloader多傳了一個optimizedDirectory
複製代碼

DexPathListgithub

多DexClassLoader數組

每一個插件單獨一個DexClassLoader，相對隔離，RePlugin採用該方案
複製代碼

單DexClassLoaderbash

將插件的DexClassLoader中的pathList合併到主工程的DexClassLoader中。方便插件與宿主(插件)之間的調用，Small採用該方案
複製代碼
插件調用主工程
主工程的ClassLoader做爲插件ClassLoader的父加載器

主工程調用插件
若使用多ClassLoader機制，經過插件的ClassLoader先加載類，再經過反射調用
若使用單ClassLoader機制，直接經過類名去訪問插件中的類，弊端是庫的版本可能不一致，須要規範
複製代碼

資源加載markdown

//建立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到具體資源路徑的映射。
複製代碼

blog.csdn.net/jiangwei091…

// 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.cn/post/684490… 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時也是沒有感知的。
複製代碼

www.jianshu.com/p/ac96420fc…

sanjay-f.github.io/2016/04/17/…

www.jianshu.com/p/d43e1fb42…

Service插件化總結

初始化時經過ActivityManagerProxy Hook住了IActivityManager。
服務啓動時經過ActivityManagerProxy攔截，判斷是否爲遠程服務，若是爲遠程服務，啓動RemoteService，若是爲同進程服務則啓動LocalService。
若是爲LocalService，則經過DexClassLoader加載目標Service，而後反射調用attach方法綁定Context，而後執行Service的onCreate、onStartCommand方法
若是爲RemoteService，則先加載插件的遠程Service，後續跟LocalService一致。
複製代碼

3.模塊化實現（好處，緣由）

www.cnblogs.com/Jackie-zhan…

一、模塊間解耦，複用。
（緣由：對業務進行模塊化拆分後，爲了使各業務模塊間解耦，所以各個都是獨立的模塊，它們之間是沒有依賴關係。
每一個模塊負責的功能不一樣，業務邏輯不一樣，模塊間業務解耦。模塊功能比較單一，可在多個項目中使用。）

二、可單獨編譯某個模塊，提高開發效率。
（緣由：每一個模塊實際上也是一個完整的項目，能夠進行單獨編譯，調試）

三、能夠多團隊並行開發，測試。
緣由：每一個團隊負責不一樣的模塊，提高開發，測試效率。
複製代碼

組件化與模塊化

組件化是指以重用化爲目的，將一個系統拆分爲一個個單獨的組件

避免重複造輪子，節省開發維護成本；
下降項目複雜性，提高開發效率；
多個團隊公用同一個組件，在必定層度上確保了技術方案的統一性。
複製代碼

模塊化業務分層：由下到上

基礎組件層：
底層使用的庫和封裝的一些工具庫（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.熱修復、插件化

www.jianshu.com/p/704cac3eb…

宿主： 就是當前運行的APP
插件： 相對於插件化技術來講，就是要加載運行的apk類文件
補丁： 相對於熱修復技術來講，就是要加載運行的.patch,.dex,*.apk等一系列包含dex修復內容的文件。
複製代碼

QQ 空間超級補丁方案

Tinker

HotFix

固然就熱修復的實現，各個大廠還有各自的實現，好比餓了嗎的Amigo,美團的Robust,實現及優缺點各有差別，但總的來講就是兩大類

ClassLoader 加載方案
Native層替換方案
或者是參考Android Studio Instant Run 的思路實現代碼總體的增量更新。但這樣勢必會帶來性能的影響。
複製代碼

Sophix

www.jianshu.com/p/4d30ce3e5…

底層替換方案
原理：在已經加載的類中直接替換掉原有方法，是在原有類的結構基礎上進行修改的。在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.項目組件化的理解

juejin.cn/post/684490…

總結
組件化相較於單一工程，在組件模式下能夠提升編譯速度，方便單元測試，提升開發效率。
開發人員分工更加明確，基本上作到互不干擾。
業務組件的架構也能夠自由選擇，不影響同伴之間的協做。
下降維護成本，代碼結構更加清晰。
複製代碼

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+

Done

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程