Android UI及API優(yōu)化指南
作為應(yīng)用的設(shè)計者，有些開發(fā)者在開發(fā)過程中容易忽略一些用戶體驗方面的問題，從而導(dǎo)致了自己的應(yīng)用用戶體驗欠佳。本期 Android 開發(fā)者 FAQ 我們整理了一些開發(fā)者們在后臺留言的關(guān)于 UI 和 API 在用戶體驗方面的問題，為大家?guī)砹?UI 及 API 的優(yōu)化指南。
Q：用戶說我的應(yīng)用在處理信息時提示不明確，老是會誤以為程序失去響應(yīng)了，有什么好的方法改進嗎?
A：系統(tǒng)應(yīng)該在合理時間內(nèi)給予適當反饋，讓用戶隨時了解系統(tǒng)狀態(tài)。
在 UI 方面，如果用戶進行操作后需要等待一段時間，那么此時，系統(tǒng)就應(yīng)當告知用戶操作完成進度。與加載圖標相比，我們更建議開發(fā)者采用進度條，并在上面顯示上傳或者下載百分比。這樣用戶就可以知道自己在等什么，還要等多久。
△ 告知用戶操作完成進度
而在 API 方面，API 應(yīng)該提供查詢當前進度的方法。例如：開發(fā)者可以通過 AnimatedVectorDrawable 類來查看動畫究竟是否在運行狀態(tài)：
- boolean isAnimationRunning = avd.isRunning();
API 可以借助某種回調(diào)機制提供反饋：當對象狀態(tài)發(fā)生變更時，通知 API 用戶 —— 有點類似于動畫開始和結(jié)束時的推送通知。AnimatedVectorDrawable 對象就允許通過注冊 AnimationCallback 函數(shù)，達到上述目的。
Q：“撤回” 的操作在變得越來越流行，這類功能有什么意義呢?如何在我的應(yīng)用內(nèi)加入類似的功能?
A：給予用戶撤回操作的權(quán)利，會讓您的應(yīng)用變得更加友好易用。
在 UI 方面，有時用戶進行的操作可能會產(chǎn)生歧義，例如刪除和歸檔郵件，此時系統(tǒng)應(yīng)當彈出信息確認操作，并提供撤回選項。
△ 允許用戶撤回某些操作
而 API 應(yīng)允許用戶 “放棄” 和 “重置” 操作，方便 API 返回正常狀態(tài)。比如，Retrofit 中的 Call#cancel 可以取消已經(jīng)發(fā)送的網(wǎng)絡(luò)調(diào)用請求或者確保該調(diào)用永遠不會被執(zhí)行(前提是在使用 Call#cancel 前，執(zhí)行尚未發(fā)生)。而通過 NotificationManager API，開發(fā)者既可以創(chuàng)建又能夠取消消息通知。
Q：有用戶反饋說我的應(yīng)用和其他的產(chǎn)品 “不一樣”，進行某些按鈕和手勢操作后沒有進行他們預(yù)想的功能，我該去哪里了解其他開發(fā)者都是怎么設(shè)置這些內(nèi)容的呢?
A：好的應(yīng)用，不應(yīng)該讓用戶對不同的措辭、情況和操作究竟指的是不是一件事而感到煩惱。
在使用您的 App 之前，用戶已經(jīng)接觸過許多別的 App，因此他們會期望常見的交互元素在各個 App 之間保持一致性。一旦脫離常規(guī)，就容易產(chǎn)生錯誤。
因此開發(fā)者須要和平臺保持一致性，并且采用用戶熟知的 UI 控件，確保用戶能夠快速識別并使用它們。此外，開發(fā)者自己的 App 也須要保持一致性：多屏操作 App 時，采用相同的用詞和圖標表示同種操作。例如，保持編輯圖標統(tǒng)一，讓用戶可以在 App 內(nèi)編輯多種元素。
△ 對話框應(yīng)和平臺統(tǒng)一
至于 API，所有設(shè)計應(yīng)當保持統(tǒng)一，如方法命名應(yīng)一致;方法內(nèi)容相同，名字也務(wù)必相同;方法中參數(shù)排序也要保持一致，等等。
Q：我覺得進行很多操作都額外彈出提示可能會讓部分用戶感到厭煩，那么究竟怎樣的設(shè)計才能在不打擾用戶和可靠之間找到平衡?
A：從一開始就預(yù)防用戶在使用中 “犯錯” 的發(fā)生，是開發(fā)者應(yīng)當遵循的一個原則。
很多情況下，用戶無法一直專注于手頭的任務(wù)，因此開發(fā)者應(yīng)該正確引導(dǎo)，以防用戶無意識犯下無法補救的錯誤。譬如，在進行破壞性行為(比如刪除)前先獲取用戶同意，或者設(shè)定良好的默認值。
比如說，Google Photos 添加了確認對話框，避免用戶不小心刪除相冊。而收件箱的鬧鐘功能(讓郵件打個盹兒)，則可以一鍵設(shè)定在某段時間后讓郵件重新出現(xiàn)在眼前。
△ 在破壞性行為前，Google Photo 會要求用戶先進行確認。收件箱一鍵設(shè)定時間，讓郵件打個盹兒。
API 應(yīng)該正確引導(dǎo)用戶使用 API，在需要的地方使用默認值。API 應(yīng)該操作簡單容易上手。開發(fā)者可以通過提供默認值，幫助用戶使用 API。比如說，當創(chuàng)建 Room 數(shù)據(jù)庫時，其中一個默認值可以保證在數(shù)據(jù)庫版本升級過程中，數(shù)據(jù)量保持不變。這意味著基于 Room 開發(fā)的 App 可用性大大增強，因為數(shù)據(jù)沒丟而且數(shù)據(jù)庫版本也是透明的。
而 Room 中的另一個方法 fallbackToDestructiveMigration 則可以更改此行為：在未提供數(shù)據(jù)遷移的情況下，數(shù)據(jù)庫版本變更后，該方法能夠破壞并重建數(shù)據(jù)庫。
Q：有越來越多的操作符號已經(jīng)在用戶的心中形成了固有印象，是跟隨潮流使用這些東西，還是用一些有新意的元素裝點我的應(yīng)用好呢?
A：識別出熟悉的對象造成的認知負荷***，也容易被場景觸發(fā);“回憶” 則要求主體從記憶中追溯細節(jié)，花費更長的時間。因此挑出滿意的選項遠比從記憶中 “讀取” 選項要來的容易。就 UI 設(shè)計來說，“識別” 派的交互界面多使用用戶熟悉的圖標，而 “回憶” 派則以命令行見長。信息和功能應(yīng)盡量可視化、直觀化并且易獲取。
△ 比如，用鉛筆圖標表示編輯功能，就算 App 不同，用戶也能容易辨認，這類已經(jīng)被廣泛接受的圖標***不要輕易自行設(shè)計。
Q：我的應(yīng)用功能有點多，但有些用戶說我的應(yīng)用功能很豐富，他們喜歡嘗試里面的各種功能，也有一些告訴我我的應(yīng)用看上去眼花繚亂，讓他們不知道怎么用，有什么好的解決方法嗎?
A：App 的用戶可能是操作熟練的老手，也可能是沒有經(jīng)驗的新手。因此在設(shè)計 UI 時，您應(yīng)該把兩種情況都考慮到，讓他們都可以逐漸熟悉 App 操作。據(jù)統(tǒng)計，App 內(nèi)只有 20% 的功能使用量達到 80%，這要求開發(fā)者在 “簡潔界面” 和 “強大功能” 達到一種平衡。找到屬于您 App 中的 20% 常用功能，讓這部分功能盡量簡單易上手。在設(shè)計過程中應(yīng)用 “逐漸披露原則”，讓其余用戶在下拉頁面獲取高級功能選項。
△ 比如，在 Android 系統(tǒng)中，Wi-Fi 設(shè)定主頁面上顯示基本選項，下拉出現(xiàn)高級選項，可以滿足各類用戶需求。
Q：對無關(guān)信息屏蔽似乎可以提升用戶的專注度，有哪些方法可以強化這點呢?
A：UI 的設(shè)計應(yīng)該簡約，僅包含和用戶有關(guān)的信息。無關(guān)緊要或者幾乎用不到的信息應(yīng)剔除或者轉(zhuǎn)移到其它屏幕，避免用戶分心，或者弱化重要信息。
△ Pocket Casts 的移動端 App 采用極簡設(shè)計
比如上圖播客 App 的節(jié)目列表界面就僅僅顯示了最精、最有用的信息：如果用戶無法下載節(jié)目，界面內(nèi)就會顯示下載文件大小和下載鍵;如果用戶已經(jīng)完成下載，就顯示節(jié)目長度和播放鍵。同時所有上述內(nèi)容和其他信息都會顯示在詳情頁面中，滿足好奇心強的用戶需求。
API 用戶只有一個目的：用 API 更快解決問題。所以讓您的 API 快準狠，用最少的時間，最有效的方法，解決用戶痛點。所以，請不要暴露 API 內(nèi)部邏輯，API 做到的，不要勞煩用戶自己做。
API：從 22.1.0 版本起，Android 支持庫就開始提供 RecyclerView 擴展包，讓開發(fā)者能夠借助大數(shù)據(jù)集和易變數(shù)據(jù)更好地設(shè)計 UI 界面元素。如果列表發(fā)生改變，開發(fā)者需要在 RecyclerView.Adapter 內(nèi)更新相關(guān)數(shù)據(jù)。這意味著開發(fā)者需要自己去解決不同列表之間的差異運算問題。從 25.1.0 開始，支持庫引入 DiffUtil 幫開發(fā)者免去這個枯燥的苦差事。DiffUtil 采用優(yōu)化算法，減少開發(fā)者代碼編寫量，同時提高性能。
Q：這個年代，幫助文檔還有必要存在嗎?會不會顯得我的應(yīng)用像個老古董?
A：用戶無須借助文檔應(yīng)該就能使用您的 App。不過對于復(fù)雜程度或者領(lǐng)域?qū)I(yè)性很高的 App，可能有點不切現(xiàn)實。如果不得不撰寫文檔，請確保文檔覆蓋所有常見問題而且能輕松找到。
△ 導(dǎo)航側(cè)邊欄底部常見 “幫助 ”和 “反饋” 選項
API 應(yīng) “自文檔化”，方法、類和成員如果命名恰當，就好比于 API 自己給自己寫了文檔。但是不論一個 API 有多棒，文檔都是必不可少的。這也就是為何所有公開內(nèi)容 —— 方法、類、域、參數(shù) —— 都應(yīng)該具備相應(yīng)文檔。API 使用者應(yīng)該和 API 開發(fā)者一樣覺得 API 簡單明了。
以上便是今年***一期 FAQ 的全部內(nèi)容，希望閱讀了這些解答后，您可以使用這些方法將自己的應(yīng)用在 UI 和 API 層面調(diào)整得更加簡單易用。
【本文是51CTO專欄機構(gòu)“谷歌開發(fā)者”的原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者(微信公眾號：Google_Developers)】
