Android UI及API 优化指南

作为应用的设计者，有些开发者在开发过程中容易忽略一些用户体验方面的问题，从而导致了自己的应用用户体验欠佳。本期 Android 开发者 FAQ 我们整理了一些开发者们在后台留言的关于 UI 和 API 在用户体验方面的问题，为大家带来了 UI 及 API 的优化指南。

Q：用户说我的应用在处理信息时提示不明确，老是会误以为程序失去响应了，有什么好的方法改进吗？

A：系统应该在合理时间内给予适当反馈，让用户随时了解系统状态。

在 UI 方面，如果用户进行操作后需要等待一段时间，那么此时，系统就应当告知用户操作完成进度。与加载图标相比，我们更建议开发者采用进度条，并在上面显示上传或者下载百分比。这样用户就可以知道自己在等什么，还要等多久。

告知用户操作完成进度

而在 API 方面，API 应该提供查询当前进度的方法。例如：开发者可以通过 AnimatedVectorDrawable 类来查看动画究竟是否在运行状态：

boolean isAnimationRunning = avd.isRunning();

API 可以借助某种回调机制提供反馈：当对象状态发生变更时，通知 API 用户 —— 有点类似于动画开始和结束时的推送通知。AnimatedVectorDrawable 对象就允许通过注册 AnimationCallback 函数，达到上述目的。

Q：“撤回” 的操作在变得越来越流行，这类功能有什么意义呢？如何在我的应用内加入类似的功能？

A：给予用户撤回操作的权利，会让您的应用变得更加友好易用。

在 UI 方面，有时用户进行的操作可能会产生歧义，例如删除和归档邮件，此时系统应当弹出信息确认操作，并提供撤回选项。

允许用户撤回某些操作

而 API 应允许用户 “放弃” 和 “重置” 操作，方便 API 返回正常状态。比如，Retrofit 中的 Call#cancel 可以取消已经发送的网络调用请求或者确保该调用永远不会被执行（前提是在使用 Call#cancel 前，执行尚未发生）。而通过 NotificationManager API，开发者既可以创建又能够取消消息通知。

Q：有用户反馈说我的应用和其他的产品 “不一样”，进行某些按钮和手势操作后没有进行他们预想的功能，我该去哪里了解其他开发者都是怎么设置这些内容的呢？

A：好的应用，不应该让用户对不同的措辞、情况和操作究竟指的是不是一件事而感到烦恼。

在使用您的 App 之前，用户已经接触过许多别的 App，因此他们会期望常见的交互元素在各个 App 之间保持一致性。一旦脱离常规，就容易产生错误。

因此开发者须要和平台保持一致性，并且采用用户熟知的 UI 控件，确保用户能够快速识别并使用它们。此外，开发者自己的 App 也须要保持一致性：多屏操作 App 时，采用相同的用词和图标表示同种操作。例如，保持编辑图标统一，让用户可以在 App 内编辑多种元素。

对话框应和平台统一

至于 API，所有设计应当保持统一，如方法命名应一致；方法内容相同，名字也务必相同；方法中参数排序也要保持一致，等等。

Q：我觉得进行很多操作都额外弹出提示可能会让部分用户感到厌烦，那么究竟怎样的设计才能在不打扰用户和可靠之间找到平衡？

A：从一开始就预防用户在使用中 “犯错” 的发生，是开发者应当遵循的一个原则。

很多情况下，用户无法一直专注于手头的任务，因此开发者应该正确引导，以防用户无意识犯下无法补救的错误。譬如，在进行破坏性行为（比如删除）前先获取用户同意，或者设定良好的默认值。

比如说，Google Photos 添加了确认对话框，避免用户不小心删除相册。而收件箱的闹钟功能（让邮件打个盹儿），则可以一键设定在某段时间后让邮件重新出现在眼前。

在破坏性行为前，Google Photo 会要求用户先进行确认。收件箱一键设定时间，让邮件打个盹儿。

API 应该正确引导用户使用 API，在需要的地方使用默认值。API 应该操作简单容易上手。开发者可以通过提供默认值，帮助用户使用 API。比如说，当创建 Room 数据库时，其中一个默认值可以保证在数据库版本升级过程中，数据量保持不变。这意味着基于 Room 开发的 App 可用性大大增强，因为数据没丢而且数据库版本也是透明的。

而 Room 中的另一个方法 fallbackToDestructiveMigration 则可以更改此行为：在未提供数据迁移的情况下，数据库版本变更后，该方法能够破坏并重建数据库。

Q：有越来越多的操作符号已经在用户的心中形成了固有印象，是跟随潮流使用这些东西，还是用一些有新意的元素装点我的应用好呢？

A：识别出熟悉的对象造成的认知负荷最低，也容易被场景触发；“回忆” 则要求主体从记忆中追溯细节，花费更长的时间。因此挑出满意的选项远比从记忆中 “读取” 选项要来的容易。就 UI 设计来说，“识别” 派的交互界面多使用用户熟悉的图标，而 “回忆” 派则以命令行见长。信息和功能应尽量可视化、直观化并且易获取。

比如，用铅笔图标表示编辑功能，就算 App 不同，用户也能容易辨认，这类已经被广泛接受的图标最好不要轻易自行设计。

Q：我的应用功能有点多，但有些用户说我的应用功能很丰富，他们喜欢尝试里面的各种功能，也有一些告诉我我的应用看上去眼花缭乱，让他们不知道怎么用，有什么好的解决方法吗？

A：App 的用户可能是操作熟练的老手，也可能是没有经验的新手。因此在设计 UI 时，您应该把两种情况都考虑到，让他们都可以逐渐熟悉 App 操作。据统计，App 内只有 20% 的功能使用量达到 80%，这要求开发者在 “简洁界面” 和 “强大功能” 达到一种平衡。找到属于您 App 中的 20% 常用功能，让这部分功能尽量简单易上手。在设计过程中应用 “逐渐披露原则”，让其余用户在下拉页面获取高级功能选项。

比如，在 Android 系统中，Wi-Fi 设定主页面上显示基本选项，下拉出现高级选项，可以满足各类用户需求。

Q：对无关信息屏蔽似乎可以提升用户的专注度，有哪些方法可以强化这点呢？

A：UI 的设计应该简约，仅包含和用户有关的信息。无关紧要或者几乎用不到的信息应剔除或者转移到其它屏幕，避免用户分心，或者弱化重要信息。

Pocket Casts 的移动端 App 采用极简设计

比如上图播客 App 的节目列表界面就仅仅显示了最精、最有用的信息：如果用户无法下载节目，界面内就会显示下载文件大小和下载键；如果用户已经完成下载，就显示节目长度和播放键。同时所有上述内容和其他信息都会显示在详情页面中，满足好奇心强的用户需求。

API 用户只有一个目的：用 API 更快解决问题。所以让您的 API 快准狠，用最少的时间，最有效的方法，解决用户痛点。所以，请不要暴露 API 内部逻辑，API 做到的，不要劳烦用户自己做。

API：从 22.1.0 版本起，Android 支持库就开始提供 RecyclerView 扩展包，让开发者能够借助大数据集和易变数据更好地设计 UI 界面元素。如果列表发生改变，开发者需要在 RecyclerView.Adapter 内更新相关数据。这意味着开发者需要自己去解决不同列表之间的差异运算问题。从 25.1.0 开始，支持库引入 DiffUtil 帮开发者免去这个枯燥的苦差事。DiffUtil 采用优化算法，减少开发者代码编写量，同时提高性能。

Q：这个年代，帮助文档还有必要存在吗？会不会显得我的应用像个老古董？

A：用户无须借助文档应该就能使用您的 App。不过对于复杂程度或者领域专业性很高的 App，可能有点不切现实。如果不得不撰写文档，请确保文档覆盖所有常见问题而且能轻松找到。

导航侧边栏底部常见 “帮助 ”和 “反馈” 选项

API 应 “自文档化”，方法、类和成员如果命名恰当，就好比于 API 自己给自己写了文档。但是不论一个 API 有多棒，文档都是必不可少的。这也就是为何所有公开内容 —— 方法、类、域、参数 —— 都应该具备相应文档。API 使用者应该和 API 开发者一样觉得 API 简单明了。

以上便是今年最后一期 FAQ 的全部内容，希望阅读了这些解答后，您可以使用这些方法将自己的应用在 UI 和 API 层面调整得更加简单易用。回顾 2017，我们的开发者 FAQ 已经做了 10 期，不知道这些文章是否对您有所帮助呢？

如果您还有其他问题，欢迎在我们的公众平台留言，我们将定期选取关注度高的问题集中解答，帮助您提升自己的开发实力，我们明年再见！