指哪不打哪：滑动跟手度与卡顿的那些事

📱

测试系统版本

HarmonyOS 6.1.0.117 SP6

我先把系统版本交代清楚：目前是HarmonyOS 6.1.0.117 SP6，这是截止到现在最新的版本。我会把版本定在这里，后续不再升级，所有关于无障碍更新或新特性都不再纳入这次的测试范围。也就是说，我的一切体验和结论，都只对这个版本负责。屏幕朗读本身没有单独的版本号，是跟随系统一起推送的，所以这次聊的就是当前系统自带的屏幕朗读。

作为一个视障用户，拿到手机后最关心的，毫无疑问是屏幕朗读自身的基本功怎么样。先说总体感受。记得HarmonyOS刚发布、华为三折叠屏那会儿，我就去店里摸过，当时屏幕朗读还存在比较明显的卡顿。这一次隔了差不多一两年重新上手，滑动速度已经有了非常显著的提升，整体已经可以达到和当前Android差不多的水平。虽然少数页面中仍然存在偶发性卡顿，比如某些窗口弹出来的时候马上触摸屏幕，有一定概率会让屏幕阅读器短暂卡死，目前这个现象没有规律可循，但确实是存在的，后续版本可以继续优化。

滑动速度上来了，但"跟手度"这件事还得单独说。目前屏幕朗读在单指滑动的时候，它的响应逻辑是：手指按下、移动、抬起，抬起之后焦点才会跳过去。也就是说，它把手势分成开始和结束，结束之后才去识别和执行，导致的结果就是手指滑过去以后焦点才追上来，而不是手指摸到哪里焦点就跟到哪里。单次滑动的时候这种延迟可能不太明显，可是如果快速连续扫动，延迟就会累加，变成一种"不那么跟手"的感觉。尤其是用惯了旁白的视障用户，感受会更强烈。

打个比方，如果说iOS旁白是"指哪打哪"，手指滑下去的一瞬间焦点就立刻跟过去，那么HarmonyOS就更像是手指离开屏幕之后焦点才跟着跑。因此旁白在连续快速扫动的时候，流畅度和跟手程度上有着非常明显的优势。Android这边的屏幕阅读器也存在类似的情况，可能有Google底层的原因或者手势识别机制上的不得已，但我还是希望屏幕朗读在后续的迭代中能向旁白看齐，把这种滞后感降下来，让焦点真正追着手指跑，那样滑动的流畅性和跟手度会有质的提升。

另一个影响流畅感的地方在列表滚动。当页面上能看到的项目滑动到头，焦点停在当前屏幕最后一项，再继续往下滑就该触发页面滚动了。就是这一瞬间，能明显感觉到一次卡顿。它的逻辑跟Android很像：触发滚动之后，无障碍焦点需要重新刷新、重新定位，这个过程就会产生一种可感知的卡顿。如果只是滑动一两次，可能觉察不出什么，但在快速扫动浏览一个长列表时，这种顿挫感就会被放大，实实在在地拖慢浏览速度。

iOS旁白在这方面又不太一样，它不会去滚动一整块屏幕，而是始终只滚动一个焦点。所以在iOS上，用户几乎感受不到页面发生了滚动，滑动的力度和页面的大小始终保持一致。反观Android和HarmonyOS，有时候滚动的是单个焦点，有时候又是一整块屏幕，以设置页面为例，大家就能非常直观地感受到这种不统一。而这种滚动逻辑的一致性，恰恰是决定屏幕阅读器是否顺畅、是否让人摸不着头脑的关键因素之一，希望华为后续可以考虑往一致性更好的方向调整。

第三个容易卡顿的场景是窗口弹出和返回上一级。屏幕阅读器需要扫描屏幕上的节点来形成无障碍树，每进入一个新的窗口，就要重新扫描、重新排列焦点的空间顺序和逻辑顺序。这就导致从设置首页点进蓝牙页面，或者从蓝牙页面返回设置主页的时候，会出现一瞬间的延迟。这一方面跟过渡动画有关，明眼人看到的缩放和抽屉式动画效果，对视障用户来说，体感上就是卡顿。很多视障用户会主动把动画减弱，正是为了缩短这种窗口切换时的响应时间。另一方面，新窗口的UI渲染完毕后，屏幕阅读器需要重新扫描页面布局，并把焦点定到起始位置，这个过程本身也需要时间。这些延迟Android也有，很可能是继承过来的问题，但HarmonyOS作为一套独立的系统，后续完全可以想办法在这方面进一步优化，同样也是朝着旁白的流畅程度去努力。

在键盘上慢下来：输入法那双击误触的坑

再说一个对日常打字影响很大的问题——输入法。我目前用的是系统自带的小艺输入法。在触摸键盘上用单指打字的体验，可以说相当不友好。手指摁下去再抬起来输入字母的过程，本身就有一点延迟，更要命的是，如果按得稍微快一点，系统就容易把它识别成双击，焦点就可能从键盘区域跳到屏幕上别的地方去，没有办法快速、连贯地在键盘上键入字母。这个问题Android上也有，想在键盘上打得顺手，得按得非常慢才行。

被语音盖掉的音效：响度不统一的尴尬

接下来想聊聊音效反馈。目前屏幕朗读的焦点滑动音效、到达边界时的音效、滚动音效以及窗口弹出音效，统一都偏柔和，音量也偏低。这就导致一个问题：当小艺语音库的声音稍微调大一点，我们在屏幕上快速扫动焦点的时候，耳朵里基本就只剩下语音朗读的声音，焦点流转和聚焦到项目上的音效很难被听到。但在整个屏幕朗读的音效体系中，双击触发控件的确认音效其实又是比较响的，明显大于刚才说的那几种音效，这就造成了整体响度的不统一。

其实音效在无障碍操作里承担的作用非常大。一个控件是否可点击、是否有可操作链接，音效往往比语音更快、更直接地把状态传达过来。在一些控件规范做得好的页面上，哪怕语音不朗读，有经验的用户靠音效也能判断出焦点当前的状态。所以音效的穿透力和辨识度，非常关键。

尽管每个人对音效的审美偏好不一样，有人喜欢柔和，有人喜欢清脆，但这应该作为个性化选项来提供，默认方案还是要优先保证辨识度，起码不能被语音朗读轻易盖过去。小艺语音库本身高频偏多，音量一大就容易掩蔽音效事件。建议华为后续能做一套相对通用、响度均衡的默认音效方案，同时在屏幕朗读设置中增加一个音效音量的调节项，允许用户自己设定音效与语音的相对响度比例，比如60%、70%等等，让不同类型的使用者都能找到适合自己的平衡点。

朗读顺序谁来定：被忽略的详细程度设置

最后是功能层面的缺失，目前最迫切的需求之一就是朗读力度的调节功能。举一个很具体的例子：进入设置的WLAN页面，已连接上的WiFi，触摸上去会先朗读WiFi的冗长名称，然后才读出连接状态。这个顺序对于浏览已连接WiFi列表其实不太合理。从视觉上来说，明眼人最先接收到的信息是WiFi前面那个打勾图标，然后才是名称和信号强度。也就是说，视觉上的信息优先级是：连接状态大于名称大于信号强度。屏幕朗读的朗读顺序，应该尽量贴合这个逻辑，或者至少把调节的权利交给用户。

事实上，目前TalkBack和iOS旁白都已经提供了类似的功能。可以设置三种组合方式：名称、类型和状态；类型、名称和状态；状态、名称和类型。用户可以根据自己的听读习惯自由调节。比如我先听到状态再听到名称再听到类型，那么已连接的那个WiFi就会读成"已连接，某某WiFi，按钮"。在默认设置上，我建议华为优先考虑"状态、名称、类型"这一组合，让用户在浏览WiFi列表时首先获得"这个WiFi已连接"之类的关键状态信息。这样的朗读力度调节功能，无论是从规范页面的角度，还是从提升日常操作效率的角度来看，都是迟早需要补上的。

每次都要等五秒：那个倒计时的逻辑该改改了

聊完基本的操作感受，再简单梳理一下屏幕朗读目前存在的一些功能缺失，逐项看看它还缺哪些东西。

首先是开启屏幕朗读的流程。在设置里找到"关怀与辅助"，第二项就是屏幕朗读，进入后可以直接打开开关。点击开关时，系统会弹出一个协议说明窗口，告诉用户开启后应该怎么操作、有哪些注意事项。窗口底部有一个带倒计时的确定按钮，五秒后才能点击，用意是引导用户把协议内容读完。但目前的问题是，每一次通过设置页面手动开启屏幕朗读，都会触发这个倒计时。而Android那边的逻辑是，只有第一次开启时需要倒计时，此后就不再需要了。

一个水印、两套语音：语速加倍为什么要另下语音包

开启屏幕朗读后，第一个设置项叫"屏幕朗读提示水印"。打开后，屏幕底部会显示一行文字，提示用户"同时按住音量上下键3秒即可关闭屏幕朗读"，主要面向低视力用户或明眼人，帮助他们知道如何退出。对于全盲用户，平时如果要用到图像描述或者OCR识别功能的，建议把这个水印关掉，因为它会占据屏幕底部靠近桌面托盘位置的一块区域，可能会遮挡画面。

第二项是语音设置。语音设置里的第一项是语速，华为目前提供了两套方案：一个是"默认语速"，另一个叫"加快语速"。选择加快语速后，系统会提示额外下载一个语音包，下载完成后切换过去，声音偏低沉，语速确实快了一些，但音质上能听出比较明显的压缩感。换句话说，它更像是换了另一个发音人，然后再把速度调快，但很难称之为真正的"语速加倍"。

"你们这个语速加倍，居然还要另外下载新的语音包才能用。"

这个问题，用一位伙伴的原话来概括就非常准确。我觉得另下语音包这个思路本身就偏了。声音变速本应是播放器层面直接处理的事情，慢放快放都属于音频处理的范畴，跟换不换语音包没有本质关系。现在华为的做法，等于是让用户下载一个新音色，再切换过去，明明可以叫"切换高速音色"，却偏偏叫"语速加倍"，逻辑上已经背离了这个功能的真正用途。

在语速设置中，华为也提供了语速滑块和语调滑块的调节，用户可以在0到100之间按自己的听读习惯调整，同时保留了还原默认的选项。但这里有一个细节没处理好：当用户把语音方案切换到"加快语速"、并把语调调到大概50左右之后，如果再切回"默认语速"，语调并不会跟着恢复。也就是说，语音方案的切换和音调参数之间没有做联动记忆。华为后续可以考虑让语调参数跟随语音方案一起保存和切换，否则每换一次方案都要手动重新调整，操作上不够顺滑。

此外，语音设置中还缺少一个试听按钮。文本转语音的能力以后肯定不止服务于屏幕朗读这一个场景，后续还会有更多应用需要调用TTS。所以试听功能有必要加进来，而且TTS的设置入口也不应该藏得太深。目前它只存在于屏幕朗读的次级页面里，长远来看，应该在设置首页的无障碍区域也提供一个入口，让非屏幕朗读用户和开发者也能方便地找到它，并逐步健全一个TTS模块该有的基础选项，比如语言选择等。

最后说一说小艺这两个语音方案本身的听感。默认语速的小艺，乍一听确实很好听，自然度和音色都相当不错。但它在语速调快之后有一个明显的问题：吐字不够清晰，朗读英文单词时尤为突出，会给听读带来额外的理解负担。而那个需要单独下载的"快速语速"方案，不仅改变了音调，声音也变得非常机械、割裂，听久了真的很不舒服。所以我的想法是，与其另做一套听感大打折扣的快速语音包，不如在默认这套好听的基础上直接做好语速加快的处理，让用户在自然清晰的音色下就能获得足够高的听读效率。

智能识别：触发场景成谜，提示还有点啰嗦

智能识别页面中有两个开关：图像描述和文字识别。文字识别可以直接开启，图像描述则需要额外下载一个十几MB的插件才能启用，下载完成之后就不需要再次下载了。

总之，智能识别的提示应当尽量简明扼要，不管是靠音效还是语音，或者两者组合的方式，行业内都有比较成熟的参考案例。比如旁白，还有天坦等国内三方屏幕阅读器，用户既可以选择纯音效，也可以选择语音加音效，或者纯语音。无论用哪一种，效率都很高，即便使用语音来提示，表达也都比较克制简洁。华为在这一块可以朝这个方向去做减法。

开关堆成杂货铺：设置页面为什么毫无章法

屏幕朗读的设置首页，目前除了语音设置、智能识别、快捷手势相关的几个分类，以及通知栏播报做了二级菜单之外，其余所有开关几乎不分先后、不顾逻辑，全部堆在首页上。比如解锁和锁屏提示、新手提示、遮蔽传感器停止朗读、朗读网格行列等等，这些开关本质上都服务于同一个目的，就是播报相关的详细度设置。明明可以收纳进一个层级里去，却全都散落在外面。而且在新手提示的前面，还夹杂了音效和触感反馈的开关，这些本应属于震动与音效那一类。即便不做二级页面，至少也应该用小标题或分割线做一个基本的区隔，而不是像现在这样毫无章法地堆在一起，给人一种非常简陋、粗糙的工程感。

具体来说，跟播报详细度相关的开关，我简单罗列一下：解锁提示、锁屏提示、朗读表格或行列、新手提醒、使用传感器控制播报，以及通知栏播报。这几项完全可以统一收进"详细程度设置"或"朗读设置"之类的二级页面里，或者用一个小标题把它们隔开，让视障用户能更快地上手和定位这些功能。

像隐藏屏幕内容、触控模式、单击操作模式这类设置，属于操作行为相关的选项，是非常规类的设置，应该归到另一个分类里，并且放在相对靠后的位置，而不是混在播报类开关中间。

最后是音效触控反馈和触控震动反馈这两个开关，它们显然应该归属于"音效与震动"这个类别，要么单独做一个二级页面，要么至少用一个标题或分割线把它们跟其他设置明确隔开。

一个开关管所有：新手提示背后的详细程度欠了多少账

接下来聊聊华为在详细播报引导方面的缺失，也就是所谓新手提示在详细程度上欠的账。目前，华为把所有新手引导类的提示全部绑定在一个"新手提示"开关上。如果用户关掉这个开关，很多按钮的元素类型也不再播报，而且没有提供更细粒度的拆分选项。

我们可以对比一下行业内比较成熟的方案。以安卓的TalkBack为例，在TalkBack设置里有一项叫"详细程度"。用户进入设置首页后，首先能看到一个朗读预设的调节项。如果把预设调到"高"，所有基于控件的详细播报都会被读出来，比如先播报控件名称，再读状态和类型，最后读出如何与之交互的提示。举个例子，一个飞行模式控件，它的类型是开关，状态是已开启，操作提示是"点按两次即可激活"，同时还会读出它位于列表中第几项、列表共多少项。

这些播报在TalkBack里是通过多个独立开关来控制的。第一个是"详细使用方式提示"，如果用户觉得每摸到一个控件都读一句"点按两次即可激活"太拖沓，就可以关掉这个开关，只保留核心信息，提升浏览效率。第二个是"列表信息播报"，用户滚动屏幕时，如果想听到"当前第几项，共几项"，就可以把这项开着，如果不需要也可以关掉。第三个是"元素类型播报"的开关，这对熟悉页面的用户很有用。还是以飞行模式为例，关掉这个开关后，读的就不再是"飞行模式，开关"，而是只读"飞行模式，已开启"，后面的"开关"两个字被省略了。

还有一个是"读出窗口名称"的开关，用来控制无障碍焦点在不同窗口之间移动时的播报。比如用户首次把手摸到顶部状态栏区域，会朗读"状态栏"；首次摸到输入法区域，会朗读"输入法窗口"；从状态栏摸回系统桌面，会朗读"系统桌面窗口"。这个功能的具体处理方式，华为可以参考安卓TalkBack和iOS旁白的实现。它不仅需要从总开关里独立拆分出来，也需要华为先把窗口播报这套逻辑本身完善好。

前面我们提到过，元素类型的播报格外重要。控件的名称、类型和状态的朗读顺序，一定要尽快让用户可以按照自己的听读习惯来选择。如果用户选的是"名称、类型、状态"，飞行模式就念成"飞行模式，开关，开启"；如果选的是"状态、名称、类型"，就念成"开启，飞行模式，开关"。这个顺序的调节之所以非做不可，正是为了规避之前提过的WiFi列表中那种"听半天才知道连接状态"的滞后问题。

总的来说，详细程度这方面的优化，需要华为多参考业内成熟屏幕阅读器的操作和功能实现案例。不一定照抄，但请认真评估用户的实际使用需求。在详细程度这个模块里，需要考虑增加的细分选项至少还有：朗读元素ID、重复标点统计、朗读Emoji表情，以及说出大写，也就是在大写字母前自动加上"大写"提示。像"大写A、大写B"这样的播报，对输入时的准确性尤其有帮助，能让视障用户在输入密码或大小写混用的场景下心里更有底。

震感全都一个样：音效与震动为什么不能更有区分度

接下来聊聊屏幕朗读的音效与震动。前面已经提过，目前屏幕朗读提供了触感反馈和触控音效反馈两个开关。开启后，滑动焦点、双击点击、双指按住屏幕滚动、双击并按住触发长按等操作，都会有相应的音效和震感来提示当前的执行状态。但华为目前的做法非常简化：触控音效只有一个总开关，打开就有音效，关掉就完全没有；震动也同样，触感反馈开启后所有操作的震动都是同一种轻微震感，滑动焦点、长按、窗口进出，反馈都一模一样，而且非常不明显。

问题是，一个真正有用的震动反馈，应当在操作不同类型的控件或不同的事件时，给出不同的反应。比如，当用户摸到一个变暗、致灰的不可点击按钮时，应该有一个轻微的、区别于常规的震动；而这个控件如果可以点击、可以长按，震感就应该是相对正常、略强一些的。用户执行返回手势成功之后，和触发长按时，震感也应该有所区分。理想的状态是，哪怕没有语音播报，视障用户仅靠震动反馈就能判断当前按钮是可点击的还是不可点击的。这才有了震动的意义。否则，所有的控件反馈都是同一种轻微的震感，开和不开又有什么区别呢？多数用户会选择关掉它。

音效事件同样存在缺失。目前我测试下来，屏幕朗读的音效事件主要集中在点击执行时，以及摸到致灰不可点击按钮时会有不同的反馈，窗口发生改变、弹出对话框这类场景也有一部分音效。但所有操作执行成功之后的那一声提示音，都是完全一样的。和震动反馈的愿景一样，我希望华为能做到：即使没有语音提示，视障用户也能通过音效知道当前按钮的状态，以及自己大致处于哪个页面。

解释其中两个比较特殊的事件。"无焦点框"指的是用户摸到了一个完全空白的页面，当前没有任何无障碍焦点时，应当播放一个音效，告诉视障用户这个位置是空的。"执行失败"指的是用户在屏幕中用左右或上下扫动遍历焦点，滑到最后一个项目之后，已经没有任何焦点可以继续遍历了，这时应该有一个撞墙式的音效事件，告诉用户已经到头了。这个音效华为目前其实是有的，只是不够明显。

关于音效声音过低的问题，我在开头就已经提到了。滚动列表的音效、执行长按的音效、触摸滑动时焦点遍历的音效，声音都偏低、偏柔和。所以我再次重申，希望华为增加一个音效音量调节功能，让用户可以自主把音效音量调到屏幕朗读语音的60%、70%等等，并且提供多套方案。默认这套柔和方案建议更换掉，因为它响度不统一，也缺乏实用性。请参考行业内成熟屏幕阅读器的默认音效做法，iOS和TalkBack的方案都是既清脆又有辨识度，也具备很强的代表性。

震感反馈也一样。请增加震动反馈强度的调节，让视障用户可以自由调整屏幕朗读操作触感反馈的强度，并提供是否启用线性马达，以及震动类型的选择，比如清脆、强烈等，满足不同用户操作上的多样性需求。

完善音效事件、完善震动反馈的丰富度和个性化、完善详细程度的播报，这些工作的最终目的，是为了更好地规范无障碍控件的设计。只有屏幕朗读本身能够精准识别并反馈一个控件是开关还是普通按钮、是复选框还是单选按钮、是下拉菜单还是弹出窗口、当前是可点击还是不可点击、是一个进度滑块还是一个气泡通知，才能反过来倒逼软件厂商去优化自己的无障碍适配。所有的音效和震动反馈，都应该服务于语音无法触及或没有必要触及的地方，通过震感或音效来达到辅助语音朗读的作用。并不是所有信息都必须通过语音读出来，音效在很多时候反而能更高效、更直接地传达信息。