如何進行用戶體驗導向的Android應用開發(fā)

如何進行用戶體驗導向的Android應用開發(fā)，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

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

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

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

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

下面主要圍繞用戶的三種感覺來說明如何進行開發(fā)。

流暢的環(huán)境

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

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

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

我的建議如下：

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

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

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

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

Android架構圖

友好的體驗

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

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

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

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

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

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

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

節(jié)省電量

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

所以需注意以下幾點：

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

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

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

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

• 對實時性有要求，考慮使用成熟的推送服務。

第三，網(wǎng)絡請求不要太頻繁。系統(tǒng)組件中最耗電的是屏幕，其次就是網(wǎng)絡。網(wǎng)絡出錯重發(fā)會降低用戶體驗，還會耗費電力?？赏ㄟ^數(shù)據(jù)預取結合數(shù)據(jù)壓縮算法減少網(wǎng)絡請求次數(shù)。

關于如何進行用戶體驗導向的Android應用開發(fā)問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業(yè)資訊頻道了解更多相關知識。