保證Android應用擁有良好使用者體驗的三要素

文章描述：使用者體驗導向的Android應用開發.

文 / 陳彧堃

本文指出“流暢的環境”、“友好的體驗”和“節省電量”是保證Android應用擁有良好使用者體驗的三要素。

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等資料壓縮和編碼機制，保證一次取到的資料不至於太大而造成額外延時。

[1] [2]  下一頁