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）提供加載速度：讓服務端提供不同分辨率的圖片才是最好的解決方案。還有合理使用內存緩存，使用開源的框架