bugly 全量更新和热修复

   bugly怎么说的，全量更新跟热修复使用起来还是很简单的，只是点点点就好了，还支持加固，还有错误收集日志。

但是！这依然不能抵挡他官方文档里的坑的问题！大问题！我用了一个星期踩坑，建了三四个项目，终于弄完了！那种成就感！那种自豪感！我都不知道自己是谁了。

下面开始集成，最好不要一次全都集成，而是分开弄，集成一个实验一下功能是否正常在集成下一个，还有，如果是集成进入现有项目的话，最好新建个测试类，不然那关联的报错会让你欲仙欲死的。

---------------------------------------------------------------

  先从全量更新开始：

更新比较简单，而且网上很多，基本上按照顺序走就都能成功，需要注意的就是签名文件问题了，这个都不用怎么说吧，还有就是生效需要一定的时间。

在项目的build.gradle中添加依赖，我的连带着修复的也算上了，如果你只需要更新的话，可以不按照我的做，去找一个更新的文章，因为我的是连带着热修复也算在内部的。

classpath ('com.tencent.tinker:tinker-patch-gradle-plugin:1.7.11')
classpath "com.tencent.bugly:tinker-support:1.1.2"

 

添加依赖，虽然大部分最后两个就够了，不过还好全点吧：

//bugly
compile 'com.android.support:multidex:1.0.1'
// 多dex配置
compile 'com.tencent.tinker:tinker-android-lib:1.9.6'
compile 'com.tencent.bugly:nativecrashreport:latest.release'
//其中latest.release指代最新版本号，也可以指定明确的版本号，例如2.2.0
compile 'com.tencent.bugly:crashreport_upgrade:latest.release'
//其中latest.release指代最新版本号，也可以指定明确的版本号，例如1.2.1

 

 

然后是权限，这个位置不需要多说，就不截图了，

然后同样是文件内配置activity和provider，如果有第三方文档的话可以按照官方文档来做，另外，v4包的需要注意一下，看看ctrl+左键能不能点进去，最好这两个都试一下，才能知道导没导入成功

然后初始化就可以了，

在Application类中初始化1

public class MyApplication extends Application{
    @Override
    public void onCreate() {
        super.onCreate();

        ------

        Bugly.init(getApplicationContext(), "你的appkey", false);

        ------
    }
}

记得在bugly申请一个账号，然后创建项目，然后填写资料就好了，这个不需要多说

找到AppID，主要需要的就是这个，初始化中也是

 

然后是初始化，创建一个全局类，集成Application类

public class MyApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();
        // bugly版本更新
 intBugly();
    }

    private void intBugly() {
        /**
         * 只允许在MainActivity上显示更新弹窗，其他activity上不显示弹窗;
         * 不设置会默认所有activity都可以显示弹窗;
         */
        Beta.canShowUpgradeActs.add(MainActivity.class);
        Beta.autoInit = true;
        Beta.autoCheckUpgrade = true;
        /**
         * 点击过确认的弹窗在APP下次启动自动检查更新时会再次显示;
         */
        Beta.showInterruptedStrategy = false;
        Bugly.init(getApplicationContext(), "自己的appid", false);
    }

}

然后在任何一个想要监测更新的类中调用方法，比如MainActivity

Beta.checkUpgrade();

这样就完成了，只要按照需求加固混淆什么的就可以了，然后上传到bugly发布更新策略就行，那个就按照官方文档走就可以了，下面是bugly的混淆，记得修改版本号哦，只能增大，不能减小。

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

 

到这里更新就集成完毕，只要正常打包然后发布就可以了，策略启动需要一定的时间，然后用打包好的更新就好了，基本上没有什么坑，也很简单，但是接下来的热修复就消耗了好长时间，出了好多坑。

首先导入依赖，上面都有了就不发了，需要注意的是，tinker-support文档创建需要的依赖需要放在项目的build中，上面也写了，然后在app目录下创建一个tinker-support.gradle文件，需要跟依赖的build同级，然后在build中添加

apply from: 'tinker-support.gradle'

下面是tinker-support.gradle的内容，基本上都有了注释，每次更新修改的都有注解，基本上只需要改两个位置就好了，需要注意的是！构筑热更新之后打包需要分清是基准包还是更新包，需要准备好签名文件，尤其要注意！签名文件的别名也要记住！如果忘了那就按照常规打包方式重新打一个记住，因为接下来会用到：

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

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

/**
 * 此处填写每次构建生成的基准包目录app-0319-18-17-55
 */
def baseApkDir = "app-0928-14-01-40"

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

    // 开启tinker-support插件，默认值true
    enable = true
    // tinkerEnable功能开关
    tinkerEnable = 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是补丁包，版本后面+.1代表补丁版本
    tinkerId = "patch-1.0.7"

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

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

    // 是否开启反射Application模式
    enableProxyApplication = 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的分配
    }
}

好的，到这里基本上差不多了，然后就到了我踩坑的位置了，没错，签名文件，看见下面这张图了吗，这就是签名，这个不是复制粘贴的，就算是你弄上也没卵用，我就是粘贴的，哪怕是换成自己的签名路径也没用，运行不会报错，但是，会，

 

首先，打开file下的project structure

这里需要注意啊，别名一定要是签名文件的别名，因为如果不是，会报错别名错误，这个我弄了半天才搞定，然后点击ok就可以了，等编译完成，还是同样的方法进来，选择你刚刚创建的那个，然后ok，这样你的签名就会自己出现了。

 

然后添加

ndk {
    //设置支持的SO库架构
    abiFilters 'armeabi' //, 'x86', 'armeabi-v7a', 'x86_64', 'arm64-v8a'
}

 

这样基本上一个热修复就完成了，接下来打包基准包：

注意保留好基准包，因为执行热修复的时候回用到，所以一定要保存好！

好了，到这里就完事了，至于在踩坑，那就需要看看你的是什么错误了。