热更新之Tinker的快速集成-CSDN博客

前言：

现在的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程序员的诉求。感谢各位大佬啦。