作为应用的设计者，有些开发者在开发过程中容易忽略一些用户体验方面的问题，从而导致了自己的应用用户体验欠佳。本期 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 添加了确认对话框，避免用户不小心删除相册。而收件箱的闹钟功能（让邮件打个盹儿），则可以一键设定在某段时间后让邮件重新出现在眼前。
API 应该正确引导用户使用 API，在需要的地方使用默认值。API 应该操作简单容易上手。开发者可以通过提供默认值，帮助用户使用 API。比如说，当创建 Room 数据库时，其中一个默认值可以保证在数据库版本升级过程中，数据量保持不变。这意味着基于 Room 开发的 App 可用性大大增强，因为数据没丢而且数据库版本也是透明的。
而 Room 中的另一个方法 fallbackToDestructiveMigration 则可以更改此行为：在未提供数据迁移的情况下，数据库版本变更后，该方法能够破坏并重建数据库。
Q：有越来越多的操作符号已经在用户的心中形成了固有印象，是跟随潮流使用这些东西，还是用一些有新意的元素装点我的应用好呢？
A：识别出熟悉的对象造成的认知负荷最低，也容易被场景触发；“回忆” 则要求主体从记忆中追溯细节，花费更长的时间。因此挑出满意的选项远比从记忆中 “读取” 选项要来的容易。就 UI 设计来说，“识别” 派的交互界面多使用用户熟悉的图标，而 “回忆” 派则以命令行见长。信息和功能应尽量可视化、直观化并且易获取。
Q：我的应用功能有点多，但有些用户说我的应用功能很丰富，他们喜欢尝试里面的各种功能，也有一些告诉我我的应用看上去眼花缭乱，让他们不知道怎么用，有什么好的解决方法吗？
A：App 的用户可能是操作熟练的老手，也可能是没有经验的新手。因此在设计 UI 时，您应该把两种情况都考虑到，让他们都可以逐渐熟悉 App 操作。据统计，App 内只有 20% 的功能使用量达到 80%，这要求开发者在 “简洁界面” 和 “强大功能” 达到一种平衡。找到属于您 App 中的 20% 常用功能，让这部分功能尽量简单易上手。在设计过程中应用 “逐渐披露原则”，让其余用户在下拉页面获取高级功能选项。
Q：对无关信息屏蔽似乎可以提升用户的专注度，有哪些方法可以强化这点呢？
A：UI 的设计应该简约，仅包含和用户有关的信息。无关紧要或者几乎用不到的信息应剔除或者转移到其它屏幕，避免用户分心，或者弱化重要信息。
比如上图播客 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 期，不知道这些文章是否对您有所帮助呢？
如果您还有其他问题，欢迎在本文评论区留言，我们将定期选取关注度高的问题集中解答，帮助您提升自己的开发实力，我们明年再见！
