文 / 陳彧堃

本文指出“流暢的環(huán)境”、“友好的體驗(yàn)”和“節(jié)省電量”是保證Android應(yīng)用擁有良好用戶體驗(yàn)的三要素。

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

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

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

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

本文主要圍繞用戶的三種感覺(jué)來(lái)說(shuō)明如何進(jìn)行開(kāi)發(fā)。

流暢的環(huán)境

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

用戶滑動(dòng)Listview、Gallery、Coverflow時(shí)覺(jué)得卡，多半是因?yàn)橄鄳?yīng)Adapter對(duì)getView的處理不夠好。每個(gè)Item都會(huì)和數(shù)據(jù)源綁定，而數(shù)據(jù)源的獲取方式有多種：網(wǎng)絡(luò)、本地文件、SQLite數(shù)據(jù)庫(kù)、SharedPreference以及內(nèi)存，它們的傳輸時(shí)間分別是7秒、2秒、1秒、100毫秒、5毫秒。

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

我的建議如下：

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

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

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

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

標(biāo)簽： 應(yīng)用 ��

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。