前言
看完本文可以達(dá)到什么程度
- 自頂向下分析
- 學(xué)會(huì) hook task
- 學(xué)會(huì)自定義 task，自定義 gradle 插件
- 掌握改造 Robust
預(yù)備知識(shí)
- 理解 gradle 的基本開發(fā)
- 掌握 Task，Transform 概念
閱讀前準(zhǔn)備工作
- 對(duì) Robust 還不了解的小伙伴 戳 Android熱更新方案Robust
- 想使用其他方案的小伙伴 戳 SDK最全熱修復(fù)方案
前文提到，當(dāng)我美滋滋接入 Robust 時(shí)卻報(bào)錯(cuò)提示，只有 Application Module 才能插樁和打補(bǔ)丁，而且還要做補(bǔ)丁管理、加解密、數(shù)據(jù)分析……
看來我們需要進(jìn)行一番改造了。
從哪入手呢？
我們自頂向下分析整個(gè)需求實(shí)現(xiàn)步驟
在我們開始寫代碼之前，我們需要清楚如何解決問題。將問題分解成子問題，直到每個(gè)子問題都可以很輕松地解決。對(duì)問題進(jìn)行建模，這樣寫出來的代碼才具有可讀性和可測(cè)性。
針對(duì)每一個(gè)步驟，我們來挖掘下對(duì)應(yīng)的問題：
是不是清晰多了？
講解之前先說明，本文著重于解決思路， 代碼細(xì)節(jié)已經(jīng)開源，不過多展開。只要掌握解決思路，剩下的都是面向 API 編程啦。
第一步：接入Robust
問題1：Robust 只支持Application Module
一個(gè) apk 和一個(gè) arr 有什么差別？
實(shí)際上沒什么差別。我們只需要加個(gè)開關(guān)，先將 SDK 配置為 Application，再 Hook apk 打包的 Task，把 build 目錄下的資源壓縮為 aar 不就行了！
實(shí)現(xiàn)見：packPlugin.gradle
hookAssembleAndCopyRes方法
問題2：怎么把插樁后的 aar 上傳到 jcenter 呢？
上傳肯定是要借助 uploadArchives 這個(gè) Task，但是我翻遍了 uploadArchives Task 配置和官方文檔，發(fā)現(xiàn)并不支持自定義數(shù)據(jù)源入口的。（心拔涼拔涼）
怎么辦？GG了？
別急，我們還有大殺招 —— Hook Gradle Task。（后面你將會(huì)陸陸續(xù)續(xù)看到，Hook 簡直就是個(gè)萬金油~）
還不了解 Gradle 工作流程、Plugin、Task 的關(guān)系？見 一文應(yīng)用 AOP 三、應(yīng)用篇的基礎(chǔ)部分
我們知道， Task 有一個(gè)重要的概念：inputs 和 outputs，Task 通過 inputs 拿到需要的參數(shù)，處理完畢之后就輸出 outputs，而下一個(gè) Task 的 inputs 則是上一個(gè) Task 的outputs，如下圖：
那我們打印一下 uploadArchives 的依賴 Task 和對(duì)應(yīng)的輸入輸出，看下有什么線索（福爾摩斯.jpg）
bundleRelease Task 就是和打包相關(guān)的 Task 了，我們打印下這個(gè) Task 的輸出和輸入：
誒，能不能這樣，hook 這個(gè)Task，把我們插樁的 jar 復(fù)制粘貼覆蓋這個(gè)輸入源的 classes.jar？！好一招移花接木，就這么辦！
實(shí)現(xiàn)見：packPlugin.gradle
hookBundle方法
問題3：資源 ID 沖突
接入后，測(cè)試跑過來：誒？怎么 sdk 里的 layout 都不顯示了。
哈？啥情況
反編譯一看：
好家伙，用 application 方式打包的 aar 資源 id 變成常量了。
這會(huì)有什么問題呢？
在 ADT 14之前，無論是主項(xiàng)目還是庫項(xiàng)目，資源 ID 統(tǒng)一被定義為 final 類型的靜態(tài)變量。如果代碼中使用了 ID，就相當(dāng)于使用一個(gè)常量，編譯器的語法優(yōu)化會(huì)將引用替換成具體的十六進(jìn)制數(shù)。這樣造成的結(jié)果：主項(xiàng)目編譯時(shí)一旦發(fā)現(xiàn)資源 ID 沖突，就會(huì)為庫項(xiàng)目的資源分配新 ID，這樣庫項(xiàng)目里引用資源文件的代碼都需要重新編譯。
如果 lib R 類中的資源 ID 僅被 static 修飾，就保留了變量。當(dāng)資源ID發(fā)送沖突時(shí)，主項(xiàng)目 R 類不變，修改庫項(xiàng)目 R 類中的變量，庫項(xiàng)目已經(jīng)編譯過的代碼仍有效。
所以 Android 設(shè)計(jì) application 的 R 類都是靜態(tài)常量，lib 的 R 類都是靜態(tài)變量。
用過 BufferKnife 的同學(xué)都知道，在 libary 中使用 switch 需要用 R2.XXX，那不就會(huì)出現(xiàn)常量 R2 和業(yè)務(wù)方 R 資源沖突的問題嗎？J 神是怎么解決的？請(qǐng)看：AST 抽象語法樹 —— 最輕量級(jí)的AOP方法
能咋整？
難道我們要根據(jù) 0x7f… 反查 R.XX.XX 然后再一一把代碼替換掉？要不我們強(qiáng)制改下插樁 aar 的資源 id 值從而避免沖突？默認(rèn)值是0x7F...改成0x02~0x7E？
這么多個(gè)方案在我腦海中繞了一圈，一拍大腿，不用這么復(fù)雜呀！
既然 R 文件的變量修飾符變了，那我們改回來唄！
先找到 R 文件生成的Task，來，我們打印一下：
...
:sdk:generateReleaseBuildConfig //會(huì)生成 releasse下的 資源和源碼 包括BuildConfig 在build/generate/source/buildConfig/release 依賴checkReleaseManifest
:sdk:generateReleaseResValues //準(zhǔn)備resource的 values文件
:sdk:generateReleaseResources //準(zhǔn)備 資源文件
:sdk:mergeReleaseResources //release下的 生成Resource文件 在build/incremental/res/release下 和 merge.xml 在build/intermediates/incremental/mergeResources/release下
:sdk:processReleaseManifest //依賴prepareReleaseDependencies 生成 AndroidManifest文件 在build/incremental/manifest/full/release
:sdk:processReleaseResources //生成resources-release.ap_
:sdk:generateReleaseSources //生成R文件 在build/generate/source/r/debug下
:sdk:processReleaseJavaRes
:sdk:compileReleaseJavaWithJavac //使用Javac編譯Java代碼
:sdk:proguardRelease //生成 混淆文件 運(yùn)行混淆規(guī)則
:sdk:androidJavadocsPicked
:sdk:copyMappingTask //復(fù)制 mapping文件
:sdk:androidJavadocsJar //生成 Javadocs的Jar文件
:sdk:androidSourcesJar //生成 Java源碼的 Jar文件
...
我們看到 generateReleaseSources Task 負(fù)責(zé)生成R文件，那我們寫個(gè) Gradle 腳本，hook 住前一個(gè)的 processReleaseResources Task，修改修飾符，so easy，hook 大法好！
實(shí)現(xiàn)見：packPlugin.gradle hookBuild方法
是不是覺得解決方案超簡單？有時(shí)候難的不是實(shí)現(xiàn)，而是你能不能找到切入點(diǎn)。
動(dòng)態(tài)修改 resId 小擴(kuò)展：
第二步：補(bǔ)丁下發(fā)
補(bǔ)丁下載、加載和上傳與一般的 app 熱更無異，所以我們少些筆墨。
補(bǔ)丁的存儲(chǔ)我們采用阿里云 OSS 對(duì)象存儲(chǔ)：一種安全、低成本、高可靠的云存儲(chǔ)服務(wù)，客戶端、服務(wù)端、阿里云三者關(guān)系如下：
第三步：補(bǔ)丁加載策略
第四步：補(bǔ)丁上傳
這里有一點(diǎn)需要注意：自定義 Gradle Task 只支持引入純 Java 庫，不支持Android庫。
第五步：補(bǔ)丁失效機(jī)制
1. 全局異常捕獲不是最優(yōu)解
一說到捕獲異常，下意識(shí)第一反應(yīng)：使用全局異常捕獲器呀！
誒誒誒，那你就掉進(jìn)經(jīng)驗(yàn)坑里了！
我們思考下，如上圖一共三步，最重要的一步是：確認(rèn)是補(bǔ)丁引起的異常，如果使用全局異常捕獲器，意味著：
- 我們需要比對(duì)堆棧信息。但是補(bǔ)丁可以獲取類，無法獲取到修復(fù)的方法名，而且堆棧比較非常低效，誤判率也高。
- 補(bǔ)丁修復(fù)了 A + B，A 修復(fù)引起異常，整個(gè)補(bǔ)丁自動(dòng)失效，B 修復(fù)也失效了。
能不能只讓 A 失效呢？能不能高效確認(rèn)是補(bǔ)丁引起的異常呢？
2. 在Robust源碼中找找靈感
我們看看 robust.xml 的配置，一個(gè)是否自動(dòng)捕獲異常的配置映入眼簾。
來，在 Robust 全局搜索下 catchReflectException 關(guān)鍵字，發(fā)現(xiàn)插樁工廠類處理簡單粗暴，直接拼接了 try-catch。
生成的補(bǔ)丁代碼如下：
3. 確認(rèn)改庫的方式
那我們利用 try-catch，改造一下 Robust 的插樁吧。
- robust.xml 增加配置項(xiàng)，支持 rollbackWhenException 配置；
- 初始化時(shí)加載 XML 配置項(xiàng)；
- 新建回滾監(jiān)聽器類，供業(yè)務(wù)方監(jiān)聽；
- 插樁時(shí)，若開啟此配置，則插入 try-catch，且 catch 里通知回滾監(jiān)聽器。
每個(gè)補(bǔ)丁方法都有唯一 id 我們利用此 id 來記錄回滾狀態(tài)
對(duì) Robust 的詳細(xì)改造MR，感興趣的可以看看
開發(fā)階段終于結(jié)束了，歇會(huì)兒~
第六步：數(shù)據(jù)分析
我們先看看我們最關(guān)心的指標(biāo)是哪些，再倒推出詳細(xì)的埋點(diǎn)項(xiàng)。
其中的接口失敗率和下載失敗率，我們還應(yīng)區(qū)別錯(cuò)誤原因：
后記
- SDK 熱修復(fù)方案少人做 ≠ 難做，考驗(yàn)的就是拆分問題、細(xì)化問題的能力
- 大膽假設(shè)，細(xì)心驗(yàn)證
以上的實(shí)現(xiàn)我已經(jīng)封裝成庫 SDKHotFix，SDK 開發(fā)者只需 5 分鐘即可讓自己的 SDK 擁有熱修復(fù)的能力，歡迎 star ！
最后，附上整個(gè)思維導(dǎo)圖：
本篇完成耗時(shí) 15 個(gè)番茄鐘（450 分鐘）
我是 FeelsChaotic，一個(gè)寫得了代碼 p 得了圖，剪得了視頻畫得了畫的程序媛，致力于追求代碼優(yōu)雅、架構(gòu)設(shè)計(jì)和 T 型成長。
歡迎關(guān)注 FeelsChaotic 的簡書和掘金，如果我的文章對(duì)你哪怕有一點(diǎn)點(diǎn)幫助，歡迎 ??！你的鼓勵(lì)是我寫作的最大動(dòng)力！
最最重要的，請(qǐng)給出你的建議或意見，有錯(cuò)誤請(qǐng)多多指正！
