Android效能最佳化的淺談，android效能最佳化

Android效能最佳化的淺談，android效能最佳化

一、概要：

　　　　本文主要以Android的渲染機制、UI最佳化、多線程的處理、緩衝處理、電量最佳化以及代碼規範等幾方面來簡述Android的效能最佳化

 

二、渲染機制的最佳化：

　　　　大多數使用者感知到的卡頓等效能問題的最主要根源都是因為渲染效能。

　　　　Android系統每隔16ms發出VSYNC訊號，觸發對UI進行渲染， 如果每次渲染都成功，這樣就能夠達到流暢的畫面所需要的60fps，為了能夠實現60fps，這意味著程式的大多數操作都必須在16ms內完成。

　　　　

　　　　如果你的某個操作花費時間是24ms，系統在得到VSYNC訊號的時候就無法進行正常渲染，這樣就發生了丟幀現象。那麼使用者在32ms內看到的會是同一幀畫面。

　　　　

　　　　Probably：也許是因為你的layout太過複雜，無法在16ms內完成渲染，有可能是因為你的UI上有層疊太多的繪製單元，還有可能是因為動畫執行 的次數過多。這些都會導致CPU或者GPU負載過重。

　　　　Resolved：我們可以通過一些工具來定位問題，比如可以使用HierarchyViewer來尋找Activity中的布局是否過於複雜，也可以使用手機設定裡 面的開發人員選項，開啟Show GPU Overdraw等選項進行觀察。

　　　　　　　　　 你還可以使用TraceView來觀察CPU的執行情況，更加快捷的找到效能瓶頸。

　　　　

　　　　淺談Overdraw（過度繪製）：

　　　　　　Overdraw(過度繪製)描述的是螢幕上的某個像素在同一幀的時間內被繪製了多次。在多層次的UI結構裡面，如果不可見的UI也在做繪製的操作，這就會導致某些像素地區被繪製了多次。這就浪費大量的CPU以及GPU資源。 

　　　　　　

　　　　　　Tips：我們可以通過手機設定裡面的開發人員選項，開啟Show GPU Overdraw的選項，可以觀察UI上的Overdraw情況

　　　　　　

　　　　　　圖解：藍色，淡綠，淡紅，深紅代表了4種不同程度的Overdraw情況，我們的目標就是盡量減少紅色Overdraw，看到更多的藍色地區。

　　　　　　Tips：Overdraw有時候是因為你的UI布局存在大量重疊的部分，還有的時候是因為非必須的重疊背景。例如某個Activity有一個背景，然后里面 的Layout又有自己的背景，同時子View又分別有自己的背景。

　　　　　　僅僅是通過移除非必須的背景圖片，這就能夠減少大量的紅色Overdraw地區，增加 藍色地區的佔比。這一措施能夠顯著提升程式效能。

 

　　　　　　注意：如需擷取更多渲染機制的內容，請移步 https://www.oschina.net/news/60157/android-performance-patterns

 

三、UI方面的最佳化：

 　　　　1）首先簡單談談view的繪製流程：measure - layout - draw

 　　　　

　　　　　　ps:具體的流程網上一搜一大把+_+

　　　　　2）子控制項越多，繪製的時間也就越長。

　　　　　　對於Listview或者GridView這種多item的組件來說，複用item可以減少inflate次數，通過setTag，getTag的ViewHolder方式實現複用，這裡要注意的是，holder中的控制項最好reset後再賦值，避免圖片，文字錯亂。

　　　　　　*以下簡單的例子：（盡量使用註解，有很多註解的開源架構可以使用：butterKnife, AndroidAnnotation, Dragger2）

 1 static class ViewHolder{ 2     @InjectView(R.id.imageView1) 3     ImageView imageView1; 4     @InjectView (R.id.text1) 5     TextView textView1; 6 } 7  8 @Override 9 public View getView(int position, View convertView, ViewGroup parent) {10     ViewHolder holder;11              12     if(convertView == null){13        holder = new ViewHolder();14        convertView = LayoutInflater.from(mContext).inflate(R.layout.listview_item, null);15        convertView.setTag(holder);16      }else{17          holder = (ViewHolder)convertView.getTag();18      }19              20          holder.imageView1.setImageResource(R.drawable.ic_launcher);21          holder.textView1.setText(mData.get(position));  22              23          return convertView;24 }

　　　　3）UI ReView（視圖的檢查）　

　　　　　　1. 減少視圖層級可以有效減少記憶體消耗，因為視圖是一個樹形結構，每次重新整理和渲染都會遍曆一次。

　　　　　　2. 想要減少視圖層級首先就需要知道視圖層級，所以下面介紹一個SDK中內建的一個非常好用的工具hierarchyviewer。你可以在下面的地址找到它：your sdk path\sdk\tools

　　　　　　

　　　　　　3. 如大家可以看到，hierarchyviewer可以非常清楚的看到當前視圖的層級結構，並且可以查看視圖的執行效率（視圖上的小圓點，綠色表示流暢，黃色和紅色次之），所以我們可以很方便的查看哪些view可能會影響我們的效能從而去進一步最佳化它。

　　　　　　　hierarchyviewer還提供另外一種列表式的查看方式，可以查看詳細的螢幕畫面，具體到像素層級的問題都可以通過它發現。

 　　　　　　

　　　   4）一些標籤的使用

　　　　　　<merge> ：它在最佳化UI結構時起到很重要的作用。目的是通過刪減多餘或者額外的層級，從而最佳化整個Android Layout的結構，最佳化布局層數。

　　　　　　<include > ：可以通過這個標籤直接載入外部的xml到當前結構中，是複用UI資源的常用標籤，來共用布局。

　　　　　　<ViewStub> : 動態載入view，此標籤可以使UI在特殊情況下，直觀效果類似於設定View的不可見度，但是其更大的意義在於被這個標籤所包裹的Views在預設狀態下不會佔用任何記憶體空間。

 

四、多線程的處理：

　　　1. Android 提供的多種多線程工具類 (AsyncTask, HandlerThread, IntentService, ThreadPool)，許多操作都需要由 主線程（UI 線程）來執行，比如：

　　　　　　

　　　　　　2. Android 系統的螢幕重新整理頻率為 60 fps, 也就是每隔 16 ms 重新整理一次。如果在某次繪製過程中，我們的操作不能在 16 ms 內完成，那它則不能趕上這次的繪製公交車，只能等下一輪。

　　　　　　 這種現象叫做 “掉幀”，使用者看到的就是介面繪製不連續、卡頓。

　　　　　　

　　　　　　3. HandlerThread 就是MessageQueue，Looper和 Handler 的組合。每個應用啟動時，系統會建立一個該應用的進程以及主線程，這裡的主線程就是一個 HandlerThread。

　　　　　　

　　　　　　4. 注意問題：

　　　　　　　1）多線程並發訪問資源要遵循重要的原則就是 原子性、可見度、有序性。沒有同步機制的情況下，多個線程同時讀寫記憶體可能會導致意料之外的問題：

　　　　　　　①安全執行緒的問題； ② UI 組件的生命週期並不確定；③線程引用導致的記憶體流失問題

　　　　　     2）不要在任何子線程持有 UI 組件或者 Activity 的引用

　　　　　　 3）保持響應不發生ANR: 

　　　　　　　　①從UI線程中移除費時操作這個方式還可以防止使用者操作出現系統不響應（ANR）對話方塊。需要做的就是繼承AsyncTask來建立一個後台背景工作執行緒，並實現doInBackground()方法。

　　　　　　　　②還有一種方式就是自己建立一個Thread類或者HandlerThread類，明確設定線程的優先順序。

　　　　　　 4）使用StrictMode來檢查UI線程中可能潛在的費時操作，使用一些特殊的工具如Safe.ijiami、Systrace或者Traceview來尋找在你的應用中的瓶頸；用進度條向使用者展示操作進度。

 

五、緩衝處理：

　　簡單的說說緩衝最佳化的幾個方面：

　　　 緩衝機制：網路+資料庫。為了避免從網路擷取重複的資料，可以在activity或者fragment或者每個組件設定一個最大請求間隔。

　　　　　　　　比如一個listview，第一次請求資料時，儲存一份到資料庫，並記下時間戳記，當下次重新初始化時，判斷是否超過最大時間間隔(如5分鐘)，如果沒有，只載入資料庫資料，不需要再做網路請求。

　　　　　　　　（當然，還有一些隱式的http請求架構會快取服務器資料，在一定時間內不再請求網路，或者當伺服器返回304時將之前緩衝的資料直接返回）

 

　

　　　網路方面：1）需要服務端配合的：json資料格式，WebP代替jpg，支援斷點續傳，多個請求合并成一個，盡量不做重新導向，伺服器緩衝以及負載平衡等。

　　　　　　　　2）對用戶端本身，除了上述的實現，我們還需要合理的緩衝，控制最大請求並發量，及時取消已失效的請求，過濾重複請求，timeout時間設定，請求優先順序設定等。

 　　　　　　　　

　　　　　　　　* WebP：WebP 的優勢體現在它具有更優的映像資料壓縮演算法，能帶來更小的圖片體積，而且擁有肉眼識別無差異的映像品質；

　　　　　　　　　　　　 同時具備了無損和有損的壓縮模式、Alpha 透明以及動畫的特性，在 JPEG 和 PNG 上的轉化效果都相當優秀、穩定和統一。

　　　　　　　　　　　　 

　　　　　　　　　　　　   轉換後的 WebP 支援 Alpha 透明和 24-bit 顏色數，不存在 PNG8 色彩不夠豐富和在瀏覽器中可能會出現毛邊的問題。

　　　　　　　　　　　　  * 更多瞭解請看：http://isux.tencent.com/introduction-of-webp.html

 

 

 六、電量最佳化：

 　　　　有下面一些措施能夠顯著減少電量的消耗：

• • • 我們應該盡量減少喚醒螢幕的次數與持續的時間，使用WakeLock來處理喚醒的問題，能夠正確執行喚醒操作並根據設定及時關閉操作進入睡眠狀態。

    • 某些非必須馬上執行的操作，例如上傳歌曲，圖片處理等，可以等到裝置處於充電狀態或者電量充足的時候才進行。

    • 觸發網路請求的操作，每次都會保持無線訊號持續一段時間，我們可以把零散的網路請求打包進行一次操作，避免過多的無線訊號引起的電量消耗。

　　　　　　　　關於網路請求引起無線訊號的電量消耗，還可以參考這裡http://hukai.me/android-training-course-in-chinese/connectivity/efficient-downloads/efficient-network-access.html

　　　　

 

　　　　Ask：假設你的手機裡面裝了大量的社交類應用，即使手機處於待機狀態，也會經常被這些應用喚醒用來檢查同步新的資料資訊。

　　　　Android會不斷關閉各種硬 件來延長手機的待機時間，首先螢幕會逐漸層暗直至關閉，然後CPU進入睡眠，這一切操作都是為了節約寶貴的電量資源。但是即使在這種睡眠狀態下，大多數應 用還是會嘗試進行工作，他們將不斷的喚醒手機。

　　　　一個最簡單的喚醒手機的方法是使用PowerManager.WakeLock的API來保持CPU工作並 防止螢幕變暗關閉。這使得手機可以被喚醒，執行工作，然後回到睡眠狀態。知道如何擷取WakeLock是簡單的，可是及時釋放WakeLock也是非常重 要的。

　　　　不恰當的使用WakeLock會導致嚴重錯誤。例如網路請求的資料返回時間不確定，導致本來只需要10s的事情一直等待了1個小時，這樣會使得電量 白白浪費了。這也是為何使用帶逾時參數的wakelock.acquice()方法是很關鍵的。

　　　　但是僅僅設定逾時並不足夠解決問題，例如設定多長的逾時比 較合適？什麼時候進行重試等等？

 

　　　　Resolved：解決上面的問題，正確的方式可能是使用非精準定時器。通常情況下，我們會設定一個時間進行某個操作，但是動態修改這個時間也許會更好。

　　　　例如，如果有 另外一個程式需要比你設定的時間晚5分鐘喚醒，最好能夠等到那個時候，兩個任務捆綁一起同時進行，這就是非精確定時器的核心工作原理。我們可以定製計劃的 任務，可是系統如果檢測到一個更好的時間，它可以延遲你的任務，以節省電量消耗。

　　　　

　　　　* 關於JobScheduler的更多知識可以參考 http://hukai.me/android-training-course-in-chinese/background-jobs/scheduling/index.html

 

 七、代碼規範

　　

　　　　1）for loop中不要聲明臨時變數，不到萬不得已不要在裡面寫try catch。

　　　　2）明白記憶體回收機制，避免頻繁GC，記憶體流失，OOM(有機會專門說)

　　　　3）合理使用資料類型，StringBuilder代替String，少用枚舉enum，少用父類聲明(List,Map)

　　　　4）如果你有頻繁的new線程，那最好通過線程池去execute它們，減少線程建立開銷。

　　　　5）你要知道單例的好處，並正確的使用它。

　　　　6）多用常量，少用顯式的"action_key"，並維護一個常量類，別重複聲明這些常量。

　　　　7）如果可以，至少要弄懂設計模式中的策略模式，組合模式，裝飾模式，原廠模式，觀察者模式，這些能協助你合理的解耦，即使需求頻繁變更，你也不用害怕牽一髮而動全身。需求變更不可怕，可怕的是沒有在寫代碼之前做合理的設計。

　　　　8）View中設定緩衝屬性.setDrawingCache為true.

　　　　9）cursor 的使用。不過要注意管理好cursor,不要每次開啟關閉cursor.因為開啟關閉Cursor非常耗時。 Cursor.require用於刷cursor.

　　　　10）採用SurfaceView在子線程重新整理UI, 避免手勢的處理和繪製在同一UI線程（普通View都這樣做）

　　　　11）採用JNI，將耗時間的處理放到c/c++層來處理

　　　　12）有些能用檔案操作的，盡量採用檔案操作，檔案操作的速度比資料庫的操作要快10倍左右

　　　　13）懶載入和緩衝機制。訪問網路的耗時操作啟動一個新線程來做，而不要再UI線程來做

　　　　14）如果方法用不到成員變數，可以把方法申明為static，效能會提高到15%到20%

　　　　15）避免使用getter/setter存取field，可以把field申明為public，直接存取

　　　　16）私人內部類要訪問外部類的field或方法時,其成員變數不要用private，因為在編譯時間會產生setter/getter,影響效能。可以把外部類的field或方法聲明為包存取權限

　　　　17）合理利用浮點數，浮點數比整型慢兩倍

　　　　18）針對ListView的效能最佳化，ListView的背景色與cacheColorHint設定相同顏色，可以提高滑動時的渲染效能。ListView中getView是效能是關鍵，這裡要儘可能的最佳化。

　　　　　　 getView方法中要重用view；getView方法中不能做複雜的邏輯計算，特別是資料庫操作，否則會嚴重影響滑動時的效能

　　　　19）不用new關鍵詞建立類的執行個體，用new關鍵詞建立類的執行個體時，建構函式鏈中的所有建構函式都會被自動調用。但如果一個對象實現了Cloneable介面，我們可以調用它的clone()方法。

　　　　　　clone()方法不會調用任何類建構函式。在使用設計模式（Design Pattern）的場合，如果用Factory模式建立對象，則改用clone()方法建立新的對象執行個體非常簡單。例如，下面是Factory模式的一個典型實現：

　　　　20）public static Credit getNewCredit() {
      　　　　　　return new Credit();
　　　　　　}
　　　　　　改進後的代碼使用clone()方法，如下所示：
　　　　　　private static Credit BaseCredit = new Credit();
     　　　　　　 public static Credit getNewCredit() {
          　　　　　　  return (Credit) BaseCredit.clone();
      　　　　　　}
　　　　上面的思路對於數組處理同樣很有用。

　　　　21）乘法和除法

　　　　　　考慮下面的代碼：

　　　　22）ViewPager同時緩衝page數最好為最小值3，如果過多，那麼第一次顯示時，ViewPager所初始化的pager就會很多，這樣pager累積渲染耗時就會增多，看起來就卡。

　　　　23）每個pager應該只在顯示時才載入網路或資料庫(UserVisibleHint=true)，最好不要預先載入資料，以免造成浪費

     24）提高下載速度：要控制好同時下載的最大任務數，同時給InputStream再包一層緩衝流會更快(如BufferedInputStream)

　　　　25）提供載入速度：讓服務端提供不同解析度的圖片才是最好的解決方案。還有合理使用記憶體緩衝，使用開源的架構