Android應用體驗如何做到更加流暢

讓使用者感覺使用非常流暢。遲緩會潛移默化地留下不好的印象。使用者看見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等資料壓縮和編碼機制，保證一次取到的資料不至于太大而造成額外延時。

本文轉自 wws5201985 51CTO部落格，原文連結：http://blog.51cto.com/wws5201985/785809，如需轉載請自行聯系原作者