有没有受 Android 工程编译慢困扰的老安卓，推荐个我自己做的方案
背景是这样的，21 年的时候我突然灵光一闪，想着“如果我编译的文件足够少，应该要编译的足够快”，然后在 3 个月肝了一个 MVP 出来（还拿去答辩通过了）。这是当时录的 [视频](https://www.bilibili.com/video/BV1W3411C7PU)。
方案核心是用了三个黑魔法：
1. 源码编译只用 javac/kotlinc 编单个文件；
2. 资源编译用 aapt2，但被我改成了支持增量 link 的定制版本；
3. 部署会优先走 Android Studio 的 Apply Changes，可以热重载；这一套下来耗时可以压在 3 秒内。
不过当时基本只是个玩具，动不动就失败崩溃。而且当时公司比较流行把工程放到云服务器编译，只拉 apk 下来，导致我这个需要本地 build 产物的方案不太好落地。后面就是 2 年断断续续的沉沦和奋起，反正没有占上班资源，都是自己下班时间搞，所以也没 KPI。
直到 23 年我突然想到（有点晚）可以用 rsync 把文件也拉到本地，所以又奋起了一波，在 23 年终于做了个 v1 版本，给组内同学开始试用起来。后面老板也给力帮忙推了一波，人开始渐渐多了起来，继续疯狂迭代了 2 年（一年 1000+ 个 commit），迭代到现在已经挺稳定了。
简述插件优势就是：
1. 平均 3s 编译耗时（需要先 gradle 编译一次生成产物，改源码增量，改 gradle 文件重新降级）；
2. 直接装 IDE 插件就能用，不用改工程；
3. 磨了 5 年，公司内部推广了 2 年半，接了十来个生产工程，编译了 80W 次（插件有个编译次数的上报），已经比较稳定了。
今年想走公司仓库开源，估计就是这两个月的事情。目前还没开源，但插件可以直接下载用。我在外网放了一份，看看有没有感兴趣的老哥试用一下，提前给点反馈。[接入文档](https://doc.weixin.qq.com/doc/w3_AAwApQZgACk9Ri1huyZSbCggqpIkE?scode=AJEAIQdfAAoJ57TDSiAAwApQZgACk)
---
原文链接：[点击查看](https://www.v2ex.com/t/1229264)
方案核心是用了三个黑魔法：
1. 源码编译只用 javac/kotlinc 编单个文件；
2. 资源编译用 aapt2，但被我改成了支持增量 link 的定制版本；
3. 部署会优先走 Android Studio 的 Apply Changes，可以热重载；这一套下来耗时可以压在 3 秒内。
不过当时基本只是个玩具，动不动就失败崩溃。而且当时公司比较流行把工程放到云服务器编译，只拉 apk 下来，导致我这个需要本地 build 产物的方案不太好落地。后面就是 2 年断断续续的沉沦和奋起，反正没有占上班资源，都是自己下班时间搞，所以也没 KPI。
直到 23 年我突然想到（有点晚）可以用 rsync 把文件也拉到本地，所以又奋起了一波，在 23 年终于做了个 v1 版本，给组内同学开始试用起来。后面老板也给力帮忙推了一波，人开始渐渐多了起来，继续疯狂迭代了 2 年（一年 1000+ 个 commit），迭代到现在已经挺稳定了。
简述插件优势就是：
1. 平均 3s 编译耗时（需要先 gradle 编译一次生成产物，改源码增量，改 gradle 文件重新降级）；
2. 直接装 IDE 插件就能用，不用改工程；
3. 磨了 5 年，公司内部推广了 2 年半，接了十来个生产工程，编译了 80W 次（插件有个编译次数的上报），已经比较稳定了。
今年想走公司仓库开源，估计就是这两个月的事情。目前还没开源，但插件可以直接下载用。我在外网放了一份，看看有没有感兴趣的老哥试用一下，提前给点反馈。[接入文档](https://doc.weixin.qq.com/doc/w3_AAwApQZgACk9Ri1huyZSbCggqpIkE?scode=AJEAIQdfAAoJ57TDSiAAwApQZgACk)
---
原文链接：[点击查看](https://www.v2ex.com/t/1229264)
· 0 个赞