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 層面調整得更加簡單易用。
【本文是51CTO專欄機構“谷歌開發者”的原創稿件，轉載請聯系原作者(微信公眾號：Google_Developers)】
