Bugly Android热更新使用指南
前言:在项目进行的时候，因为可能上线项目存在bug，影响用户的体验。所以不得不集成热更新框架。目前网上也有很多的框架。我最开始看bugly的时候感觉集成好复杂后面集成了阿里百川，然后tinker。当对tinker的集成了解差不多了，最终没有集成成功。然后当我在看到bugly的时候感觉他的集成还是挺简单的bugly的集成也正是基于tinker进行集成的。
image.png
集成步骤
1.工程根目录下“build.gradle”文件中添加：
buildscript {
repositories {
jcenter()
}
dependencies {
// tinkersupport插件, 其中lastest.release指拉取最新版本，也可以指定明确版本号，例如1.0.4
classpath "com.tencent.bugly:tinker-support:1.1.2"
}
}
注意：自tinkersupport 1.0.3版本起无需再配tinker插件的classpath。
版本对应关系:
tinker-support 1.1.2 对应 tinker 1.9.6
tinker-support 1.1.1 对应 tinker 1.9.1
tinker-support 1.0.9 对应 tinker 1.9.0
tinker-support 1.0.8 对应 tinker 1.7.11
tinker-support 1.0.7 对应 tinker 1.7.9
tinker-support 1.0.4 对应 tinker 1.7.7
tinker-support 1.0.3 对应 tinker 1.7.6
tinker-support 1.0.2 对应 tinker 1.7.5（需配置tinker插件的classpath）
2.集成SDK
1.在app module的“build.gradle”文件中添加（示例配置）
android {
defaultConfig {
ndk {
//设置支持的SO库架构
abiFilters 'armeabi' //, 'x86', 'armeabi-v7a', 'x86_64', 'arm64-v8a'
}
}
}
dependencies {
compile "com.android.support:multidex:1.0.1" // 多dex配置
//注释掉原有bugly的仓库
//compile 'com.tencent.bugly:crashreport:latest.release'//其中latest.release指代最新版本号，也可以指定明确的版本号，例如1.3.4
compile 'com.tencent.bugly:crashreport_upgrade:1.3.5'
// 指定tinker依赖版本（注：应用升级1.3.5版本起，不再内置tinker）
compile 'com.tencent.tinker:tinker-android-lib:1.9.6'
compile 'com.tencent.bugly:nativecrashreport:3.3.1' //其中latest.release指代最新版本号，也可以指定明确的版本号，例如2.2.0
}
2.在app module的“build.gradle”文件中添加：
// 依赖插件脚本
apply from: 'tinker-support.gradle'
3.打开project,在app同级目录下创建tinker-support.gradle文件
apply plugin: 'com.tencent.bugly.tinker-support'
def bakPath = file("${buildDir}/bakApk/")
def appName = "app-0928-15-43-01"
/**
* 对于插件各参数的详细解析请参考
*/
tinkerSupport {
// 开启tinker-support插件，默认值true
enable = true
// 指定归档目录，默认值当前module的子目录tinker
autoBackupApkDir = "${bakPath}"
// 是否启用覆盖tinkerPatch配置功能，默认值false
// 开启后tinkerPatch配置不生效，即无需添加tinkerPatch
overrideTinkerPatchConfiguration = true
// 编译补丁包时，必需指定基线版本的apk，默认值为空
// 如果为空，则表示不是进行补丁包的编译
// @{link tinkerPatch.oldApk }
baseApk = "${bakPath}/${appName}/app-release.apk"
// 对应tinker插件applyMapping
baseApkProguardMapping = "${bakPath}/${appName}/app-release-mapping.txt"
// 对应tinker插件applyResourceMapping
baseApkResourceMapping = "${bakPath}/${appName}/app-release-R.txt"
// 唯一标识当前版本
tinkerId = "1.0-base" //打补丁时要修改tinkerid 原来是 1.0-base 1.0-fix
// 是否开启代理Application，设置之后无须改造Application，默认为false
enableProxyApplication = true
}
4.设置 enableProxyApplication = true，在appication中添加
public class MyApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
// 这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId
// 调试时，将第三个参数改为true
Bugly.init(this, "900029763", false);
}
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// you must install multiDex whatever tinker is installed!
MultiDex.install(base);
// 安装tinker
Beta.installTinker();
}
}
5.配置权限
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.READ_LOGS" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
经过以上就算基本配置好了。接下来就是打基准包了。就是你要发到线上用的那个包。
编译基准包
编译基准包的时候我们给tinkerId取名叫 “1.0.-base”,名字随便取，是一个唯一标志
image.png
执行assembleRelease编译生成基准包：
image.png
编译成功之后会在build/outputs/bakApk路径下生成每次编译的基准包、混淆配置文件、资源Id文件
image.png
注意：实际应用中，请注意保存线上发布版本的基准apk包、mapping文件、R.txt文件，如果线上版本有bug，就可以借助我们tinker-support插件进行补丁包的生成。
svn的话，可以在 项目文件夹的地方右键-->TortoiseSVN--->branch/tag来创建分支，方便后面修复的时候拉取
记得保存当前的项目，最好创建一个分支。并同时保存上面的
image.png
。
上面生成的app-release.apk可以上线了。
-----------------------------------------华丽的分割线---------------------------------------------------
然后你就继续你主分支的开发。某一天，出现一个bug,那种tinker能修复的那种bug。然后你一想我有备份。立刻拉取下来分支。当然不能再主分支上修改删，主分支上你可能已经新创建了activity等，这样不支持。然后你在拉取的分支下，修复了bug,然后，就需要打修复的包了。
新拉取的项目，在app/build/下是没有bakApk目录的。所以需要创建bakApk目录,并复制报存好的 app-xx-xx-xx的目录到改目录下。eg:
image.png
根据基线版本生成补丁包。
把你保存的app-xxx-xxx-xxx-xx的目录复制到app/build/bakApk下。在你打补丁包的时候，可以删除存在的outputs目录。这样打包的时候会重新创建一个，就不会存在patch目录为空的结果。
image.png
执行构建补丁包的task
image.png
如果你要生成不同编译环境的补丁包，只需要执行TinkerSupport插件生成的task，比如buildTinkerPatchRelease就能生成release编译环境的补丁包
生成的补丁包在build/outputs/patch目录下：
image.png
注意如果我打了多个补丁包，比如先上传了补丁A已经下发到了设备中并且修复，如果我又打了一个补丁(
需要重新修改tinkerid，不改tinkerid没测试，反正改了是成功了的)，这种情况会怎样？如果你的基于基线版本打了多个补丁包，并且上传了多个，我们会以你最后上传的补丁为准，就是说后面的补丁会覆盖前面的补丁。
image.png
意思就是打一次就修改一次tinkid
上传补丁包到平台
image.png
选择path_signed_7zip.apk,并选择下发。
应用可能要重启一两次就可以修复了。一下发，可能结束应用，不能马上看到效果。可能还得过一会。
问题
比如我们在修复之后，只想在自己手机上看看下发效果，选择的是开发下发。文档中有这么一点
Bugly.setIsDevelopmentDevice(getApplicationContext(), true);，
我们后台就会将你当前设备识别为开发设备，如果设置为false则非开发设备，我们会根据这个配置进行策略控制。
这个是什么意思？
意思在发版本前，我们需要同时保存一个线上的版本为flase,表示用户版本。同时保存一个版本为true,表示开发者版本？修改flase,true打包，不是目录又会变(apk-xxx-xxx-xxx).感觉不是很方便啊
网友评论