Android 基础编译流程

Android 工程的构建打包是一个复杂的流程，涉及工程源代码、资源文件、AIDL 文件以及工程所依赖的库文件的编译转换。

官方提供的构建流程图：

new Thread

1
2
3
4
5

Thread(
    Runnable {
        // ignore
    }
).start()

远古时期的写法，问题也很多：

• 每次通过 new Thread 新建对象性能差
• 线程缺乏统一管理，可能无限制新建线程，相互之间竞争，及可能占用过多系统资源导致死机或oom
• 缺乏更多功能，如定时执行、定期执行、线程中断

写在最前

每到写年终的时候总是思绪万千，一到提笔，又不知道该写些啥，只能明日复明日，于是，本该在 2019年发布的年终总结还是拖到了 2020年。

前言

距离上篇《Android持续集成·前篇》已经有些时日，这次将会填上上篇留下的大坑，pipline 构建。

为什么要做单元测试

优点

• 当组内有强迫症的童鞋想重构某块代码时，单元测试就是坚实的后盾，想象如下对话：

童鞋A：项目里这块代码写的不优雅，我要重构

负责人：重构啊，好事啊，可以，只要你重构之后单元测试能全部运行通过。

童鞋A：…

当然，这段对话的前提是建立在单元测试的覆盖率足够高的基础上

• 优化设计，开发者先编写测试，然后再编写代码，让代码通过测试的方式来开发业务，这也就是 TDD 开发，强迫每个开发者写出易于调试和可测试的代码，并且很好的解耦合。
• No 文档，单元测试就是一种很好的文档，自己就展示了函数和类的使用。并且这份文档还是可以编译、运行的，与项目代码保持同步
• 可回归，与 CI 集成之后实现了真正的敏捷开发，重构完、开发完新业务，线上运行测试，而不需要将代码再部署到真机上，然后人肉点点点。

为什么要持续集成

人肉构建太累了

我们想做的事情

• clone 仓库的代码
• 静态代码检查（可选）
• 单元测试（可选）
• 编译打包 apk
• 上传到测试分发平台
• 自动化测试（可选）
• 通知相关人员构建结果等

救救孩子吧！！！

为什么需要组件化

组件化之前的项目结构

• App 工程
  • 多个业务组件
  • 一个静态的路由，依赖了所有的业务组件，业务组件可以通过 Router 暴露出来的方法跳转到其他业务组件
• CommonLibrary
  • 多个技术组件