Android如何打造高质量的应用？( 一)

如何打造高质量的应用？

应用至少会经过开发、编译 CI(自动编译,提交到gitlab之后,合并之前)、测试、灰度和发布这几个阶段。

1. 开发阶段。耗时分析工具 Traceview 来说，它背后的实现原理是什么？能不能做一个完全没有性能损耗的 Traceview？或者怎么样将它移植到线上使用？
   Traceview:

2. 编译 CI 阶段。如何防止代码不断地恶化？怎样进一步优化性能？d8 与 ReDex 有什么神奇的黑科技？如何利用好 Coverity、Infer 这些静态分析工具？这部分可能需要一些编译原理的知识，
   你可以把编译简单理解为，将高级语言转化为机器或者虚拟机所能识别的低级语言的过程。对于 Android 来说，这个过程就是把 Java 或者 Kotlin 转变为 Android 虚拟机能够运行的Dalvik 字节码的过程。
   编译实在太重要了，每个公司的情况又各不相同，必须强行造一套自己的“轮子”。已经开源的项目有 Facebook 的Buck以及 Google 的Bazel。
   Gradle、Buck、Bazel 都是以更快的编译速度、更强大的代码优化为目标

   
   
   20191114174629372.png

编译时间和安装时间两个纬度来看Android的编译速度。

编译时间。把 Java 或者 Kotlin 代码编译为“.class“文件，然后通过 dx 编译为 Dex
文件。对于增量编译，我们希望编译尽可能少的代码和资源，最理想情况是只编译变化的部分。但是由于代码之间的依赖，大部分情况这并不可行。这个时候我们只能退而求其次，希望编译更少的模块。Android
Plugin 3.0及以后的版本使用 Implementation 代替 Compile，正是为了优化依赖关系；
安装时间。我们要先经过签名校验，校验成功后会有一大堆的文件拷贝工作，例如 APK 文件、Library 文件、Dex
文件等。之后我们还需要编译 Odex 文件，这个过程特别是在 Android 5.0 和 6.0
会非常耗时。对于增量编译，最好的优化是直接应用新的代码，无需重新安装新的 APK。

对于增量编译，我先来讲讲 Gradle 的官方方案Instant Run。在 Android Plugin 2.3 之前，它使用的 Multidex 实现。在 Android Plugin 2.3 之后，它使用 Android 5.0 新增的 Split APK 机制。资源和 Manifest 都放在 Base APK 中， 在 Base APK 中代码只有 Instant Run 框架，应用的本身的代码都在 Split APK 中。Google 的人也发现了 Instant Run 的种种问题，在 Android Studio 3.5 之后，对于 Android 8.0 以后的设备将会使用新的方案“Apply Changes”代替 Instant Run
对于编译速度的优化，我还有几个建议：
1.更换编译机器。对于实力雄厚的公司，直接更换 Mac 或者其他更给力的设备作为编译机，这种方式是最简单的；
2.Build Cache。可以将大部分不常改变的项目拆离出去，并使用远端 Cache模式保留编译后的缓存；
3.升级 Gradle 和 SDK Build Tools。我们应该及时去升级最新的编译工具链，享受 Google 的最新优化成果；
4.使用 Buck。无论是 Buck 的 exopackage，还是代码的增量编译，Buck
都更加高效。但我前面也说过，一个大型项目如果要切换到 Buck，其实顾虑还是比较多的。在 2014 年初微信就接入了
Buck，但是因为跟其他项目协作的问题，导致在 2015 年切换回 Gradle 方案。
相比之下，可能目前最热的 Flutter 中Hot Reload秒级编译功能会更有吸引力。
当然最近几个 Android Studio 版本，Google 也做了大量的其他优化，例如使用AAPT2替代了 AAPT 来编译 Android 资源。AAPT2 实现了资源的增量编译，它将资源的编译拆分成 Compile 和 Link 两个步骤。前者资源文件以二进制形式编译 Flat 格式，后者合并所有的文件再打包。

ProGuard、d8、R8 和 ReDex 这四种我们可能会用到的代码优化工具
ProGuard:在微信 Release 包 12 分钟的编译过程里，单独 ProGuard 就需要花费 8 分钟。尽管 ProGuard 真的很慢，但是基本每个项目都会使用到它。ProGuard 主要有混淆、裁剪、优化这三大功能.其中优化包括内联、修饰符、合并类和方法等 30 多种

D8:Android Studio 3.0 推出了d8，并在 3.1 正式成为默认工具。它的作用是将“.class”文件编译为 Dex 文件，取代之前的 dx 工具,d8 除了更快的编译速度之外，还有一个优化是减少生成的 Dex 大小。根据 Google 的测试结果，大约会有 3%～5% 的优化

R8:R8 在 Android Studio 3.1 中引入，它的志向更加高远，它的目标是取代 ProGuard 和 d8。我们可以直接使用 R8 把“.class”文件变成 Dex。

ReDex 是 Facebook 开源的工具，通过对字节码进行优化，以减小 Android Apk 大小，同时提高 App 启动速度。
GitHub：ReDex github，官网主页：fbredex.com

3. 测试阶段。我们希望可以做到测试“左移”，尽可能早地发现问题。但是很多时候我们不是不想测试，而是发现测不出什么问题。那么怎样提升实验室发现问题的能力呢？如何尽可能地模拟用户的操作路径？做好测试并不容易，自动化测试结合 AI 或许可以帮助我们解决一些痛点。

4. 灰度和发布阶段。

   
   
   1639121385807.jpg