Android-Bugly 版本更新和热修复接入

详解

提起版本更新，是每个app和开发者最熟悉的东西，但是频繁的更新会让用户反感，但是不更新的话在发现了bug怎么办呢？在用户体验和版本稳定性的碰撞下，热修复出来了，热修复就不用多说了，常见热修复分为冷启动修复和实时修复，这里不多介绍，感兴趣的朋友可以了解各大平台的热修复原理，这次由于公司有用到Bugly的热修复，所以记录下来。

1.引入依赖及签名配置

首先在我们app目录下的build.gradle文件中引入：

implementation 'com.tencent.bugly:crashreport_upgrade:latest.release'
    implementation 'com.tencent.bugly:nativecrashreport:latest.release'
    implementation 'com.tencent.tinker:tinker-android-lib:1.9.9'

这里的latest.release代表最新版本的意思，然后我们在Project的build.gradle文件中引入

classpath "com.tencent.bugly:tinker-support:1.1.5"

回到我们app目录下的build.gradle文件，在顶部加入

apply from: 'tinker-support.gradle'

然后配置好签名，为什么要配置签名呢？因为在我们等下自动打包的时候会用上，在app目录下的build.gradle文件中android节点下加入

signingConfigs {

        release {
            keyAlias '签名文件别名'
            keyPassword '密码'
            storeFile file('签名文件路径')
            storePassword '签名文件密码'
        }
    }

配置好后，我们还要在 buildTypes 的节点中设置：

buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.release//在这里设置配置的签名
        }
    }

以上我们就完成了自动打包的签名配置，接下来接入和初始化，需要在清单文件中先配置：

<!--腾讯bugly升级服务start-->
        <activity
            android:name="com.tencent.bugly.beta.ui.BetaActivity"
            android:configChanges="keyboardHidden|orientation|screenSize|locale"
            android:theme="@android:style/Theme.Translucent" />

        <provider
            android:name="android.support.v4.content.FileProvider"
            android:authorities="${applicationId}.fileProvider"
            android:exported="false"
            android:grantUriPermissions="true">
            <meta-data
                android:name="android.support.FILE_PROVIDER_PATHS"
                android:resource="@xml/provider_paths"/>
        </provider>

        <!--腾讯bugly升级服务end-->

provider文件主要是为了支持andorid N以上访问共享路径的文件，如果你的项目中有其他第三方库也配置了，可以继承FileProvider类来解决合并冲突的问题：

<provider
    android:name="com.tencent.bugly.beta.utils.BuglyFileProvider"
    android:authorities="${applicationId}.fileProvider"
    android:exported="false"
    android:grantUriPermissions="true"
    tools:replace="name,authorities,exported,grantUriPermissions">
    <meta-data
        android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/provider_paths"
        tools:replace="name,resource"/>
</provider>

然后我们需要在res目录新建xml文件夹，创建provider_paths.xml文件如下：

<paths xmlns:android="http://schemas.android.com/apk/res/android">
    <!-- /storage/emulated/0/Download/${applicationId}/.beta/apk-->
    <external-path name="beta_external_path" path="Download/"/>
    <!--/storage/emulated/0/Android/data/${applicationId}/files/apk/-->
    <external-path name="beta_external_files_path" path="Android/data/"/>
</paths>

这样我们就完事具备，只欠东风，在Application中初始化：

Beta.autoInit = true;
 Beta.canShowUpgradeActs.add(MainActivity.class);
 Beta.installTinker();
 Bugly.init(this, "appId", true);

Beta类作为Bugly的初始化扩展，通过Beta类可以修改升级的检测时机，界面元素以及自定义升级行为，详情可以查看官方文档Beat拓展类,在这里呢，我就不多说了，由于自动检测更新我觉得有延迟，所以可以在主页面调用Beta.checkUpgrade(isManual ,isSilence )；方法来检测更新 参数1：isManual 用户手动点击检查，非用户点击操作请传false

参数2：isSilence 是否显示弹窗等交互，[true:没有弹窗和toast] [false:有弹窗或toast] 然后打包上传一气呵成，这里提交后要稍等几分钟才能生效，然后关掉app，打开就会有更新提示了。

更新完成后，到我们的重头戏热更了。

2.热更新配置

首先我们要在app的目录下创建tinker-support.gradle，然后拷入代码：

apply plugin: 'com.tencent.bugly.tinker-support'

def bakPath = file("${buildDir}/bakApk/")

/**
 * 此处填写每次构建生成的基准包目录
 */
def baseApkDir = "app-0523-11-17-07"

/**
 * 对于插件各参数的详细解析请参考
 */
tinkerSupport {

    // 开启tinker-support插件，默认值true
    enable = true

    // 指定归档目录，默认值当前module的子目录tinker
    autoBackupApkDir = "${bakPath}"

    // 是否启用覆盖tinkerPatch配置功能，默认值false
    // 开启后tinkerPatch配置不生效，即无需添加tinkerPatch
    overrideTinkerPatchConfiguration = true

    // 编译补丁包时，必需指定基线版本的apk，默认值为空
    // 如果为空，则表示不是进行补丁包的编译
    // @{link tinkerPatch.oldApk }
    baseApk = "${bakPath}/${baseApkDir}/app-release.apk"

    // 对应tinker插件applyMapping
    baseApkProguardMapping = "${bakPath}/${baseApkDir}/app-release-mapping.txt"

    // 对应tinker插件applyResourceMapping
    baseApkResourceMapping = "${bakPath}/${baseApkDir}/app-release-R.txt"

    // 构建基准包和补丁包都要指定不同的tinkerId，并且必须保证唯一性
    tinkerId = "0.0.39.2-pasth"
    //tinkerId = "0.0.39.1-app"
    // 构建多渠道补丁时使用
    // buildAllFlavorsDir = "${bakPath}/${baseApkDir}"

    // 是否启用加固模式，默认为false.(tinker-spport 1.0.7起支持）
    // isProtectedApp = true

    // 是否开启反射Application模式
    enableProxyApplication = true

    // 是否支持新增非export的Activity（注意：设置为true才能修改AndroidManifest文件）
    supportHotplugComponent = true

}

/**
 * 一般来说,我们无需对下面的参数做任何的修改
 * 对于各参数的详细介绍请参考:
 * https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97
 */
tinkerPatch {
    //oldApk ="${bakPath}/${appName}/app-release.apk"
    ignoreWarning = false
    useSign = true
    dex {
        dexMode = "jar"
        pattern = ["classes*.dex"]
        loader = []
    }
    lib {
        pattern = ["lib/*/*.so"]
    }

    res {
        pattern = ["res/*", "r/*", "assets/*", "resources.arsc", "AndroidManifest.xml"]
        ignoreChange = []
        largeModSize = 100
    }

    packageConfig {
    }
    sevenZip {
        zipArtifact = "com.tencent.mm:SevenZip:1.1.10"
//        path = "/usr/local/bin/7za"
    }
    buildConfig {
        keepDexApply = false
        //tinkerId = "1.0.1-base"
        //applyMapping = "${bakPath}/${appName}/app-release-mapping.txt" //  可选，设置mapping文件，建议保持旧apk的proguard混淆方式
        //applyResourceMapping = "${bakPath}/${appName}/app-release-R.txt" // 可选，设置R.txt文件，通过旧apk文件保持ResId的分配
    }
}

大多数配置不用修改，在这里注意 baseApkDir tinkerId baseApkProguardMapping 这三个参数，第一个呢暂时不用管，是打补丁包时的基准包目录，第二个时标识符，可以随意明明，但是注意唯一性，第三个参数如果项目没有启用混淆，可以屏蔽掉，由于我们配置好了签名，先修改tinkerId的参数，随意命名（最好用版本号加项目名），然后打开anroid studio的Gradle菜单：

如图打基准包的箭头所指，双击，等待控制台日志如下图：

出现BUILE SUCCESSFUL字样，表示编译成功，然后我们在以下目录可以看到生成的基准包：

基准包有了，我们先修改一下app的内容，修改完后，将tinker-support.gradle文件中的baseApkDir修改为编译生成的基准包的目录名，如上图的app-0523-16-28-51，然后记得修改tinkerId，之后点击Gradle菜单中的buildTinkerPatchRelease，等待日志出现BUILD SUCCESSFUL的字样，在如下路径中找到补丁包：

箭头所指就是我们的补丁包，打工告成，记住，上传补丁包前请先安装基准包并打开，否则会报找不到版本的错误。

等待十几分钟后，重新打开app会发现修复成功。

总结

热更新的配置不是很麻烦，熟悉了以后就很快了，关键是Bugly生效时间慢，一开始配置成功见没生效还以为没弄好，这是个坑，希望能帮到配置Bugly热更的大家。

Android核心知识点笔记github：https://github.com/AndroidCot/Android