Android 性能优化技术月报 | 2025 年 5 月
每个月都会有一些 Android 性能优化相关的优质内容发布，然而，碎片化阅读使得这些知识难以形成完整体系，且容易被遗忘。为解决这些问题，我决定尝试使用技术月报的形式，总结我在最近一个月内查阅的 Android 性能优化相关的优质内容。
月报的主要内容包括：整理展示我在最近一个月所查阅的 Android 性能优化领域的最新技术动态、精选博客，精选视频等内容。
最新动态
《Android 性能优化之道》上架微信读书
这是一套从Android性能优化本质入手，指导读者实现从硬件层到操作系统层再到应用层全面优化的实战方法论。本书由Android方向Google开发者专家撰写，融合了作者10年大厂实战经验，其中不仅包括作者实操过的监控、优化、防劣化等方向的各种典型案例，还包括多个实战小技巧，可以帮助读者解决工作中遇到的90%以上的能优化问题。 本书内存、速度和流畅性、稳定性、包体积、耗电、磁盘占用、流量、降级这8个方向的性能优化内容。这些内容方向均从原理和实战两个维度进行解读。其中，原理部分直指优化的本质，不仅包括相关基础知识，还包括性能优化的底层逻辑；实战部分以指导读者实操为主要目标，以案例为主要讲解形式，深度解读作者精心总结的各种实战案例中用到的技术和原理。
精选博客
严格模式也能干大事
StrictMode按字面翻译，也称作严格模式，可以用于检测UI线程上的磁盘操作和网络请求等。
检测两大类型，分别是线程相关setThreadPolicy和虚拟机相关setVmPolicy。
setThreadPolicy, 设置线程需要检测的策略（当前线程实际就是main线程）； 设置检测命中后的警告方式，如日志输出，弹框，杀死进程，屏幕闪烁 具体来说，目前支持如下几种检测：
detectDiskReads 磁盘读操作
detectDiskWrites 磁盘写操作
detectNetwork 网络连接
detectCustomSlowCalls 自定义的耗时操作
detectResourceMismatches >=API 23 资源类型不匹配
detectUnbufferedIo >= API 26 未缓冲的IO
setVmPolicy, 设置虚拟机进程检测的策略(包括进程内的任意线程) 设置检测命中后的警告方式，如日志输出，弹框，杀死进程，屏幕闪烁 具体来说，目前支持如下几种检测：
detectActivityLeaks Activity泄漏
detectLeakedClosableObjects 未调用关闭方法，比如Closeable的close
detectLeakedRegistrationObjects 为注销监听/注册，比如BroadcastReceiver
detectLeakedSqlLiteObjects sql游标未关闭
detectFileUriExposure >= API 18 对外暴露file://
detectCleartextNetwork >= API 23 网路操作明文检测，未使用SSL/TLS加密
detectUntaggedSockets >= API 26 为标记Socket连接，TrafficStats
detectContentUriWithoutPermission >= API 26 对外暴露content://时，未做权限要求
2025 跨平台框架更新和发布对比，这是你没看过的全新版本
2025 年可以说又是一个跨平台的元年，其中不妨有「鸿蒙 Next」 平台刺激的原因，也有大厂技术积累“达到瓶颈”的可能，又或者“开猿截流、降本增笑”的趋势的影响，2025 年上半年确实让跨平台框架又成为最活跃的时刻。本文详细对比了当下热门的跨平台框架：
- Flutter 的特性与局限：作为自绘领域的跨平台框架，Flutter 凭借 “自绘” 和 “AOT 模式” 在平台统一性和性能上表现出色，2025 年的更新如平台和 UI 线程合并，为 Dart 与原生语言同步互操作提供基础。其核心竞争力 Impeller 解决了 Skia 着色器编译卡顿问题，在类游戏场景支持良好。但它存在文字排版不如原生、内存占用高、官方不支持热更新等局限，鸿蒙版本落后，在不同平台也有各自推进缓慢的问题。
- React Native 的变革与不足：2025 年 React Native 借助 Skia 和 WebGPU 实现重大突破，新架构解决诸多性能瓶颈，如 JSI 可切换 JS 引擎、Fabric 支持并发渲染、TurboModules 按需加载插件等。同时支持热重载，能快速对齐新 React 特性。在动画和图像处理等场景借 Skia 和 WebGPU 获得强力补充，在 PC 和小程序领域也有一定支持。不过，它面临平台 UI 一致性问题、第三方库新旧框架支持风险、版本升级风险以及平台 API 兼容复杂度高等局限。
- Compose Multiplatform 的优势与挑战：Compose Multiplatform 以 Kotlin 为语言基础，使用 Skia 绘制 UI，实现了不同平台的 UI 一致性，在 Android 上依赖系统 skia 使 apk 体积较小，在 PC 平台也有一定可用性。Kotlin 强大的编译器是其核心优势，能灵活适配各平台。但它在鸿蒙适配方面缺乏官方支持，适配成本高，小程序领域需第三方支持，iOS 平台存在着色器问题，第三方包适配难度较高，hotload 仅支持 PC 桌面，还面临内存占用和官方热更新缺失等问题。
- Kuikly 的独特之处与局限：Kuikly 属于 KMP 体系，与 CMP 不同在于绘制采用类 RN 方式，通过自研 DSL 构建 UI，支持 Kotlin/JS 和 Kotlin/Native 两种模式，有 “薄原生层” 设计，将大部分 UI 逻辑提升到共享 Kotlin 层，减少平台差异。它还表示后续支持全平台小程序，能与腾讯热更新管理平台集成。但它 UI 理解有额外成本，不支持 PC 平台，基于原生 OEM 存在部分不一致，在原有 App 集成时功能受限，动态化场景也存在诸多限制。
- Lynx 的创新与待完善之处：Lynx 是面向 Web 前端的跨平台全家桶，当前开源的 ReactLynx 是类 RN 框架，未来计划支持自渲染及多种前端框架。其 “双线程架构” 和深度定制的 PrimJS 引擎是主要技术特点，对即时首帧渲染和流畅交互体验有优势，支持多平台。然而，它非常年轻，社区、生态系统和第三方库有待发展，对客户端开发学习成本高，除部分平台外其他平台支持和自绘能力不明确，开发环境对 Windows 和 Linux 兼容性需打磨。
- uniapp x 的模式与局限：uniapp x 是 DCloud 的新尝试，基于 Web 技术栈，将 js（uts）代码在打包时编译成原生代码，可直接引用平台原生 API，实现 “代码混写”。在 UI 上编译为原生体系，性能与原生相当。但它面临不同平台翻译成本高、API 需删减、插件生态割裂、不支持 PC 和 HBuilderX IDE 等局限，iOS 平台为兼顾插件生态保留 js 老模式，增加了模式选择的复杂性。
CSS闯关指南：从手写地狱到“类”积木之旅
- 背景：CSS在Web开发中至关重要，早期纯手写CSS痛点多，催生了多种解决方案，原子化CSS理念带来新思路。
- 纯手写CSS的问题
- 代码冗余，维护成本高，文件体积膨胀。
- 开发时需频繁切换HTML和CSS文件，效率低。
- 类名命名困难，易出现样式污染。
- 响应式和动态样式实现复杂，调试困难。
- 样式与结构分离，降低组件内聚性。
- 工程化解决方案
- CSS预处理器：用变量、嵌套等提升代码复用率，但有工具链依赖等问题。
- CSS命名规范：如BEM、SMACSS、OOCSS，提高代码可维护性与团队协作效率。
- CSS模块化：借助工具实现CSS类名本地作用域，避免命名冲突。
- CSS-in-JS：将样式与组件绑定，实现作用域隔离和动态样式。
- 原子化CSS框架
- Tailwind CSS：组合原子类构建界面，消除冗余，提升响应式开发效率，但学习成本高。
- UnoCSS：按需生成原子类，配置灵活，性能高，但规则调试和生态成熟度存在问题。
- 总结：开发者应依项目情况选择合适的CSS开发方式，平衡开发效率与代码质量。