Android 官方在 2016 年 3 月更新了 Bottom navigation 设计规范，所谓设计规范就是告诉开发者和设计师要如何去设计和使用某一个组件。不过这次 Bottom navigation 的发布，让许多人大跌眼镜，毕竟 Bottom navigation 这样的组件，在之前的 MD 设计语言中可是只字未提，当时 Android 与 iOS 常见的导航布局也有差异：iOS 应用常用底部标签栏，Android 的旧指南则建议避免这种布局。这是设计建议的变迁，不是两个平台的能力限制，也不是所有 iOS 应用都必须使用底栏。
本文是 Android Bottom navigation 的第一篇文章，主要介绍 Bottom navigation 的使用，以及 Bottom navigation 小变迁。
之前有人在知乎提问：“怎么计算apk的启动时间？” :
利用python或者直接用adb命令怎么计算apk的启动时间呢？就是计算从点击图标到apk完全启动所花费的时间。比如，对游戏来说就是点击游戏图标到进入到登录界面的这段时间。
已知的两种方法貌似可以获取，但是感觉结果不准确：一种是，adb shell am start -w packagename/activity,这个可以得到两个值，ThisTime和TotalTime，不知道两个有什么区别，而且与实际启动时间不匹配，两者相加都可能比实际启动时间小（测试游戏的时候差别更大）；另外一种是通过adb logcat的方式，感觉获取的结果也与实际有差别。
我和另外一个同事郭启发 针对两个方面进行了回答，不过毕竟知乎上看的人会比较少，所以我在征得他的同意之后，将这两个答案整理了一下，记录到博客中，一来算是一个小的总结，之后自己看得时候比较方便，二来给需要的同学一个更加方便的途径。
上一篇文章我们使用第三种方法来实现延迟加载。不过上一篇写的比较简单，只是讲解了如何去实现，这一篇就来讲一下为何要这么做，以及这么做后面的原理。
其中会涉及到一些 Android 中的比较重要的类，以及 Activity 生命周期中比较重要的几个函数。
其实这个其中的原理比较简单，不过要弄清楚其实现的过程，还是一件蛮好玩的事情，其中会用到一些工具，自己加调试代码等，一步一步下来，自己对 Activity 的启动的理解又深了一层，希望大家读完之后也会对大家有一定的帮助。
在 Android 开发中,应用启动速度是一个非常重要的点,应用启动优化也是一个非常重要的过程.对于应用启动优化,核心思想就是在启动过程中少做事情,具体实践的时候无非就是下面几种:
不用一一去解释,做过启动优化的估计都使用过,本篇文章将详细讲解一下一种延时加载的实现以及其原理.
这种加载的实现很简单,但是其中的原理可能比较复杂,还涉及到Looper/Handler/MessageQueue/VSYNC等.以及其中碰到的一些问题,还会有一些我自己额外的思考.
本篇文章是自己的一个学习笔记，记录了 Android 5.0 中 hwui 中的 RenderThread 的简单工作流程。由于是学习笔记，所以其中一些细节不会太详细，我只是将大概的流程走一遍，将其工作流标注出来，下次遇到问题的时候就可以知道去哪里查。
下图是我用 Systrace 抓取的应用启动时 RenderThread 第一次 Draw 的历史 Trace。它能帮助观察线程内的执行顺序，但 DrawFrame 区间结束不等于画面已显示：还需要核对 GPU 完成、缓冲区消费、合成和显示的时点。启动期间可能先看到 StartingWindow，它的退出也不能仅凭这段 CPU Trace 判断。
在没有排序或额外索引的数组、链表中，按值查找最坏需要遍历全部元素。哈希表（hash table）通过哈希值定位桶，在哈希分布良好时，基本查找可以接近常数时间；这不代表所有输入下都能保证 O(1)。
HashMap是基于哈希表的 Map 接口的实现。此实现提供所有可选的映射操作，并允许使用 null 值和 null 键。（除了非同步和允许使用 null 之外，HashMap 类与 Hashtable 大致相同。）此类不保证映射的顺序，特别是它不保证该顺序恒久不变。
本文按源码顺序看 HashMap：数组与链表的数据结构、构造函数、put 和扩容、get，最后是迭代器如何用 modCount 检查结构修改。末尾补充后续 JDK 的变化。
Android 内存优化系列文章：
onTrimMemory(int level) 从 Android 4.0（API 14）提供，用于提示应用在合适的时机减少不必要的内存占用。合理缩减缓存有助于系统保留更多后台进程，但不能保证应用不被终止，也不能保证下次返回一定更快。
本文仍用问答方式介绍回调的作用、接入和资源清理。重点是按资源的用途决定保留什么、释放什么，并确保返回界面时能够恢复。
Android 内存优化系列文章：
我写这篇文章的初衷，是希望在动手写代码前，先把容易出内存问题的地方弄清楚，少留些问题到后面排查。下面从 Bitmap、数据库查询、列表复用和绘制等方面展开，看看资源由谁创建、谁持有、什么时候不再需要。这里有资源滞留、重复分配，也有泄漏，几种情况要分开处理。
Android 内存优化系列文章：
为了让垃圾回收器释放不再使用的对象，需要避免让长生命周期的对象继续持有已经无用的引用。判断条件是对象是否还能从 GC Roots 到达，并不是“有没有其他对象引用它”：一组互相引用、但整体不可达的对象也可以被回收。失去可达性不代表立即执行 GC，更不代表这部分内存立即归还给系统。
内存管理还包括缓存上限、资源所有权和组件生命周期。文件、连接和 native 资源应按各自接口及时关闭或释放，不能只等 Java 对象被 GC。
Android 内存优化系列文章：
这篇文章介绍的是 Android Java 代码中的微优化。选择合适的算法与数据结构仍应放在前面；减少热点路径上的重复工作和临时分配，才是这些技巧的主要用途。
本文最初整理自 Google Android Training 的 Performance Tips。标题中的“Java 官方篇”指这份 Android 文档里的 Java 代码建议，并非 Oracle 的 Java 性能规范。
2015 年 5 月 28 日，Google 在 I/O 发布了 Android M Developer Preview，支持 Nexus 6 等设备。这篇记录的是当时的体验，下面是桌面和彩蛋界面。
已过期的实验流程 · 技术复核（2026-10-13）：修改系统属性打开隐藏多窗口开关，仅作为 Nexus 6（shamu）与 2015 年 Android M 预览版的历史记录。Google 后续公告把首轮预览版标为 MPZ44Q；本文没有保留设备构建号输出，不能把它当成本机镜像的核验结果。今日的正式多窗口适配见文末版本说明，不需要这套改系统流程。
单例模式也叫单子模式，是一种常用的软件设计模式。本文按饿汉式、双重检查锁、静态内部类和枚举的顺序，介绍各自的初始化方式及边界。
技术复核（2026-10-13）：这些实现思路仍然适用。下文以 Java 5+ 的内存模型和 Java SE 25 规范核查，修正“类加载即创建”“private 只在编译期生效”“枚举因抽象而不能反射”等说法。各个名为
Singleton的代码块是替代方案，不应同时放进同一个源文件。
系列文章目录：
技术复核（2026-10-13）：本文保留 2015 年视频的三色柱形图。旧图的 Update / Execute / Process 可对照 Android 4.4.4 源码；Android 6.0 与 Android 16 已有更细的分段和不同参考线实现，不能把旧图例套到所有设备。
当时的视频简介：
“If you can measure it, you can optimize it” is a common term in the computing world, and for Android’s rendering system, the same thing holds true. In order to optimize your pipeline to be more efficient for rendering, you need a tool to give you feedback on where the current perf problems lie.
And in this video, +Colt McAnlis walks you through an on-device tool that’s built for this exact reason. “Profile GPU Rendering” will help you understand the stages of the rendering pipeline, and also get a chance to see what portions of it might be taking too long, and what you can do about it for your application.
Profile GPU Rendering 是开发者选项里的快速观察工具，可以帮助找到哪些操作伴随较高的绘制耗时。它的名字虽然有 GPU，柱形图却不是 GPU 硬件执行时间的直接测量，也不能单独告诉你卡顿的全部原因。官方说明
系列文章目录：
技术复核（2026-10-13）：保留 2015 年的视频简介和九张示意图。正文已修正固定 60Hz、撕裂原因以及“VSync 复制后缓冲”的说法，并补充现代 Android 的帧率提示与分析入口。
当时的视频简介：
Unbeknown to most developers, there’s a simple hardware design that defines everything about how fast your application can draw things to the screen.
You may have heard the term VSYNC - VSYNC stands for vertical synchronization and it’s an event that happens every time your screen starts to refresh the content it wants to show you.
Effectively, VSYNC is the product of two components Refresh Rate (how fast the hardware can refresh the screen), and Frames Per Second (how fast the GPU can draw images), and in this video +Colt McAnlis walks through each of these topics, and discusses where VSYNC (and the 16ms rendering barrier) comes from, and why it’s critical to understand if you want a silky smooth application.
想要理解界面为什么流畅或卡顿，需要先区分应用产帧、系统合成和屏幕呈现。VSync（垂直同步） 用来协调这些阶段的节奏，不是刷新率与 FPS 的数学乘积，也不是一个替应用完成绘制的操作。AOSP VSync 说明
系列文章目录：
技术复核（2026-10-13）：本文保留 2015 年的视频摘录和示意图。过度绘制的概念仍然适用；下文补充默认颜色表的版本依据、透明混合的例外和删除背景的前提，不把颜色变浅直接当成性能收益。
当时的视频简介：
One of the most problematic performance problems on Android is the easiest to create; thankfully, it’s also easy to fix.
OVERDRAW is a term used to describe how many times a pixel has been re-drawn in a single frame of rendering. It’s a troublesome issue, because in most cases, pixels that are overdrawn do not end up contributing to the final rendered image. As such, it amounts to wasted work for your GPU and CPU.
Fixing overdraw has everything to do with using the available on-device tools, like Show GPU Overdraw, and then adjusting your view hierarchy in order to reduce areas where it may be occurring.
视频开头作者举了一个例子，说如果你是一个粉刷匠，你应该会知道，给墙壁粉刷是一件工作量非常大的工作，而且如果你需要重新粉刷一遍的话(比如对颜色不满意),那么第一次的粉刷就白干了. 同样的道理，如果一个不透明区域完全覆盖了前面画出的内容，前面的部分绘制就可能没有贡献。如果你想兼顾高性能和完美的设计,那么你的程序可能会出现一个性能问题:OverDraw!
Overdraw（过度绘制） 指同一帧里，同一个像素被重复绘制。例如下面重叠的卡片，不透明卡片下面被完全遮住的部分可能做了无用功；但不能把“发生重叠”一律视为浪费。半透明内容、阴影和抗锯齿边缘仍需要底下的颜色参与混合，直接删掉底层会改变画面。实际工作量也受裁剪和渲染器优化影响。官方概念说明
系列文章目录：
技术复核（2026-10-13）：本文是 2015 年视频的学习笔记，Nexus 5 的例子和工具截图保留为历史材料。下方原视频简介中的 16ms 是 60Hz 的近似说法；正文已修正刷新、掉帧和调试工具的适用范围。
当时的视频简介：
Rendering performance is all about how fast you can draw your activity, and get it updated on the screen. Success here means your users feeling like your application is smooth and responsive, which means that you’ve got to get all your logic completed, and all your rendering done in 16ms or less, each and every frame. But that might be a bit more difficult than you think.
In this video, +Colt McAnlis takes a look at what “rendering performance” means to developers, alongside some of the most common pitfalls that are ran into; and let’s not forget the important stuff: the tools that help you track down, and fix these issues before they become large problems.
当你觉得自己开发了一个改变世界的应用的时候，你的用户可能并不会这么认为，他们认为你的应用又慢又卡，达不到他们所期望的那种顺滑，更谈不上改变这该死的世界了，回收站走你！等等！明明我这个应用在我的Nexus5上非常顺滑啊？你咋能说又慢又卡呢？如果你对Android的碎片化有一定了解的话，你就应该知道，很多低配置的手机并不像Nexus5那样有强大的处理器和GPU，以及没有被怎么污染的原生系统。
如果有大量的用户投诉说你的应用又卡又慢的时候，不要总是抱怨用户的低端手机，有时候问题就出在你的应用本身，可能涉及渲染、主线程阻塞等问题，需要先测量再定位。了解问题发生的根源，才能有效地解决问题。所以了解Android渲染相关的知识，是一个Android开发者必不可少的知识。
系列文章目录：
2015 年，Google 推出了关于 Android 性能优化的短视频系列 Android Performance Patterns，原播放列表在 YouTube。官方当年的配套课程介绍也记录了这个系列。
技术复核（2026-10-13）：本文保留 2015 年的选题说明和观看经历。早期视频仍可用于理解渲染问题；旧工具、Google+ 入口及“16ms”说法需要按下面的版本条件阅读。
过度绘制、VSYNC、主线程与 RenderThread 的协作仍然值得学习，但帧间隔不是永远 16ms。60Hz 对应约 16.67ms，90Hz 约 11.11ms，120Hz 约 8.33ms；实际产帧截止时间还要看系统调度和 trace，不能把一个固定阈值套到所有设备与场景。
| 要调查的问题 | 今天的入口与适用条件 |
|---|---|
| View / Compose 的层级和属性 | 用 Layout Inspector 检查可调试应用；它也支持 Compose 重组/跳过信息，不能把层级检查等同于帧耗时测量 |
| 快速观察绘制阶段和过度绘制 | 开发者选项里的 Profile GPU/HWUI Rendering、Debug GPU Overdraw；柱形图是 CPU 侧绘制阶段信号，不是纯 GPU 执行时间，也不能覆盖所有自建渲染路径。官方说明 |
| 具体哪些帧错过期限 | 使用 Perfetto 的 FrameTimeline，要求 **Android 12 / API 31+**；再结合已采集到的线程、调度和 SurfaceFlinger 轨道定位 |
| 滑动或页面切换是否退化 | Macrobenchmark FrameTimingMetric 从 AndroidX Benchmark 1.1.0 提供；frameOverrunMs 要求 **API 31+**，与 frameDurationCpuMs 的口径不同 |
Hierarchy Viewer、Traceview 所属的旧 Android Device Monitor已在 Android Studio 3.1 弃用、3.2 移除。方法级分析使用当前 Profiler，层级检查用 Layout Inspector。做 Macrobenchmark 时按项目配置要求使用接近发布状态的 non-debuggable、profileable 目标应用，并固定设备与操作场景。
当时的官方简介（原文摘录）：
Android Performance Patterns is a collection of videos focused entirely on helping developers write faster, more performant Android Applications. On one side, it’s about peeling back the layers of the Android System, and exposing how things are working under the hood. On the other side, it’s about teaching you how the tools work, and what to look for in order to extract the right perf out of your app.
But at the end of the day, Android Performance Patterns is all giving you the right resources, at the right time to help make the fastest, smoothest, most awesome experience for your users. And that’s the whole point, right?
总之就是一系列讲解Android性能相关的视频。这些小视频的时间非常短，在3-5分钟之内，主讲人的英文语速也非常快，初期这些视频没有翻译的时候，着实考验了一把听力。当时已有中英文字幕可供参考；现在具体有哪些字幕，以各视频实际提供的轨道为准。
这些视频的时间虽然很短，但是信息量却非常大，有些他一句话带过的内容，我们却需要花费很多的时间去研究他的原理，或者研究一个调试工具如何使用。也就是说，这一系列视频并没有真正教你如何去优化你的应用，而是告诉你关于Android性能优化你需要知道的知识，这样你去优化你的Android应用的时候，知道该用什么工具，该采取什么样的步骤，需要达到什么样的目标。
本文是 MAT 工具使用系列的第三篇，这个系列共三篇，详细介绍了如何使用 MAT 来分析内存问题，既可以是 Java 应用的内存问题，也可以是 Android 应用的内存问题：
技术复核（2026-10-13）：这是依赖旧 Bitmap 实现的历史技巧，保留原截图。下文以 AOSP android-4.4.4_r2 核对
mBuffer，以 Android 8.0 / API 26 说明 native 像素的变化，并补充 GIMP 3.2.6 导入参数及现代调试入口。
在 MAT 里查图片相关的内存问题时，如果能知道“到底是哪张图”，排查起来会方便很多。这里的“原图”指 Bitmap 在运行时保存的像素，不能恢复下载前的 JPEG/PNG 文件、压缩参数或 EXIF。MAT 能帮我们找到是谁留着这个对象，再把图像和业务场景对应起来；单凭一个 Bitmap 很大，还不能判断它泄漏了。
本文介绍从旧 heap dump 导出像素的步骤。前提是快照确实包含像素数组；只有 Java 包装对象和 native 地址时，不能从不存在的数据还原图片。
本文是 MAT 工具使用系列的第二篇，这个系列共三篇，详细介绍了如何使用 MAT 来分析内存问题，既可以是 Java 应用的内存问题，也可以是 Android 应用的内存问题：
技术复核（2026-10-13）：保留 2015 年的操作截图，概念与菜单说明对照 MAT 1.17.0 文档。旧 Android Studio 的右键转换和 GC 按钮不代表当前界面；下文修正引用方向、Unreachable 和泄漏判定，并补上缺失的分析步骤。
抓取流程见本系列入门篇：先在 Android Studio Profiler 以 debuggable / complete data 模式获取 heap dump，再按需要导出给 MAT。自动化测试可使用 LeakCanary，但普通 leakcanary-android 依赖应放在 debug 构建；官方 2.14 文档里的 release 分析方案仍标为实验性质，不能把“接入 LeakCanary”直接当成通用线上采集方案。UI 测试集成 / release 方案
下面是早期 Android Studio 的抓取界面，保留作为历史记录：
本文是 MAT 工具使用系列的第一篇，这个系列共三篇，详细介绍了如何使用 MAT 来分析内存问题，既可以是 Java 应用的内存问题，也可以是 Android 应用的内存问题：
技术复核（2026-10-13）：本文保留原教程和历史截图。MAT 的堆分析概念仍适用；旧 Eclipse/DDMS 抓取流程已过期。下载与运行要求更新到 MAT 1.17.0（2026-06-10，独立版要求 Java 21+），并修正 ART、Bitmap、Retained Size 和引用类型说明。
现在可以先在 Android Studio Profiler 抓取 Java/Kotlin heap dump，再按需要导出给 MAT 分析。Android 内存泄漏也可用 LeakCanary 辅助定位。MAT 主要回答托管堆中的对象为何仍被保留；进程总内存和 native 分配还要结合 dumpsys meminfo、native allocation recording 或 Android 10+ 的 Perfetto heapprofd。后者在 user 系统上要求应用允许 debuggable 或 profileable，不能任意采集其他应用。
MAT(Memory Analyzer Tool)，一个基于 Eclipse 的内存分析工具，是一个快速、功能丰富的JAVA heap分析工具，它可以帮助我们查找内存泄漏和减少内存消耗。使用内存分析工具从众多的对象中进行分析，快速的计算出在内存中对象的占用大小，看看是谁阻止了垃圾收集器的回收工作，并可以通过报表直观的查看到可能造成这种结果的对象。
MAT 有 Eclipse 插件和独立的 Eclipse RCP 应用。独立版不要求先安装完整 Eclipse IDE，但仍需要兼容的 Java 运行环境。Android HPROF 是否需要转换，取决于导出格式和分析器支持，不取决于 MAT 是插件还是独立安装。
本文是一篇译文，原文Android Performance Case Study Follow-up的作者是大名鼎鼎的Romain Guy。本文讲述了Android性能优化的一些技巧、方法和工具。
技术复核（2026-10-13）：保留 2015 年 Falcon Pro 3 / Moto X 2014 的历史案例，以下第一人称属于原作者。Tracer for OpenGL ES、Hierarchy Viewer 所在的 Android Device Monitor 已在 Android Studio 3.1 弃用、3.2 移除；旧工具步骤标为历史内容，文末补充 Android 12+ 的 Perfetto 分析入口。原站链接本次未能重新读取，技术修订依据文中列出的官方资料和版本化源码。
两年前，我发表了一篇名为Android Performance Case Study 的文章，来帮助Android开发者了解需要使用什么工具和技术手段来确定、追踪和优化性能问题。
那篇文章以一个Twitter客户端 Falcon Pro为典范，其开发人员为 Joaquim Vergès. Joaquim人不错，他允许我在我的文章中使用它的程序作为例子，并且快速处理了我发现的所有问题。一切都OK，直到Joaquim 从头开始开发Falcon Pro 3，前不久在他准备发布它的新应用的时候，他联系了我，因为他有一个和滚动相关的性能问题需要我来帮助他，这一次我依然没有源代码可以参考。
本文是一篇译文,这篇是这个系列的第五篇.讲述的是Android开发中遇到的一些好用的小技巧,或者一些实用的API,很多人都知道,但也有人不知道,记录下来,如果能帮助到大家,也是极好的.由于不是严格的博文,所以翻译也不那么严格,有些工具和类我也会经常用,所以我会根据自己的想法去写.有些地方作者并没有将这个工具的作用讲出来,我会补充上去.
技术复核（2026-10-13）：原文发表于 2014 年，本译文发表于 2015 年。旧 Support Library 链接改为 AndroidX；外部存储、缩略图和应用语言补充新版本用法。清除应用数据和数据库让出事务的副作用也在对应条目中明确说明。
本文是一篇译文,这篇是这个系列的第四篇.讲述的是Android开发中遇到的一些好用的小技巧,或者一些实用的API,很多人都知道,但也有人不知道,记录下来,如果能帮助到大家,也是极好的.由于不是严格的博文,所以翻译也不那么严格,有些工具和类我也会经常用,所以我会根据自己的想法去写.有些地方作者并没有将这个工具的作用讲出来,我会补充上去.
技术复核（2026-10-13）：这些 View/XML API 大多仍可用，但原文关于配置变化、裁剪和文件原子性的说明需要修正。Gradle 3.0 起默认启用 Daemon；
AtomicFile的实现则以下面的 Android 4.4.4 与 Android 16 源码对照说明。
本文是一篇译文,这篇是这个系列的第三篇.讲述的是Android开发中遇到的一些好用的小技巧,或者一些实用的API,很多人都知道,但也有人不知道,记录下来,如果能帮助到大家,也是极好的.由于不是严格的博文,所以翻译也不那么严格,有些工具和类我也会经常用,所以我会根据自己的想法去写.有些地方作者并没有将这个工具的作用讲出来,我会补充上去.
技术复核（2026-10-13）：原文发表于 2014 年，本译文发表于 2015 年。平台
android.app.Fragment在 API 28 弃用，下面的 Fragment 建议改用 AndroidX；LocalBroadcastManager 与 Otto 已停止维护。其余条目保留原顺序，并补充 API 版本和使用边界。
技术复核（2026-10-13）：这是一篇 Nexus 5 / Android Lollipop 的历史教程，设备与工具链已过期。文中的 LRX22C 二进制对应 **Android 5.0.1 / AOSP
android-5.0.1_r1**，下文据此明确源码、驱动和刷机条件。新学习环境另补 Android 16 Cuttlefish 示例；不要把新版本的构建命令与旧真机固件混用。
接前一篇文章使用Android Studio查看Android Lollipop源码, 我们知道,仅仅看代码,提高是比较有限的,而且理解起来也比较肤浅,往往过目就忘. 而自己写过的代码,往往会印象比较深刻,在写的时候也会比较容易理解流程. 所以我们在看代码的同时, 如果能修改代码, 在手机上跑起来并看到修改的效果,这无疑会加快看代码的效率和积极性. 所以这篇文章,就讲解一下如何自己编译AndroidL的源码,并且在Nexus5上跑起来. 至于为何需要自己编译固件，而不是直接安装 Google 给出的工厂固件？这里的目的是获得便于平台调试的 userdebug 构建。user 版本限制 ADB root 等调试能力；userdebug 支持更多调试操作，但并不等于任意分区都能不受限制地写入。
本文假设你已准备好版本一致的 Lollipop 源码和一台 Nexus 5。环境可参考 旧版本 AOSP 构建说明和源码下载说明。Android 5.x 在 Linux 上使用 OpenJDK 7；旧系统与依赖应放在专门的历史构建环境中，不能直接作为当前开发机的安装建议。如果访问官方文档或下载源码不顺畅，需要先处理网络与源码获取环境。
AOSP 是 Android Open Source Project，即 Android 开源项目。它包含平台和开源应用，不包含 Google Mobile Services（GMS）这组专有应用与服务。厂商二进制、GMS 授权和 Android 兼容性是不同问题：满足 CDD 并通过 CTS 是兼容性要求，不等于自动获得 GMS。具体要求可以参见 Android 兼容性说明。
技术复核（2026-10-13）：本文原写于 2015 年。Systrace 的事件时间线仍有参考价值，Eclipse / Device Monitor 入口已过期；旧脚本参数以下文核对的 AOSP
android-5.0.0_r1为准。新增命令以 Android 11 / API 30 及以上的 Perfetto 为例，旧系统差异另列。后续文章见 Android Perfetto 系列目录。
| 旧流程 | 现在的对应方式 |
|---|---|
| Eclipse / Device Monitor 的 Systrace 按钮 | Android 9 / API 28 起可用设备端 System Tracing；也可通过 ADB 采集 |
systrace.py 调用 atrace 并生成 HTML |
Perfetto 采集命令生成二进制 trace；具体事件由类别或配置文件决定 |
| 浏览器直接打开旧 HTML | 使用 Perfetto UI 导入 trace，也可用 Trace Processor 做 SQL 分析 |
| 把 user 构建理解为不能采集 | user 构建可以采集系统 trace；可见数据取决于系统、数据源、应用配置与厂商策略 |
本文是Android性能优化工具系列的第一篇，这个系列主要介绍Android性能优化过程中会使用到的一些工具，以及如何用这些工具来发现问题和解决问题。在性能优化方面，Android有不少性能工具供大家来使用，按照我们一贯地 “发现问题-解决问题”的思路来看，发现问题才是最主要的，一上来就想着如何去解决问题，反而会事倍功半。
这一篇先来简单介绍一下Systrace这个工具。
Systrace 随 Android 4.1 / SDK Tools R20 推出，是系统事件跟踪与可视化工具。它把 CPU 调度、SurfaceFlinger、WindowManager、View 等已启用的事件放到同一条时间线上，帮助开发者寻找系统行为之间的关系。它不会自动采样每一个 Java 方法，也不等于完整调用栈分析器。当年的 SDK Tools R20 公告
旧流程主要由三部分组成：
atrace 配置类别并读取跟踪数据。应用添加自己的区间可使用 android.os.Trace.beginSection() / endSection()；这组公开 API 从 Android 4.3 / API 18 才提供，不是从 Android 4.1 就能直接调用。systrace.py 通过 ADB 调用设备的 atrace，处理数据并生成带查看器的 HTML。采集已有系统事件不要求先修改应用代码；只有自定义业务区间需要相应埋点。当前 Perfetto 还能接入更多数据源，不能把它的全部功能概括为 ftrace 封装。android.os.Trace 的标记仍可被 Perfetto 读取，接口说明见 Trace 和 Perfetto ATrace 文档。
技术复核（2026-10-13）：原文面向 Android 5.0 Lollipop 与 Android Studio 1.x。下面的 IDEGen 流程已按 AOSP
android-5.0.0_r1源码核对，属于历史方案；新增的 AIDEGen 示例以android-16.0.0_r1文档为准。
作为Google的亲儿子,Nexus手机系列所收到的待遇大家有目共睹.Android5.0出来之后,Nexus5第一时间就升级到了最新的系统.那么作为Google亲儿子的Android Studio同样备受Google的重视,我也是第一时间从Eclipse转投到了Android Studio的怀抱中,从最初的测试版本一路升级到现在的1.0正式版本.
上一篇文章从理论的角度讲解了一下什么是过度绘制，以及可以用来查看和确认过度绘制的工具，还提供了一些优化过度绘制的方法。对代码和布局比较熟悉的人，看完上一篇其实就已经可以对自己的应用进行优化了。我记得有人说过，用iphone你只需要保证苹果有节操即可，用Android你就得保证所有的Android开发者都有节操。但现实是残酷的，现在Android市场上，有很多粗制滥造的应用，其中不乏大厂之作，各位打开过度绘制按钮，就知道我所言非虚。作为一个Android开发人员，我肯定是更希望Android能一步一步好起来，超越iphone。
这篇文章从实战的角度，讲解了一个过度绘制的优化过程。当然这里用到的只是很少的一部分，毕竟每个应用差别很大，优化方式也各不一样。所以这篇文章仅供参考，想把这块做好还是要下功夫的。
如果没有看过前一篇，可以点这里：Android性能优化之过度绘制(一)
2026-10-13 更新：本文原写于 2014 年，源码节选已对照 AOSP
android-4.4.4_r2。Overdraw 的概念仍适用，ADT、monitor、Hierarchy Viewer 和旧 OpenGL 跟踪入口已过时；Android Studio 3.1 起改用 Layout Inspector 查看层级，帧时序使用 Perfetto。下文保留历史源码，并补充 Android 12 / Android 16 的对应边界。
博客有一段时间没有更新了，到了新公司后，一直比较忙，博客也更新地不那么频繁了。最近一直在看Android上和性能相关的部分，也就是所谓的Android性能优化，才发现Android性能这一块，自己懂得还是太少了，所以从上层开始看，也算是一点一点入门吧。这个系列将讲解学习过程中总结的和性能相关的内容。
先讲讲 GPU 过度绘制，也是开发者最直接接触的部分吧。这个内容分两篇来讲：第一篇讲原理和一些优化建议，第二篇用实际例子来看一般的优化步骤。
GPU 过度绘制（Overdraw）指同一帧内，一个像素被绘制多次。例如 TextView 先画背景再画文字，文字覆盖到的像素就可能参与两次绘制。多余的像素着色、混合和内存访问会消耗资源，但是否造成掉帧，取决于绘制面积、透明度、GPU 能力以及这一帧的其他工作，不能仅凭颜色数量判断。Android 过度绘制说明
2026-10-13 核查：这个方法适用于传统 Android View 布局，所用焦点属性从 API 1 起可用，仍然有效。但输入焦点和软键盘可见性是两个状态，不能保证加上两个属性后键盘在所有场景都不弹出。
Android中,使用EditText作为输入框很方便,但是有时候EditText会自动获取焦点,其行为:点击进入这个页面后,EditText自动获取焦点,导致软键盘直接跳出.有时候这么做很方便,但是大部分时候我们还是希望在点击EditText的时候,软键盘才弹出来.
2026-10-13 核查：本文是 2014 年的 View/系统工具 API 清单。
Activity.onBackPressed()从 API 33 废弃，文字布局应优先使用 API 23 起的 Builder；下面补充替代方式，并修正闹钟、应用内存和屏幕密度的解释。
本文是一篇译文,这篇是这个系列的第二篇.讲述的是Android开发中遇到的一些好用的小技巧,或者一些实用的API,很多人都知道,但也有人不知道,记录下来,如果能帮助到大家,也是极好的.由于不是严格的博文,所以翻译也不那么严格,有些工具和类我也会经常用,所以我会根据自己的想法去写.有些地方作者并没有将这个工具的作用讲出来,我会补充上去.
2026-10-13 核查：这份清单原写于 2014 年，主要面向 Android View 系统。多数 API 仍然有效；旧版
Html.fromHtml(String)从 API 24 废弃，下面补充替代签名，并修正缓存目录、布局加载和动画反向播放的说明。
本文是一篇译文,这篇是这个系列的第一篇.讲述的是Android开发中遇到的一些好用的小技巧,或者一些实用的API,很多人都知道,但也有人不知道,记录下来,如果能帮助到大家,也是极好的.由于不是严格的博文,所以翻译也不那么严格,有些工具和类我也会经常用,所以我会根据自己的想法去写.有些地方作者并没有将这个工具的作用讲出来,我会补充上去.
2026-10-13 更新：2014 年版本直接向外部存储根目录写文件，这种用法已过时。Android 10（API 29）引入分区存储，Android 11（API 30）对 targetSdk 30 及以上应用忽略
requestLegacyExternalStorage。下面改用应用内部目录，示例最低版本为 Android 4.4（API 19），不需要存储权限。Android 11 存储变化
Log2File 工具类用于 Android 程序把应用主动记录的日志写入文件，适合下面这些场景：
它只保存传给 w() 的内容，不会自动读取系统 logcat；系统日志抓取仍使用 Logcat 工具。
这篇文章最早发布在我的 CSDN 博客，后来迁移到这里。原 GitHub 源码地址在本次更新时返回 404，因此下面直接保留可阅读的替代实现。
2026-10-13 更新：本文记录的是 Android 4.3 之前通过无障碍事件观察通知的旧方案，这条通用通知中心实现路线已过时。Android 4.3（API 18）起提供专门的
NotificationListenerService，第 4 节补充 Android 7.0（API 24）及以上的最小监听示例。旧代码仅用于理解历史实现，不保证取得完整通知列表。
上一篇文章介绍了什么是 Accessibility 以及简单的使用，这一篇文章就来讲讲如何使用Accessibility服务来创建一个简单的Android通知中心。Android中通知中心是一个系统层面的服务，负责显示应用和系统发来的通知（Notification，比如USB插入、选择输入法、未接来电、截图、天气信息、新闻推送等等）。在android4.3之前，一般的第三方应用是无法获取Notification list的（在Android4.3之后，有了一个新的接口,NotificationListenerService.getActiveNotifications(),可以获取当前的Notification）。但是利用Accessibility服务可以监听到各种事件的特性，可以开发一个第三方的通知中心，实现与系统通知栏类似的功能。
这篇写于 2014 年，当时用的是 Nokia X 和旧版 Android SDK。2026-10-13 更新了 Ubuntu 24.04 LTS 下的 udev 和用户组配置；旧
SYSFS规则、Upstart 重启方式已经不适用，adb_usb.ini的办法留在文末作历史记录。
最近开发Nokia项目，遇到的问题如下：
插入Nokia x后，电脑没有反应，即不识别，同事的windows也不识别，最后在谷歌上搜索了良久，才找到了解决方案，但是没有记录，后来又要给别人配置的时候，发现忘记怎么配置了。想想这也是一个具有通性的问题，还是记录下来，分享给大家。
先在设备上开启 USB 调试，并使用支持数据传输的 USB 线。用 adb version 确认调用的 Platform-Tools 版本，再运行 adb devices -l 查看设备状态。
no permissions：优先检查 Linux 的 udev 规则和当前用户组。unauthorized：设备已经被发现，解锁设备并确认 RSA 调试授权弹窗。offline：设备未正常响应 ADB；重新插拔或重启 ADB 后再观察。2026-10-13 更新：本文原写于 2014 年，介绍 Android 4.0（API 14）起的无障碍服务配置。无障碍服务本身仍然有效，但用它实现通用通知中心的路线已过时；Android 4.3（API 18）起应使用专门的 NotificationListenerService。下文修正服务声明和示例，并补充 Android 13（API 33）的节点回收变化。
辅助性服务（现通常称无障碍服务）用于帮助残障用户或暂时无法正常操作设备的用户使用应用，例如将界面文本读出来，或者提供触觉反馈。这一节介绍如何创建服务、接收界面事件和查询节点信息。
AccessibilityService 由系统在用户授权后绑定，不能当作普通后台任务服务来启动。下面给出服务骨架和几个方法的写法；接进自己的应用时，还需要补上语音引擎、设置界面和应用资源。服务生命周期与配置