【写在该系列之前】
该系列为索尼关于智能手机触摸屏的文章，共四篇，对Android智能手机触摸体系做了系统并详细的说明。
注1：虽然做了翻译，但还是认为原文更准确，若可以，请大家移步原文：http://developer.sonymobile.com/tag/touch/
注2：若有错误，肯请大家指正，先行谢过。
（二）理解触摸响应
理解触摸响应
这是我们触摸屏技术系列中的第二篇文章。在前一篇文章中，我们解释了触摸屏系统的组件和这些组件如何将一个触摸输入转换成图形化用户反馈。在这篇文章中，我们将继续触摸响应话题，并且解释在触摸时所遭遇的触摸滞后。继续阅读，获取更多详细信息。
什么是触摸响应
触摸响应是指 为用户从设备获取反馈作为输入结果所花费的时间。在我们的特殊情况中，这意味着来自触摸硬件的触摸事件和在显示屏上的帧更新。具体来说，触摸响应是 从用户按下触摸板直到一个应用程序更新它的UI以致其在屏幕上显示 的时间。
由于设备系统的许多部分更倾向于触摸响应的另一个名字“系统延时”，因此“系统延时”将是一个更合适的描述。因此，它实际上就是用户感受到的系统延时，不仅仅是触控相关配件。通常，触摸硬件被当成造成系统延时的罪魁祸首。事实上，它在系统延时中只占很小部分。
为什么触摸响应很重要？
触摸响应直接关系到终端用户，比如游戏，刷新列表火管理启动器应用。即使用户没有注意到（或者不在意）系统延时，但延时短则用户体验更好，这就是为什么它对提高设备响应度如此重要的原因。更少的系统延时，设备将更流畅和快速。
我
们认为有三种不同的延时对触摸体验来说非常重要——点击延时，初始化移动延时，和移动延时。点击延时是 来自“touch up” 或“touch
down”事件的时间——当用户从触摸平板上抬起（或按下）一指，直到显示屏上显示一些东西 作为此次事件的回应。初始化移动延时是
从首次“move”事件到显示屏上显示一些东西作为此次事件回应。最后，移动延时与初始化移动延时相同但在更换手势（swiping
gesture？？）后测量。
触摸生态系统的定时（timing）解析
在
触摸事件处理中的所有步骤都需要花费时间，并且均有助于整个系统延时。尽管某些部分比其他花费时间更长，触摸生态系统中的延时依赖与当前活动的应用程序和
不同的定时机制而变化。在下列几个部分中，我们将了解系统中有助于延时的各个部分（用一个非常简单的使用场景）。该生态系统组件已在上一篇文章有描述。
一个非常简单的使用场景——一个正在运行的Android应用程序
一
个简单的使用场景是 当我们有一个正在运行着的Android的应用程序。我们的示例程序响应触摸输入 并且当 监测到一个 “touch down
action”
，在应用程序的View中画一个白色四边行。在Android中一个View公开一个接口去访问图形布局和绘制表面。以下讨论基于该使用场景。
系统延时概述
结合时序详细信息解析触摸生态系统
在Android 体系中， 上图通常代表全部的系统延时。上图的值在Android版本Jelly Bean测量出来。在触摸系列接下来的文章中我们将解释如何测量这些不同的部分。
触摸面板
检测点（通常是手指），触摸集成电路扫描通道连接到传感器。这就允许 该集成电路按照大概60Hz到120Hz 生成事件，这是现今移动设备通用报告速率。
有时当信号噪声非常大，如果点的位置不能被确定，触摸集成电路可能需要重新扫描面板。这会降低报告速率，尽管这不应该在一个精心调校过的系统上发生。这在所有电容式触控面板的移动设备上很常见。
一个60Hz电容触控集成电路每16.67ms（1/60s）生成一次事件。如果一个按下恰好在前一次传感器后，这可能导致两个整个扫描的时间，意味着增加到最大34ms的延时。
举例说明来自面板的最大延时，如下所述：
1、从面板顶部到底部扫描笼统的扫描；
2、用户轻敲事件恰好发生在扫描了面板顶部之后。触控集成电路需要扫描面板余下的部分。这采用一个0到16.667ms的延时，包括固件处理。该点还未被检测到。
3、新一次扫描，该点在此次扫描中将被检测到。包括固件处理，延时将是16.667ms。
4、扫描完毕——固件处理数据并将它们发送给主机系统。
固
件扫描花费时间取决于触摸电路上的信道数和激活的滤波器算法的数量。触控集成电路滤波器地址的问题例如噪声、线性度和抖动，并且依赖与从硬件实现的信号电
平（the signal
level）来激活。当然，使能多点触控会增加固件处理时间，来自增加的数据。如果触控集成电路CPU不够强大，报告速率可能降低。
如果我们用一个能以120Hz运行的触控集成电路，扫描时间是8.33ms，意味着我们能够几乎减少近乎触控面板近乎一般的延时。最坏情况下将是16.667(8.33*2)。
触控面板睡眠模式
当
触控面板一段时间不使用，它常常降低到睡眠模式来节省电量。睡眠模式在触控面板能够发送响应给Android系统前会增加更多时间。这额外的时间由触控面
板减少扫描速率到5Hz到20Hz导致，该扫描率依赖于生产厂家在设计阶段的决定。这增加一个另外50ms到200ms给轻敲延时和初始化点击延时。有时
人们错误地说这种长唤醒延时是由于错误的触控解决方案，而它事实上是一个用以减少电流消耗的清醒决定。
正常与降低扫描模式
正常和降低扫描是两种不同的从触控面板获取数据时可以使用的模式。正常模式以在设计中决定好的的速度扫描触控面板传感器。因此如果触控传感器工程师指定一个最佳扫描速率
60Hz，
只要有一个手指或者其他导电物体存在，触控面板传感器一直以60Hz扫描。相反，当一个手指存在并且不移动时，降低扫描模式降低扫描速率。当监测到用户触
摸，在此例中上报速率增加到60Hz，并且只要用户移动手指就一直处于该数值。当手指停止，上报速率降低直到它重新开始移动。
而设置触控集成电路以降低模式扫描来节省电量，缺点是长延时——如果在触控面板上用户手指暂停并且随后又开始生成事件，例如移动手指。
主机触控驱动延时
主机触控驱动延时来自作用于总线产生的终端，读取数据，组装数据转换成操作系统特定触摸事件 和 在操作系统内核队列中发布数据。50 bytes 是一个用来计算延时的合理数字。50 bytes（400bits）在400kHz
I2C bus由主机触控驱动花费1ms来读取（400bits/400000bits/s = 1ms）。然后这些数据被组装和处理。除此之外，操作系统特定行为例如上下文交换进场（comes into play）。
总而言之，在主机驱动中一个点的延时大约2到3ms是合理的。不得不（having to ??）处理多个点（多点触控）增加延时。
事件和窗口管理
高
级操作系统（或
窗口框架）的事件管理器读取由主机驱动发布的触控事件。在我们的场景中，这由Android完成。Android中的事件管理器不是系统延时的一个大的贡
献者，它花费很少毫秒（如下图）去处理和运输事件给正确的目标，在Android场景中，这些目标将是一个Activity，View和
（或）ViewGroup。在Android中许多部分关系到事件传输，这些事件传输被作为观察者模式实现。这意味着这些观察者待用直到它们注意到有一个
事件到来。另一个延时因子是这些事件将穿过几个不同线程到达它们的最终目的地。当这些事件在一个线程中被处理时，它需要被操作系统调度程序切换去执行
（it needs to be switched in by the operating system scheduler to be
executed）。
直到Android JB（Jelly Bean）版本，一个叫做Choreographer的机制被作为事件管理器的一部分被介绍。Choreographer影响延时，如下所述。
Choreographer和延时
当
Choreographer
接收一个垂直同步（VSYNC）信号通知，它调用事件分布给事件目标们。此机制给应用程序们在下一帧前更可能多的时间去处理和绘制他们的内容。然而，当来
自于触摸输入的触控事件创建和VSYNV不一致时，这可能导致更多延时。在定时坏的的情况下（in case the timing is
bad??），假设在触控面板上一个60Hz频率，这将增加一个附加帧，或者16.667ms延时。
SLOP
SLOP
是用于定义作为一个实际的运动的运动的阈值。在实践中，人们将需要前一个“移动”事件将被发送移动手指的像素数。这增加了感知的初始延时，因为任何移动的
对象将进一步落后。有SLOP阈值的理由是为了防止来自输入数据中的任何抖动。例如，如果因为一个像素的变化就发送一个移动事件，我们就永远无法点击或按
任何东西，因为所有触摸都将被视为移动。在1080p分辨率5英寸显示屏上，一个像素非常小，约58μm。
应用程序
应用程序增加的时间变化很大，并且花费两个大步骤上：
1、执行一些应用程序逻辑响应接收到的触摸事件；
2、绘制和更新用户接口（UI：user interface）
这些步骤中，应用程序们使用的变化从小于1ms到，在真实灾难性的情况下，几百毫秒。一个重要数字不要超过1/60Hz，意即16.67ms，这有两个理由：
1、如果一个应用程序每一次事件花费超过16.67ms做处理和绘制，它错过 frame/VSYNC并且不得不等下一次VSYNC再增加另一个16.67ms到延时。更多帧被丢失，则产生更多延时。
2、
打破16.67ms边界意味着应用程序可能不能达到每秒60帧的速度。这将致使掉帧引起在图像渲染时不平滑导致非常糟糕的用户体验。每秒60帧要求来自于
一个事实：
现今所有智能手机显示屏有一个平均内部刷新率约60Hz。因此这是能够显示给用户的帧率最大值。为了不掉帧应用程序刷新率必须等于或者高于该值。
图像合成器
图
像合成器是一个进程，该进程可以将多个内容表面组装成一个单帧。在Android中，图像组装器和管理帧缓存会花费很多时间，即使是在一个简单用例中。在
图像合成phase的许多步骤直接与VSYNC绑定，这意味着 in the flow risk
更多步骤花费时间等待。关于此的例子可以在下面的system trace中被看出。
在图像合成中直接绑定VSYNC等待的步骤包括：
- 使无效（告知系统该帧需要更新）
- 绘制（意味着实际绘制和交换缓存）
- 在MDP（移动显示处理器）上的层组装
- 内核帧发布到显示屏
意思是需要VSYNC定时必须被忽略，这将大大有助于延时。我们测试了在一个单独的SurfaceFlinger中处理超过40ms的延时。学习更多在Android中图像组装如何工作：https://source.android.com/devices/graphics.html。
分辨率
显
示分辨率也是另一个有助于延时的因子。一个低的分辨率转换被CPU和GPU更少处理，并更少数据通过和复制到系统。我们的测量指出至少一个20ms不同在
一个720p(720*1280 pixel)和一个1080p（1080*1920 pixel）分辨率。在一个qHD（540*960
pixel）和1080p（1080*1920 pixel）之间的不同约30ms。
系统跟踪事件到图像管理器
为了理解系统事件当接收到一个触摸事件，我们需要做一些 tracing：http://en.wikipedia.org/wiki/Tracing_%28software%29。下面是一个我们前文提到的非常简单的使用场景的系统跟踪。
系统跟踪插图
如上图所示，一些相关线程从系统跟踪会话中被显示出来。下面，这张图详细描述了从Android framework读取输入事件那里发生了什么 到
一帧在哪里被graphics framework组装并准备发送到显示驱动。我们已经排除了那些
触控集成电路扫描传感器和最终有显示驱动处理渲染后的帧并显示它自己的部分。
1、
Android系统读取事件并分发它到事件管理框架（the event management
framework）。这花费2到3ms。下一步，该事件被Choreographer接收，并如图中所示，它是一个很长的时间直到下一次VSYNC来
临。注意输入事件创建与VSYNC无关在它之中，它可以在前一个VSYNC之间的任意时间来临，依赖于上报速率。因此此处延时变化与整个VSYNC定时有
关（So the latency here can vary with a whole VSYNC timing）。
2、当Choreographer接收到VSYNC信号是，它分发输入事件给目标，在此场景中是我们的应用程序。
3、CPU0当前处于忙碌状态并且要求一个 couple of milliseconds直到应用程序开始处理该事件。注意这实际上是4核CPU（ a quad-core(4) ）系统但是其中的三个当前处于下线状态。
来自我们系统跟踪会话的额外相关线程
4、现在测试应用程序做基本绘制——在一个黑色背景上的一个用2D API绘制的白色四边行。当一次绘制完成，该表面被标记为脏（已改变）并告知 graphics framework：它应该在一次来临的显示帧更新 和任何其他已改变的表面组装。
5、graphics framework接管并组成改变后的表面，结合所有其他表面完成最终一帧。当一个新VSYNC定时被检测到这将首先开始，因此该测试应用程序在噶VSYNC之前必须准备好。否这，我们将得到一个丢帧。
6、下一步，VSYNC来临并且触摸显示驱动能够更进一步处理已完成的帧。
主机显示驱动
主
机显示驱动是一个介于基于帧缓存的组装帧和由Android
framework提供的overlays间实例。它的角色是提供数据，因此这些数据可以通过MIPI DSI
总线传输并显示。我们的延迟的测量表明，相对于系统的其余部分，通常采取几毫秒来处理数据此处所用的时间是相当有限的。
显示屏
至于延时，这儿有两个方面我们需要考虑到。第一是它为了物理材料作出响应实际需要花费的时间。有几种不同的显示技术，例如 LCD with
sub-catagories，VA，TN，和IPS。这些都基于液晶（liquid
crystals）。另一种常见的显示技术是基于发光化合物的OLED。
LCD显示屏在延时上有很大的不同，范围介于2ms和100ms之间，这取决于其所用的颜色和LCD类型。另一方面，OLED显示屏非常快并具有微秒的延时。
另一个方面是显示器的内部刷新时间。现今，移动设备显示器具备的内部刷新率约60Hz
，转化后约16.67ms更新整个显示屏。
显示屏特写，它展示了当渲染一个新帧是刷新的发生。
上图刷新发生在显示屏上当渲染一个新帧时——当显示器被触摸时，颜色渐变反转。在该图中，右侧显示的是完全反转，单左侧不是，展示出显示屏的继续刷新通常需要花费16.67ms来完成。
在
一个 RAM-less 显示屏中，没有额外的延时或者等待状态，因为来自设备平台的数据必须持续地被传输并且该显示屏将由此流更新。在一个
RAM-base
的显示屏中，最新一帧被存储到显示屏的内存中，在它能够被显示之前以便有一个以上的buffer去装载。通过这种方式，我们增加一个帧更新延
时，16.67ms（This way, we add one more frame update to the latency , which
is 16.67ms）。
***
至此关于系统延时和触控响应的文章就结束了。在下一篇文中中，我们将继续相关触控话题的覆盖采样。
更多信息