溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

10個提高Android App性能的建議

發(fā)布時間:2020-07-27 04:57:22 來源:網(wǎng)絡(luò) 閱讀:558 作者:ouyeaa 欄目:移動開發(fā)

到目前為止,android的平臺手機(jī)的市場占有率是最大的,那么app的開發(fā)數(shù)量也很龐大,但是成功的卻很少,原因有很多,那最有可能的就是界面奇慢無比、耗電、耗內(nèi)存。接下來就會得到用戶的消極評論,最后名聲也就臭了。即使你的應(yīng)用設(shè)計精良、創(chuàng)意無限也沒用。


耗電或者內(nèi)存占用等影響產(chǎn)品效率的每一個問題都會影響App的成功。這就是為什么在開發(fā)中確保最優(yōu)化、運(yùn)行流暢而且不會使Android系統(tǒng)出問題 是至關(guān)重要的了。這里不需要討論高效編程,因為我們不會關(guān)心你寫的代碼是否能夠經(jīng)得起測試。即使高效的代碼也是需要時間來運(yùn)行。今天這篇文章我們就講講怎 么盡可能地縮短運(yùn)行時間,以及如何開發(fā)用戶喜歡的App。


高效地利用線程

建議一:怎么在后臺取消一些線程中的動作

我們知道App運(yùn)行過程中所有的操作都默認(rèn)在主線程(UI線程)中進(jìn)行的,這樣App的響應(yīng)速度就會受到影響。會導(dǎo)致程序陷入卡頓、死掉甚至?xí)l(fā)生系統(tǒng)錯誤。

為了加快響應(yīng)速度,需要把費時的操作(比如網(wǎng)絡(luò)請求、數(shù)據(jù)庫操作或者復(fù)雜的計算)從主線程移動到一個單獨的線程中。最高效的方式就是在類這一級完成 這項操作,可以使用AsyncTask或者IntentService來創(chuàng)建后臺操作。如果選擇使用IntentService,它會在需要的時候啟動起 來,然后通過一個工作線程來處理請求(Intent)。

使用IntentService時需要注意以下幾點限制:

  • 這個類不要給UI傳遞信息,如果要向用戶展示處理結(jié)果信息請用Activity;

  • 每次只能處理一個請求;

  • 每一個處理請求過程都不能中斷;

建議二:怎么保持響應(yīng)不發(fā)生ANR

從UI線程中移除費時操作這個方式還可以防止用戶操作出現(xiàn)系統(tǒng)不響應(yīng)(ANR)對話框。需要做的就是繼承AsyncTask來創(chuàng)建一個后臺工作線程,并實現(xiàn)doInBackground()方法。

還有一種方式就是自己創(chuàng)建一個Thread類或者HandlerThread類。需要注意這樣也會使App變慢,因為默認(rèn)的線程優(yōu)先級和主線程的優(yōu)先級是一樣的,除非你明確設(shè)定線程的優(yōu)先級。

建議三:怎么在線程中初始化查詢操作

當(dāng)查詢操作正在后臺處理時,展示數(shù)據(jù)也不是即時的,但是你可以使用CursorLoader對象來加快速度,這個操作可以使Activity和用戶之間的互動不受影響。

使用這個對象后,你的App會為ContentProvider初始化一個獨立的后臺線程進(jìn)行查詢,當(dāng)查詢結(jié)束后就會給調(diào)用查詢的Activity返回結(jié)果。

建議四:其它需要注意的方面
  • 使用StrictMode來檢查UI線程中可能潛在的費時操作;

  • 使用一些特殊的工具如Systrace或者Traceview來尋找在你的應(yīng)用中的瓶頸;

  • 用進(jìn)度條向用戶展示操作進(jìn)度;

  • 如果初始化操作很費時,請展示一個歡迎界面。

優(yōu)化設(shè)備的電池壽命

如果應(yīng)用很費電,請不要責(zé)怪用戶卸載了你的應(yīng)用。對于電池使用來說,主要費電情況如下:

  • 更新數(shù)據(jù)時經(jīng)常喚醒程序;

  • 用EDGE或者3G來傳遞數(shù)據(jù);

  • 文本數(shù)據(jù)轉(zhuǎn)換,進(jìn)行非JIT正則表達(dá)式操作。

建議五:怎么優(yōu)化網(wǎng)絡(luò)
  • 如果沒有網(wǎng)絡(luò)連接,請讓你的應(yīng)用跳過網(wǎng)絡(luò)操作;只在有網(wǎng)絡(luò)連接并且無漫游的情況下更新數(shù)據(jù);

  • 選擇兼容的數(shù)據(jù)格式,把含有文本數(shù)據(jù)和二進(jìn)制數(shù)據(jù)的請求全部轉(zhuǎn)化成二進(jìn)制數(shù)據(jù)格式請求;

  • 使用高效的轉(zhuǎn)換工具,多考慮使用流式轉(zhuǎn)換工具,少用樹形的轉(zhuǎn)換工具;

  • 為了更快的用戶體驗,請減少重復(fù)訪問服務(wù)器的操作;

  • 如果可以的話,請使用framework的GZIP庫來壓縮文本數(shù)據(jù)以高效使用CPU資源。

建議六:怎么優(yōu)化應(yīng)用在前端的工作
  • 如果考慮使用wakelocks,盡量設(shè)置為最小的級別;

  • 為了防止?jié)撛诘腷ug導(dǎo)致的電量消耗,請明確指定超時時間;

  • 啟用 android:keepScreenOn屬性;

  • 除了系統(tǒng)的GC操作,多考慮手動回收J(rèn)ava對象,比如XmlPullParserFactory和BitmapFactory。還有正則表達(dá)式的Matcher.reset(newString)操作、StringBuilder.setLength(0)操作;

  • 要注意同步的問題,盡管在主線程中是安全的;

  • 在Listview中要多采用重復(fù)利用策略;

  • 如果允許的話多使用粗略的網(wǎng)絡(luò)定位而不用GPS,對比一下GPS需要1mAh(25s * 140 mA),而一般網(wǎng)絡(luò)只用0.1mAh(2s * 180mA);

  • 確保注銷GPS的位置更新操作,因為這個更新操作在onPause()中也是會繼續(xù)的。當(dāng)所有的應(yīng)用都注銷了這個操作,用戶可以在系統(tǒng)設(shè)置中重新啟用GPS而不浪費電量;

  • 請考慮在大量數(shù)理運(yùn)算中使用低精度變量并在用DisplayMetrics進(jìn)行DPI任務(wù)時緩存變量值;

建議七:怎么優(yōu)化工作在前臺的應(yīng)用
  • 請確保service生命周期都是短暫的,因為每個進(jìn)程都需要2MB的內(nèi)存,而在前臺程序需要內(nèi)存時也會重新啟動;

  • 保持內(nèi)存的使用量不要太大;

  • 如果要應(yīng)用每30分鐘更新一次,請在設(shè)備處于喚醒狀態(tài)下進(jìn)行;

  • Service在pull或者sleep狀態(tài)都是不好的,這就是為什么在服務(wù)結(jié)束時要使用AlarmManager或者配置屬性stopSelf()的原因。

建議八:其它注意事項
  • 在進(jìn)行整體更新之前檢查電池的狀態(tài)和網(wǎng)絡(luò)狀態(tài),等待最好的狀態(tài)在進(jìn)行大幅度裝換操作;

  • 讓用戶看到用電情況,比如更新周期,后臺操作的時候;

實現(xiàn)低內(nèi)存占用UI

建議九:怎么找到布局顯示問題

當(dāng)我們?yōu)椴季謫为殑?chuàng)建UI的時候,就是在創(chuàng)建濫用內(nèi)存的App,它在UI中會出現(xiàn)可惡的延時。要實現(xiàn)一個流暢的、低內(nèi)存占用的UI,第一步就是搜索 你的應(yīng)用找出潛在的瓶頸布局。使用Android SDK/tools/中自帶的Hierarchy Viewer Tool工具。

還有一個很好的工具就是Lint,它會掃描應(yīng)用的源碼去尋找可能存在的bug,并為控件結(jié)果進(jìn)行優(yōu)化。

建議十:如何解決問題

如果布局顯示結(jié)果發(fā)現(xiàn)了問題,你可以考慮簡化布局結(jié)構(gòu)??梢园袻inearLayout類型轉(zhuǎn)化成RelativeLayout類型,降低布局的層級結(jié)構(gòu)。

做到更加完美并不斷優(yōu)化

盡管以上的每條建議看起來都是很小的改進(jìn),但是如果它能成為你日常代碼的一部分,那么你就會看到意想不到的結(jié)果。要讓Google Play看到更多杰出的、流暢的、更快速、更省電的應(yīng)用,向Android走向完美的目標(biāo)邁進(jìn)一步。


向AI問一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI