微信tinker 热修复
Tinker 是微信官方的Android热补丁解决方案，它支持动态下发代码、So库以及资源，让应用能够在不需要重新安装的情况下实现更新。当然，你也可以使用Tinker来更新你的插件。
github：https://github.com/Tencent/tinker
关于接入：
公司接入tinker过程很顺利，基本问题都能够在tinker上，或者观看源码中获得答案。我们自己搭建的后台下发补丁、验证，安装。
build.gradle:
1、添加dependencies
1 //可选，用于生成application类 2 compile 'com.tencent.tinker:tinker-android-anno:1.7.1' 3 //tinker的核心库 4 compile 'com.tencent.tinker:tinker-android-lib:1.7.1'
关于补丁后台管理：
1、Bugly热更新SDK-集成tinker：
http://dev.qq.com/topic/583ccfecb5f2ebea6e610f90
2、tinkerpatch tinker 热修复平台
3、自己搭建后台管理：
server方面：
（1）提供请求tinker信息接口
（2）tinker补丁包下载
（3）tinker信息添加管理平台（添加，删除，修改tinker补丁包信息）
android方面：
（1）tinker配置类：
1 import java.io.Serializable; 2 3 public static class TinkerConfig implements Serializable { 4 public String tinker_id; // tinkerId 5 public String version_name; // 版本号 6 public String download_url; // tinker补丁下载地址 7 public String md5; // tinker补丁文件的md5值 8 }
（2）applicationlike create()方法调用时，http请求tinker配置信息，请求成功后，检查tinker版本的，
通过 Tinker.with(context).getTinkerLoadResultIfPresent() 获取现有的tinker版本。
1 TinkerLoadResult tinkerLoadResult = Tinker.with(context).getTinkerLoadResultIfPresent(); 2 String newTinkerID = ""; 3 String tinkerID = ""; 4 if (tinkerLoadResult != null) { 5 newTinkerID = tinkerLoadResult.getNewTinkerID(); 6 tinkerID = tinkerLoadResult.getTinkerID(); 7 }
（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补丁安装：
1 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
使用packer-ng-plugin命令行的方式
