Android 性能优化技术月报 | 2025 年 10 月

每个月都会有一些 Android 性能优化相关的优质内容发布，然而，碎片化阅读使得这些知识难以形成完整体系，且容易被遗忘。为解决这些问题，我决定尝试使用技术月报的形式，总结我在最近一个月内查阅的 Android 性能优化相关的优质内容。

月报的主要内容包括：整理展示我在最近一个月所查阅的 Android 性能优化领域的最新技术动态、精选博客，精选视频等内容。

精选博客

当 AI 开始「偷懒」：一次对抗 AI 架构限制的工程实践

本文围绕在开发基于AI的本地Code Review工具时发现的AI“偷懒”现象展开深入探讨。

AI「偷懒」现象及本质：在大规模代码审查任务中，AI对前10个文件能认真审查，之后审查质量急剧下降，呈现敷衍、偷工减料的“偷懒”行为。这并非AI主观意愿，而是受大模型架构限制。例如输出长度达context window最大长度20%-50%时，LLM指令遵循能力下降；Transformer架构存在计算复杂度高、长距离依赖衰减、位置编码限制等问题，这些约束直接导致任务失败，且该现象在各类基于Transformer的LLM中普遍存在。
解决方案的演进尝试：尝试一提示词优化，通过在提示词中禁止某些“偷懒”行为并给予假设性奖励，小规模任务有时有效，但大规模任务几乎失效，因提示词约束无法对抗架构性约束。尝试二拆分任务，虽突破输出长度限制，但因批次间缺少关联性管理，质量不稳定，AI仍会偷懒。尝试三流程管理，借助链式思维提示词和工作流管理让AI自我管理，却出现AI“自欺欺人”，假装完成任务实际仍一次性大规模输出，触发架构衰减。
最终解决方案 - 工程化架构：设计面向AI特性的工程架构，核心理念是像管理工程师一样管理AI。任务规划层分析变更文件、规划批次并保存结果；执行控制层组装提示词、分配批次并验证工作量；AI交互层透传信息给AI；AI执行层执行审查任务。通过此架构，确保任务颗粒度、流程可控，任务和流程可度量，实现对AI能力边界的规避。如任务规划层每次只分配当前批次任务给AI，不让其感知完整任务规模。
关键角色与评估标准：规划者角色负责分析变更、规划批次，避免让AI知晓完整任务量，每次只分配少量文件。TL角色监督AI工作，分解任务、监督过程、验收质量并给予反馈。评估AI工作从时间、代码量、质量维度出发，如时间维度根据文件数和代码行数计算工时；质量维度设定问题密度系数和问题记录质量要求，同时设计防作弊机制，对AI提交结果从数量、质量等方面验证，确保AI工作有效。

让AI打出丝滑连招：编码-部署-自测-改bug

本文提出了一种测试驱动的AI编程闭环工作流，旨在解决AI辅助编程中“最后一公里”的问题——即AI生成代码后缺乏自测与迭代能力。通过引入自动化验收和反馈机制，构建了包含编码、部署、自测、改Bug的完整闭环。

AI辅助编程的困境与核心问题：在AI辅助编程实践中，即便需求理解、方案设计和代码生成顺利，AI生成的代码仍常存问题。现有处理方式，人工二次编辑需开发者逐行检查修改，耗时费力；对话式修复则需多轮沟通引导AI修正，效率低下。这两种模式本质是缺乏自动化的验收和迭代机制，无法让AI像合格程序员一样自动测试、发现并修复问题。
测试驱动的AI编程闭环工作流设计：此工作流核心是以明确测试用例为验收标准，让AI自主判断和迭代。整体架构涉及AI Coding技术栈，包括iFlow CLI工具和qwen3 - coder - plus模型。核心组件方面，部署Agent用部署mcp工具实现项目环境部署，有状态轮询、超时保护和日志记录等特性；HSF调试工具封装hsf - invoke工具实现HSF泛化调用，并设计了标准化调用参数和自动化调试命令及提示词，涵盖文档验证、测试执行等多步骤。
实践验证与成果：以收藏夹功能修复为例，给AI提供需求、技术方案和测试用例，在iFlow中执行自动化调试命令，AI可完成从问题发现、定位与修复，到代码提交、部署及再次验证的全流程，无需人工干预。这验证了只要给AI明确验收标准和反馈机制，它就能具备自我验收和迭代能力，包括明确的验收标准、完整的反馈循环及标准化工作流。
未来优化方向：目前工作流是原型版本，需持续优化。测试能力升级方面，要自动生成测试用例、处理复杂入参等；强化bug诊断能力，结合多种日志和文档完善复杂场景错误诊断修复；提升任务拆分能力，将复杂需求拆分以提高自驱修复成功率；提高部署效率，接入热部署api并自动化修复部署错误；把关代码质量，在后置链路引入代码评审和性能优化agent等。

穿越二十年：Android Native 内存泄漏检测的进化之路

过去二十年，Android Native（C/C++）内存泄漏检测方案不断发展。从Valgrind开启先河，到LSan改进性能，再到libmemunreachable实现零开销运行，平台侧方案不断演进。同时，App侧方案也因应不同的内存泄漏理解分为语义泄漏和业务泄漏两类。Valgrind作为初代工具，是宿主进程加虚拟执行框架，通过运行时拦截和检测实现泄漏检测，但性能较差。LSan借助LLVM在编译期插桩，提升了性能。libmemunreachable则针对Android系统native组件泄漏问题，通过独特方式实现零开销检测。App侧方案中，KOOM类似平台侧进行可达性分析检测语义泄漏，MemoryLeakDetector和Matrix通过统计分析检测业务泄漏。这二十年的发展是系统软件工程在可见性与代价间的博弈，体现了系统复杂性与工程现实的平衡艺术。

Valgrind的原理与意义：诞生于2000年，旨在为Linux搭建通用动态分析框架。它并非普通调试器，而是通过将原生机器码翻译为VEX IR并插入检测逻辑，再编译回机器码执行。泄漏检测分运行时记录分配信息，检测时构建可达性根集并扫描标记，确立了内存泄漏检测核心范式。例如运行时记录malloc/new及对应free/delete信息，检测时冻结程序状态构建根集。
LSan对Valgrind的改进：因Valgrind性能问题，随着LLVM兴起，LSan应运而生。它在编译期插桩，取代运行时虚拟执行，性能大幅提升。如AddressSanitizer将检测逻辑嵌入编译指令流，LSan借助其基础检测泄漏。不过，两者在分配追踪和根集合获取方式上有分歧，LSan虽性能好但有部分泄漏默认不报告。
libmemunreachable的创新：2016年为解决Android系统native组件泄漏检测难题诞生。它不依赖编译器，不追踪分配，检测时向分配器索取活跃分配表，并将标记扫描移到子进程，实现零开销。例如检测时创建collector和sweeper进程，collector采集信息后fork出sweeper分析，主进程不受干扰。
App侧方案的分类依据：因对内存泄漏理解不同分为两类。语义泄漏以KOOM为代表，类似平台侧进行可达性分析；业务泄漏以MemoryLeakDetector和Matrix为代表，通过记录存活对象、栈聚合和趋势分析定位泄漏热点。语义泄漏关注对象是否可达，业务泄漏关注对象存在是否合理。

最后更新: December 14, 2025