Android 熱修復(fù) Tinker接入及源碼淺析

1、Android 熱修復(fù) Tinker接入及源碼淺析一、概述放了一個大長假，happy，先祝大家2017年笑口常開。假期中一行代碼沒寫，但是想著馬上要上班了，趕緊寫篇博客回顧下技能，于是便有了本文。熱修復(fù)這項技術(shù)，基本上已經(jīng)成為項目比較重要的模塊了。主要因?yàn)轫椖吭谏暇€之后，都難免會有各種問題，而依靠發(fā)版去修復(fù)問題，成本太高了?，F(xiàn)在熱修復(fù)的技術(shù)基本上有阿里的AndFix、QZone的方案、美團(tuán)提出的思想方案以及騰訊的Tinker等。其中AndFix可能接入是最簡單的一個（和Tinker命令行接入方式差不多），不過兼容性還是是有一定的問題的；QZone方案對性能會有一定的影響，且在Art模式下出現(xiàn)內(nèi)

2、存錯亂的問題(其實(shí)這個問題我之前并不清楚，主要是tinker在MDCC上指出的);美團(tuán)提出的思想方案主要是基于Instant Run的原理，目前尚未開源，不過這個方案我還是蠻喜歡的，主要是兼容性好。這么看來，如果選擇開源方案，tinker目前是最佳的選擇，tinker的介紹有這么一句：Tinker已運(yùn)行在微信的數(shù)億Android設(shè)備上，那么為什么你不使用Tinker呢？好了，說了這么多，下面來看看tinker如何接入，以及tinker的大致的原理分析。希望通過本文可以實(shí)現(xiàn)幫助大家更好的接入tinker，以及去了解tinker的一個大致的原理。二、接入Tinker接入tinker目前給了兩種方式

3、，一種是基于命令行的方式，類似于AndFix的接入方式；一種就是gradle的方式?？紤]早期使用Andfix的app應(yīng)該挺多的，以及很多人對gradle的相關(guān)配置還是覺得比較繁瑣的，下面對兩種方式都介紹下。（1）命令行接入接入之前我們先考慮下，接入的話，正常需要的前提（開啟混淆的狀態(tài)）。對于API一般來說，我們接入熱修庫，會在Application#onCreate中進(jìn)行一下初始化操作。然后在某個地方去調(diào)用類似loadPatch這樣的API去加載patch文件。對于patch的生成簡單的方式就是通過兩個apk做對比然后生成；需要注意的是：兩個apk做對比，需要的前提條件，第二次打包混淆所使用的

4、mapping文件應(yīng)該和線上apk是一致的。最后就是看看這個項目有沒有需要配置混淆；有了大致的概念，我們就基本了解命令行接入tinker，大致需要哪些步驟了。依賴引入dependencies / . /可選，用于生成application類 provided('com.tencent.tinker:tinker-android-anno:1.7.7') /tinker的核心庫 compile('com.tencent.tinker:tinker-android-lib:1.7.7')順便加一下簽名的配置：android /. signingConfigs rel

5、ease try storeFile file("release.keystore") storePassword "testres" keyAlias "testres" keyPassword "testres" catch (ex) throw new InvalidUserDataException(ex.toString() buildTypes release minifyEnabled true signingConfig signingConfigs.release proguardFiles ge

6、tDefaultProguardFile('proguard-android.txt'), '' debug debuggable true minifyEnabled true signingConfig signingConfigs.release proguardFiles getDefaultProguardFile('proguard-android.txt'), '' 文末會有demo的下載地址，可以直接參考build.gradle文件，不用擔(dān)心這

7、些簽名文件去哪找。API引入API主要就是初始化和loadPacth。正常情況下，我們會考慮在Application的onCreate中去初始化，不過tinker推薦下面的寫法：DefaultLifeCycle(application = ".SimpleTinkerInApplication", flags = ShareConstants.TINKER_ENABLE_ALL, loadVerifyFlag = false)public class SimpleTinkerInApplicationLike extends ApplicationLike public S

8、impleTinkerInApplicationLike(Application application, int tinkerFlags, boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime, long applicationStartMillisTime, Intent tinkerResultIntent) super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillis

9、Time, tinkerResultIntent); Override public void onBaseContextAttached(Context base) super.onBaseContextAttached(base); Override public void onCreate() super.onCreate(); TinkerInstaller.install(this); ApplicationLike通過名字你可能會猜，并非是Application的子類，而是一個類似Application的類。tinker建議編寫一個ApplicationLike的子類，你可以當(dāng)成A

10、pplication去使用，注意頂部的注解：DefaultLifeCycle，其application屬性，會在編譯期生成一個SimpleTinkerInApplication類。所以，雖然我們這么寫了，但是實(shí)際上Application會在編譯期生成，所以AndroidManifest.xml中是這樣的： <application android:name=".SimpleTinkerInApplication" ./>編寫如果報紅，可以build下。通過該文會對一個編譯時注解的運(yùn)行流程和基本API有一定的掌握，文中也會對tinker該部分的源碼做解析。上述，就

11、完成了tinker的初始化，那么調(diào)用loadPatch的時機(jī)，我們直接在Activity中添加一個Button設(shè)置：public class MainActivity extends AppCompatActivity Override protected void onCreate(Bundle savedInstanceState) super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); public void loadPatch(View view) TinkerInstaller.onRec

12、eiveUpgradePatch(getApplicationContext(), Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed.apk"); 我們會將patch文件直接push到sdcard根目錄；所以一定要注意：添加SDCard權(quán)限，如果你是6.x以上的系統(tǒng)，自己添加上授權(quán)代碼，或者手動在設(shè)置頁面打開SDCard讀寫權(quán)限。<uses-permission android:name="android.permission.WRITE_EXTERNAL

13、_STORAGE" />除以以外，有個特殊的地方就是tinker需要在AndroidManifest.xml中指定TINKER_ID。<application> <meta-data android:name="TINKER_ID" android:value="tinker_id_6235657" /> /.</application>到此API相關(guān)的就結(jié)束了，剩下的就是考慮patch如何生成。patch生成tinker提供了patch生成的工具，源碼見：tinker-patch-cli，打成一個ja

14、r就可以使用，并且提供了命令行相關(guān)的參數(shù)以及文件。命令行如下：java -jar tinker-patch-cli-1.7.7.jar -old old.apk -new new.apk -config tinker_config.xml -out output需要注意的就是tinker_config.xml，里面包含tinker的配置，例如簽名文件等。這里我們直接使用tinker提供的簽名文件，所以不需要做修改，不過里面有個Application的item修改為與本例一致：<loader value="com.zhy.tinkersimplein.SimpleTinkerIn

15、Application"/>大致的文件結(jié)構(gòu)如下：可以在tinker-patch-cli中提取，或者直接下載文末的例子。上述介紹了patch生成的命令，最后需要注意的就是，在第一次打出apk的時候，保留下生成的mapping文件，在/build/outputs/mapping/release/mapping.txt。可以copy到與同目錄，同時在第二次打修復(fù)包的時候，在中添加上：-applymapping mapping.txt11保證后續(xù)的打包與線上包使用的是同一個mapping文件。tinker本身的混淆

16、相關(guān)配置，可以參考：tinker_如果，你對該部分描述不了解，可以直接查看源碼即可。測試首先隨便生成一個apk（API、混淆相關(guān)已經(jīng)按照上述引入），安裝到手機(jī)或者模擬器上。然后，copy出mapping.txt文件，設(shè)置applymapping，修改代碼，再次打包，生成new.apk。兩次的apk，可以通過命令行指令去生成patch文件。如果你下載本例，命令需要在該目錄下執(zhí)行。最終會在output文件夾中生成產(chǎn)物：本例修改了title。點(diǎn)擊loadPatch，觀察log，如果成功，應(yīng)用默認(rèn)為重啟，然后再次啟動即可達(dá)到修復(fù)效果。到這里命令行的方式就介紹完了，和Andfix

17、的接入的方式基本上是一樣的。值得注意的是:該例僅展示了基本的接入，對于tinker的各種配置信息，還是需要去讀tinker的文檔（如果你確定要使用）tinker-wiki。（2）gradle接入gradle接入的方式應(yīng)該算是主流的方式，所以tinker也直接給出了例子，單獨(dú)將該tinker-sample-android以project方式引入即可。引入之后，可以查看其接入API的方式，以及相關(guān)配置。在你每次build時，會在build/bakApk下生成本地打包的apk，R文件，以及mapping文件。如果你需要生成patch文件，可以通過：./gradlew tinkerPatchRelea

18、se / 或者 ./gradlew tinkerPatchDebug生成。生成目錄為:build/outputs/tinkerPatch需要注意的是，需要在app/build.gradle中設(shè)置相比較的apk（即old.apk，本次為new.apk），ext tinkerEnabled = true /old apk file to build patch apk tinkerOldApkPath = "$bakPath/old.apk" /proguard mapping file to build patch apk tinkerApplyMappingPath = &

19、quot;$bakPath/old-mapping.txt"所以，如果你使用命令行方式接入，也不要忘了學(xué)習(xí)下其支持哪些擴(kuò)展。三、Application是如何編譯時生成的從注釋和命名上看：/可選，用于生成application類provided('com.tencent.tinker:tinker-android-anno:1.7.7')明顯是該庫，其結(jié)構(gòu)如下：入口為com.tencent.tinker.anno.AnnotationProcessor，可以在該services/cessing.Processor文件中找到處理類全

20、路徑。直接看AnnotationProcessor的process方法：Overridepublic boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) processDefaultLifeCycle(roundEnv.getElementsAnnotatedWith(DefaultLifeCycle.class); return true;直接調(diào)用了processDefaultLifeCycle：private void processDefaultLifeCycle

21、(Set<? extends Element> elements) / 被注解DefaultLifeCycle標(biāo)識的對象 for (Element e : elements) / 拿到DefaultLifeCycle注解對象 DefaultLifeCycle ca = e.getAnnotation(DefaultLifeCycle.class); String lifeCycleClassName = (TypeElement) e).getQualifiedName().toString(); String lifeCyclePackageName = lifeCycleCla

22、ssName.substring(0, lifeCycleClassName.lastIndexOf('.'); lifeCycleClassName = lifeCycleClassName.substring(lifeCycleClassName.lastIndexOf('.') + 1); String applicationClassName = ca.application(); if (applicationClassName.startsWith(".") applicationClassName = lifeCyclePack

23、ageName + applicationClassName; String applicationPackageName = applicationClassName.substring(0, applicationClassName.lastIndexOf('.'); applicationClassName = applicationClassName.substring(applicationClassName.lastIndexOf('.') + 1); String loaderClassName = ca.loaderClass(); if (lo

24、aderClassName.startsWith(".") loaderClassName = lifeCyclePackageName + loaderClassName; / /TinkerAnnoApplication.tmpl final InputStream is = AnnotationProcessor.class.getResourceAsStream(APPLICATION_TEMPLATE_PATH); final Scanner scanner = new Scanner(is); final String template = scanner.us

25、eDelimiter("A").next(); final String fileContent = template .replaceAll("%PACKAGE%", applicationPackageName) .replaceAll("%APPLICATION%", applicationClassName) .replaceAll("%APPLICATION_LIFE_CYCLE%", lifeCyclePackageName + "." + lifeCycleClassName) .

26、replaceAll("%TINKER_FLAGS%", "" + ca.flags() .replaceAll("%TINKER_LOADER_CLASS%", "" + loaderClassName) .replaceAll("%TINKER_LOAD_VERIFY_FLAG%", "" + ca.loadVerifyFlag(); JavaFileObject fileObject = processingEnv.getFiler().createSourceFile

27、(applicationPackageName + "." + applicationClassName); processingEnv.getMessager().printMessage(Diagnostic.Kind.NOTE, "Creating " + fileObject.toUri(); Writer writer = fileObject.openWriter(); PrintWriter pw = new PrintWriter(writer); pw.print(fileContent); pw.flush(); writer.clo

28、se(); 代碼比較簡單，可以分三部分理解：步驟1：首先找到被DefaultLifeCycle標(biāo)識的Element(為類對象TypeElement)，得到該對象的包名，類名等信息，然后通過該對象，拿到DefaultLifeCycle對象，獲取該注解中聲明屬性的值。步驟2：讀取一個模板文件，讀取為字符串，將各個占位符通過步驟1中的值替代。步驟3：通過JavaFileObject將替換完成的字符串寫文件，其實(shí)就是本例中的Application對象。我們看一眼模板文件：package %PACKAGE%;import com.tencent.tinker.loader.app.TinkerAppli

29、cation;/* * * Generated application for tinker life cycle * */public class %APPLICATION% extends TinkerApplication public %APPLICATION%() super(%TINKER_FLAGS%, "%APPLICATION_LIFE_CYCLE%", "%TINKER_LOADER_CLASS%", %TINKER_LOAD_VERIFY_FLAG%); 對應(yīng)我們的SimpleTinkerInApplicationLike，Defa

30、ultLifeCycle(application = ".SimpleTinkerInApplication", flags = ShareConstants.TINKER_ENABLE_ALL, loadVerifyFlag = false)public class SimpleTinkerInApplicationLike extends ApplicationLike 主要就幾個占位符：包名，如果application屬性值以點(diǎn)開始，則同包；否則則截取類名，application屬性值中的類名%TINKER_FLAGS%對應(yīng)flags%APPLICATION_LIFE

31、_CYCLE%，編寫的ApplicationLike的全路徑“%TINKER_LOADER_CLASS%”，這個值我們沒有設(shè)置，實(shí)際上對應(yīng)DefaultLifeCycle的loaderClass屬性，默認(rèn)值為com.tencent.tinker.loader.TinkerLoader%TINKER_LOAD_VERIFY_FLAG%對應(yīng)loadVerifyFlag于是最終生成的代碼為：/* * * Generated application for tinker life cycle * */public class SimpleTinkerInApplication extends Tink

32、erApplication public SimpleTinkerInApplication() super(7, "com.zhy.tinkersimplein.SimpleTinkerInApplicationLike", "com.tencent.tinker.loader.TinkerLoader", false); tinker這么做的目的，文檔上是這么說的：為了減少錯誤的出現(xiàn)，推薦使用Annotation生成Application類。這樣大致了解了Application是如何生成的。接下來我們大致看一下tinker的原理。四、原理tinker

33、貼了一張大致的原理圖?？梢钥闯觯簍inker將old.apk和new.apk做了diff，拿到patch.dex，然后將patch.dex與本機(jī)中apk的classes.dex做了合并，生成新的classes.dex，運(yùn)行時通過反射將合并后的dex文件放置在加載的dexElements數(shù)組的前面。運(yùn)行時替代的原理，其實(shí)和Qzone的方案差不多，都是去反射修改dexElements。兩者的差異是：Qzone是直接將patch.dex插到數(shù)組的前面；而tinker是將patch.dex與app中的classes.dex合并后的全量dex插在數(shù)組的前面。tinker這么做的目的還是因?yàn)镼zone方案

34、中提到的CLASS_ISPREVERIFIED的解決方案存在問題；而tinker相當(dāng)于換個思路解決了該問題。接下來我們就從代碼中去驗(yàn)證該原理。本片文章源碼分析的兩條線：應(yīng)用啟動時，從默認(rèn)目錄加載合并后的classes.dexpatch下發(fā)后，合成classes.dex至目標(biāo)目錄五、源碼分析（1）加載patch加載的代碼實(shí)際上在生成的Application中調(diào)用的，其父類為TinkerApplication，在其attachBaseContext中輾轉(zhuǎn)會調(diào)用到loadTinker()方法，在該方法內(nèi)部，反射調(diào)用了TinkerLoader的tryLoad方法。Overridepublic Inte

35、nt tryLoad(TinkerApplication app, int tinkerFlag, boolean tinkerLoadVerifyFlag) Intent resultIntent = new Intent(); long begin = SystemClock.elapsedRealtime(); tryLoadPatchFilesInternal(app, tinkerFlag, tinkerLoadVerifyFlag, resultIntent); long cost = SystemClock.elapsedRealtime() - begin; ShareInte

36、ntUtil.setIntentPatchCostTime(resultIntent, cost); return resultIntent;tryLoadPatchFilesInternal中會調(diào)用到loadTinkerJars方法：private void tryLoadPatchFilesInternal(TinkerApplication app, int tinkerFlag, boolean tinkerLoadVerifyFlag, Intent resultIntent) / 省略大量安全性校驗(yàn)代碼 if (isEnabledForDex) /tinker/

37、/patch-641e634c/dex boolean dexCheck = TinkerDexLoader.checkComplete(patchVersionDirectory, securityCheck, resultIntent); if (!dexCheck) /file not found, do not load patch Log.w(TAG, "tryLoadPatchFiles:dex check fail"); return; /now we can load patch jar if (isEnabledForDex) boolean loadTi

38、nkerJars = TinkerDexLoader.loadTinkerJars(app, tinkerLoadVerifyFlag, patchVersionDirectory, resultIntent, isSystemOTA); if (!loadTinkerJars) Log.w(TAG, "tryLoadPatchFiles:onPatchLoadDexesFail"); return; TinkerDexLoader.checkComplete主要是用于檢查下發(fā)的meta文件中記錄的dex信息（meta文件，可以查看生成patch的產(chǎn)物，在assets/de

39、x-meta.txt），檢查meta文件中記錄的dex文件信息對應(yīng)的dex文件是否存在，并把值存在TinkerDexLoader的靜態(tài)變量dexList中。TinkerDexLoader.loadTinkerJars傳入四個參數(shù)，分別為application，tinkerLoadVerifyFlag（注解上聲明的值，傳入為false），patchVersionDirectory當(dāng)前version的patch文件夾，intent，當(dāng)前patch是否僅適用于art。TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)public static bool

40、ean loadTinkerJars(Application application, boolean tinkerLoadVerifyFlag, String directory, Intent intentResult, boolean isSystemOTA) PathClassLoader classLoader = (PathClassLoader) TinkerDexLoader.class.getClassLoader(); String dexPath = directory + "/" + DEX_PATH + "/" File opt

41、imizeDir = new File(directory + "/" + DEX_OPTIMIZE_PATH); ArrayList<File> legalFiles = new ArrayList<>(); final boolean isArtPlatForm = ShareTinkerInternals.isVmArt(); for (ShareDexDiffPatchInfo info : dexList) /for dalvik, ignore art support dex if (isJustArtSupportDex(info) c

42、ontinue; String path = dexPath + info.realName; File file = new File(path); legalFiles.add(file); / just for art if (isSystemOTA) parallelOTAResult = true; parallelOTAThrowable = null; Log.w(TAG, "systemOTA, try parallel oat dexes!"); TinkerParallelDexOptimizer.optimizeAll( legalFiles, opt

43、imizeDir, new TinkerParallelDexOptimizer.ResultCallback() ); SystemClassLoaderAdder.installDexes(application, classLoader, optimizeDir, legalFiles); return true; 找出僅支持art的dex，且當(dāng)前patch是否僅適用于art時，并行去loadDex。關(guān)鍵是最后的installDexes：SuppressLint("NewApi")public static void installDexes(Application

44、application, PathClassLoader loader, File dexOptDir, List<File> files) throws Throwable if (!files.isEmpty() ClassLoader classLoader = loader; if (Build.VERSION.SDK_INT >= 24) classLoader = AndroidNClassLoader.inject(loader, application); /because in dalvik, if inner class is not the same c

45、lassloader with it wrapper class. /it won't fail at dex2opt if (Build.VERSION.SDK_INT >= 23) V23.install(classLoader, files, dexOptDir); else if (Build.VERSION.SDK_INT >= 19) V19.install(classLoader, files, dexOptDir); else if (Build.VERSION.SDK_INT >= 14) V14.install(classLoader, files

46、, dexOptDir); else V4.install(classLoader, files, dexOptDir); /install done sPatchDexCount = files.size(); Log.i(TAG, "after loaded classloader: " + classLoader + ", dex size:" + sPatchDexCount); if (!checkDexInstall(classLoader) /reset patch dex SystemClassLoaderAdder.uninstallP

47、atchDex(classLoader); throw new TinkerRuntimeException(ShareConstants.CHECK_DEX_INSTALL_FAIL); 這里實(shí)際上就是根據(jù)不同的系統(tǒng)版本，去反射處理dexElements。我們看一下V19的實(shí)現(xiàn)（主要我看了下本機(jī)只有個22的源碼）：private static final class V19 private static void install(ClassLoader loader, List<File> additionalClassPathEntries, File optimizedDir

48、ectory) throws IllegalArgumentException, IllegalAccessException, NoSuchFieldException, InvocationTargetException, NoSuchMethodException, IOException Field pathListField = ShareReflectUtil.findField(loader, "pathList"); Object dexPathList = pathListField.get(loader); ArrayList<IOExceptio

49、n> suppressedExceptions = new ArrayList<IOException>(); ShareReflectUtil.expandFieldArray(dexPathList, "dexElements", makeDexElements(dexPathList, new ArrayList<File>(additionalClassPathEntries), optimizedDirectory, suppressedExceptions); if (suppressedExceptions.size() >

50、 0) for (IOException e : suppressedExceptions) Log.w(TAG, "Exception in makeDexElement", e); throw e; 找到PathClassLoader（BaseDexClassLoader）對象中的pathList對象根據(jù)pathList對象找到其中的makeDexElements方法，傳入patch相關(guān)的對應(yīng)的實(shí)參，返回Element對象拿到pathList對象中原本的dexElements方法步驟2與步驟3中的Element數(shù)組進(jìn)行合并，將patch相關(guān)的dex放在數(shù)組的前面最后將合

51、并后的數(shù)組，設(shè)置給pathList（2）合成patch這里的入口為： TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(), Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed.apk");上述代碼會調(diào)用DefaultPatchListener中的onPatchReceived方法:# DefaultPatchListenerOverridepublic int onPatchReceived(String path) int returnCode = patchCheck(path); if (returnCode = ShareConstants.ERROR_PATCH_OK) TinkerPatchService.runPatchService(context, path); else Tinker.with(context).getLoadReporter().onLoadPatchListenerReceiveFail(new File(path), returnCode); return return