Reprint please indicate the source: juejin.cn/post/684490…

Written in the beginning

Since 2015, various technology leaders have begun to study the hot repair technology, and many open source hot repair frameworks have been developed. Such as Jasonross’s Nuwa, meituan’s Robust, ali’s Andfix, Tencent’s Tinker and so on… Are the achievements of Android predecessors day and night. Now that hotfixes are widely used in Android apps and games, using and understanding the hotfix framework is a plus in an interview. So get started…

This paper takes Tinker as a learning object, mainly tells the comparison of various open source frameworks and records the Demo integration process of Tinker.

Summary of thermal repair frame principle

This section is quite long and mainly summarizes the realization principle of each thermal repair framework in my own words. If you want to see the Tinker access implementation, you can go to the next section. Android hotfix – Tinker implementation and stepped on the pit

Nuwa implementation principle:

The first article about the hotfix framework was the official Qzone article, but the implementation code of Qzone hotfix technology is not open source. However, Nuwa, an open source hotfix framework on GitHub, works in a similar way. Here, we take Qzone as an example for analysis.

Qzone is implemented by generating differential dex files and inserting patch.dex in front of dexElements. Java in patch.dex and classesb. Java in classes.dex refer to each other, and an error will be reported if the patch.dex and classes.dex are not in the same file.

Dex and classes2.dex are not the same file. So I went ahead and found this judgment

if(! fromUnverifiedConstant && IS_CLASS_FLAG_SET(referrer, CLASS_ISPREVERIFIED)){

If the referenced (that is, classESB.java) class is marked CLASS_ISPREVERIFIED, the dex verification is performed. Check but error report.

So when did this sign go up? During apK installation, the virtual machine optimizes dex to Odex before executing it. All classes are validated during this process.

How is it checked? Suppose the ClassESB.java class references the ClassESB.java class directly in its static, private, constructor, and Override methods. If the classESB. Java class and the classEsC. Java class are in the same dex, then the classESB. Java class is marked CLASS_ISPREVERIFIED. The class marked with this flag cannot refer to classes in other dex; otherwise, an error is reported. Therefore, you must prevent the class from being marked with CLASS_ISPREVERIFIED.

If (referrer->pDvmDex! = resClassCheck->pDvmDex && resClassCheck->classLoader ! = NULL)Copy the code

How do I prevent my classes from being marked with CLASS_ISPREVERIFIED? The Common class is packaged into a separate hack.dex so that when APK is installed, all classes in class. dex refer to the Common class on a different dex. This prevents the class from being marked by CLASS_ISPREVERIFIED. Any class that is not marked with this flag can be patched.

Advantages:

  • Development is transparent and simple;
  • Hot repair success rate is high.

Disadvantages:

  • On Art, the patch package is large.
  • Performance consumption is large on Dalvik.

Robust realization principle:

The Robust plug-in automatically inserts a code for each function of each production code in the compilation and packaging phase. By judging if(changeQuickRedirect! = null) to determine whether hotfix is performed. When changeQuickRedirect is not null, the method with the same name in patch.dex is called to achieve the purpose of hotfix.

How do you call it? There are two main classes in the generated patch.dex, PatchesInfoImp.java and the patched apatch.java class of the same name. After the client gets patch.dex, it loads patch.dex with DexClassLoader and gets the patchesInfoPl. Java class by reflection. And create an object of this class. We then use this object to know who is being replaced, assign its changeQuickRedirect variable to the APatch object in patch.dex, and execute the methods in the patch pack.

The flowchart is as follows: A_old indicates the original class that has not been repaired, and A_new indicates the new class that has been repaired.

advantages

  • High compatibility, transparent development;
  • It takes effect in real-time.

disadvantages

  • It will increase the number of methods and affect the operation efficiency;
  • Replacement of SO files and resources is not currently supported.

Andfix implementation principle:

The method adopted by Andfix is to replace the original method directly in the native layer in the loaded class, which is modified on the basis of the original class. The core of replaceMethod is the replaceMethod function, so only method replacement is supported, the addition and deletion of methods, resource update, so file update and class and attribute replacement are not supported.

The implementation of Andfix is partial native layer, the author’s ability is limited, its specific implementation process, I will not arbitrarily summarize. See the Andfix article for more implementation details

advantages

  • Immediate effect, low consumption;
  • The patch package is small.

disadvantages

  • Only method substitution is supported;
  • Poor compatibility, temporarily not supported for some models.

Tinker implementation principle:

Halfway through the App, all the classes that need to be changed have already been loaded, and it is impossible to uninstall a Class on Android. Tinker’s solution is to let the Classloader load new classes. If you do not restart the vm, the original class is still in the VIRTUAL machine, and the new class cannot be loaded. Therefore, only on the next reboot, load the new class in the patch before it reaches the business logic so that Resolve will be the new class when it is accessed later. So as to achieve the purpose of thermal repair.

Tinker’s implementation is more like an optimization of the Qzone hotfix. The core point is optimal performance and lowest consumption.

According to the investigation by Tinker developers, the biggest challenge of Qzone scheme lies in performance, that is, Dalvik platform has performance loss caused by piling, and Art platform may have too large patch package due to address offset. In order to avoid these two problems, according to the idea of replacing the new Dex with the full amount of Instant Run, we decided to put the differences between the old and new Dex into the patch package.

After investigation, BsDiff algorithm is not very effective in supporting Dex, so the Tinker development team developed the DexDiff algorithm by itself.

Finally, BsDiff loads SO and part of resource files, and DexDiff loads Dex files to achieve optimal performance. However, this scheme also has disadvantages, that is, it takes up more ROM. All right! Now mobile phone memory is not small, more than dozens of M can be accepted.

advantages

  • The patch package is smaller and consumes less.
  • Development is transparent and well documented.

disadvantages

  • Occupy large ROM;
  • You need to restart the system to make it take effect.

Data comparison:

Type | Nuwa | Robust |Andfix | Tinker

  • | – | – | – | –

Company | Null | at Meituan | Alibaba | Tencent development time | 2015 | 2016 | 2015 | 2016 replacement class replacement So | | | |) X X) | | | X X X |) Replace the resources effective immediately | | | |) X X) | | | |)) X X success rate highest high | | | | generally higher interface document painted painted painted painted painted painted | | | | u u u u

Is written on the back

In terms of one or more bugs in the APP on the hot repair line, Andfix can fix them instantly, and the operation is simple, and urgent problems can be easily solved without generating many patch.dex packages.

But for non-urgent bug fixes and minor releases that require less immediate availability, Tinker’s replacement is richer and better.

Alibaba upgraded Andfix to the commercial SDK Sophix; Tencent upgraded Tinker to Bugly. Sophix supports not only instant fixes, but also restarting repair classes, SO files, resources, and more. As a business APP integration Sophix is a good choice. However, Tinker’s open source has brought a large number of users and testers to Tinker. Besides, it has established relationships with major mobile phone manufacturers, so that they will also consider the issue of thermal repair when customizing the system. So Tinker’s compatibility is evident.

All in all, each to his own. We’re going to use Tinker as a learning object, so let’s get tinker-demo running and see what it looks like in action. Android hotfix – Tinker implementation and stepped on the pit

Android hotfix – Tinker implementation and stepped on the pit Amigo learning (a) to solve the problems encountered in use

Record here, just for learning!

Thank you for reading! Welcome correction!