Fundamentals of Android main hot update technology

I. Andfix

The Andfix principle is the replacement of the method, replacing the bug with the method in the patch file.

Note: Replacing the bug method with pointer substitution in the native layer has been achieved to fix the bug.

The andfix uses the native hook approach, which directly uses dalvik_replaceMethod the implementation of the method in the replacement class. Since it does not replace the class as a whole, and the relative address of field in class is determined when the class is loaded, Andfix cannot support the case of adding or removing filed (by replacing init and clinit only modifying the value of field). Andfix can support patch scenarios that are relatively limited and can only be used to fix specific problems.

Two. QZone

The solution is based on the Android Dex subcontracting Scheme, a simple generalization, is to plug multiple dex files into the app's ClassLoader, but the Android Dex unpacking the class is not duplicated,  If there are duplicate classes in Classes.dex and Classes1.dex, which class will the system choose to load when this repeating class is used? Let's take a look at the code for class loading:

A classloader can contain multiple Dex files, each dex file is an element, and multiple Dex files are arranged into an ordered array dexelements, and when the class is found, the Dex file is traversed sequentially, and then the class is found from the currently traversed Dex file. If the lookup class is returned, if it is not found, continue looking from the next Dex file.

In theory, if the same class exists in different Dex, then the class that precedes the Dex file is preferred, such as:

Based on this, we envision a hot patch scenario, package the problematic class into a Dex (Patch.dex), and then insert the Dex into the front of the elements, such as:

Three. Tinker

Instant Run's cold Plug and Buck's exopackage may inspire us, and their thinking is to replace the new Dex with a full amount.

We can put the difference between the old and the new two Dex in the patch package, the simplest we can use the Bsdiff algorithm.

Simply put, the difference path.dex is generated at compile time through the old and new two Dex. At run time, the diff patch.dex is re-restored to the new Dex with the old Dex of the original installation package. This process can be time-consuming and memory-intensive, so we put it in a single background process: Patch. In order to make the patch package as small as possible, self-developed the Dexdiff algorithm, which deeply uses the Dex format to reduce the size of the differences.

Reference: https://github.com/WeMobileDev/article/blob/master/%E5%BE%AE%E4%BF%A1Android%E7%83%AD%E8%A1%A5%E4%B8%81%E5% Ae%9e%e8%b7%b5%e6%bc%94%e8%bf%9b%e4%b9%8b%e8%b7%af.md

Fundamentals of Android main hot update technology