android游戏开发入门！330页PDF，10万字的知识点总结，年薪50W

不好意思久等了

这篇文章让小伙伴们久等了。

一年多以来，关于嵌入式开发学习路线、规划、看什么书等问题，被问得没有一百，也有大几十次了。但是无奈自己对这方面了解有限，所以每次都没法交代，搞得实在不好意思。

但是办法总归是有的，正如前篇文章所聊，虽然我自己不从事这些方向，但寻思了一下，我的同学和朋友中，多少还是有一些从事相关方向并且在一线（或曾在一线）工作过的，所以我就请他们帮忙一起梳理这几个我不熟悉领域的学习路线，这次嵌入式开发就是其中之一。

这篇文章之所以拖这么久，因为沟通实在太费时间了，毕竟大佬们都挺忙，况且梳理总结这件事情本身就比较繁琐，所以等到现在才发出来。

背景介绍

Android 项目一般使用 gradle 作为构建打包工具，而其执行速度慢也一直为人所诟病，对于今日头条 Android 项目这种千万行级别的大型工程来说，全量编译一次的时间可能高达六七分钟，在某些需要快速验证功能的场景，改动一行代码的增量编译甚至也需要等两三分钟，这般龟速严重影响了开发体验与效率，因此针对 gradle 编译构建耗时进行优化显得尤为重要。

在今日头条 Android 项目上，编译构建速度的优化和恶化一直在交替执行，18 年时由于模块化拆分等影响，clean build 一次的耗时达到了顶峰 7 分 30s 左右，相关同学通过模块 aar 化，maven 代理加速，以及增量 java 编译等优化手段，将 clean build 耗时优化到 4 分钟，增量编译优化到 20~30s 。但是后面随着 kotlin 的大规模使用，自定义 transform 以及 apt 库泛滥，又将增量编译速度拖慢到 2 分 30s ，且有进一步恶化的趋势。为了优化现有不合理的编译耗时，防止进一步的恶化，最近的 5，6 双月又针对编译耗时做了一些列专项优化(kapt,transform,dexBuilder,build-cache 等) 并添加了相关的防恶化管控方案。 从 4.27 截止到 6.29 ，整体的优化效果如下:

历史优化方案

由于 18 年左右客户端基础技术相关同学已经对今日头条 Android 工程做了许多 gradle 相关的优化，且这些优化是近期优化的基础，因此先挑选几个具有代表性的方案进行介绍，作为下文的背景同步。

maven 代理优化 sync 时间

背景

gradle 工程往往会在 repositories 中添加一些列的 maven 仓库地址，作为组件依赖获取的查找路径，早期在今日头条的项目中配置了十几个 maven 的地址，但是依赖获取是按照 maven 仓库配置的顺序依次查找的，如果某个组件存在于最后一个仓库中，那前面的十几个仓库得依次发起网络请求查找，并在网络请求返回失败后才查找下一个ÿ