EN

loading
Android 性能优化典范之 Understanding Overdraw

系列文章目录:

  1. Android性能优化典范综述
  2. Android性能优化典范之Render Performance
  3. Android性能优化典范之Understanding Overdraw
  4. Android性能优化典范之Understanding VSYNC
  5. Android性能优化典范之Profile GPU Rendering

技术复核(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!

Overdraw(过度绘制) 指同一帧里,同一个像素被重复绘制。例如下面重叠的卡片,不透明卡片下面被完全遮住的部分可能做了无用功;但不能把“发生重叠”一律视为浪费。半透明内容、阴影和抗锯齿边缘仍需要底下的颜色参与混合,直接删掉底层会改变画面。实际工作量也受裁剪和渲染器优化影响。官方概念说明

Android 性能优化典范 - Render Performance

系列文章目录:

  1. Android性能优化典范综述
  2. Android性能优化典范之Render Performance
  3. Android性能优化典范之Understanding Overdraw
  4. Android性能优化典范之Understanding VSYNC
  5. Android性能优化典范之Profile GPU Rendering

技术复核(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.

Android渲染知识

当你觉得自己开发了一个改变世界的应用的时候,你的用户可能并不会这么认为,他们认为你的应用又慢又卡,达不到他们所期望的那种顺滑,更谈不上改变这该死的世界了,回收站走你!等等!明明我这个应用在我的Nexus5上非常顺滑啊?你咋能说又慢又卡呢?如果你对Android的碎片化有一定了解的话,你就应该知道,很多低配置的手机并不像Nexus5那样有强大的处理器和GPU,以及没有被怎么污染的原生系统。

如果有大量的用户投诉说你的应用又卡又慢的时候,不要总是抱怨用户的低端手机,有时候问题就出在你的应用本身,可能涉及渲染、主线程阻塞等问题,需要先测量再定位。了解问题发生的根源,才能有效地解决问题。所以了解Android渲染相关的知识,是一个Android开发者必不可少的知识。

Android 性能优化典范综述

系列文章目录:

  1. Android性能优化典范综述
  2. Android性能优化典范之Render Performance
  3. Android性能优化典范之Understanding Overdraw
  4. Android性能优化典范之Understanding VSYNC
  5. Android性能优化典范之Profile GPU Rendering

2015 年,Google 推出了关于 Android 性能优化的短视频系列 Android Performance Patterns,原播放列表在 YouTube。官方当年的配套课程介绍也记录了这个系列。

Android性能优化典范

技术复核(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应用的时候,知道该用什么工具,该采取什么样的步骤,需要达到什么样的目标。

Android 内存优化之三 - 打开 MAT 中的 Bitmap 原图

本文是 MAT 工具使用系列的第三篇,这个系列共三篇,详细介绍了如何使用 MAT 来分析内存问题,既可以是 Java 应用的内存问题,也可以是 Android 应用的内存问题:

  1. Android 内存优化之一:MAT 使用入门
  2. Android内存优化之二:MAT使用进阶
  3. Android内存优化之三:打开MAT中的Bitmap原图

技术复核(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 地址时,不能从不存在的数据还原图片。

Android 内存优化之二 - MAT使用进阶

本文是 MAT 工具使用系列的第二篇,这个系列共三篇,详细介绍了如何使用 MAT 来分析内存问题,既可以是 Java 应用的内存问题,也可以是 Android 应用的内存问题:

  1. Android 内存优化之一:MAT 使用入门
  2. Android内存优化之二:MAT使用进阶
  3. Android内存优化之三:打开MAT中的Bitmap原图

技术复核(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 方案

Java的内存泄露的特点

  • Java 内存泄漏常见的特征是:可达,无用。对象还被保留着,业务上却已经用不到了。
  • 需要把对象的预期生命周期与实际保留它的引用路径对照,不能只看对象大不大、数量多不多。
  • 可以复用却反复创建对象,会增加分配和 GC 开销;如果旧对象能正常回收,这是分配浪费,不一定是泄漏。OOM 也可能来自一次过大的正常分配。

MAT使用技巧进阶

使用Android Studio Dump内存文件

下面是早期 Android Studio 的抓取界面,保留作为历史记录:

Android Studio 历史抓取界面

Android 内存优化(1) - MAT 使用入门

本文是 MAT 工具使用系列的第一篇,这个系列共三篇,详细介绍了如何使用 MAT 来分析内存问题,既可以是 Java 应用的内存问题,也可以是 Android 应用的内存问题:

  1. Android 内存优化(1) - MAT 使用入门
  2. Android 内存优化(2) - MAT使用进阶
  3. Android 内存优化(3) - 打开MAT中的Bitmap原图

技术复核(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简介

MAT介绍

MAT(Memory Analyzer Tool),一个基于 Eclipse 的内存分析工具,是一个快速、功能丰富的JAVA heap分析工具,它可以帮助我们查找内存泄漏和减少内存消耗。使用内存分析工具从众多的对象中进行分析,快速的计算出在内存中对象的占用大小,看看是谁阻止了垃圾收集器的回收工作,并可以通过报表直观的查看到可能造成这种结果的对象。

image

MAT 有 Eclipse 插件和独立的 Eclipse RCP 应用。独立版不要求先安装完整 Eclipse IDE,但仍需要兼容的 Java 运行环境。Android HPROF 是否需要转换,取决于导出格式和分析器支持,不取决于 MAT 是插件还是独立安装。

Android性能优化后续

前言

本文是一篇译文,原文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 小技巧 - 4

本文是一篇译文,这篇是这个系列的第四篇.讲述的是Android开发中遇到的一些好用的小技巧,或者一些实用的API,很多人都知道,但也有人不知道,记录下来,如果能帮助到大家,也是极好的.由于不是严格的博文,所以翻译也不那么严格,有些工具和类我也会经常用,所以我会根据自己的想法去写.有些地方作者并没有将这个工具的作用讲出来,我会补充上去.

技术复核(2026-10-13):这些 View/XML API 大多仍可用,但原文关于配置变化、裁剪和文件原子性的说明需要修正。Gradle 3.0 起默认启用 Daemon;AtomicFile 的实现则以下面的 Android 4.4.4 与 Android 16 源码对照说明。

Android 性能优化之 Systrace 工具介绍(一)

技术复核(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 简单介绍

Systrace 随 Android 4.1 / SDK Tools R20 推出,是系统事件跟踪与可视化工具。它把 CPU 调度、SurfaceFlinger、WindowManager、View 等已启用的事件放到同一条时间线上,帮助开发者寻找系统行为之间的关系。它不会自动采样每一个 Java 方法,也不等于完整调用栈分析器。当年的 SDK Tools R20 公告

旧流程主要由三部分组成:

  • 内核事件:依赖内核已启用的 ftrace 功能和可访问的事件。调度、I/O、频率等类别的可用性要在设备上确认。
  • 用户态标记与采集:系统组件通过 ATrace 写入标记,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 文档。

使用 Android Studio 查看 Android Lollipop 源码

技术复核(2026-10-13):原文面向 Android 5.0 Lollipop 与 Android Studio 1.x。下面的 IDEGen 流程已按 AOSP android-5.0.0_r1 源码核对,属于历史方案;新增的 AIDEGen 示例以 android-16.0.0_r1 文档为准。

Android Studio

作为Google的亲儿子,Nexus手机系列所收到的待遇大家有目共睹.Android5.0出来之后,Nexus5第一时间就升级到了最新的系统.那么作为Google亲儿子的Android Studio同样备受Google的重视,我也是第一时间从Eclipse转投到了Android Studio的怀抱中,从最初的测试版本一路升级到现在的1.0正式版本.

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 过度绘制说明

Android 小技巧 - 如何让EditText不自动获取焦点

2026-10-13 核查:这个方法适用于传统 Android View 布局,所用焦点属性从 API 1 起可用,仍然有效。但输入焦点和软键盘可见性是两个状态,不能保证加上两个属性后键盘在所有场景都不弹出。

Android中,使用EditText作为输入框很方便,但是有时候EditText会自动获取焦点,其行为:点击进入这个页面后,EditText自动获取焦点,导致软键盘直接跳出.有时候这么做很方便,但是大部分时候我们还是希望在点击EditText的时候,软键盘才弹出来.

Android 小技巧 -2

2026-10-13 核查:本文是 2014 年的 View/系统工具 API 清单。Activity.onBackPressed() 从 API 33 废弃,文字布局应优先使用 API 23 起的 Builder;下面补充替代方式,并修正闹钟、应用内存和屏幕密度的解释。

本文是一篇译文,这篇是这个系列的第二篇.讲述的是Android开发中遇到的一些好用的小技巧,或者一些实用的API,很多人都知道,但也有人不知道,记录下来,如果能帮助到大家,也是极好的.由于不是严格的博文,所以翻译也不那么严格,有些工具和类我也会经常用,所以我会根据自己的想法去写.有些地方作者并没有将这个工具的作用讲出来,我会补充上去.

Android 小技巧 - 1

2026-10-13 核查:这份清单原写于 2014 年,主要面向 Android View 系统。多数 API 仍然有效;旧版 Html.fromHtml(String) 从 API 24 废弃,下面补充替代签名,并修正缓存目录、布局加载和动画反向播放的说明。

本文是一篇译文,这篇是这个系列的第一篇.讲述的是Android开发中遇到的一些好用的小技巧,或者一些实用的API,很多人都知道,但也有人不知道,记录下来,如果能帮助到大家,也是极好的.由于不是严格的博文,所以翻译也不那么严格,有些工具和类我也会经常用,所以我会根据自己的想法去写.有些地方作者并没有将这个工具的作用讲出来,我会补充上去.

Android Tools - Log2File

2026-10-13 更新:2014 年版本直接向外部存储根目录写文件,这种用法已过时。Android 10(API 29)引入分区存储,Android 11(API 30)对 targetSdk 30 及以上应用忽略 requestLegacyExternalStorage。下面改用应用内部目录,示例最低版本为 Android 4.4(API 19),不需要存储权限。Android 11 存储变化

Log2File 工具类用于 Android 程序把应用主动记录的日志写入文件,适合下面这些场景:

  1. 无法连接电脑进行调试,例如 USB 口被 OTG 设备占用。
  2. 日志不容易实时抓取。
  3. Bug 出现很随机,需要保留操作过程中的记录。
  4. 其他自己脑补。

它只保存传给 w() 的内容,不会自动读取系统 logcat;系统日志抓取仍使用 Logcat 工具。

0.说明

这篇文章最早发布在我的 CSDN 博客,后来迁移到这里。原 GitHub 源码地址在本次更新时返回 404,因此下面直接保留可阅读的替代实现。

Android Service:开发自己的通知中心(2):辅助性服务实战

2026-10-13 更新:本文记录的是 Android 4.3 之前通过无障碍事件观察通知的旧方案,这条通用通知中心实现路线已过时。Android 4.3(API 18)起提供专门的 NotificationListenerService,第 4 节补充 Android 7.0(API 24)及以上的最小监听示例。旧代码仅用于理解历史实现,不保证取得完整通知列表。

1.辅助性服务实战介绍

上一篇文章介绍了什么是 Accessibility 以及简单的使用,这一篇文章就来讲讲如何使用Accessibility服务来创建一个简单的Android通知中心。Android中通知中心是一个系统层面的服务,负责显示应用和系统发来的通知(Notification,比如USB插入、选择输入法、未接来电、截图、天气信息、新闻推送等等)。在android4.3之前,一般的第三方应用是无法获取Notification list的(在Android4.3之后,有了一个新的接口,NotificationListenerService.getActiveNotifications(),可以获取当前的Notification)。但是利用Accessibility服务可以监听到各种事件的特性,可以开发一个第三方的通知中心,实现与系统通知栏类似的功能。

Android:Ubuntu 下执行 Adb 命令找不到设备

这篇写于 2014 年,当时用的是 Nokia X 和旧版 Android SDK。2026-10-13 更新了 Ubuntu 24.04 LTS 下的 udev 和用户组配置;旧 SYSFS 规则、Upstart 重启方式已经不适用,adb_usb.ini 的办法留在文末作历史记录。

1.问题概述

最近开发Nokia项目,遇到的问题如下:

插入Nokia x后,电脑没有反应,即不识别,同事的windows也不识别,最后在谷歌上搜索了良久,才找到了解决方案,但是没有记录,后来又要给别人配置的时候,发现忘记怎么配置了。想想这也是一个具有通性的问题,还是记录下来,分享给大家。

2.问题解决方案

先在设备上开启 USB 调试,并使用支持数据传输的 USB 线。用 adb version 确认调用的 Platform-Tools 版本,再运行 adb devices -l 查看设备状态。

  • 列表为空:检查线缆、接口、USB 调试开关,以及主机是否枚举到设备。
  • no permissions:优先检查 Linux 的 udev 规则和当前用户组。
  • unauthorized:设备已经被发现,解锁设备并确认 RSA 调试授权弹窗。
  • offline:设备未正常响应 ADB;重新插拔或重启 ADB 后再观察。

USB 枚举、主机访问权限和设备授权是不同环节。具体连接与状态说明参见 ADB 文档和设备连接指南。

Android Service:开发自己的通知中心(1):辅助性服务介绍

1 辅助性服务介绍

2026-10-13 更新:本文原写于 2014 年,介绍 Android 4.0(API 14)起的无障碍服务配置。无障碍服务本身仍然有效,但用它实现通用通知中心的路线已过时;Android 4.3(API 18)起应使用专门的 NotificationListenerService。下文修正服务声明和示例,并补充 Android 13(API 33)的节点回收变化。

辅助性服务(现通常称无障碍服务)用于帮助残障用户或暂时无法正常操作设备的用户使用应用,例如将界面文本读出来,或者提供触觉反馈。这一节介绍如何创建服务、接收界面事件和查询节点信息。

AccessibilityService 由系统在用户授权后绑定,不能当作普通后台任务服务来启动。下面给出服务骨架和几个方法的写法;接进自己的应用时,还需要补上语音引擎、设置界面和应用资源。服务生命周期与配置