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 期，不知道這些文章是否對您有所幫助呢？

若是您還有其餘問題，歡迎在咱們的公衆平臺留言，咱們將按期選取關注度高的問題集中解答，幫助您提高本身的開發實力，咱們明年再見！