热修复这项技术,基本上已经成为Android项目比较重要的模块了。主要因为项目在上线之后,都难免会有各种问题,而依靠发版去修复问题,成本太高了。
现在热修复的技术基本上有阿里的AndFix、QZone的方案、美团提出的思想方案以及腾讯的Tinker等。
其中AndFix可能接入是最简单的一个(和Tinker命令行接入方式差不多),不过AndFix兼容性有一定的问题,QZone方案对性能会有一定的影响,且在Art模式下出现内存错乱的问题,美团提出的思想方案主要是基于Instant Run的原理,目前尚未开源,兼容性较好。
这么看来,如果选择开源方案,Tinker目前是最佳的选择,下面来看看Tinker的大致的原理分析。
1. 原理概述
Tinker将old.apk和new.apk做了diff,拿到patch.dex后将其与本机中apk的classes.dex做了合并,生成新的classes.dex,运行时通过反射将合并后的dex文件放置在加载的dexElements数组的前面。
运行时替代的原理,其实和Qzone的方案差不多,都是去反射修改dexElements。两者的差异是:Qzone是直接将patch.dex插到数组的前面;而Tinker是合并后的全量dex插在数组的前面。因为Qzone方案中提到的CLASS_ISPREVERIFIED的解决方案存在问题。
Android的ClassLoader体系中加载类一般使用的是PathClassLoader和DexClassLoader,大家只需要明白,Android使用PathClassLoader作为其类加载器,DexClassLoader可以从.jar和.apk类型的文件内部加载classes.dex文件就好了。对于加载类,无非是给个classname,然后去findClass,PathClassLoader和DexClassLoader都继承自BaseDexClassLoader。在BaseDexClassLoader中有如下源码:
#BaseDexClassLoader @Override protected Class<?> findClass(String name) throws ClassNotFoundException { Class clazz = pathList.findClass(name); if (clazz == null) { throw new ClassNotFoundException(name); } return clazz; } #DexPathList public Class findClass(String name) { for (Element element : dexElements) { DexFile dex = element.dexFile; if (dex != null) { Class clazz = dex.loadClassBinaryName(name, definingContext); if (clazz != null) { return clazz; } } } return null; } #DexFile public Class loadClassBinaryName(String name, ClassLoader loader) { return defineClass(name, loader, mCookie); } private native static Class defineClass(String name, ClassLoader loader, int cookie);
可以看出BaseDexClassLoader中有个pathList对象,pathList中包含一个DexFile的集合dexElements,而对于类加载就是遍历这个集合,通过DexFile去寻找。
通俗点说,一个ClassLoader可以包含多个dex文件,每个dex文件是一个Element,多个dex文件排列成一个有序的数组dexElements,当找类的时候,会按顺序遍历dex文件,然后从当前遍历的dex文件中找类,如果找类则返回,如果找不到从下一个dex文件继续查找。那么这样的话,我们可以在这个数组的第一个元素放置我们的patch.jar,里面包含修复过的类,这样的话,当遍历findClass的时候,我们修复的类就会被查找到,从而替代有bug的类。
本片文章Tinker源码分析的两条线:
(1)应用启动时,从默认目录加载合并后的classes.dex
(2)patch下发后,合成classes.dex至目标目录
2.源码浅析
2.1 加载patch
加载的代码实际上在生成的Application中调用的,其父类为TinkerApplication,在其attachBaseContext中辗转会调用到loadTinker()方法,在该方法内部,反射调用了TinkerLoader的tryLoad方法。继而调用了tryLoadPatchFilesInternal方法。
@Override public Intent 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; ShareIntentUtil.setIntentPatchCostTime(resultIntent, cost); return resultIntent; }
private void tryLoadPatchFilesInternal(TinkerApplication app, int tinkerFlag, boolean tinkerLoadVerifyFlag, Intent resultIntent) { // 省略大量安全性校验代码 if (isEnabledForDex) { //tinker/patch.info/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 loadTinkerJars = TinkerDexLoader.loadTinkerJars(app, tinkerLoadVerifyFlag, patchVersionDirectory, resultIntent, isSystemOTA); if (!loadTinkerJars) { Log.w(TAG, "tryLoadPatchFiles:onPatchLoadDexesFail"); return; } } }
其中TinkerDexLoader.checkComplete主要是用于检查下发的meta文件中记录的dex信息(meta文件,可以查看生成patch的产物,在assets/dex-meta.txt),检查meta文件中记录的dex文件信息对应的dex文件是否存在,并把值存在TinkerDexLoader的静态变量dexList中。
TinkerDexLoader.loadTinkerJars传入四个参数,分别为application,tinkerLoadVerifyFlag(注解上声明的值,传入为false),patchVersionDirectory当前version的patch文件夹,intent,当前patch是否仅适用于art。
@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH) public static boolean loadTinkerJars(Application application, boolean tinkerLoadVerifyFlag, String directory, Intent intentResult, boolean isSystemOTA) { PathClassLoader classLoader = (PathClassLoader) TinkerDexLoader.class.getClassLoader(); String dexPath = directory + "/" + DEX_PATH + "/"; File optimizeDir = 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)) { continue; } 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, optimizeDir, new TinkerParallelDexOptimizer.ResultCallback() { } ); SystemClassLoaderAdder.installDexes(application, classLoader, optimizeDir, legalFiles); return true;
找出仅支持art的dex,且当前patch是否仅适用于art时,并行去loadDex。关键是最后的installDexes:
@SuppressLint("NewApi") public static void installDexes(Application 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 classloader 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, 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.uninstallPatchDex(classLoader); throw new TinkerRuntimeException(ShareConstants.CHECK_DEX_INSTALL_FAIL); } } }
这里实际上就是根据不同的系统版本,去反射处理dexElements。我们看一下V19的实现:
private static final class V19 { private static void install(ClassLoader loader, List<File> additionalClassPathEntries, File optimizedDirectory) throws IllegalArgumentException, IllegalAccessException, NoSuchFieldException, InvocationTargetException, NoSuchMethodException, IOException { Field pathListField = ShareReflectUtil.findField(loader, "pathList"); Object dexPathList = pathListField.get(loader); ArrayList<IOException> suppressedExceptions = new ArrayList<IOException>(); ShareReflectUtil.expandFieldArray(dexPathList, "dexElements", makeDexElements(dexPathList, new ArrayList<File>(additionalClassPathEntries), optimizedDirectory, suppressedExceptions)); if (suppressedExceptions.size() > 0) { for (IOException e : suppressedExceptions) { Log.w(TAG, "Exception in makeDexElement", e); throw e; } } } }
(1)找到PathClassLoader(BaseDexClassLoader)对象中的pathList对象
(2)根据pathList对象找到其中的makeDexElements方法,传入patch相关的对应的实参,返回Element[]对象
(3)拿到pathList对象中原本的dexElements方法
(4)步骤2与步骤3中的Element[]数组进行合并,将patch相关的dex放在数组的前面
(5)最后将合并后的数组,设置给pathList
2.2 合成patch
入口为onReceiveUpgradePatch()方法:
TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(), Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed.apk");
上述代码会调用DefaultPatchListener中的onPatchReceived方法:
# DefaultPatchListener @Override public 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 returnCode; }
首先对Tinker的相关配置(isEnable)以及patch的合法性进行检测,如果合法,则调用TinkerPatchService.runPatchService(context, path)。
public static void runPatchService(Context context, String path) { try { Intent intent = new Intent(context, TinkerPatchService.class); intent.putExtra(PATCH_PATH_EXTRA, path); intent.putExtra(RESULT_CLASS_EXTRA, resultServiceClass.getName()); context.startService(intent); } catch (Throwable throwable) { TinkerLog.e(TAG, "start patch service fail, exception:" + throwable); } }
TinkerPatchService是IntentService的子类,这里通过intent设置了两个参数,一个是patch的路径,一个是resultServiceClass,该值是调用Tinker.install的时候设置的,默认为DefaultTinkerResultService.class。由于是IntentService,直接看onHandleIntent即可。
@Override protected void onHandleIntent(Intent intent) { final Context context = getApplicationContext(); Tinker tinker = Tinker.with(context); String path = getPatchPathExtra(intent); File patchFile = new File(path); boolean result; increasingPriority(); PatchResult patchResult = new PatchResult(); result = upgradePatchProcessor.tryPatch(context, path, patchResult); patchResult.isSuccess = result; patchResult.rawPatchFilePath = path; patchResult.costTime = cost; patchResult.e = e; AbstractResultService.runResultService(context, patchResult, getPatchResultExtra(intent)); }
比较清晰,主要关注upgradePatchProcessor.tryPatch方法,调用的是UpgradePatch.tryPatch。这里有个有意思的地方increasingPriority(),其内部实现为:
private void increasingPriority() { TinkerLog.i(TAG, "try to increase patch process priority"); try { Notification notification = new Notification(); if (Build.VERSION.SDK_INT < 18) { startForeground(notificationId, notification); } else { startForeground(notificationId, notification); // start InnerService startService(new Intent(this, InnerService.class)); } } catch (Throwable e) { TinkerLog.i(TAG, "try to increase patch process priority error:" + e); } }
如果你对“保活”这个话题比较关注,那么对这段代码一定不陌生,主要是利用系统的一个漏洞来启动一个前台Service。下面继续回到tryPatch方法:
# UpgradePatch @Override public boolean tryPatch(Context context, String tempPatchPath, PatchResult patchResult) { Tinker manager = Tinker.with(context); final File patchFile = new File(tempPatchPath); //it is a new patch, so we should not find a exist SharePatchInfo oldInfo = manager.getTinkerLoadResultIfPresent().patchInfo; String patchMd5 = SharePatchFileUtil.getMD5(patchFile); //use md5 as version patchResult.patchVersion = patchMd5; SharePatchInfo newInfo; //already have patch if (oldInfo != null) { newInfo = new SharePatchInfo(oldInfo.oldVersion, patchMd5, Build.FINGERPRINT); } else { newInfo = new SharePatchInfo("", patchMd5, Build.FINGERPRINT); } //check ok, we can real recover a new patch final String patchDirectory = manager.getPatchDirectory().getAbsolutePath(); final String patchName = SharePatchFileUtil.getPatchVersionDirectory(patchMd5); final String patchVersionDirectory = patchDirectory + "/" + patchName; //copy file File destPatchFile = new File(patchVersionDirectory + "/" + SharePatchFileUtil.getPatchVersionFile(patchMd5)); // check md5 first if (!patchMd5.equals(SharePatchFileUtil.getMD5(destPatchFile))) { SharePatchFileUtil.copyFileUsingStream(patchFile, destPatchFile); } //we use destPatchFile instead of patchFile, because patchFile may be deleted during the patch process if (!DexDiffPatchInternal.tryRecoverDexFiles(manager, signatureCheck, context, patchVersionDirectory, destPatchFile)) { TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, try patch dex failed"); return false; } return true; }
拷贝patch文件拷贝至私有目录,然后调用DexDiffPatchInternal.tryRecoverDexFiles:
protected static boolean tryRecoverDexFiles(Tinker manager, ShareSecurityCheck checker, Context context, String patchVersionDirectory, File patchFile) { String dexMeta = checker.getMetaContentMap().get(DEX_META_FILE); boolean result = patchDexExtractViaDexDiff(context, patchVersionDirectory, dexMeta, patchFile); return result; }
直接看patchDexExtractViaDexDiff:
private static boolean patchDexExtractViaDexDiff(Context context, String patchVersionDirectory, String meta, final File patchFile) { String dir = patchVersionDirectory + "/" + DEX_PATH + "/"; if (!extractDexDiffInternals(context, dir, meta, patchFile, TYPE_DEX)) { TinkerLog.w(TAG, "patch recover, extractDiffInternals fail"); return false; } final Tinker manager = Tinker.with(context); File dexFiles = new File(dir); File[] files = dexFiles.listFiles(); ...files遍历执行:DexFile.loadDex return true; }
核心代码主要在extractDexDiffInternals中:
private static boolean extractDexDiffInternals(Context context, String dir, String meta, File patchFile, int type) { //parse meta ArrayList<ShareDexDiffPatchInfo> patchList = new ArrayList<>(); ShareDexDiffPatchInfo.parseDexDiffPatchInfo(meta, patchList); File directory = new File(dir); //I think it is better to extract the raw files from apk Tinker manager = Tinker.with(context); ZipFile apk = null; ZipFile patch = null; ApplicationInfo applicationInfo = context.getApplicationInfo(); String apkPath = applicationInfo.sourceDir; //base.apk apk = new ZipFile(apkPath); patch = new ZipFile(patchFile); for (ShareDexDiffPatchInfo info : patchList) { final String infoPath = info.path; String patchRealPath; if (infoPath.equals("")) { patchRealPath = info.rawName; } else { patchRealPath = info.path + "/" + info.rawName; } File extractedFile = new File(dir + info.realName); ZipEntry patchFileEntry = patch.getEntry(patchRealPath); ZipEntry rawApkFileEntry = apk.getEntry(patchRealPath); patchDexFile(apk, patch, rawApkFileEntry, patchFileEntry, info, extractedFile); } return true; }
这里的代码比较关键了,可以看出首先解析了meta里面的信息,meta中包含了patch中每个dex的相关数据。然后通过Application拿到sourceDir,其实就是本机apk的路径以及patch文件;根据mate中的信息开始遍历,其实就是取出对应的dex文件,最后通过patchDexFile对两个dex文件做合并。
private static void patchDexFile( ZipFile baseApk, ZipFile patchPkg, ZipEntry oldDexEntry, ZipEntry patchFileEntry, ShareDexDiffPatchInfo patchInfo, File patchedDexFile) throws IOException { InputStream oldDexStream = null; InputStream patchFileStream = null; oldDexStream = new BufferedInputStream(baseApk.getInputStream(oldDexEntry)); patchFileStream = (patchFileEntry != null ? new BufferedInputStream(patchPkg.getInputStream(patchFileEntry)) : null); new DexPatchApplier(oldDexStream, patchFileStream).executeAndSaveTo(patchedDexFile); }
通过ZipFile拿到其内部文件的InputStream,其实就是读取本地apk对应的dex文件,以及patch中对应dex文件,对二者的通过executeAndSaveTo方法进行合并至patchedDexFile,即patch的目标私有目录。至于合并算法,这里其实才是Tinker比较核心的地方,感兴趣可以参考这篇文章!
以上就是Android开发— 热修复Tinker源码的简单介绍的详细内容,更多请关注php中文网其它相关文章!