作者：我已经每天使用 Firefox OS 好几年了（哇，时间过得真快！）。虽然像 Project Silk 这样的努力使得性能稳步提升，但我经常注意到用户界面存在延迟。我假设延迟是因为硬件远远低于我使用 Android 和 iOS 设备时所习惯的“旗舰级”硬件。
去年，我为 Nexus 4 打造了 Firefox OS 并开始将其用作我的日常手机。很快，我意识到即使有了更好的硬件，我仍然需要等待 Firefox OS 执行一些基本的交互，即使该任务在计算上并不密集。我换成了 Nexus 5，然后是 Sony Z3 Compact，两者规格都比 Nexus 4 好，但我仍然遇到了相同的问题。
时间过去了，沮丧情绪加剧了。 无名恐惧的耳语…
数字分析
在阅读 Ralph Thomas 关于 基于物理模型创建动画 的帖子时，我开始思考 Firefox OS 中动画的实现方式，以及这与该问题是否存在关联。我分析了不同动画实例的数量，并按其持续时间进行了分组。我删除了进度指示器和启动关闭动画之类的元素。以下是 Firefox OS 中动画和过渡持续时间，按持续时间分组，针对过渡性交互，例如缩放、打开、关闭和滑动
- 0.1 秒：15
- 0.2 秒：57
- 0.3 秒：79
- 0.4 秒：40
- 0.5 秒：78
- 0.6 秒：8
有几个关键点。首先，动画持续时间分布非常广泛。其次，绝大多数动画的持续时间超过 300 毫秒！
实际上，在超过 80 个动画中，我们让用户等待超过半秒钟。这些缓慢的动画 拖慢了我们的速度，导致 Firefox OS 的整体体验下降。
我们是如何走到这一步的？
Firefox OS 的 UX 和交互设计师并没有聚在一起，故意设计出每次交互都缓慢地完成。实现这些动画的工程师也从未想过“这感觉很响应式…让我们把它放慢一些！”
我的理论是，当您设计和实现这些交互时，它们不会感觉缓慢，因为您一次只处理一个交互。在设计和开发动画时，我会寻找运动的流畅性、单个操作的美学以及视觉效果如何增强手头的任务，然后我会迭代持续时间和效果，直到感觉合适。
我们确实有 Firefox OS 响应性和用户感知性能指南，由 Gordon Brander 编写，您可以从下面的屏幕截图中看到。（点击图片查看更大、更清晰的版本。）但是，这些指南没有涵盖在初始感知因果关系和用户界面下一个可操作状态之间的亚秒级时间段。
用户与我们开发人员和设计师的体验完全不同。用户在匆匆发送短信、试图捕捉到完美的镜头、输入用户名和密码或费力地逐个上传一堆图片时，会体验我们的动画。人们试图从 A 点到达 B 点。他们希望完成一项任务…嗯，实际上不止一项：根据 Tecmark 去年 10 月在英国进行的一项研究，智能手机用户每天要完成 221 项任务。所有这些动画加起来可不少！我断言，Gaia 中 203 个持续时间为 300 毫秒或更长的动画的总和，导致了我在深入研究之前所体验到的令人沮丧的缓慢感。
让它感觉更快
因此，我测试了这一理论，将 Gaia 中所有动画的持续时间更改为 200 毫秒，作为起点。结果如何？Firefox OS 的响应速度明显加快了。在任务之间移动和在操作系统中导航感觉很快，但并非突然。相机快速进入就绪状态。发短信感觉流畅多了，响应速度也快了许多。应用程序弹出来，而不是缓慢地从睡梦中爬起来。Rocketbar 更接近于名副其实（尽管我认为键盘应该在工具栏变为活动状态时向上动画）。
以下是一些动画在应用此补丁前后并排对比的演示
我们可以在 Gaia 中做几件事来解决这个问题
- 我提交了一个错误，要求将此更改合并到 Gaia 中。200 毫秒的持续时间只是第一步，直到我们可以进行进一步的测试。最好出错在灵敏的一边，而不是迟缓的一边。我们得到了大多数 16 位开发人员的支持，他们必须审查这些更改，现在我们正与 UX 团队合作，在它可以合并之前获得他们的签字。 Kevin Grandon 通过 添加了一个 CSS 变量，我们可以在整个 Gaia 中使用它，这将使我们在将来实施这些类型的系统范围更改变得更容易，因为我们将不断学习。
- 我正在与 Firefox OS UX 团队合作，为动画定义全局一致的最佳实践。这些指南不会始终完全正确，但可以作为实施新动画的起点，确保默认值基于研究和经验。
12 条评论