腾讯Bugly集成热更新

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).感觉不是很方便啊

常见问题汇总

热更新常见问题