Tinker
前言：
由于公司需要，入坑Tinker，结果发现dex以及资源文件，可以替换。而So文件，Log日志提示替换成功，而使用时不好使。所以有了该文章。
目标：
更新Dex，资源文件，以及So库文件
原理：
简单说下Tinker的原理。通过算法，将新的更新的APK和原版的BaseApk之间的差异生成一个Patch补丁包。将补丁包发送到手机本地，在用户打开手机时将补丁包加载进手机。更加具体的原理，此处不做叙述。
集成：
1. 在全局的build.gradle中新增classpath。如图：
classpath ('com.tencent.tinker:tinker-patch-gradle-plugin:1.9.1')
2.将Demo中的app中的build.gradle复制进项目中。这里有几个需要注意的地方。
3.将Demo中的文件复制进项目中.并注册service。
4.新建ApplicationLike。继承自DefaultApplication。这里是为了自动生成Application。
//application为生成的Application的名称。flags为可以替换的类型，这里TINKER_ENABLE_ALL为全都可以替换（dex，资源文件，so库）
@DefaultLifeCycle(application = ".TestTinkerApplication",flags = ShareConstants.TINKER_ENABLE_ALL
)
public class TestTinkerLike extends DefaultApplicationLike {
private static TestTinkerLike mTestTinkerLike;
public TestTinkerLike(Application application, int tinkerFlags, boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime, long applicationStartMillisTime, Intent tinkerResultIntent) {
super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);
mTestTinkerLike=this;
}
/**
* install multiDex before install tinker
* so we don't need to put the tinker lib classes in the main dex
*
* @param base
*/
@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
@Override
public void onBaseContextAttached(Context base) {
super.onBaseContextAttached(base);
//you must install multiDex whatever tinker is installed!
MultiDex.install(base);
TinkerManager.fastInstallAll(this);
}
public static TestTinkerLike getmTestTinkerLike(){
return mTestTinkerLike;
}
}
5.注册Application。会报错，因为TestTinkerApplication没有生成，build一下即可。
热更新
1. 配置签名
2. 生成基础APK包，生成位置如图。生成位置可以自行配置（在build.gradle中修改bakPath）
3. 生成补丁代码。注意：这里生成的补丁必须是基于用户安装的基础APK。假如用户安装的是A版本。而你是基于B版本生成的补丁包。这样是无法在A版本上更新的。即图中的基础APK必须是用户正在用的版本。
4. 将补丁包放到手机中，具体位置为图中所示（可以自行更改）。这里有一点需要注意就是权限问题，我看别人的Demo貌似不需要申请权限，可我做时却必须申请。这点大家可以自己试试。
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M && ActivityCompat.checkSelfPermission(MainActivity.this, Manifest.permission.WRITE_EXTERNAL_STORAGE)
!= PackageManager.PERMISSION_GRANTED) {
ActivityCompat.requestPermissions(MainActivity.this, new String[]{Manifest.permission.WRITE_EXTERNAL_STORAGE}, 0);
} else {
TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(), Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed_7zip.apk");
}
5.加载so库的几种方式：
- Hack方式（成功率最大的方式）
String CPU_ABI = android.os.Build.CPU_ABI;
// 将tinker library中的 CPU_ABI架构的so 注册到系统的library path中。
TinkerLoadLibrary.installNavitveLibraryABI(MainActivity.this, CPU_ABI);
- 非Hack方式：
String CPU_ABI = android.os.Build.CPU_ABI;
boolean a=TinkerLoadLibrary.loadLibraryFromTinker(getApplicationContext(), "lib/" + CPU_ABI, "native-lib");
- Arm方式：
TinkerLoadLibrary.loadArmLibrary(getApplicationContext(), "native-lib");
- Arm-V7a方式：
TinkerApplicationHelper.loadArmV7aLibrary(TestTinkerLike.getmTestTinkerLike(), "native-lib");
注意：
这里有两个类可以加载So文件，TinkerLoadLibrary和TinkerApplicationHelper 不过他们的原理时一样的，不知道作者为什么封了两个。
特别注意：
so文件是打补丁的时候自动加载的，但是却需要手动的链一下，相当于，基础apk本身的so文件A。在打补丁的时候加载了so文件B。此时有两个so文件。你每次都要手动的用上面的方法加载so库B。否则默认调用的还是基础APK的so文件A中的方法。一旦你在加载so库前，调用了A中的方法，默认加载的是so库A。此时你要调用so库B中 新增的方法（so库B中有，但是so库A中没有的方法）。就会报错。
文件 ：
基础文件，以及补丁包。如图所示！
切记，第一次的时候由于没有权限，需要手动打补丁。
项目地址：https://github.com/13046434521/TestTinker
问题：
如果文章有什么错误，请及时指正。比如权限的问题，我这里是必须申请的。比如so文件同时存在，而不是替换，也是个人猜测，有时间我会去证实。希望大家一同进步。
总结：
特别注意中这个简单的逻辑，却难了我3天的时间，由于大部分集成tinker的，只要替换资源文件和dex即可。所以几乎很难找到so无法生效的原因。也算是为后来人，铺了个路。后续会上代码和图片。希望大家点个喜欢，关注。还是老话，风力雨里，都在这里等你，你们的关注是我最大的动力。感谢各位了，一个入坑JNI开发的小Android程序员的诉求。感谢各位大佬啦。
