[核心提示] Android 開發者關系團隊每天都會試用無數的 App 或者受到無數的開發者發來的請求評測的 App，在評測如此之多的應用之后，他們總結出了10個最常見的錯誤。

作為一個長期使用 Android 的用戶，我在使用 Android 應用的時候經常遇到各種各樣的交互上的問題，并且早就想整理它們寫一篇文章了。但是由于懶惰和拖延，這篇文章一直處于草稿的狀態。正巧，這期 ADiA 中，Android 開發團隊為我們著重強調了當下 Android 應用中很常見的，應該避免的錯誤。

Android 開發者關系團隊每天都會試用無數的 App 或者受到無數的開發者發來的，請求評測的 App。在評測如此之多的應用之后，他們總結出了一些最常見的錯誤，并且在這期節目中為大家呈現出來。

在正式介紹這些錯誤之前，我想稍微提一句。這些錯誤是非常具有普遍意義的錯誤，也就是說，你用十個應用可能就會碰見這十個錯誤，甚至你會在一個應用中碰見全部十個錯誤。這種情況在天朝顯得更加嚴峻。所以，希望這篇文章能讓大家擺脫摸著石頭過河的窘境，直接的避免一些常見的錯誤。

十大用戶體驗"反模式"，Android 開發者聯系團隊為你用心呈現，每個典型錯誤都有個有趣的小標題，希望大家看 (乖) 得 (乖) 開 (中) 心 (槍)。

第十：你必須加載完這些東西……否則！

這里的加載實際上指的是左圖中的那種，一個圈圈轉啊轉的對話框。這種對話框的出現是應該要避免的，另外，比起這么一個對話框，那些不響應 Back 操作的對話框實在太不合理。

解決方案其實也很簡單，采用嵌入式的載入指示即可。當然如果你能做到實現在后臺加載好數據那就更棒了。

第九：你摸我不到！

首當其沖的問題是過小的觸摸區域。Android Design?中專門強調過，所有可觸摸的對象都應該有至少 32dp 高，理想的大小是 48dp，除非你的目標用戶是嬰兒等手特小的人。

另一個很糟糕的錯誤是沒有觸摸反饋。有些開發者不想使用標準的按鈕控件，但是標準按鈕的好處就是它有提供觸摸反饋的視覺效果。對于用戶而言，摸到沒有反饋的按鈕會讓他們認為你的應用（比它本身的速度）慢。對于用戶而言，感知速度是他們能體會到的，而真正的載入速度和運行速度反而沒有感知速度那么容易被用戶體會到。另外，亮起的觸摸反饋還能指示出實際的觸摸區域。比如說一個列表，當用戶按下某一列表項的時候，這一項所處的一整行都會亮起，但是兩邊會留有 16dp 的空白，這樣便相當于告訴用戶，這個列表項最靠近屏幕邊緣的 16dp 不是觸摸區域。

第八：設計?≠ Photoshop

首先，同學們不要學習右邊小圖上的那個變態。我知道大家都對 PS 能實現的各種各樣的效果很在行/感興趣，但是不當的/過度的使用這些效果只會讓你的應用看起來顯得很過時或者更糟糕——很業余。

當你設計你的應用的時候，請務必將注意力優先放在內容而不是那些高光上。用戶裝了你的應用并不是為了看閃閃發光的按鈕，所有的這些視覺設計到最后都應該是為了內容服務，而不是為了裝飾而裝飾。

另外，請務必保證應用內視覺風格的一致性。沒用用戶會希望看到一個一半 Holo 一半草泥馬的應用。點名批評一下 Feedly 這種外表光鮮亮麗, 設置卻像是侏羅紀時代的應用。另外，一個應用中不應該有太多的按鈕/選框/對話框樣式，一個就夠了——直接調用 Android 風格的控件是個簡單有效的辦法。

還有一些開發者，對于細節的忽視實在是到了令人發指的地步，比如說不一致的度量，錯誤的間距，鬼畜的用色（如我之前的微信 Redesign?），喪病的字體選擇……這些都是會令用戶感到不爽的細節，作為開發者沒有理由忽視他們。

第七：侏羅紀來客

如果你的應用是 2009 年的時候做的，那么你的用戶可就要遭殃了……

這里最先要提到的問題就是 Menu 鍵，或者說，菜單按鈕的恥辱。我們現在已經有了 Action Bar 來取代侏羅紀時代的菜單鍵了不是嗎？需要向下兼容也不是個借口，因為如果你設置了適當的參數，那么 Overflow 按鈕就不會在有實體菜單鍵的機器上出現。當然，你也可以讓有實體菜單鍵的機器強行顯示 Action Overflow 來增加它的可見性。但是，無論怎么樣，都不要讓菜單鍵只能通過實體 Menu 鍵 (在只有虛擬鍵的機器上就會變成?Nav Bar 右側的三個小點) 呼出。

雖然說現在 Android 最新的 API 已經到了?Lv 18，但是你并不一定要設置 targetSdkVersion 大到 18，只要是 16 以上就行了。如果你把 API 設置到 Lv 14 甚至更低，你的應用就會強制在 Nav Bar 上顯示三個小點，這對于某些設備比如?HTC One?的用戶而言實在是一件不能更痛苦的事情了。

還有一種情況就是繼續沿用 Android 2.3 甚至更古早的視覺風格。這種 App 有時候看起來還算挺 Holo 的，但是當你按下按鈕或者列表項的時候，Android 2.3 樣式的橙色的視覺反饋出現了（如 MIUI），或者卷動的時候看到了 2.3 樣式的滾動條，或者載入的時候看到 2.3 樣式的圈圈等等。這絕對不是用戶想要的。說道載入時的圈圈，Roman Nurik 稍微強調了一下，Holo 樣式的載入環其實是兩個圈以不同的速度反向同時旋轉，能夠制造出比起單圈更為順滑的動畫。

第六：純血的雜種 Android

這里的原則性問題是：不要違背“純血 Android”的規約。

就和標題一樣，這一章的內容是在說，不要從別的平臺上搬運元素到 Android 上。這個問題我在往期的文章里也提到過很多次，這里就不展開說了。幾個特別要注意也是常見的錯誤：

• 右箭頭：次級導航在 Android 上是沒有水平方向的映射的。換句話說，次級導航和橫向導航是兩碼事
• 底部標簽欄：對于 Android 而言, 頂部才是屬于標簽欄的位置
• 從其他平臺"借鑒"視覺樣式：Android 用戶想要的是 Android 應用?

第五：導航就是我的品牌

不要試著重新發明輪子。應用中導航在 Android 中已經有了成熟的定義，把應用名稱放在 Action Bar 中間，或者用?iOS?樣式的 Top Bar 都是很愚蠢的行為。請直接用?ActionBarCompat，如果有需要在更早的版本上實現 Action Bar，那么?Action Bar Sherlock?也不失為一個好的選擇。

另外 Drawer 是用來放主要的導航元素的，像搜索和設置之類的東西放進 Overflow 就行了。此外，屏幕內容滑動露出 Drawer 這種方式也是不建議的（具體請詳見之前的介紹文章?Android Design 趨勢——Navigation Drawer）。

既然這篇文章講的是誤區，那么這里就尤其要強調一下不應該放進 Drawer 的東西。首先最上面的主頁探索購物和個人資料是完全沒問題的。中間的搜索應該放進 Action Bar，因為這是一個很常見的"動作"，而且不是一個"導航元素" 。設置，幫助，關于和反饋都是應該放進 Action Overflow 的東西另外，廣告什么的絕對不要有。也沒有必要在 Drawer 中推廣自己的 App，這些東西放進"關于"里倒是可以的。至于"我姐妹的朋友有個網站我保證它很有意思請務必去看看"這種東西，趁早刪了為妙。

第四：自制的非 Android 風格的分享

首先注意一下，這里提供的三個截圖都是正面的例子。

實際上，強大的應用間分享一直是 Android 的強項。Android 系統也提供了很方便的分享功能（ACTION_SEND）。開發者完全沒必要也不應該人為的把分享的目標限定在某幾個應用上。另外，自制的符合 Android Design 的分享功能也是不錯的選擇，比如右圖的?Timely，還有沒出現在圖片中的 Pocket，它們針對分享的內容 (文章和應用) 默認列出了幾個比較推薦的分享方式，同時也允許用戶點擊 More 來選擇其它的應用，免得用戶面對一長條的列表不知所措。

第三：利用 WebView 來模仿原生應用

如果你上過 YouTube 的話應該不難看出，左邊的應用整個就是源自 YouTube 網頁版的 ADiA 播放列表，只不過加了個 Action Bar 罷了。而右邊則是一個很不錯的例子，一個第三方的 ADiA 應用。它采用了響應式設計和原生界面，繼承了 Google+ 的評論和話題功能，提供每期 ADiA 幻燈片的查看功能，還有節目提醒，是一個非常棒的應用。

利用 WebView 來模擬原生應用并不是個聰明的選擇，因為實際上他的性質是欺騙用戶。如果你試圖用 WebView 來呈現 Android 的核心 UI 控件， 效果不會很好。而且，這么做也會造成運行效率的降低，于用戶而言就是不順滑，反應慢。

不要僅僅是為了"登陸 Android 平臺"而把一個 web app 打包成 APK 發布，Web App 就讓它以 web App 的形態存在吧，Android 歡迎 web Apps。用戶可以把 web Apps 以書簽的形式固定在桌面，完全沒必要專門發布一個偽裝成本地應用的 web App。實際上，用戶使用瀏覽器的時間越來越多了，瀏覽器的平均性能也在不斷提升，你并不會因為沒有發布本地應用就流失用戶。所以完全不必要為此擔心。

當然，并不是說完全的禁止使用 WebView。舉個例子，GMail 就采用了 HTML 來渲染郵件內容并且效果很棒，四次元之前也一直是采用 WebView 來進行圖片瀏覽。

第二：貧弱的首屏交互

無論對于什么樣的應用，首屏的重要性都是不言而喻的。開門見山的要用戶注冊，使用啟動畫面都是很糟糕的。用戶更希望應用能直接給它帶來內容，而登錄和注冊都最好留到萬不得已的時候再做（微博這樣的東西除外）。另外，先讓用戶明白你的應用到底是干嘛的然后再要求注冊，是比較合理的。

而正確的做法則是應該整合流行的社交網絡登錄選項，并且檢測用戶是否已經安裝了它們的客戶端，如果有，就可以直接通過客戶端驗證登錄，能夠大大減少輸入用戶名和密碼的麻煩。實際上，你可以做盡可能多的事情幫助用戶快速通過注冊和登錄，而不是讓他們感到煩躁。在這方面，整合 G+ 登錄的應用的體驗就是極好的，我只需要按下登錄按鈕，選擇賬戶，許可權限就行了，比起國內各種應用的輸入用戶名/郵箱/密碼要便捷太多。

另外，你也可以采用展示動畫/圖片幻燈來告訴用戶你的應用是干什么的。這方面做得很好的是?Next Browser。

第一：Android?≠ 豎屏手機

Android 設備千千萬，并不是只有豎屏的手機。糟糕的平板支持或者橫屏支持只會給你的品牌帶來負面的影響（如?MIUI 自帶應用都還沒有支持橫屏）。

有很多人確實是會橫著用手機的，比如說那些用車載底座/充電底座的用戶。橫屏支持的方式有很多，請挑選最合適的方案。而且這里的重點其實是，不要強迫用戶只使用某個方向的設備。

另外，Android 平板的占有率也在不斷變多，雖然手機和平板間的界限越來越模糊，但這可不是不提供平板支持/優化的接口。Android 設備幾乎囊括了從 3" 到 10" 間的所有尺寸，所以合理的利用響應式設計吧，它能提供更為合理的多屏支持。仔細考慮留白，布局和其他設計，不要忽視那些平板用戶。 只要一兩個小時的 XML 工作就能讓你做到很多東西。

到這里，十大常見錯誤就都說完了。如果你覺得還有什么常見的錯誤，請在評論或者微博評論或者 G+ 評論中告訴我。