android加固！整理出Android逆向系列学习进阶视频，附超全教程文档

前言

作为一个程序员，性能优化是无法避开的事情，并且性能优化也是软件系统中最有挑战的工作之一，更是每个工程师都需要掌握的核心技能。

性能问题和Bug不同，后者的分析和解决思路更清晰，很多时候从应用日志即可直接找到问题根源，而性能问题，其排查思路更为复杂一些。

对App进行性能优化，是一个系统性的工程，对工程师的技术广度和技术深度都有所要求。 一个简单的应用，它不仅包含了应用代码本身，还和虚拟机、存储、网络等紧密相关，线上应用一旦出现了性能问题，需要我们从多方面去考虑。

但在实际的工作中，很多情况下只能看到症状，却完全不知道该从哪下手去排查和解决它。

与此同时，除了一些低级的代码逻辑引发的性能问题外，很多性能问题隐藏的较深，即便能够排查，排查起来也会比较困难，需要我们对应用的各个子模块、应用所使用的框架和组件的原理有所了解，同时掌握一定的性能优化工具和经验。

背景介绍

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 仓库配置的顺序依次查找的，如果某个组件存在于最后一个仓库中，那前面的十几个仓库得依次发起网络请求查找