博主最新文章
博主热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)博主最新文章
博主热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)工作记录（32）
这两天公司项目需要是用热更新来提升用户使用体验，减少由于bug造成的频繁发版，最后当然选择使用triker作为热更新了，不过我还是决定使用bugly，原因如下：
1.bugly热更新是对trinker的再次封装，集成起来相对简单
2.bugly有操控控制台，我可以很简单随意的下发补丁，并且如果补丁不合适我还可以撤回，可以根据不同的版本进行细分下发等等
基于以上两点我决定选用bugly热更新了，下面说一下这两天集成的过程中踩得坑吧：
一.参考文档记录：
1.https://bugly.qq.com/docs/user-guide/instruction-manual-android-hotfix/?v=59
2.http://m.blog.csdn.net/ou/article/details/
3.https://bugly.qq.com/docs/user-guide/faq-android-hotfix/?v=24
二.中间的差错
1.按照官方文档来集成，第四部功能清单其实是可以不用配置的，因为我们基本上都是用的最新的腾讯sdk
2.关于tinkerId，这个其实就是我们每次发版前需要改一下，然后发完版后打补丁的时候再改一次，就改这两次就好了，直到下一次再发版的时候再重复上述操作例如：
// 构建基准包跟补丁包都要修改tinkerId，主要用于区分，每次上线时改变一次
//tinkerId = "base-1.3.6"
//打补丁时用
tinkerId ="patch-1.3.6"3.就是集成官方文档的时候，最好先把分渠道打包的build注释掉，最后成功了，再打开配置分渠道打包，否则你会发现始终打补丁不成功，特别纠结。还有就是
多渠道打包基准包的名称必须要规范，否则会找不到基准包例如app-dev-release.apk，app-main-release.apk
4.打包所用的guadle在AS的右侧，展开就可以看到了
5.最重要的一个就是补丁包的位置：你必须要上传build/outputs/patch目录下的补丁包腾讯Bugly热更新集成以及问题 - 简书
腾讯Bugly热更新集成以及问题
前言热更新能力是Bugly为解决开发者紧急修复线上bug，而无需重新发版让用户无感知就能把问题修复的一项能力。Bugly目前采用的开源方案，开发者只需要集成我们提供的SDK就可以实现自动下载补丁包、合成、并应用补丁的功能，我们也提供了热更新管理后台让开发者对每个版本补丁进行管理。Tinker是什么：Tinker是微信官方的Android热补丁解决方案，它支持动态下发代码、So库以及资源，让应用能够在不需要重新安装的情况下实现更新。当然，你也可以使用Tinker来更新你的插件。为什么使用Tinker：
当前市面的热补丁方案有很多，其中比较出名的有阿里的AndFix、美团的Robust以及QZone的超级补丁方案。但它们都存在无法解决的问题，Tinker我们不仅可以用做bugfix,甚至可以替代功能的发布。Tinker已运行在微信的数亿Android设备上，那么为什么你不使用Tinker呢？
Tinker热更新的优势
接入Bugly热更新
接入了热更新就已经接入了异常上报了，所有就不需要在进行异常上报的接入了。第一步：添加插件依赖
工程根目录下“build.gradle”文件中添加：buildscript{repositories{
}dependencies{// tinkersupport插件, 其中lastest.release指拉取最新版本，也可以指定明确版本号，例如1.0.4
classpath"com.tencent.bugly:tinker-support:latest.release"}}版本对应关系:tinker-support 1.0.5 对应 tinker 1.7.8（支持部分加固app的热更新）tinker-support 1.0.4 对应 tinker 1.7.7tinker-support 1.0.3 对应 tinker 1.7.6tinker-support 1.0.2 对应 tinker 1.7.5（需配置tinker插件的classpath）第二步：集成SDK
gradle配置在app module的“build.gradle”文件中添加（示例配置）：android {
defaultConfig {
ndk {//设置支持的SO库架构abiFilters'armeabi'//, 'x86', 'armeabi-v7a', 'x86_64', 'arm64-v8a'}
}dependencies{// 多dex配置//注释掉原有bugly的仓库
必须依赖multidex才可以使用 MultiDex.install(base);compile"com.android.support:multidex:1.0.1" //其中latest.release指代最新版本号，也可以指定明确的版本号，例如1.2.0compile'com.tencent.bugly:crashreport_upgrade:latest.release''//其中latest.release指代最新版本号，也可以指定明确的版本号，例如2.2.0compile'com.tencent.bugly:nativecrashreport:latest.release}在app module的“build.gradle”文件中添加：// 依赖插件脚本applyfrom:'tinker-support.gradle'tinker-support.gradle内容如下所示（示例配置）：注：您需要在同级目录（Moudle目录下）下创建tinker-support.gradle这个文件哦。applyplugin:'com.tencent.bugly.tinker-support'defbakPath = file("${buildDir}/bakApk/")/***此处填写每次构建生成的基准包目录
根据下面的基准包生成对应的补丁包*/defbaseApkDir ="app--19"/***对于插件各参数的详细解析请参考*/tinkerSupport {//开启tinker-support插件，默认值trueenable =true//指定归档目录，默认值当前module的子目录tinkerautoBackupApkDir ="${bakPath}"//是否启用覆盖tinkerPatch配置功能，默认值false//开启后tinkerPatch配置不生效，即无需添加tinkerPatchoverrideTinkerPatchConfiguration =true//编译补丁包时，必需指定基线版本的apk，默认值为空//如果为空，则表示不是进行补丁包的编译// @{link tinkerPatch.oldApk }baseApk ="${bakPath}/${baseApkDir}/app-release.apk"//对应tinker插件applyMappingbaseApkProguardMapping ="${bakPath}/${baseApkDir}/app-release-mapping.txt"//对应tinker插件applyResourceMappingbaseApkResourceMapping ="${bakPath}/${baseApkDir}/app-release-R.txt"//构建基准包和补丁包都要指定不同的tinkerId，并且必须保证唯一性 tinkerId = "base-1.0.4"
//生成对于的基包版本
只有生成基准包的时候使用//tinkerId ="patch-1.0.4"
//对于生成的补丁包版本
只有生成补丁包的时候使用//构建多渠道补丁时使用 // buildAllFlavorsDir = "${bakPath}/${baseApkDir}"//支持加固需要添加的属性
1.7.8以后才可以使用的isProtectedApp =true//是否开启反射Application模式
这里有2中情况 enableProxyApplication =true}/***一般来说,我们无需对下面的参数做任何的修改*对于各参数的详细介绍请参考:* https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97*/tinkerPatch {oldApk ="${bakPath}/${baseApkDir}/app-release.apk"ignoreWarning =falseuseSign =truedex {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的分配}}第三步：初始化SDK
enableProxyApplication = false 的情况
这是Tinker推荐的接入方式，一定程度上会增加接入成本，但具有更好的兼容性。集成Bugly升级SDK之后，我们需要按照以下方式自定义ApplicationLike来实现Application的代码（以下是示例）：自定义Applicationpublic class SampleApplication extends TinkerApplication {/*注意：这个类集成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*/publicSampleApplication() {super(TINKER_ENABLE_ALL,"com.bugly.smile.buglydemo.SampleApplicationLike","com.tencent.tinker.loader.TinkerLoader", false);}}自定义的ApplicationLikepublic class SampleApplicationLike extends DefaultApplicationLike {public static finalStringTAG="Tinker.SampleApplicationLike";public SampleApplicationLike (Application application, inttinkerFlags,booleantinkerLoadVerifyFlag, longapplicationStartElapsedTime,longapplicationStartMillisTime,Intent tinkerResultIntent) {super(application,tinkerFlags,tinkerLoadVerifyFlag,applicationStartElapsedTime,applicationStartMillisTime,tinkerResultIntent);}@Overridepublic voidonCreate() {super.onCreate();//这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId//调试时，将第三个参数改为trueBugly.init(getApplication(),"&申请的APPID&", false);}@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)@Overridepublic voidonBaseContextAttached(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)publicvoidregisterActivityLifecycleCallback(Application.ActivityLifecycleCallbacks callbacks){getApplication().registerActivityLifecycleCallbacks(callbacks);}}注意：tinker需要你开启MultiDex,你需要在dependencies中进行配置compile "com.android.support:multidex:1.0.1"才可以使用MultiDex.install方法； SampleApplicationLike这个类是Application的代理类，以前所有在Application的实现必须要全部拷贝到这里，在onCreate方法调用SDK的初始化方法，在onBaseContextAttached中调用Beta.installTinker(this);enableProxyApplication = true 的情况
public class MyApplication extends Application {@Overridepublic voidonCreate() {super.onCreate();//设置为开发设备 注意这个必须在初始化Bugly之前设置为开发设备Bugly.setIsDevelopmentDevice(this, true);//这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId//调试时，将第三个参数改为true
打印Log的开关Bugly.init(this,"申请的appId", false);//异常展示时候，建议设置为手机号码，方便后期Bug的修复CrashReport.setUserId(this,"你需要作为UseId的参数"); }@Overrideprotected voidattachBaseContext(Context base) {super.attachBaseContext(base);// you must install multiDex whatever tinker is installed!MultiDex.install(base);//安装tinkerBeta.installTinker();}}注：无须你改造Application，主要是为了降低接入成本，我们插件会动态替换AndroidMinifest文件中的Application为我们定义好用于反射真实Application的类最后只需要在AndroidManifest文件中将Application替换上就可以使用了。第四步：AndroidManifest.xml配置
1. 权限配置&uses-permissionandroid:name="android.permission.READ_PHONE_STATE"/&&uses-permissionandroid:name="android.permission.INTERNET" /&&uses-permissionandroid:name="android.permission.ACCESS_NETWORK_STATE" /&&uses-permissionandroid:name="android.permission.ACCESS_WIFI_STATE"/&&uses-permissionandroid:name="android.permission.READ_LOGS"/&&uses-permissionandroid:name="android.permission.WRITE_EXTERNAL_STORAGE"/&&uses-permissionandroid:name="android.permission.READ_EXTERNAL_STORAGE"/&第五步：混淆配置为了避免混淆SDK，在Proguard混淆文件中增加以下配置：-dontwarn com.tencent.bugly.**-keep public class com.tencent.bugly.**{*;}如果你使用了support-v4包，你还需要配置以下混淆规则：-keep class android.support.**{*;}到这里为止 Bugly热更新就已经完成了，下面就是如何使用了，我们需要验证热更新的能力：注意tinker无法使用热更新修复的情况：由于原理与系统限制，Tinker有以下已知问题：Tinker不支持修改AndroidManifest.xml，Tinker不支持新增四大组件；由于Google Play的开发者条款限制，不建议在GP渠道动态更新代码；在Android N上，补丁对应用启动时间有轻微的影响；不支持部分三星android-21机型，加载补丁时会主动抛出"TinkerRuntimeException:checkDexInstall failed"；对于资源替换，不支持修改remoteView。例如transition动画，notification icon以及桌面图标。验证Bugly热更新 必须在联网的情况下才可以使用热更新普通打包
1、编译基准包
配置基准包的tinkerId （注意这里的base版本必须联网上报 才可以上传补丁包）设置你的基准版本号 最好是和app version对应
Bugly基线版本
执行assembleRelease编译生成基准包： 在android studio的右边选择gradle找到我们接入热更新的model 进入build中选择生成的基准包类型：这里可以是Release和Debug版本
生成基准包
这个会在build/outputs/bakApk路径下生成每次编译的基准包、混淆配置文件、资源Id文件，如下图所示：
生成的基准Apk目录
这里面有的app-release.apk就是我们需要上线的基线版本，请注意保存线上发布版本的基准apk包、mapping文件、R.txt文件，如果线上版本有bug，就可以借助我们tinker-support插件进行补丁包的生成。如果你没有开启混淆是不会有mapping.txt文件的，需要在Moudle的build.g'radle文件中开启混淆
开启基线混淆
如何生成签名文件这里就不介绍了。2、对基线版本的bug修复上面生成了base包了，那就需要去生成patch包了。基准包的代码：
base包的代码
补丁包（patch）的代码：
3、根据基线版本生成补丁包这里需要注意的：基准包目录必须是你上次生成的base包，注意这里是按照时间命名的，检查是否正确，tinkerId 需要生成patch包必须使用 tinkerId="patch-base版本号对应"
patch补丁生成配置
执行构建补丁包的task
patch补丁包的task
如果你要生成不同编译环境的补丁包，只需要执行TinkerSupport插件生成的task，比如buildTinkerPatchRelease就能生成release编译环境的补丁包。生成的补丁包在build/outputs/patch目录下，其中7zip.apk就是我们需要使用的补丁包：
补丁包目录
打开补丁包可以看到里面会有一个YAPATCH.MF，这里面包含了我们是从base版本到patch版本：以及app的version信息
4、上传补丁包到平台
进入到对应appid的app中，选择应用升级，热更新，发布新补丁。发布patch版本，选择补丁文件之后会自动从补丁包的YAPATCH.MF去寻找base版本以及app版本，注意这里的base版本必须联网上报（必须在联网的情况下启动app），才可以上传补丁成功。如果没有
上传补丁包
上传了补丁包可以选择下发的范围：开发设备：仅仅针对设置了开发设备。利用代码：Bugly.setIsDevelopmentDevice(this, true);设置为开发者设备。全量设备：针对所有的用户。自定义：可以设置下发范围:随机下发设置的版本数量，还可以设置android版本范围，仅仅在这个范围内才会下发并且生效。下发补丁之后：
下发补丁的撤回
里面包括了激活的用户数量以及下发的数量，在操作过程中我们可能对于上个补丁不太满意，我们需要发布一个新的补丁，bugly提供了2中操作。停止下发：点击之后将不会在下发bugly补丁，但是之前已经下载并且激活的不会删除掉补丁。撤回：点击之后将停止下发补丁，并且之前已经下载并且激活的用户将会删除掉补丁包，并且恢复到基准包的版本。检查patch包是否生效：基准包执行效果图：
基准包效果图
修复之后的效果图：
补丁合成效果图
不能立即生效，需要吧app至于后台一段时间才能生效。如果你的手机root的话，可以在data/data/app包名目录下有一个tinker目录，里面就有对于的patch补丁包下载在里面。
补丁包生效统计
如果用户以及补丁下载成功以及激活的都会有统计的。热更新加固：之前的tinker只有1.7.5之前支持加固，tinker 1.7.8 可以通过 isProtectedApp 开启加固支持，这种模式仅仅可以使用在加固应用中。isProtectedApp=true
测试腾讯云·乐固
Tested爱加密
Tested梆梆加固
Tested360加固暂不支持，需要等待新版本发布其他请自行测试，只要满足下面规则的都可以支持最后附上自己在github上面的。
一个默默爬行的码农。
Tinker介绍 Tinker是微信团队开源的Android热修复工具，支持dex, library和resources的热更新。关于Tinker的基本的接入方法、Api和原理等，在官方wiki中有非常详细的介绍。我这里重点描述一下基于我们项目的接入流程（客户端和后台），使...
前言 之前发过一篇文章——Bugly热更新SDK你需要知道的一些事，那是Bugly集成Tinker之后正式发布的第一个版本—1.2.0，针对我们热更新能力进行的一些说明，经过之后的版本迭代当中也是不断的跟进Tinker版本并且不断优化和简化开发者的接入，让开发者能够将热更新...
Bugly目前采用微信Tinker的开源方案已经集成异常上报功能 使用指南： 在项目根目录下的build.gradle文件中添加插件依赖： 在app目录下的build.gradle文件中添加依赖和属性配置： 在app目录下创建tinker-support.gradle文件并...
在介绍Bugly之前，需要先向大家简单介绍下一些热更新的相关内容。当前市面的热补丁方案有很多，其中比较出名的有阿里的AndFix、美团的Robust以及QZone的超级补丁方案。但它们都存在无法解决的问题，这也是Tinker面世的原因。Tinker目前已运行在微信...
用两张图告诉你，为什么你的 App 会卡顿? - Android - 掘金Cover 有什么料？ 从这篇文章中你能获得这些料： 知道setContentView()之后发生了什么？ ... Android 获取 View 宽高的常用正确方式，避免为零 - 掘金相信有很多朋友...
昨晚做了一个梦，梦见我开会的时候一气之下辞职了。 刚办完离职手续，我突然觉得后悔了，想起再找一份工作有多辛苦，我就和我领导说我想回来。 领导笑笑，走就走了吧。 突然我就醒了，还好这都是梦，还好我还没辞职。心里突然觉得悻悻。 美好的一天开始了。
粮食小贩子，鱼贩子如同文化贩子，资金贩子
UICollectionView 笔记 Collection View Basics CollectionView和tableView有几分相似却又有不同。那什么是collectionView呢。你看过苹果自带的相册吗那个就是collectionView。就是一个个cell...
世间真正的遥远不是距离，而是视若无睹。 看过一个小故事，一对儿小情侣闹别扭分手了。女孩儿在机场要离开，又有一丝不舍，飞机起飞前一小时，女孩儿给男孩儿发短信说，给你最后一次机会，一个小时之内赶到机场来见我！男孩儿收到短信就冲了出去。结局是女孩儿坐飞机离开了。 曾几何时，国内大...
人生在世，要经历好多的事情。在涉及一些事情的处理的时候真应该多想想别人，站在对方的角度思考问题，而不应该一切以自己为中心，这样就会很局限，将自己逼向墙脚，让自己活得很自我，失去了人生活水的根源，活着活着就成一座无人登陆的孤岛了。所以为人处事应该海纳百川，学会吸收，...}