萬盛學電腦網

 萬盛學電腦網 >> 網絡編程 >> 安卓開發 >> 用戶體驗導向的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等數據壓縮和編碼機制,保證一次取到的數據不至於太大而造成額外延時。

用戶體驗導向的Android應用開發 三聯教程

  Android架構圖(圖片來源:http://developer.Android.com/guide/basics/what-is-Android.html)

  友好的體驗

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

  其一是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月加入友盟,開始打造友盟移動開發平台。

  文章來源:程序員官網

copyright © 萬盛學電腦網 all rights reserved