Android UI 及 API 优化指南｜Android 开发者 FAQ Vol.10

做为应用的设计者，有些开发者在开发过程当中容易忽略一些用户体验方面的问题，从而致使了本身的应用用户体验欠佳。本期 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 期，不知道这些文章是否对您有所帮助呢？

若是您还有其余问题，欢迎在咱们的公众平台留言，咱们将按期选取关注度高的问题集中解答，帮助您提高本身的开发实力，咱们明年再见！