这是在公司做的一个关于热修复的技术分享
是刚推出的时候就关注的.其中的一些问题和经验写在前面,其中也有使用上的谬误,关于版本号的理解,后来咨询@悟二解决的.由于当初做的是ppt现在转换成图片格式.
若有不足之处,欢迎拍砖.
实际使用的总结
1.version name 应该和原项目一致
2.同一台手机加载成功后，卸载再安装统计上只会出现一次
3.未安装app的手机第一次安装，patch即会打入进去
4.在测试中三星手机到达率要低于其他的手机
5.dagger rxjava 项目中都有使用,修改方法补丁也可顺利到达
备注此处是最新的依赖
添加maven仓库地址：
repositories {
maven {
url "http://repo.baichuan-android.taobao.com/content/groups/public/"
}
}
添加gradle坐标版本依赖：
dependencies {
compile 'com.alibaba.sdk.android.plugins:alisdk-hotfix:1.3.3'
compile 'com.alibaba.sdk.android.plugins.jar:alisdk-utdid:0.0.1'
}
特别说明
如果编译期间报utdid类重复异常,
那么应该是其它阿里系SDK也依赖了utdid这个SDK, 此时去掉
compile'com.alibaba.sdk.android.plugins.jar:alisdk-utdid:0.0.1'
现在项目中集成了友盟统计,出现了这个问题
3.初始化
特别的说明关于SO库的处理
当前项目集成了高德地图,按照官方文档操作操作即可，以下为特别的说明
不管是android studio/eclipse集成方式都务必做如下检查! 否则将抛UnsatisfiedLinkError异常导致补丁加载失败
检查当前项目结构jniLibs中是否有armeabi-v7a, arm64-v8a目录, 如果有: 请复制下载SDK（SDK下载&版本更新记录里“SDK”项下载下来, 然后解压）文件夹中armeabi-v7a/arm64-v8a目录下对应的so文件到对应的文件夹下面. 如果没有armeabi-v7a/arm64-v8a目录, 则不需要做这个处理。
PS:hotfix这样处理的目的: 减少jar包大小进而减少apk大小. 所以alisdk-hotfix-**.aar中只有armeabi下的libandfix.so文件, 所以如果当前项目目录下有armeabi-v7a/arm64-v8a目录, 但是没有复制对应的libandfix.so文件进去, 那么在相应cpu架构的机型下加载libandfix.so就会报找不到so文件的异常(UnsatisfiedLinkError)
如果做了上述处理仍然发现UnsatisfiedLinkError异常, 那么请确保是否是打包引起的问题, 解压apk, 看libs下armeabi-v7a/arm64-v8a目录是否有对应的libandfix.so文件
生成patch
参数说明
-c, -cmd: 值为patch: 打补丁命令 值为help: 查看使用说明
-s, -src_apk：填写本地的原始APK（有问题的APK）. 必选
-f, -fixed_apk：已经修复过该问题APK. 必选
-w, -wp：输出patch的路径, 最后如果打补丁成功会在wp目录下自动创建的hotfix-working目录生成baichuan-hotfix-patch.jar补丁文件. 必选
-k, -sign_file_url：本地的签名文件的路径，不输入则不做签名. 可选
-p, -sign_file_pass: 证书文件的密码, 可选
-a, -sign_alias: 证书的别名. 可选
-e, -sign_alias_pass: 证书别名的密码. 可选
-l, -filterClassFilePath：本地的白名单类列表文件的路径，放进去的类不会再计算patch，文件格式: 一行一个类名. 可选
demo示例
java -jar BCFixPatchTools-1.3.0.jar -c patch -s old.apk -f new.apk -w patch-out -k test.keystore -p test123 -a test123 -e test123 -l filterClass.txt
filterClass.txt文件内容如下: 表示A类和B类不会比较在新旧apk中的差异直接过滤.
最后baichuan-hotfix-patch.jar补丁文件在patch-out/hotfix-working目录
补丁包的生成有一些细节需要注意，特别强调按照官方文档操作
再次强调版本号的问题，新旧项目版本号一致
如果生成过程提示JniLibs不存在，可做如下操作
上传补丁
关于灰度发布的说明,感觉上这个地方很有意思,实际上测试存在很多种,AB,灰度等等.
百川的灰度是完全的随机,并不是想象的可以基于Android版本或者品牌来操作.
臆测这种完全的随机才能体现真正的补丁到达率.
使用测试工具
补丁顺利下拉,接下来应该是皆大欢喜的结局,然而.....
verifyApk.failed
李四他爹不知不觉成了老王!!!
关于混淆
现在有了各种加固方式混淆的意义没有当时那么重要，实际上混淆的另一个意义是瘦身，百川对于混淆这个地方有特别的说明。
-keep class * extends java.lang.annotation.Annotation
-keepclasseswithmembernames class * {
native <methods>;
}
-keep class com.alipay.euler.andfix.**{
*;
}
-keep class com.taobao.hotfix.aidl.**{*;}
-keep class com.ta.utdid2.device.**{*;}
-keep class com.taobao.hotfix.HotFixManager{
public *;
}
－－－－－－－－－－－－－－－总结分割线－－－－－－－－－－－－
项目中目前集成了热修复,但并未使用,如之前所说的在技术选型上的考虑（红色标注的地方）,当然各家公司需求也不一样,可斟酌选择.阿里百川较容易的实现了热修复功能,有些高级用法还是要参见官方文档和Demo
附链接
http://baichuan.taobao.com/docs/doc.htm?spm=a3c0d.7629140.0.0.IJz6Sj&treeId=234&articleId=105457&docType=1
