Android中高级开发进阶指南：系统原理、性能优化与工程实践

我大概从Android 2.3时代就开始写App，一路走到现在，亲眼看着这个生态从“会写布局就能找到工作”变成“不懂系统原理都不好意思说自己资深”。如果你正在往中高级Android开发工程师这个方向走，你会发现单纯会写几个页面、调一调接口已经不够用了。中高级工程师真正拼的是对系统的理解、对架构的取舍、对性能问题的敏感度，以及一套能快速定位问题的方法论。

这篇指南不是零基础教程，而是给那些已经有1～3年工作经验、项目做过不少、但总觉得遇到瓶颈的开发者的一个整体路线图。我会从能力模型、核心框架、构建工具链、性能优化、底层调试、常见大坑这几个方面展开，把我这些年踩过的坑、验证过有效的做法一次讲清楚。内容会比较长，建议收藏后按章节慢慢看。

1. 中高级Android工程师的能力模型与成长路径

1.1 从“会写”到“会设计”的分水岭

很多人在初级岗位干得不错，能快速接需求、写界面、配合后端调接口，但一旦进入中高级阶段，考核标准就变了。你不再只是“把功能实现出来”的人，而是需要回答“为什么这么做”“有没有更好的方案”“线上出了问题如何快速止血”的人。

这个转变最典型的分水岭在于：初级开发看到的是一个个Activity和Fragment，中高级开发看到的是整个App的生命周期、任务栈、进程模型、内存分配和启动链路。举个例子，同样是处理一个“首页启动慢”的问题，初级开发可能直接网上搜“启动优化”，然后加一个延迟初始化；中级开发会先测量冷启动耗时，确认是主线程耗时还是资源加载耗时，再决定用懒加载、异步Inflate还是预加载；高级开发则会进一步思考，这套优化方案是否对低端机友好，是否会影响后续功能迭代，是否引入了新的兼容性问题。

这个思维转变听起来抽象，但它直接决定了晋升速度。中高级工程师的日常，就是在需求、性能、稳定性、可维护性、团队协作之间反复做权衡。

1.2 高级工程师需要具备的四个核心能力

如果说初中级阶段的核心是“掌握API”，那中高级阶段的核心就是“掌握原理 + 工程经验 + 系统思维”。我总结了四个高频能力维度，大家可以对照自己：

• 架构设计能力：不是会写MVVM就叫懂架构，而是能根据业务规模和团队情况，选对分层方案、模块化粒度、以及状态管理方式。既要避免一上来就“全家桶”过度设计，也要避免项目都膨胀到几百个类了还继续堆Activity。
• 性能调优能力：知道卡顿、掉帧、内存抖动、启动耗时这些问题的排查路径，能利用工具找到瓶颈，并且理解每个优化方案背后的代价。
• 稳定性治理能力：能处理崩溃、ANR、OOM、线上用户反馈，能从日志和火焰图中还原现场，并把问题沉淀为自动化监控与防护机制。
• 底层原理理解能力：能说清楚AMS、Binder、Handler、资源加载、类加载这些机制的基本原理。不是为了面试，而是因为真遇到疑难问题时，不靠猜，靠对系统的理解去定位。

1.3 一条比较清晰的进阶路线

我这些年带过不少新人，也面过很多候选人，总结出一条相对有效的进阶路径：先把自己的知识体系按“纵向深度”和“横向广度”两个方向补全。

纵向深度，就是在某一个领域做透，比如专门钻研性能优化、跨端架构、或者系统框架定制；横向广度，则是对Android工具链、开发流程、自动化测试、逆向分析、硬件交互都要有基本认知。两条线同时走，比单追一个方向要稳。

具体到行动上，可以分三步：

• 第一步，把日常用的Android Studio、Gradle、AGP、R8这些工具弄明白，不要只是点按钮编译，而是清楚每一步做了什么。
• 第二步，把应用层到框架层的链路打通，比如点击一个按钮到最终回调onClick，中间经历了什么，IPC是怎么走的，View的绘制为什么是在Choreographer的Vsync信号之后。
• 第三步，跳出应用层，去接触一些系统级开发、底层调试和逆向分析的内容，比如APEX、OpenOCD、反编译等，这会极大提升你排查疑难问题的能力。

2. 核心框架与底层原理：从应用层走到系统层

2.1 AMS与四大组件的运行机制

ActivityManagerService，也就是AMS，是Android系统里最核心的系统服务之一。很多候选人一听到AMS就头疼，觉得它是面试题，但真到线上问题排查时，你如果不懂AMS，很多诡异现象根本无从下手。

简单来说，AMS负责所有组件的调度、任务栈的管理、进程优先级调整。你每次startActivity，并不是真的让那个Activity“弹出来”，而是通过Binder IPC通知AMS，AMS再根据当前进程状态决定是创建新进程、复用已有进程，还是直接拒掉这次启动。理解这个链路后，你就可以解释很多现象：为什么后台进程经常被杀，为什么有些App第一次启动特别慢，为什么系统低内存时会优先杀某些进程。

我的建议是，不要死背启动流程的十来个步骤，而是试着画一条启动链：Launcher点击图标 -> startActivity -> Instrumentation.execStartActivity -> ActivityManagerNative（现在叫ActivityTaskManager） -> AMS.startActivity -> 进程创建 -> ActivityThread.main -> Application.onCreate -> Activity生命周期。画完这条链，再去分析冷启动耗时、进程被杀恢复这类问题就会通透很多。

2.2 AIDL与跨进程通信：不只为了面试

AIDL（Android Interface Definition Language）是很多中高级岗位面试必问的一个点，但它绝不是为了让你背模板。它的本质是帮你生成Binder通信的Java代码，屏蔽了Parcel、transact这些底层细节。在实际项目里，App之间通过ContentProvider传数据、或者和服务进程进行双向通信，都会用到类似的机制。

我见过很多人写AIDL只会在Service的onBind里返回一个Binder对象，然后调用几个接口，但过了一段时间就莫名其妙出现连接断开、接口回调不执行的问题。这背后往往是忽略了Binder线程模型：Binder调用是同步阻塞的，而且Binder线程池是有限的。如果你在主线程去调用一个耗时很长的AIDL方法，就会卡UI；如果你在Binder回调里又去拉起其他Binder调用，就可能造成线程饥饿。

实操建议：一个App里真正跨进程通信的场景并不多，能用单例和进程内消息总线解决的，不要轻易上AIDL；迫不得已要跨进程时，最好在AIDL接口定义中保持短平快，避免循环调用，并且给Service配置独立的进程名，保证主进程和辅助进程互不拖累。

2.3 APEX与系统组件升级机制

APEX是Android 10之后引入的一种新型系统组件包格式，类似APK，但它可以升级系统层的原生库和框架模块，而不需要重新刷机。你可以把它理解成“系统组件包的热更新方案”，对于做ROM定制或者企业级设备方案的人来说，这是一个绕不开的东西。

很多应用层开发可能接触不到APEX，但理解它有个好处：能帮你理解Android系统为什么能越来越频繁地通过Project Mainline更新核心模块，比如媒体、网络、权限等。当你以后做系统级开发时，至少知道为什么要在源码里新增一个apex模块，以及它的构建、签名、安装机制是怎样的。

在实际开发中，如果要对某个系统组件做模块化升级，通常要在源码中写对应的Android.bp文件，配置好apex_name、key、内容依赖，然后编译生成.apex文件，再通过adb install或者fastboot刷入。这个过程中最坑的是签名一致性：如果APEX的公钥和系统里已有的模块不匹配，会直接安装失败，而且日志往往特别隐蔽。

3. 构建工具链与工程化实践

3.1 Android Studio版本与AGP版本适配

热词里有个很具体的问题：“Android Studio Hedgehog | 2023.1.1 Patch 2支持AGP 8吗？”答案其实要分版本看。Hedgehog是2023年底到2024年初的版本，它默认带的AGP版本是8.2.x，所以支持AGP 8系列是没问题的。但如果你想把项目从老版本AGP升级到8.x，需要注意几个硬性变化：Gradle最低版本要求、JDK版本要求、以及一些旧API的移除。

我遇到过最典型的一个错误是：“Could not load compiled classes for settings file 'd:\android\coffee\settings.gradle'”。这个问题通常发生在升级Android Studio后，旧项目的Gradle缓存和新版本AS的配置不一致导致的。解决方案很简单：先clean一下项目，删除项目根目录下的.gradle和.idea文件夹，然后让AS重新同步。如果还不行，检查一下JDK版本是否和AGP要求匹配，尤其是在Windows环境下，JDK路径带空格也可能引发类似问题。

我自己的建议是：不要盲目追求最新版Android Studio和AGP，稳定压倒一切。维护团队项目时，先看现有Gradle版本是否在AGP支持矩阵里，再决定是否升级。升级时要逐个module编译排查，别一次性跨太多版本。

3.2 R8与代码压缩：keep规则里藏着大坑

R8是AGP 3.4之后默认开启的代码压缩和混淆工具，它把原来ProGuard做的shrink、optimize、obfuscate、desugar这些工作合并到了一起，编译速度更快，产物更小。但我发现很多开发者对R8的认知停留在“开了会混淆，报错就加keep规则”，几乎不去关注R8对反射、泛型、序列化、注解处理的影响。

这里有个经验：一旦开启R8，最先出问题的往往是两处，一处是反射调用，另一处是Java序列化和Gson等库的序列化操作。R8在优化时会把类名、方法名重命名，如果反射代码依赖字符串名称，就会在运行时抛出ClassNotFoundException或NoSuchMethodException。解决方案不是把整个类全部keep，而是尽量精确地keep你的反射入口、注解字段、还有被 Fragment 或 ViewBinding 引用的内部类。

下面是一个比较稳的R8配置片段，可以参考：

# 保持自定义View名称，兼容布局文件反射 -keep public class * extends android.view.View { <init>(android.content.Context); <init>(android.content.Context, android.util.AttributeSet); <init>(android.content.Context, android.util.AttributeSet, int); } # 保持实现Parcelable的类 -keepclassmembers class * implements android.os.Parcelable { public static final ** CREATOR; } # 保持Java序列化类 -keepclassmembers class * implements java.io.Serializable { static final long serialVersionUID; private static final java.io.ObjectStreamField[] serialPersistentFields; private void writeObject(java.io.ObjectOutputStream); private void readObject(java.io.ObjectInputStream); }

3.3 依赖管理与构建加速的实操技巧

中大型项目的构建速度决定了你的开发效率。很多人一提到构建加速就想到升级电脑，其实软件层面的优化空间很大。首先，把需要频繁调试的模块独立成单独的可运行模块，避免每次改一行代码都全量编译整个App。其次，一些纯功能的AAR模块可以做成单独的Maven仓库，二次改动时只编译依赖方。

Gradle配置上也有些细节值得优化：启用Gradle缓存、并行构建，合理配置JVM内存参数。我在项目里的gradle.properties通常这样设置：

org.gradle.jvmargs=-Xmx4096m -XX:MaxMetaspaceSize=1024m -Dfile.encoding=UTF-8 org.gradle.parallel=true org.gradle.caching=true kotlin.incremental=true

如果你用到的是Kotlin项目，还应该开启Kotlin增量编译。实测下来，这些配置叠加后能明显减少日常增量编译的时间，尤其是模块多的项目。

3.4 MVVM与Compose架构落地要点

MVVM这几年已经成了应用架构的主流，但真正落地时很多人把它和DataBinding、LiveData、ViewModel这些组件混在一起理解。其实MVVM的核心是“单向数据流”和“可测试性”，而不是某个具体库。就算不引入DataBinding，只用ViewModel + StateFlow + Repository，也能写出很干净的MVVM。

Kotlin + Jetpack Compose是现在的新方向，但我想提醒大家不要因为用了Compose就以为“自动获得MVVM架构”。Compose只是UI层，是声明式的，它和ViewModel之间依然要约定清楚状态来源和事件回调。我习惯用一层简单的State类来承载页面所有UI状态，ViewModel负责把业务状态映射成UI状态，Compose通过collectAsStateWithLifecycle来订阅，这样可以避免因为生命周期导致的界面闪烁。

下面是一个最简的ViewModel + Compose状态管理示例：

class MainViewModel : ViewModel() { private val _uiState = MutableStateFlow(MainUiState()) val uiState: StateFlow<MainUiState> = _uiState.asStateFlow() fun loadData() { viewModelScope.launch { _uiState.update { it.copy(loading = true) } val result = repository.getData() _uiState.update { it.copy(loading = false, data = result) } } } } data class MainUiState( val loading: Boolean = false, val data: List<String> = emptyList() ) @Composable fun MainScreen(viewModel: MainViewModel = viewModel()) { val uiState by viewModel.uiState.collectAsStateWithLifecycle() when { uiState.loading -> LoadingView() else -> DataList(uiState.data) } }

注意，这里用到了collectAsStateWithLifecycle，它是lifecycle-runtime-compose库提供的API，比collectAsState更安全，能在页面不可见时自动停止收集，避免底层数据源持续更新导致浪费。

4. 性能优化与稳定性治理：火焰图与内存优化

4.1 火焰图与卡顿定位：别再凭感觉优化

性能优化的第一步不是改代码，而是测量。很多开发者在“页面卡”的时候第一反应是“把异步任务整理一下”，或者“少用一点嵌套布局”，这些动作可以碰运气，但不一定解决真正瓶颈。我强烈建议先使用CPU Profiler采集一段卡顿发生时的采样数据，然后生成火焰图来分析。

火焰图怎么看？正常情况下，每一条横条代表一个函数调用栈，横条越宽，说明这个函数在 CPU 上执行的时间越长。你从上往下看是调用链，从下往上看是父调用。当你发现某个方法横条非常宽，且经常会出现在多个采样点里，那它大概率是优化目标。

我曾经优化过一个列表滑动卡顿的问题，刚开始以为是RecyclerView的item布局太复杂，后来用火焰图一看，发现大量时间消耗在图片加载库的某个缓存压缩函数上，原因是我给每张图都设置了很大的TargetSize。改成自适应尺寸之后，列表瞬间就流畅了。这就是用数据的价值。

Android Studio自带的CPU Profiler对中大型项目来说足够用，但如果你想让采样更加轻量且能跑到线上，可以使用开源的simpleperf来抓native性能瓶颈。

4.2 内存泄漏与检测工具

内存泄漏是Android开发者绕不开的话题。常见的泄漏场景有：Activity泄漏、View持有Activity、静态集合生命周期过长、Handler持有Activity、回调接口没取消注册等。最简单的检测工具是LeakCanary，它会在应用进程里监听Activity和Fragment的销毁，如果发现没被回收，就在通知栏提醒并给出引用链。

但不要只停留在“跑一下LeakCanary，看着不报错就觉得没问题”。内存优化的高级姿势是：分析Heap Dump，找出大对象和有异常引用链的对象。Android Studio的Memory Profiler可以导出hprof文件，然后用MAT或者Android Studio自带的分析器找到“Retained Size”最大的对象。

我见过一个实际案例：App长时间使用后OOM，内存监控显示Bitmap对象非常多。排查下来发现是某个图片列表的ViewHolder没有及时释放ImageView对Bitmap的引用，加上Glide的风控策略没配置好。优化后不仅OOM消失，整体滚动帧率也提升了不少。

4.3 ANR与崩溃治理的工程手段

ANR（Application Not Responding）比崩溃更让人头大，因为它在测试环境很难复现，往往只出现在用户低端机上。理解ANR的本质很重要：只要主线程在限定时间内没有处理完一些关键事件，比如输入分发、广播接收、Service执行，系统就会弹ANR。所以治理ANR的核心思路只有一个：让主线程尽量“没事干”。

我给你们一个实用的排查步骤：线上收集到ANR日志后，先看主线程的堆栈，判断是哪种类型的ANR；然后追溯主线程当时在等什么，是等锁、等Binder调用、还是等I/O。如果是锁等待，继续看是哪个线程持有了锁；如果是I/O，考虑把文件读取、数据库操作、共享Preferences写入全部移出主线程。

这里有一个容易忽略的点：SharedPreferences的apply()虽然在异步写磁盘，但在首次加载时会阻塞主线程读取，如果文件很大，一样会造成严重的卡顿。中大型项目里建议逐步迁移到DataStore或者自研轻量数据库。

4.4 使用i2c-tools与底层硬件调试

热词里出现了“i2c-tools 在 Android 上使用”，这偏向嵌入式调试，但对中高级Android工程师来说，做车载、智能硬件、监控设备时会经常遇到。I2C是一种常用的低速通信协议，调试传感器、触摸屏、外设时都会用到。

在Android设备上，如果系统已经内置了i2c-tools，可以直接用命令来读取设备寄存器。常用操作包括：

# 探测总线上的设备地址 i2cdetect -y -r 1 # 读取寄存器值 i2cget -y 1 0x48 0x00 # 写入寄存器值 i2cset -y 1 0x48 0x00 0x10

这里的“1”是I2C总线编号，需要根据设备树或kernel log确认。如果你自己编译系统，可以在BoardConfig或defconfig中开启CONFIG_I2C_CHARDEV和CONFIG_I2C_TOOLS，然后adb shell就能直接使用这些命令了。调试硬件时，最需要留意的是电平匹配、时钟频率和地址7位还是8位的问题，不然很容易读不到数据。

5. 进阶调试与安全分析：反编译、动态图标、文件访问适配

5.1 反编译与去广告的基本思路

热词里有“Android 反编译去广告”，我在解读这个词时，必须提醒一句：反编译他人的App并修改其逻辑，可能违反软件授权协议，甚至违法。所以我这里只讨论合法的场景：分析自己的App产物是否被篡改、追踪线上问题的资源文件、或者学习某个开源项目的实现细节。

常用工具和流程如下：

• apktool：解码res和AndroidManifest.xml，用于修改资源、查看布局等。
• jadx：直接反编译成Java代码，阅读代码逻辑非常好用。
• dex2jar + JD-GUI：老牌组合，但效果不如jadx直观。

如果你只是想去掉自己开发测试包里的广告SDK，我建议不要用反编译去改逻辑，而是在Gradle依赖和AndroidManifest里做裁剪，从源头去掉.arr依赖。对于已经打包的文件，临时加载大资源或修改布局的验证，可以用apktool解包后重新打包签名，但务必只在内部测试环境使用。

5.2 Android动态图标主题的实现

“Android动态图标主题”这个热词，本质上是应用图标能根据系统主题、第三方主题包或用户设置动态切换。Android 13之后引入了Themed Icons，可以让应用图标适配Material You的主题色，但这是系统层面的能力。如果你想要在桌面上显示动态变化的图标，通常需要申请系统桌面权限，或者在应用内部通过Shortcuts机制来替换快捷方式图标。

如果想做一个不依赖桌面的动态图标，最简单的方案是在启动器Widget里自绘一个ImageView，根据数据变化实时更新。但如果目标是替换桌面图标本身，你会发现普通应用无法直接操作其他Launcher的图标显示位置，除非系统定制ROM开放了接口。

所以在做这个功能前，先想清楚使用场景。如果只是“App图标会随着节日变化”，可以重点放在动态主题库的架构设计上；如果是“想在第三方桌面动态显示”，那基本走不通，别在这上面浪费时间。

5.3 Android 14上的root与文件访问适配

热词里有“Android 14 root”和若干content://协议路径。Android对文件访问的限制越来越严，尤其从Android 10开始强制分区存储，到Android 13、14进一步收紧。新开发的应用，如果直接使用“file:///storage/emulated/0/...”这种路径去访问公共目录，会遇到FileUriExposedException，或者发现权限明明申请了但就是打不开文件。

正确的做法是使用FileProvider，并在AndroidManifest中配置Provider。比如热词中出现过的content://com.baidu.searchbox.fileprovider和content://com.ss.android.uri.key，这就是各家App通过FileProvider暴露出来的Uri。我们自己实现时，一般这样配置：

<provider android:name="androidx.core.content.FileProvider" android:authorities="${applicationId}.fileprovider" android:exported="false" android:grantUriPermissions="true"> <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/file_paths" /> </provider>

在res/xml/file_paths.xml中，把你允许暴露的目录路径声明出来，比如/Android/data/下的下载目录、/DCIM/等。如果业务确实需要访问Android/data下的数据，还要注意Android 11以后系统禁止普通App直接读取其他应用的Android/data目录，只能借助SAF（Storage Access Framework）让用户手动选择目录。

这部分内容很琐碎，但却是中高级工程师排查线上文件问题最常遇到的一类坑。

5.4 OpenOCD与底层调试

热词里还有“Android OpenOCD”，这是嵌入式开发里常用的片上调试工具。如果你的系统跑在ARM上，或者你在调试一个定制的Android设备启动阶段，OpenOCD可以通过JTAG/SWD接口直接访问CPU和内存，帮你分析启动早期的问题。

常见配合方式是：OpenOCD（宿主机） -> JTAG转接板 -> 目标板，然后通过GDB连接OpenOCD进行断点调试。对Android开发者来说，这种场景通常出现在系统启动到应用层之前的阶段，比如U-Boot、kernel、设备树等。如果你是应用开发，暂时用不到，但如果想往系统定制方向进阶，建议至少能看懂OpenOCD的配置文件和log输出。

6. 常见问题排查与经验实录

6.1 Android Studio安装、汉化与插件配置里的坑

Android Studio官网下载其实一直是可以直接访问的，但很多人会卡在SDK下载慢、Gradle同步失败这些问题上。我建议在首次安装后，先把SDK Manager里常用的SDK Platform和Build-Tools装好，再去新建项目，否则新建项目时会现场下载，容易卡住。

关于汉化，Android Studio官方已经自带中文语言包，你只需要在Plugins市场搜索“Chinese (Simplified) Language Pack / 中文语言包”，安装后重启即可。不过我个人更推荐保持英文界面，因为很多报错、文档、Stack Overflow都是英文，长期用英文IDE会更顺手，也能减少踩坑时的翻译成本。

插件方面，热词提到的“Android Studio插件仓库”，说的是Plugins面板。不要装太多花哨的插件，否则反而拖慢IDE启动速度。比较实用的插件通常包括：Kotlin官方插件、JSON转Kotlin DataClass、ADB Idea（快速卸载和清理数据）、SonarLint（代码检查）。安装插件后如果遇到编译异常，先禁用最近安装的插件再测试。

6.2 常见编译错误速查表

我把这些年群里问得最多的几个编译错误整理成了一个表格，方便大家对照：

排查这些报错时，我自己有一个原则：先看最顶层的Caused by，不要一上来就搜完整日志。很多问题根本原因在最后一行，前面都是过程中的噪音。

6.3 蓝牙开发与硬件交互的四个关键点

热词里出现了“Android 蓝牙”，这块也是中高级开发常遇到的硬件交互场景。我概括成四个关键点：

• 权限申请：Android 12及以上需要在运行时申请BLUETOOTH_SCAN、BLUETOOTH_CONNECT权限，且不能与旧版权限混用。
• 蓝牙打开的时机：蓝牙状态变化是异步的，不要在你调用enable()后立刻开始扫描，要监听系统蓝牙状态广播。
• GATT连接回调：很多连接失败是因为没有在onConnectionStateChange里处理失败状态，或者没有进行重连退避。
• 日志分析：蓝牙问题非常依赖日志，最好抓取BluetoothAdapter相关的系统日志，确认连接失败的具体原因。

我之前做过一个智能硬件App，连接模块反复出现偶发性断开，最后通过抓日志发现是设备侧BLE连接间隔设置过长，导致手机在Activity休眠后进入低功耗模式，链路被系统断开。这种问题不做底层日志分析，根本看不出来。

6.4 从“能用”到“易维护”的代码习惯

很多开发者在写项目时只考虑“跑通”，不考虑后面谁维护、怎么扩展。中高级工程师写代码，应该天然带有“易读、易删、易替换”的意识。我经常在代码评审里强调几个原则：

• 命名要能表达意图，不要用a、b、data1这种名字。
• 工具类不要写成一个几百行的上帝类，尽量按功能拆分成多个小类。
• 所有外部调用和系统状态变化，最好都在明确定义的回调或State中流转，避免到处修改全局状态。
• 写注释的优先级不是解释“做了什么”，而是解释“为什么这么做”，否则半年后自己看代码都可能懵。

我见过很多项目，功能都能跑，但代码烂到连自己团队都不敢动。中高级工程师要努力避免这一点，因为架构腐化比功能性bug要难修得多。

写在最后的个人经验

做Android开发这十来年，我最深的一点体会是：技术更新永远追不完，但核心方法论是稳定的。中高级工程师的核心竞争力，不是“会用某个新框架”，而是“遇到没有标准答案的问题时，能通过定位、分析、验证、沉淀，给出一个可靠解决方案”。你掌握AMS、R8、火焰图、FileProvider这些东西，不是为了背面试题，而是为了在线上故障时比别人更快一步找到原因。

如果你正卡在进阶瓶颈，我建议你先拿出自己最近做的一个项目，用性能工具完整跑一遍，把启动阶段每个方法的耗时想办法量化清楚；再把工程里容易混淆的Gradle、R8、签名、权限适配规则整理成文档；最后把这些经验输出给团队。这个过程会让你发现很多“我好像会了，但真要讲清楚又不太确定”的知识盲区。补上这些盲区，你就离真正的中高级工程师更近了一步。