在没有排序或额外索引的数组、链表中，按值查找最坏需要遍历全部元素。哈希表（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 是插件还是独立安装。
