Android 性能优化技术月报 | 2025 年 6 月
每个月都会有一些 Android 性能优化相关的优质内容发布，然而，碎片化阅读使得这些知识难以形成完整体系，且容易被遗忘。为解决这些问题，我决定尝试使用技术月报的形式，总结我在最近一个月内查阅的 Android 性能优化相关的优质内容。
月报的主要内容包括：整理展示我在最近一个月所查阅的 Android 性能优化领域的最新技术动态、精选博客，精选视频等内容。
精选博客
鸿蒙编译时 AOP实践之路
- 插件功能与优势：aspect - pro - plugin 是轻量级鸿蒙编译时 AOP 插件，能让应用 3 分钟支持鸿蒙编译时 AOP 能力。支持 ets、ts、js 语法解析，可自定义配置规则，支持 replace 自动导包，还提供丰富插桩 demo 示例，如函数耗时、函数替换等。
- 方案选型与难点：调研鸿蒙 AOP 能力后发现，鸿蒙未开放 ArkTs 对应的 AST 工具，修改 CompileArkTs 的 build 产物对方舟字节文件无效，Hvigor 开放 api 有限等问题。确定基于 Hvigor 自定义 Plugin 在编译期插入，用 TS Compile Api 进行 AST 解析的思路。关键难点是在 Hvigor 自定义 Plugin 中获取 “符合 TS 语法规范的 ETS 文件”。
- 实践方案确定：实践过程对比了强转 ETS、修改编译工具 ets_loader、自定义 compile plugin 等方案。强转 ETS 稳定性差，修改 ets_loader 影响范围大，最终采用自定义 compile plugin 方案。此方案利用 Hvigor 非公开 api 在 ets_loader 到 ark compile 编译成 abc 中间插入 sourcefile 的 compile plugin，虽非官方方案，但经与华为官方沟通，是当前可落地的最佳实践。
btrace 3.0 发布
自 btrace 2.0 发布近两年，收到大量用户反馈，主要问题包括：
- 接入维护成本较高：接入、使用及维护的成本均偏高，对用户的使用体验产生了影响。接入的插件配置较为复杂，编译期插桩致使构建耗时增加，接入后字节码插桩异常会导致无法正常编译，且问题原因难以排查。
- 系统方法信息缺失：编译期的字节码插桩方案仅能对打包至 apk 内的方法生效，无法对 android framework 等系统方法生效，导致所采集的 Trace 信息不够丰富，影响后续的性能分析。
btrace 现有问题源于编译期字节码插桩方案，因此探索其他 Trace 采集方案。对比代码插桩和采样抓栈方案，前者虽能精确捕获执行时间、收集更多运行时数据，但对应用体积、性能及编译耗时有较大影响；后者可调整采样率、捕获应用整体行为，但 Trace 精度和性能不足。最终提出将动态插桩和同步抓栈结合的方案，以取长补短。
让 Bug 自动“蒸发”！我们造了个 AI 程序员同事
本文介绍了雪球开发的一款 AI 神器 AIFix，它旨在帮助程序员提高修复代码 Bug 的效率。AIFix 的开发源于程序员手动修复 Bug 的痛点，与传统 AI 编程工具不同，它能端到端处理完整开发流程
内部测试结果亮眼，AIFix 已经能搞定： - 70% 的前端样式问题（间距乱了？颜色错了？小 case！) - 60% 的接口调用问题（参数传错？不在话下！) - 80% 的 React Native 应用闪退 （Crash？稳稳拿捏） - 自动修复的准确率高达 66%
SOLID 设计原则在 Android 中的实战应用
大多数开发者都听说过 SOLID 设计原则，这些原则由鲍勃大叔（罗伯特・C・马丁）提出，有助于提高代码的可测试性和关注点分离。Android 开发者的对话中热衷讨论 MVVM，MVP，却很少提及 SOLID。但其实这些设计原则早已渗透在 Android 开发的方方面了，是一名高阶 Android 开发者必备的思想基础。本文通过多个示例为大家介绍了 SOLID 在 Android 开发中的应用场景。
- 单一职责原则（SRP），倡导拆分类的职责，避免臃肿，如将 ViewModel 中的业务逻辑分离至 UseCase 等；
- 开闭原则（OCP），强调在不修改现有代码前提下扩展功能，像通过密封类继承扩展页面状态，利用依赖注入自定义 ViewModelFactory 等；
- 里氏替换原则（LSP），要求子类型能安全替换基类型，例如 BaseFragment 与子 Fragment 的关系、不同 ViewHolder 的替换等；
- 接口隔离原则（ISP），主张保持接口简洁，拆分臃肿接口，如拆分 Repository 接口、RecyclerView 点击事件接口等；
- 依赖倒置原则（DIP），提倡依赖抽象而非具体实现，像将 UseCase 注入 ViewModel、抽象数据源实现数据源切换等
SOLID 原则并非只是抽象理论，做一个简单回顾：
- SRP 拆分职责，让类保持专注。
- OCP 在不修改现有代码的情况下安全扩展。
- LSP 确保安全的继承和多态性。
- ISP 有助于拆分臃肿的接口。
- DIP 解耦逻辑，提高可测试性和灵活性。
Swift 官方正式支持 Android，iOS 的跨平台春天要来了吗？
近日，Swift 官方正式宣布成立 Android 的工作组，将 Android 列为官方支持的平台，该工作组的主要目标是为 Swift 语言添加并维护 Android 平台支持，让开发者能够使用 Swift 开发 Android 应用
- 技术实现：基于 LLVM 与 Android NDK，利用 Clang 编译器兼容特性，在 Linux 环境将 Swift 代码编译为 Android 原生机器码。
- 支持现状：核心库（String、Int 等）已支持编译，Foundation、Dispatch 等库移植中。无官方 UI 框架，需手动实现与 Java 代码交互。
总得来说，Swift on Android 目前处于早期阶段，更侧重底层编译支持，UI 和生态整合尚不完善，距离生产级应用标准仍有差距。但其官方背书为跨平台开发提供了新可能，未来或推动 iOS/Android 代码共享（类似 KMP），但需等待生态成熟与工具链完善。