Android利用腾讯Bugly实现一键多渠道打包+一包热更新全

作者: Mr_冯先生 | 来源:发表于2017-05-25 16:08 被阅读1685次

腾讯Bugly，为移动开发者提供专业的异常上报和运营统计，帮助开发者快速发现并解决异常，同时掌握产品运营动态，及时跟进用户反馈。

Bugly主要功能有异常上报、运营统计和应用升级（包含热更新和全包更新），这些功能在官网上都有对应的开发文档可供参考，并且在热更新模块还录有专门的视频教程以供参考。

我在按照官方文档和视频教程使用之后，发现还是会存在部分不太好理解或者操作不顺畅的地方，此处便对我的所有操作做一个总结。我目前总结的是将Bugly提供的所有的功能都利用上，并且个人认为操作比较简单的做法。文末会有我参考到的所有文档信息，各位也可自行学习改进。

首先我们需要在Bugly上创建自己的应用，从而获取自己应用的App Key和App ID；然后按照以下步骤进行集成；

集成应用升级+异常上报

一：添加插件依赖

工程根目录下“build.gradle”文件中添加：

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        // tinkersupport插件, 其中lastest.release指拉取最新版本，也可以指定明确版本号，例如1.0.4
        classpath "com.tencent.bugly:tinker-support:latest.release"
     }
}

二：集成SDK

在app module的“build.gradle”文件中添加（示例配置）：

android {
    defaultConfig {
       //不开启multiDex（需要用到设为true）
        multiDexEnabled false
    }
}

dependencies {
      /*腾讯Bugly*/
    compile 'com.tencent.bugly:crashreport_upgrade:latest.release'//latest.release指代最新版本号
    compile "com.android.support:multidex:1.0.1" //多dex配置
}

// 依赖插件脚本
apply from: 'tinker-support.gradle'

在app module的“build.gradle”文件的同级目录下创建“tinker-support.gradle”文件，内容如下：

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

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

/**
 * 此处填写每次构建生成的基准包目录
 * 打热更新包时会修改
 */
def baseApkDir = "app-0208-15-10-00"

/**
 * 对于插件各参数的详细解析请参考
 */
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，并且必须保证唯一性
    //此处会经常修改，我的习惯：打基准包时“base-序号”，打热更新包时“patch-序号”
    tinkerId = "base-1.0.1"

    // 构建多渠道补丁时使用
    buildAllFlavorsDir = "${bakPath}/${baseApkDir}"

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

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

}

/**
 * 一般来说,我们无需对下面的参数做任何的修改
 * 对于各参数的详细介绍请参考:
 * 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的分配
    }
}

更详细的配置项参考tinker-support配置说明

三：初始化SDK

初始化SDK，Bugly提供了两种方式，本人采用了Bugly推荐的非反射Application模式，即在“tinker-support.gradle”文件中设置“enableProxyApplication = false”；

这是Tinker推荐的接入方式，一定程度上会增加接入成本，但具有更好的兼容性。

首先我们需要按照以下方式自定义ApplicationLike来实现Application的代码（以下是示例）：
自定义Application

public class SampleApplication extends TinkerApplication {
    public SampleApplication() {
        super(ShareConstants.TINKER_ENABLE_ALL, "xxx.xxx.SampleApplicationLike",
                "com.tencent.tinker.loader.TinkerLoader", false);
    }
}

注意：这个类集成TinkerApplication类，这里面不做任何操作，所有Application的代码都会放到ApplicationLike继承类当中
参数解析
参数1：tinkerFlags 表示Tinker支持的类型 dex only、library only or all suuport，default: TINKER_ENABLE_ALL
参数2：delegateClassName Application代理类这里填写你自定义的ApplicationLike
参数3：loaderClassName Tinker的加载器，使用默认即可
参数4：tinkerLoadVerifyFlag 加载dex或者lib是否验证md5，默认为false

我们需要您将以前的Applicaton配置为继承TinkerApplication的类(此处引用Bugly提供的图片)：

replace_application.png

自定义ApplicationLike：

public class SampleApplicationLike extends DefaultApplicationLike {

    public static final String TAG = "Tinker.SampleApplicationLike";

    public SampleApplicationLike(Application application, int tinkerFlags,
            boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime,
            long applicationStartMillisTime, Intent tinkerResultIntent) {
        super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);
    }


    @Override
    public void onCreate() {
        super.onCreate();
        buglyInit();
    }


    @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    @Override
    public void onBaseContextAttached(Context base) {
        super.onBaseContextAttached(base);
        // you must install multiDex whatever tinker is installed!
        MultiDex.install(base);

        // 安装tinker
        // TinkerManager.installTinker(this); 替换成下面Bugly提供的方法
        Beta.installTinker(this);
    }

    @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    public void registerActivityLifecycleCallback(Application.ActivityLifecycleCallbacks callbacks) {
        getApplication().registerActivityLifecycleCallbacks(callbacks);
    }

    /**
     * 初始化Bugly升级和CrashReport
     */
    private void buglyInit() {
        /*
         * true表示app启动自动初始化升级模块;
         * false不会自动初始化;
         * 开发者如果担心sdk初始化影响app启动速度，可以设置为false，
         * 在后面某个时刻手动调用Beta.init(getApplicationContext(),false);
         */
        Beta.autoInit = true;

        /*
         * true表示初始化时自动检查升级;
         * false表示不会自动检查升级,需要手动调用Beta.checkUpgrade()方法;
         */
        Beta.autoCheckUpgrade = true;

        /*
         * 设置升级检查周期为60s(默认检查周期为0s)，60s内SDK不重复向后台请求策略);
         */
        Beta.upgradeCheckPeriod = 60 * 1000;

        /*
         * 设置启动延时为1s（默认延时3s），APP启动1s后初始化SDK，避免影响APP启动速度;
         */
        Beta.initDelay = 5 * 1000;

        /*
         * 设置通知栏大图标，largeIconId为项目中的图片资源;
         */
        Beta.largeIconId = R.mipmap.ic_launcher;

        /*
         * 设置状态栏小图标，smallIconId为项目中的图片资源Id;
         */
        Beta.smallIconId = R.mipmap.ic_launcher;

        /*
         * 设置更新弹窗默认展示的banner，defaultBannerId为项目中的图片资源Id;
         * 当后台配置的banner拉取失败时显示此banner，默认不设置则展示“loading“;
         */
        Beta.defaultBannerId = R.mipmap.ic_launcher;

        /*
         * 设置sd卡的Download为更新资源保存目录;
         * 后续更新资源会保存在此目录，需要在manifest中添加WRITE_EXTERNAL_STORAGE权限;
         */
        Beta.storageDir = Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOWNLOADS);

        /*
         * 点击过确认的弹窗在APP下次启动自动检查更新时会再次显示;
         */
        Beta.showInterruptedStrategy = true;

        /*
         * 只允许在MainActivity上显示更新弹窗，其他activity上不显示弹窗;
         * 不设置会默认所有activity都可以显示弹窗;
         */
        Beta.canShowUpgradeActs.add(MainActivity.class);

        /*
         *  设置自定义升级对话框UI布局
         *  注意：因为要保持接口统一，需要用户在指定控件按照以下方式设置tag，否则会影响您的正常使用：
         *  标题：beta_title，如：android:tag="beta_title"
         *  升级信息：beta_upgrade_info  如： android:tag="beta_upgrade_info"
         *  更新属性：beta_upgrade_feature 如： android:tag="beta_upgrade_feature"
         *  取消按钮：beta_cancel_button 如：android:tag="beta_cancel_button"
         *  确定按钮：beta_confirm_button 如：android:tag="beta_confirm_button"
         *  详见layout/upgrade_dialog.xml
         */
        Beta.upgradeDialogLayoutId = R.layout.upgrade_dialog;

        // 这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId
        // 调试时，将第三个参数改为true
        Bugly.init(getApplication(), "900029763", false);//初始化Bugly
    }

}

注意：tinker需要你开启MultiDex,你需要在dependencies中进行配置compile "com.android.support:multidex:1.0.1"才可以使用MultiDex.install方法； SampleApplicationLike这个类是Application的代理类，以前所有在Application的实现必须要全部拷贝到这里，在onCreate方法调用SDK的初始化方法，在onBaseContextAttached中调用Beta.installTinker(this);

其中应用升级的详细配置可以参考应用升级配置文档

第四步：AndroidManifest.xml配置

1. 权限配置

    <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" />
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>

2. Activity配置

<activity
    android:name="com.tencent.bugly.beta.ui.BetaActivity"
    android:configChanges="keyboardHidden|orientation|screenSize|locale"
    android:theme="@android:style/Theme.Translucent" />

3. 配置FileProvider

注意：如果您想兼容Android N或者以上的设备，必须要在AndroidManifest.xml文件中配置FileProvider来访问共享路径的文件。如果你使用的第三方库也配置了同样的FileProvider，你需要将第三方库配置的路径copy到我们配置的provider_path文件下。

<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>

${applicationId}请替换为您的包名，例如com.bugly.upgrade.demo。这里要注意一下，FileProvider类是在support-v4包中的，检查你的工程是否引入该类库。

在res目录新建xml文件夹，创建provider_paths.xml文件如下：

provider_paths位置.png

<?xml version="1.0" encoding="utf-8"?>
<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>

这里配置的两个外部存储路径是升级SDK下载的文件可能存在的路径，一定要按照上面格式配置，不然可能会出现错误。

第五步：混淆配置

为了避免混淆SDK，在Proguard混淆文件中增加以下配置：

-dontwarn com.tencent.bugly.**
-keep public class com.tencent.bugly.**{*;}

如果你使用了support-v4包，你还需要配置以下混淆规则：

-keep class android.support.**{*;}

第六步：添加Bugly符号表配置

我们为了安全都会对我们的apk进行混淆，混淆之后上传到Bugly的crash信息有部分就会出现隐藏类名的情况，这样我们就无法快速的定位到我们程序的bug所在。只有我们上传对应的符号表信息后，Bugly会自动匹配并解析出我们想要找的类名。每次发包都要上传太麻烦，还是配置一个自动上传的比较方便：

一：添加插件依赖

工程根目录下“build.gradle”文件中添加：

classpath 'com.tencent.bugly:symtabfileuploader:latest.release'//Bugly符号表插件

二：添加插件和配置

在module的buid.gradle文件的顶部添加：

apply plugin: 'bugly'

bugly {
    appId = '<APP_ID>' // 注册时分配的App ID
    appKey = '<APP_KEY>' // 注册时分配的App Key
}

其中APP_ID和APP_KEY是必填的，App ID和App key可以从“产品设置”里面获取。
符号表配置的详细文档可以参考Bugly符号表插件使用指南

添加渠道信息并实现多渠道打包

我们将采用美团的walle来打多渠道包；

Walle（瓦力）：Android Signature V2 Scheme签名下的新一代渠道包打包神器

一：添加插件依赖

工程根目录下“build.gradle”文件中添加：

classpath 'com.meituan.android.walle:plugin:1.1.3'//多渠道打包

二：添加插件和配置

在module的buid.gradle文件的顶部添加：

apply plugin: 'walle'

//美团walle多渠道打包
walle {
    // 指定渠道包的输出路径
    apkOutputFolder = new File("${project.buildDir}/outputs/channels");
    // 定制渠道包的APK的文件名称
    apkFileNameFormat = '${appName}-${packageName}-${channel}-${buildType}-v${versionName}-${versionCode}-${buildTime}.apk';
    // 渠道配置文件
    channelFile = new File("${project.getProjectDir()}/channel")
}

然后添加打包用的签名文件和混淆等配置信息（此处我是将debug版本和release版本使用了共同的签名文件）；

android {
    signingConfigs {
        release {
            try {
                keyAlias 'bugly'
                keyPassword '!@#$%^&*('
                storeFile file('bugly.jks')//签名文件，位置和module的buid.gradle文件平级
                storePassword '!@#$%^&*('
            } catch (ex) {
                throw new InvalidUserDataException(ex.toString())
            }
        }
    }

    buildTypes {
        release {
            //移除无用的资源文件
            shrinkResources true
            zipAlignEnabled true

            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.release
        }
        debug {
            debuggable true
            minifyEnabled false
            signingConfig signingConfigs.release
        }
    }
}

dependencies {
    /*渠道信息统计分析*/
    compile 'com.meituan.android.walle:library:1.1.3'
}

插入渠道配置文件

channel文件.png

由于集成了Bugly的异常上报，所以还需要通过以下方式来塞入渠道信息：即在SampleApplicationLike类中添加

String channel = WalleChannelReader.getChannel(getApplication());
Bugly.setAppChannel(getApplication(), channel);
 // 这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId
Bugly.init(getApplication(), "YOUR_APP_ID", true);

这样Bugly就可以按渠道维度来统计app的Crash数据了。

三：打出多渠道包

同步gradle信息后按照下图操作打出多渠道包

打多渠道包步骤.png

打热更新包

热更新能力是Bugly为解决开发者紧急修复线上bug，而无需重新发版让用户无感知就能把问题修复的一项能力。Bugly目前采用微信Tinker的开源方案，开发者只需要集成我们提供的SDK就可以实现自动下载补丁包、合成、并应用补丁的功能，我们也提供了热更新管理后台让开发者对每个版本补丁进行管理。

之前我们打出了多个渠道包，现在我们要实现一个热更新包解决所有线上同一个版本的bug（同一个版本是指“tinker-support.gradle”文件中的“tinkerId”相同）；接着上面的打包情况我们来打热更新包：

打热更新包.png

现在我们就可以使用打出的热更新包来修改我们的线上bug了；
如果大家不清楚如何上传apk全包和热更新包，或者在上传热更新包的时候遇到一些无法处理的问题都可以参考Bugly录制的视频：

课程1：Bugly热更新介绍
课程2：tinker-support插件使用
课程3：集成升级SDK
课程4：生成补丁包之痛我懂你
课程5：补丁包为何上传不上去？
课程6：普通打包的热更新、
课程7：渠道包的热更新
课程8：加固的热更新

参考文章：
Bugly 文档中心
 Bugly多渠道热更新解决方案
 Walle

Android利用腾讯Bugly实现一键多渠道打包+一包热更新全

集成应用升级+异常上报

一：添加插件依赖

二：集成SDK

三：初始化SDK

第四步：AndroidManifest.xml配置

1. 权限配置

2. Activity配置

3. 配置FileProvider

第五步：混淆配置

第六步：添加Bugly符号表配置

一：添加插件依赖

二：添加插件和配置

添加渠道信息并实现多渠道打包

一：添加插件依赖

二：添加插件和配置

三：打出多渠道包

打热更新包

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

Android 开发技术交流

Android开发进阶

HotFix

Android知识

Android开发

手机移动程序开发

Android进阶之旅