您好,登錄后才能下訂單哦!
到目前為止,android的平臺手機的市場占有率是最大的,那么app的開發數量也很龐大,但是成功的卻很少,原因有很多,那最有可能的就是界面奇慢無比、耗電、耗內存。接下來就會得到用戶的消極評論,最后名聲也就臭了。即使你的應用設計精良、創意無限也沒用。
耗電或者內存占用等影響產品效率的每一個問題都會影響App的成功。這就是為什么在開發中確保最優化、運行流暢而且不會使Android系統出問題 是至關重要的了。這里不需要討論高效編程,因為我們不會關心你寫的代碼是否能夠經得起測試。即使高效的代碼也是需要時間來運行。今天這篇文章我們就講講怎 么盡可能地縮短運行時間,以及如何開發用戶喜歡的App。
我們知道App運行過程中所有的操作都默認在主線程(UI線程)中進行的,這樣App的響應速度就會受到影響。會導致程序陷入卡頓、死掉甚至會發生系統錯誤。
為了加快響應速度,需要把費時的操作(比如網絡請求、數據庫操作或者復雜的計算)從主線程移動到一個單獨的線程中。最高效的方式就是在類這一級完成 這項操作,可以使用AsyncTask或者IntentService來創建后臺操作。如果選擇使用IntentService,它會在需要的時候啟動起 來,然后通過一個工作線程來處理請求(Intent)。
使用IntentService時需要注意以下幾點限制:
這個類不要給UI傳遞信息,如果要向用戶展示處理結果信息請用Activity;
每次只能處理一個請求;
每一個處理請求過程都不能中斷;
從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的時候,就是在創建濫用內存的App,它在UI中會出現可惡的延時。要實現一個流暢的、低內存占用的UI,第一步就是搜索 你的應用找出潛在的瓶頸布局。使用Android SDK/tools/中自帶的Hierarchy Viewer Tool工具。
還有一個很好的工具就是Lint,它會掃描應用的源碼去尋找可能存在的bug,并為控件結果進行優化。
如果布局顯示結果發現了問題,你可以考慮簡化布局結構。可以把LinearLayout類型轉化成RelativeLayout類型,降低布局的層級結構。
盡管以上的每條建議看起來都是很小的改進,但是如果它能成為你日常代碼的一部分,那么你就會看到意想不到的結果。要讓Google Play看到更多杰出的、流暢的、更快速、更省電的應用,向Android走向完美的目標邁進一步。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。