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