下载网站的服务器文件,历史建筑信息平台,在linux上做网站搭建,南京seo推广公司本文来自于腾讯bugly开发者社区#xff0c;非经作者同意#xff0c;请勿转载#xff0c;原文地址#xff1a;http://dev.qq.com/topic/57a31921ac3a1fb613dd40f3 Android 不仅系统版本众多#xff0c;机型众多#xff0c;而且各个市场都各有各的政策和审核速度#xff0… 本文来自于腾讯bugly开发者社区非经作者同意请勿转载原文地址http://dev.qq.com/topic/57a31921ac3a1fb613dd40f3 Android 不仅系统版本众多机型众多而且各个市场都各有各的政策和审核速度每次发布一个版本对于开发同学来讲都是一种漫长的煎熬。相比于 iOS 两三天就能达到 80% 的覆盖速度而言Android 应用版本升级至少需要两周才能达到 80% 的升级率严重阻碍了版本迭代速度。也导致市场上 App 版本分散处理 bug 和投诉等也越来越麻烦。 修复的 bug 需要等待下个版本发布窗口才能发布已经 ready 的需求排队上线需要等待其他 Feature Team 合入代码老版本升级速度慢频繁上线版本提醒用户升级影响用户体验这几个问题是每个 App 开发同学都必然要面对的。那么有没有方法能在用户无感知的情况下加速 bug 处理和版本迭代速度 在这方面 PC 端 Chrome 浏览器的 patch 升级方案给我们了一个很好的借鉴当 Chrome 有版本升级的时候会自动下载 patch 文件。下次启动后Chrome 就已经是新版本。 他山之石可以攻玉 近一两年 Android 热补丁框架非常热门。从最初 360 动态下发 lua 脚本到后来出现的各种方案如雨后春笋般出现。早期的补丁框架偏向于以代码修复为主主要分为两大类native hook 方案和 Multidex 方案。 native hook 方案如阿里巴巴的 AndFix 和 Dexposed。Multidex 方案如 Qzone。切入点都是替换掉将要执行的代码。基于 Qzone 方案的思路出现了 nuwa 这个比较完善的库工具链比较完善。 类似 Chrome 的 patch 升级方案足以满足加速 bug 处理和版本迭代速度的需求给了我们很大的借鉴意义。在安卓系统上可以通过 hotfix 的思路来达到这一目的下发补丁文件更新 App 版本。 站在巨人的肩膀上 在今年 3 月份开始做技术选型的时候把上面的几种方案试了一轮。其中 AndFix 甚至跟上了现网的一个发布版本但是由于影响正向开发过程只能修改方法、不能修改 field、不能新增类等问题、库本身难于维护需要依赖外部开源力量进行维护以及发现的莫名其妙的 bug导致我们 App 下发 patch 后白屏所以即使跟上了发布版本也没有使用。nuwa 仅支持更新 Java 代码不能更新资源和 so 文件满足不了我们的需求。 没有好用的轮子我们决定自己造一个于是有了现在的 patch 方案。 App 只是一个加载器 既然做安卓 patch 方案最好的结果就是能支持更新 App 所有的代码和资源。但是 Application 类是 App 启动之初就被安卓系统加载起来所以至少 Application 类和它启动依赖的其他业务类是不能被更新的修复 bug 或者版本迭代过程中难免会遇到需要修改资源文件的情况。资源文件能更新吗native 实现的 so 文件如何更新针对上面三个问题 我们的设计是把 App 仅仅当做一个加载器。系统启动 App 之后加载器决定将要运行的代码和资源的位置。当有新功能或者 bugfix 需要推送给用户替换加载器内容即可。 支持更新全部代码 上面提到 Application 由于启动就被加载而不能被更新的问题我们代理了真实 Application 类的创建过程。通过代理 Application控制 Application 从新 dex 文件中加载。假设真实的 Application 类是 MyApplication。我们在编译期间自动修改 AndroidManifest.xml 文件把 MyApplication 替换为 MoaiApplication是 App 的入口 Application。App 启动后由 MoaiApplication 加载完相应的文件dex/资源文件/so 文件后再将控制权交回给 MyApplication。 代理生命周期 将控制权交回给 MyApplication我们最初是代理 MyApplication 的生命周期。具体做法是MoaiApplication 决定加载哪里的业务代码、资源文件以及 so 文件之后依然负责接收 App 的全部生命周期然后把生命周期代理给 MyApplication简单例子如下 还有比较多生命周期函数上面代码就没一一列举。 从上面代码容易想到代理方案的缺点必须要完整代理所有生命周期接口。否则 MyApplication 会由于生命周期不完整而出现奇怪的 bug。比如我们最初版本在测试过程中就出现了没有代理 registerActivityLifecycleCallbacks 函数而导致拿不到 Activity 生命周期 onActivityCreated/onActivityDestroyed 等回调。 反射 Application 踩到生命周期回调不完整的坑之后我们开始考虑能不能把 App 运行期间 Application 的引用全部替换成 MyApplication 这样就无需 MoaiApplication 把生命周期代理给 MyApplication而是由 MyApplication 直接接收系统回调。安卓系统 ContextWrapper 的实现是包装了一层真正的 mBase 上下文App 真正使用到的就是这个 mBase。通过反射 mBase 以及其中字段对 Application 的引用『彻底』解决了需要手写代理 Application 全部生命周期的方法。 dex分包 Qzone 方案下发的 patch 文件是变更过的 Java 类组成的 patch.dex在 dalvik 和 ART 虚拟机下分别需要解决 Class ref in pre-verified class resolved to unexpected implementation 和内存地址错乱问题。这些问题根源在于改变了类原本所属的 dex 文件。既然改变类所在的 dex 会导致各种各样的问题那直接替换掉整个 dex 不就好了在调研 JRebal for Android 和 Instant Run 的时候也发现了他们有类似的做法。 我们把 App 的 dex 分成两部分 patch 库的 dex 文件 - classes.dex其他业务代码的 dex 文件 - classes[N].dex其中 classes.dex 中仅包含了 patch 库的全部代码并不包含任何其他业务代码。 假设 apk 中包含三个文件classes.dex、classes2.dex、classes3.dex。classes.dex 充当的角色就是加载器负责启动 App 并且加载后面的两个 dex。这样做的目的是App 启动需要用到的所有类都集中在 classes.dex 中所有业务代码的类都集中在 classes[N].dex 中。如果某次下发 patch 代码把 classes2.dex 变更为 classes2-1.dex那么由加载器加载 classes2-1.dex 和 classes3.dex 即可实现更新包含 MyApplication 类在内的所有代码。 怎么加载更新后的代码 如果 dex 文件有更新加载器会选择加载更新后的文件。我们最初采用了 Google 官方的 Multidex 方案扩展 DexPathList 的 dexElements 字段。 Multidex 方案存在问题 Multidex 方案上线后发现某些机型比如三星s6 5.0.2 ROM并不能加载扩展进去的 dex 中的代码。debug 阶段却能顺利加载debugger 拖慢代码执行速度。目前的猜测是某些厂商在 5.x 以上版本改动 ROM 导致 App 启动逻辑有多线程并发执行。 最终我们弃用了 Multidex 方案转而 Hack 系统 ClassLoader。 ClassLoader Hack 方案 所有线程使用的是同一个 ClassLoader 对象。所以一旦 Hack 了这个对象所有线程都开始使用 Hack 过的对象从而能够解决多线程导致加载不到扩展的 dex 文件中代码的问题。 安卓系统加载代码的 ClassLoader 是 PathClassLoader 和 BootClassLoader。我们最初设计的方案是在 PathClassLoader 和 BootClassLoader 之间插入一个 BaseDexClassLoader让所有业务代码都在这个插入的 BaseDexClassLoader 中加载。但是这样的设计存在缺陷业务代码的 ClassLoader 会变成 BaseDexClassLoader如果业务代码依赖了 patch 库的代码在 classes.dex 中会出现 ClassNotFoundException。 在这方面 Instant Run 的设计很精巧。它让 PathClassLoader 插入的父 loader IncrementalClassLoader包装了 DelegateClassLoader并且把 DelegateClassLoader 的父 loader 设置为 PathClassLoader使得类加载的路径变成 在 DelegateClassLoader 加载业务代码的时候业务代码在 classesN.dex 中流程会沿着标记的顺序最终第 5 步成功加载到业务代码。业务代码如果依赖 patch 库的代码会在 PathClassLoader 加载。这样所有代码都可以被加载到。 怎么更新资源 单纯更新 Java 代码的 patch 框架实用性会受到很大的局限。开发同学需要仔细验证提交内容确保提交中不包含资源文件的变更以及 native so 的改动会导致本就复杂的开发流程变得更加繁琐。所以我们在支持更新 Java 代码的基础之上也支持更新资源和 native so 文件。 App 加载资源是依赖 Context#getResources 函数返回的 Resources 对象。Resources 内部包装了 AssetManager最终由 AssetManager 从 apk 文件中加载资源。所以我们反射了替换系统默认的 Resources让 AssetManager 从我们更新后的 apk 中加载资源。现阶段的实现支持比如 string/anim/drawable/color/layout 等资源文件的变更。由于 Android 系统在安装 apk 时候已经把 AndroidManifest.xml 文件解析并写入到系统中目前还不支持修改四大组件比如增加 Activity。后续会继续研究如何做到无缝修改四大组件。 怎么更新 so 文件 在 Android 项目中使用 native 函数前需要先调用 System.loadLibrary(libName)。 当 lib 文件需要更新或者有 bug 时候怎么办首先想到的是在代码中把加载 so 文件的代码改成System.load(libFilePath)让系统加载自己指定的 libFilePath 文件。然而这样的改动需要 在源代码中修改或者使用工具在编译期把 loadLibrary 接口改为 loadpatch 库把 so 文件从 patch 文件中复制到特定目录这样在运行期才有可能加载更新后的 so 文件。 通过分析系统加载 so 文件的方式后我们使用了更简单的处理方法。查找 lib 文件是通过调用 PathClassLoader 的 findLibrary最终调用到 DexPathList 的 findLibrary。DexPathList 会在自己维护的列表目录中查找对应的 lib 文件是否存在。所以我们在发现 patch 文件中有 so 文件变更的时候会在 PathClassLoader 的 nativeLibraryDirectoriesAndroid6.0以下或者nativeLibraryPathElements Android 6.0及以上的最前面插入自定义的lib文件目录。这样 ClassLoader 在 findLibrary 的时候会先在自定义的 lib 目录中查找优先加载变更过的 so 文件。 patch 包的生成与应用 回到我们最初的目标patch 不应该影响正向开发流程。我们生成 patch 文件是针对 apk 进行的开发同学无需关心此次发布是 patch 版本还是正常版本只需要正常开发并且打包要发布的 apk 即可不会对正向开发流程产生任何影响。 我们提供 python 脚本生成两个 apk 的对比两个 apk 中的所有文件找出有变更的文件进行 diff把 diff 结果写入 patch 文件。线上用户下载 patch 文件到本地之后启动一条新的进程使用 context.getApplicationInfo().sourceDir 路径的 apk 与 patch 文件合并得到新的 apk包含资源文件不包含 dex 文件以及 dex 文件、native so 文件并在这条进程中提前做 dex 优化dex2oat/dexopt。针对 dex 优化过程太慢的问题优化过程慢会导致进程可能会系统kill降低 patch 成功率我们并发了 dex 优化过程使 patch 过程耗时相对减小。新 apk、dex文件、so 文件就可以在下次启动 App 的时候由加载器加载。 优势和不足 正所谓没有完美的架构只有适合自己的架构。当前的开源方案并不能满足我们加速 bug处理和版本迭代速度的需求于是有了站在巨人肩膀上的思考和我们现在的 patch 方案。我们目前的优势 全面支持 patch Java 代码、资源文件 和 native so 文件。版本只需要正常滚动开发同学无需关心是发布 patch 版本还是正常版本使用相对简单减少接入成本也是我们的最初思考点之一只需要在 build.gradle 中加入三行代码即可无需更多配置。从我们团队发布的多个 patch 版本来看下发的 diff 结果文件稍大。大文件下载过程可能出现的错误也会间接影响到 patch 铺开的速度所以我们也在尝试更好的 diff 方案。Chrome 最初升级方案也是 bsdiff而后慢慢演变出 Courgette 算法。 演进与思考 我们对于补丁框架的定义不仅仅是『修复bug』就足够除此之外如何快速接入如何做到不影响现有流程这对于很多应用来说至关重要。在此之上搞清楚框架的定位适当舍弃一些不重要方面的时候快速迭代在迭代中持续优化事情往往比想象的更加简单。 持续交付一直都是快速迭代思想的一种践行方式对于 App 开发而言如果我们通过构造补丁框架这样一个渠道可以通过自动化系统把补丁快速地把新功能推送给用户那这个事情的意义就不仅仅是『修复 bug』这么简单。减少线上 crash 率和加速版本迭代、让新功能尽早与用户见面从而可以在更短的时间内不断收集用户反馈信息对产品进行打磨。 目前我们已经在微信读书线上三个版本开始试行了用补丁代替版本发布或者加速老版本升级的做法期待将来能通过这个渠道为安卓开发同学们做到无感知的持续交付过程 。 更多精彩内容欢迎关注bugly的微信公众账号 腾讯 Bugly是一款专为移动开发者打造的质量监控工具帮助开发者快速便捷的定位线上应用崩溃的情况以及解决方案。智能合并功能帮助开发同学把每天上报的数千条 Crash 根据根因合并分类每日日报会列出影响用户数最多的崩溃精准定位功能帮助开发同学定位到出问题的代码行实时上报可以在发布后快速的了解应用的质量情况适配最新的 iOS, Android 官方操作系统鹅厂的工程师都在使用快来加入我们吧 转载于:https://www.cnblogs.com/bugly/p/5740807.html
