热更新之Tinker的快速集成

前言：

如今的Android项目，大部分都离不开热更新这项技术。因为公司须要，入坑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中没有的方法）。就会报错。

文件 ：

基础文件，以及补丁包。如图所示！ 切记，第一次的时候因为没有权限，须要手动打补丁。

项目地址：github.com/13046434521…

问题：

若是文章有什么错误，请及时指正。好比权限的问题，我这里是必须申请的。好比so文件同时存在，而不是替换，也是我的猜想，有时间我会去证明。但愿你们一同进步。

总结：

特别注意中这个简单的逻辑，却难了我3天的时间，因为大部分集成tinker的，只要替换资源文件和dex便可。因此几乎很难找到so没法生效的缘由。也算是为后来人，铺了个路。后续会上代码和图片。但愿你们点个喜欢，关注。仍是老话，风力雨里，都在这里等你，大家的关注是我最大的动力。感谢各位了，一个入坑JNI开发的小Android程序员的诉求。感谢各位大佬啦。