微信tinker 热修复

Tinker 是微信官方的Android热补丁解决方案，它支持动态下发代码、So库以及资源，让应用能够在不需要重新安装的情况下实现更新。当然，你也可以使用Tinker来更新你的插件。

github：https://github.com/Tencent/tinker

关于接入：

Tinker-接入指南

Tinker 自定义扩展

Tinker-常见问题

公司接入tinker过程很顺利，基本问题都能够在tinker上，或者观看源码中获得答案。我们自己搭建的后台下发补丁、验证，安装。

build.gradle:

1、添加dependencies

    //可选，用于生成application类
    compile 'com.tencent.tinker:tinker-android-anno:1.7.1'
    //tinker的核心库
    compile 'com.tencent.tinker:tinker-android-lib:1.7.1'

关于补丁后台管理：

1、Bugly热更新SDK-集成tinker：

http://dev.qq.com/topic/583ccfecb5f2ebea6e610f90

2、tinkerpatch tinker 热修复平台

http://tinkerpatch.com/

3、自己搭建后台管理：

server方面：

（1）提供请求tinker信息接口

（2）tinker补丁包下载

（3）tinker信息添加管理平台（添加，删除，修改tinker补丁包信息）

android方面：

（1）tinker配置类：

 import java.io.Serializable;
 
 public static class TinkerConfig implements Serializable {
         public String tinker_id;    // tinkerId
         public String version_name;     // 版本号
         public String download_url;        //  tinker补丁下载地址
         public String md5;         // tinker补丁文件的md5值
 }

（2）applicationlike create()方法调用时，http请求tinker配置信息，请求成功后，检查tinker版本的，

通过 Tinker.with(context).getTinkerLoadResultIfPresent() 获取现有的tinker版本。

 TinkerLoadResult tinkerLoadResult = Tinker.with(context).getTinkerLoadResultIfPresent();
 String newTinkerID = ""; 
 String tinkerID = "";
 if (tinkerLoadResult != null) {
     newTinkerID = tinkerLoadResult.getNewTinkerID();
     tinkerID = tinkerLoadResult.getTinkerID();
 }

（3）判断http获取到tinker信息跟现有的tinker信息：

if (tinkerPatch.tinker_id.equals(newTinkerID)) {
    Log.e(TAG, "补丁已安装");
    return;
}
if (!Utils.getVersionName().equals(tinkerPatch.version_name)) {
    Log.e(TAG, "补丁版本不一致");
    return;
}
// 下载tinker补丁，并安装。
downloadPatchInstall(context, tinkerPatch);

（4）判断是否已存在tinker补丁，否则下载tinker补丁。

（5）判断下载补丁文件的md5跟服务器的补丁md5是否一致。

（6）执行tinker补丁安装：

TinkerInstaller.onReceiveUpgradePatch(context.getApplicationContext(), file.getAbsolutePath());

源码解析：

官方事例源码：tinker-sample

http://www.cnblogs.com/yyangblog/p/6249715.html

移动原application逻辑到新的applicationLike中：

 一般不建议你自定义Application，把原来Application里的逻辑转移到ApplicationLike里会好很多 不过如果你真的自定义了Application，就要把你的自定义Application直接引用的类也加到loader pattern里，不然就会报preveriried的异常，而且这就导致了你的自定义Application和它直接引用的类无法被补丁更新，所以最好不要在Application里放任何逻辑，原来的Application里的逻辑全部移到ApplicationLike里就好。

包括分包的方法等，全都移到applicationlike，不移动会导致一些类提前加载，导致后续无法对这些类修改的问题。

tinkerId：

tinkerid一致的话，补丁会复用

可以用versioncode, clientversion之类的

只要保证每次发版本都会不一样就可以了。

打包发布：

关于保存基准包apk以及mapping文件以及resc文件，发版出去才需要保存，需结合自己的打包平台使用。

支持加固：

（由于各个厂商的加固实现并不一致，在1.7.6以及之后的版本，tinker不再支持加固的动态更新。）

tinker的一般模式需要Dex的合成，它并不支持加固，一定要使用加固的app可以使用usePreGeneratedPatchDex模式。

 只要加固后重新签名就没问题

关于：patch

:patch 进程， 在回调会自动kill掉的啊

要在Manifest；里面注册服务的。

intentservice 的实现机制就是新开一个handlerthread，然后stopself的时候把thread quit掉。

调用stopself杀死service以后，patch进程就是空进程，空进程什么时候回收，要看系统策略以及当前进程情况。

主要这个进程在，下次就无法修复了，因为补丁的时候，发现这个进程还在，就直接返回了。

检查下自己的代码，自己的service是否已经在manifest注册。

关于assets

例子里面下面这个assets/secondary-dex-?.jar是干什么用的呢？

如果assets里面也有dex, 可以这么设。

关于productFlavors编渠道包：

使用gradle的productFlavors编渠道包，由于会改变BuildConfig类的内容，从而导致dex不一致。 目前有什么好的方案吗？除了zip comment。能够既编出渠道包又不将FLAVOR写入BuildConfig。

只是用flavor来配置友盟的统计渠道

打release包换下保存目录就好了

如果使用Zip comment方式的话，稳定的工具或gradle插件推荐：

https://github.com/seven456/MultiChannelPackageTool

   说明：这个方式的还是不支持v2SigningEnabled啊，android 7.0上校验不通过，看来只能把v2SigningEnabled关了，v2SigningEnabled 不是要求打包完后对apk不能做任何修改吗，AndResGuard也不支持。

http://blog.csdn.net/liuyanggofurther/article/details/50978407

tinker-如何兼容多渠道包？

使用packer-ng-plugin命令行的方式