本系列将从以下三个方面对Tinker进行源码解析：
Android热更新开源项目Tinker源码解析系列之一：Dex热更新
Android热更新开源项目Tinker源码解析系列之二:资源文件热更新
Android热更新开源项目Tinker源码解析系类之三：so文件热更新
转载请标明本文来源：
更多内容欢迎star作者的github：https://github.com/LaurenceYang/article
如果发现本文有什么问题和任何建议，也随时欢迎交流~
首先讲下Android里面关于so的加载的两种方式：
方式一：System.loadLibrary， 这种方式传入的是so的名字，会直接从系统的目录去加载so文件，系统的路径包括/data/data/${package_name}/lib、/system/lib、/vender/lib等这类路径。
方式二：System.load， 这种方式传入的是so的绝对路径，直接从这个路径加载so文件。
Tinker的so文件热更新的原理就是通过方式二，直接加载新的so实现的。
相对于Dex和资源的更新，是不是简单很多。
so文件的热更新流程同dex、资源文件一样，包含补丁生成，补丁合成，补丁加载三个部分。
生成补丁时比较新旧so文件使用BSdiff算法生成补丁包，
然后在下发补丁成功后根据BSpatch算法将补丁包和旧的library合成新的library，
并将更新后的Library库文件保存在tinker下面的目录下，
这个目录就是/data/data/${package_name}/tinker/lib。
然后在加载的时候直接通过System.load加载该目录下面的so文件。
具体的源码不再做阐述。
需要注意的是，Tinker中so的热更新对用户并不是无感的，需要用户自发的去加载自己需要的库文件，下面是tinker的wiki里关于这方面的描述：
但是Tinker并没有直接将补丁的lib路径添加到DexPathList中，理论上这样可以做到程序完全没有感知的对Library文件作补丁。这里主要是因为在多abi的情况下，某些机器获取的并不准确。
所以想要加载最新的库，需要自己使用TinkerInstaller.load*Library去加载库文件，它会自动尝试先去Tinker中的库文件加载，加载不成功会调用System.loadLibrary调用系统的库文件。
1 //load lib/armeabi library 2 TinkerInstaller.loadArmLibrary(getApplicationContext(), "stlport_shared"); 3 //load lib/armeabi-v7a library 4 TinkerInstaller.loadArmV7Library(getApplicationContext(), "stlport_shared");