Android開發目前是移動開發中的“當紅炸子雞”，大量Java程序員涌向Android，同時會習慣性地將桌面和Web端的開發/設計經驗帶到移動設備上。這樣的好處是充分利用了移動開發和桌面/Web服務的共性，比如廣泛使用的列表、本地數據庫等常用組件；壞處是移動和桌面/Web的使用場景和載體完全不同，直接移植桌面端開發的經驗有害無益。

比如，手機主要在碎片時間使用，用戶容易對復雜的界面設計感到疲憊；同時，移動環境中上網慢，網絡連接頻率和失敗重發機制的設計更有講究；此外，手機電池續航能力差，后臺復雜的計算會加速耗電速度。這些開發理念直接影響用戶最終體驗，下面我們來討論一下在Android中如何以用戶體驗為導向進行開發優化。

雖然不用深入了解底層，但需要對系統有基本的了解。Android系統分層清晰，***層是Linux Kernel 2.6，之上包含了Webkit、SQLite、OpenGL ES等基礎C/C++庫，同時Dalvik虛擬機運行于Kernel之上，幫助應用進行底層內存管理（這樣使Android應用無法直接進行內存釋放）。這些庫一方面被系統大量使用，另一方面也通過Framework層提供接口給開發者。此外，Framework層還提供其他系統級的服務，如消息通知服務、位置獲取服務、設備信息讀取服務等。

由此可見Android對于開發者非常開放和靈活，盡管如此，開發時仍然要注意不要過于隨意，以免產品過于復雜而讓用戶不知所措。當然，除了少數系統級應用開發需要深入了解Framework層實現機制之外，一般第三方應用開發者并不需要深入了解每一層原理，應把重點放在如何理解和靈活運用龐大的Android SDK API。

本文主要圍繞用戶的三種感覺來說明如何進行開發。

流暢的環境

讓用戶感覺使用非常流暢。遲緩會潛移默化地留下不好的印象。用戶看見App的圖標，便會在心中和“遲緩”、“卡”、“不穩定”畫上等號，產生“打開畏懼癥”。

用戶滑動Listview、Gallery、Coverflow時覺得卡，多半是因為相應Adapter對getView的處理不夠好。每個Item都會和數據源綁定，而數據源的獲取方式有多種：網絡、本地文件、SQLite數據庫、SharedPreference以及內存，它們的傳輸時間分別是7秒、2秒、1秒、100毫秒、5毫秒。

對于最耗時的網絡請求，很多人會采用異步操作，不會讓用戶耗費精力在網絡等待過程中。但在I/O以及SQLite查詢時，用戶的等待時間容易被忽略，從而降低滑動的流暢感。Android用戶常常遇到的ANR（Application Not Responding），便是這個問題的升級版。要知道，Activity Manager和Window Manager監視著應用程序的響應，當發現按鍵或觸摸發生后5秒還沒執行完處理邏輯，或是BroadcastReceiver處理時間超過了10秒，系統便會拋出ANR錯誤，并提醒用戶強制終止應用。

我的建議如下：

• 對于無法在短時間完成的操作，在獨立線程中處理，Android有多種異步處理模型可供使用，包括Thread-Handler、AsyncTask以及Loader and CursorLoader。 

• 盡可能減少復雜計算和降低I/O，充分估計對象的使用頻率，選擇合適的數據源。個人認為大部分應用中不會存在太多太大的對象，可以考慮將數據緩存在內存中。如果應用中有太多圖片不能一直緩存，可采用LRU（Least Recently Used ,最近最少使用）算法將不常用的緩存清理出內存，這樣緩存大小可控，從而不會出現Out of Memory（內存溢出）的Bug。 

但要注意，算法是把雙刃劍，如果你享受到類似LRU帶來的提速后的爽快，就可能會挖空心思探索更高效的算法。這時要慎重，后面會講到看上去很牛的算法帶來的問題。

另外，網絡等待雖然是最耗時，但卻容易被忽略。因為粗看上去網絡是不可控的，與開發無關。一般會設置幾秒鐘的超時，超時則重發。事實上，在國內，中國移動的GRPS網絡占主導，所以手機上網普遍很慢，HTTP連接上下行10秒是很正常的，超時設置20秒都不為過。同時，根據友盟對Android應用使用的統計，用戶在每個App上的一次啟動花費時間是1分鐘左右，理論上有3次重發機會，但一次超時（假設是20秒）后，用戶就已經失去信心，不會再等待一次了。所以在開發時，要結合具體使用場景，設計數據預取機制，盡量降低網絡請求次數，同時考慮gzip、protobuf等數據壓縮和編碼機制，保證一次取到的數據不至于太大而造成額外延時。

友好的體驗

不友好的體驗來自三個方面。

其一是Android的碎片化帶來了UI適配問題。Android機型眾多，和iPhone相比，界面適配飽受詬病。要保證應用能運行在不同分辨率的手機上，需要理解Android提供的自動適配方案。事實上，Android系統為UI適配做了充分的考慮，只要理解系統對此的精心設計，就能在開發時少走很多彎路，給不同分辨率的用戶提供友好的呈現界面。
簡單來說可做如下解釋：

• 開發時避免絕對布局（AbsoluteLayout），因為這會讓你的應用只在測試機上“看上去很美”，放到別處就橫七豎八。 

• 界面控件大小單位多用DIP（Device Independent Pixels），理由同上。 

• 圖片盡量使用系統提供的NinePatch技術，能使同一張小圖片在不同分辨率的屏幕上保持精度自由縮放。 

其二是濫用通知服務，導致用戶很容易被打斷。典型場景是在通知欄上的各種通知消息，有關無關的都推送，讓用戶感覺不適。建議是通知適可而止，除非是對用戶真正有用的信息，否則***讓用戶進入程序后再提示。

其三是主要來自設計師的問題，就是照搬iPhone應用的設計。Android的系統特點不同于iPhone，如程序的棧式管理機制、菜單按鈕、返回按鈕，從而用戶的預期也不盡相同。比如我發現很多設計師喜歡拋棄返回鍵，模仿iPhone給每一頁設計一個軟返回按鈕。生硬做作的移植會導致與用戶預期不一致，是徹底的設計敗筆。

節省電量

隨時都得插在墻上充電的設備，不叫移動設備。如果你的App讓用戶一直守著墻角，用戶也會很快把你丟到墻角。你會問：“他怎么知道我的應用耗電？”很抱歉，目前來看，Android用戶中有大量發燒友和技術高手，同時系統很不客氣地記錄了每個應用的耗電量，于是用戶偶爾會去系統后臺查查耗電大戶，之后會毫不客氣地打開卸載工具。

所以需注意以下幾點：

***，不要絞盡腦汁設計復雜算法，不要在后臺跑服務，不要網斷了還不停重試。在開發一個模塊前先想想會不會費電，如果會，就不要去做。代碼是為了服務用戶，而不是折騰用戶。

高手喜歡挑戰，尤其在手機上實現精巧的算法，這樣能帶來更強的征服感。有人曾在手機上實現了布隆過濾器（一個龐大精巧的類哈希表，多用于在服務器端如垃圾郵件查找），其內存消耗和計算復雜度都遠遠高于普通的HashMap，且實現并不容易。結果App發布之后，出現用戶抱怨耗電量大，并且經常出現Bug，***還是老老實實換成了HashMap。任何算法的目的都是為了服務用戶，如果簡單自然的方法能更好地做到這點，何樂而不為？如果真的在客戶端找不到簡單的算法，則需要反思——為什么在手機上需要復雜的計算？是否該將這些計算放在服務器端？

第二，不要在后臺濫用Service。Android非常開放，開發者可在后臺觸發任何處理邏輯，肆意占用CPU和內存。一般來說，Service的目的是為了監控變化，包括系統和網絡變化。系統變化可通過注冊BroadcastReceiver監聽控制，比如應用安裝和卸載等事件，這樣耗電量非常小，完全可替代在Service中輪播。網絡請求無法用BroadcastReceiver監聽，但是有兩個建議。

• 無嚴苛的實時性要求，可延長輪播間隔，如6小時自動請求一次，同時時間隔可通過服務器在線更新。這樣既省電，偶爾急需實時推送時也可在線調整時間間隔。 

• 對實時性有要求，考慮使用成熟的推送服務，如Google的C2DM（http://code.google.com/Android/c2dm/），和亞馬遜的AWS SDK （http://aws.amazon.com/sdkforAndroid/）。 

第三，網絡請求不要太頻繁。系統組件中最耗電的是屏幕，其次就是網絡。前文已經提到過，網絡出錯重發會降低用戶體驗，還會耗費電力。可通過數據預取結合數據壓縮算法減少網絡請求次數。

總之，在開發時我們要替用戶思考是否做到了“流暢、友好、省電”，以保證App擁有不錯的用戶體驗。

作者陳彧堃，曾任職于微軟研究院，從事數據挖掘及機器學習的相關研究，對時空數據挖掘，普適計算等領域有深入了解。2010年4月加入友盟，開始打造友盟移動開發平臺。