假如要Google Play上作一個最失敗的案例,那最好的祕訣就是界面奇慢無比、耗電、耗內存。接下來就會獲得用戶的消極評論,最後名聲也就臭了。即便你的應用設計精良、創意無限也沒用。php
耗電或者內存佔用等影響產品效率的每個問題都會影響App的成功。這就是爲何在開發中確保最優化、運行流暢並且不會使Android系統出問題是相當重要的了。這裏不須要討論高效編程,由於咱們不會關心你寫的代碼是否可以經得起測試。即便高效的代碼也是須要時間來運行。今天這篇文章咱們就講講怎麼儘量地縮短運行時間,以及如何開發用戶喜歡的App。html
高效地利用線程
建議一:怎麼在後臺取消一些線程中的動做
咱們知道App運行過程當中全部的操做都默認在主線程(UI線程)中進行的,這樣App的響應速度就會受到影響。會致使程序陷入卡頓、死掉甚至會發生系統錯誤。前端
爲了加快響應速度,須要把費時的操做(好比網絡請求、數據庫操做或者複雜的計算)從主線程移動到一個單獨的線程中。最高效的方式就是在類這一級完成這項操做,可使用AsyncTask或者IntentService來建立後臺操做。若是選擇使用IntentService,它會在須要的時候啓動起來,而後經過一個工做線程來處理請求(Intent)。android
使用IntentService時須要注意如下幾點限制:正則表達式
- 這個類不要給UI傳遞信息,若是要向用戶展現處理結果信息請用Activity;
- 每次只能處理一個請求;
- 每個處理請求過程都不能中斷;
建議二:怎麼保持響應不發生ANR
從UI線程中移除費時操做這個方式還能夠防止用戶操做出現系統不響應(ANR)對話框。須要作的就是繼承AsyncTask來建立一個後臺工做線程,並實現doInBackground()方法。數據庫
還有一種方式就是本身建立一個Thread類或者HandlerThread類。須要注意這樣也會使App變慢,由於默認的線程優先級和主線程的優先級是同樣的,除非你明確設定線程的優先級。編程
建議三:怎麼在線程中初始化查詢操做
當查詢操做正在後臺處理時,展現數據也不是即時的,可是你可使用CursorLoader對象來加快速度,這個操做可使Activity和用戶之間的互動不受影響。緩存
使用這個對象後,你的App會爲ContentProvider初始化一個獨立的後臺線程進行查詢,當查詢結束後就會給調用查詢的Activity返回結果。安全
建議四:其它須要注意的方面
- 使用StrictMode來檢查UI線程中可能潛在的費時操做;
- 使用一些特殊的工具如Systrace或者Traceview來尋找在你的應用中的瓶頸;
- 用進度條向用戶展現操做進度;
- 若是初始化操做很費時,請展現一個歡迎界面。
優化設備的電池壽命
若是應用很費電,請不要責怪用戶卸載了你的應用。對於電池使用來講,主要費電狀況以下:服務器
- 更新數據時常常喚醒程序;
- 用EDGE或者3G來傳遞數據;
- 文本數據轉換,進行非JIT正則表達式操做。
建議五:怎麼優化網絡
- 若是沒有網絡鏈接,請讓你的應用跳過網絡操做;只在有網絡鏈接而且無漫遊的狀況下更新數據;
- 選擇兼容的數據格式,把含有文本數據和二進制數據的請求所有轉化成二進制數據格式請求;
- 使用高效的轉換工具,多考慮使用流式轉換工具,少用樹形的轉換工具;
- 爲了更快的用戶體驗,請減小重複訪問服務器的操做;
- 若是能夠的話,請使用framework的GZIP庫來壓縮文本數據以高效使用CPU資源。
建議六:怎麼優化應用在前端的工做
- 若是考慮使用wakelocks,儘可能設置爲最小的級別;
- 爲了防止潛在的bug致使的電量消耗,請明確指定超時時間;
- 啓用 android:keepScreenOn屬性;
- 除了系統的GC操做,多考慮手動回收Java對象,好比XmlPullParserFactory和BitmapFactory。還有正則表達式的Matcher.reset(newString)操做、StringBuilder.setLength(0)操做;
- 要注意同步的問題,儘管在主線程中是安全的;
- 在Listview中要多采用重複利用策略;
- 若是容許的話多使用粗略的網絡定位而不用GPS,對比一下GPS須要1mAh(25s * 140 mA),而通常網絡只用0.1mAh(2s * 180mA);
- 確保註銷GPS的位置更新操做,由於這個更新操做在onPause()中也是會繼續的。當全部的應用都註銷了這個操做,用戶能夠在系統設置中從新啓用GPS而不浪費電量;
- 請考慮在大量數理運算中使用低精度變量並在用DisplayMetrics進行DPI任務時緩存變量值;
建議七:怎麼優化工做在前臺的應用
- 請確保service生命週期都是短暫的,由於每一個進程都須要2MB的內存,而在前臺程序須要內存時也會從新啓動;
- 保持內存的使用量不要太大;
- 若是要應用每30分鐘更新一次,請在設備處於喚醒狀態下進行;
- Service在pull或者sleep狀態都是很差的,這就是爲何在服務結束時要使用AlarmManager或者配置屬性stopSelf()的緣由。
建議八:其它注意事項
- 在進行總體更新以前檢查電池的狀態和網絡狀態,等待最好的狀態在進行大幅度裝換操做;
- 讓用戶看到用電狀況,好比更新週期,後臺操做的時候;
實現低內存佔用UI
建議九:怎麼找到佈局顯示問題
當咱們爲佈局單首創建UI的時候,就是在建立濫用內存的App,它在UI中會出現可惡的延時。要實現一個流暢的、低內存佔用的UI,第一步就是搜索你的應用找出潛在的瓶頸佈局。使用Android SDK/tools/中自帶的Hierarchy Viewer Tool工具。
還有一個很好的工具就是Lint,它會掃描應用的源碼去尋找可能存在的bug,併爲控件結果進行優化。
建議十:如何解決問題
若是佈局顯示結果發現了問題,你能夠考慮簡化佈局結構。能夠把LinearLayout類型轉化成RelativeLayout類型,下降佈局的層級結構。
作到更加完美並不斷優化
儘管以上的每條建議看起來都是很小的改進,可是若是它能成爲你平常代碼的一部分,那麼你就會看到意想不到的結果。要讓Google Play看到更多傑出的、流暢的、更快速、更省電的應用,向Android走向完美的目標邁進一步。
原文連接: azoft 翻譯: 伯樂在線 - chris