Android性能調優

Android性能調優

http://www.trinea.cn/android/android%E6%80%A7%E8%83%BD%E8%B0%83%E4%BC%98/

本文主要分享本身在娛樂精選（功能相似垂直類appstore）項目中的性能調優勢，包括同步改異步、緩存、Layout優化、數據庫優化、算法優化、延遲執行等。
1、性能瓶頸點
整個頁面主要由6個Page的ViewPager，每一個Page爲一個GridView，GridView一屏大概顯示4*4的item信息(本文最後有附圖)。因爲網絡數據獲取較多且隨時須要保持頁面內app下載進度及狀態，因此出現如下性能問題
a.  ViewPager左右滑動明顯卡頓
b.  GridView上下滾動明顯卡頓
c.  其餘Activity返回ViewPager Activity較慢
d.  網絡獲取到展示速度較慢

2、性能調試及定位
主要使用traceview、monkey、monkey runner調試，traceview相似java web調優的visualvm，使用方法以下：
在須要調優的activity onCreate函數中添加

1	android . os . debug . startMethodTracing ( "Entertainment" ) ;

onDestrory函數中添加

1	android . os . debug . stopMethodTracing ( ) ;

程序退出後會在sd卡根目錄下生成Entertainment.trace這個文件，cmd到android sdk的tools目錄下運行traceview.bat Entertainment.trace便可，截圖以下

從中能夠看出各個函數的調用時間、調用次數、平均調用時間、時間佔用百分比等從而定位到耗時的操做。traceview、monkey、monkey runner更詳細的見後面博客介紹

3、性能調優勢
主要包括同步改異步、緩存、Layout優化、數據庫優化、算法優化、延遲執行。
1. 同步改異步
這個就不用多講了，耗時操做放在線程中執行防止佔用主線程，必定程度上解決anr。
但須要注意線程和service結合（防止activity被回收後線程也被回收）以及線程的數量（後面優化介紹）
PS：請使用java的線程池（後面介紹），少使用AsyncTask，由於AsyncTask存在性能問題(之後會單獨博文介紹)

2. 緩存
java的對象建立須要分配資源較耗費時間，加上建立的對象越多會形成越頻繁的gc影響系統響應。主要使用單例模式、緩存(圖片緩存、線程池、View緩存、IO緩存、消息緩存、通知欄notification緩存)及其餘方式減小對象建立。
(1). 單例模式
對於建立開銷較大的類可以使用此方法，保證全局一個實例，在程序運行過程當中該類不會因新建額外對象產生開銷。示例代碼以下：

1 2 3 4 5 6 7 8 9 10 11 12 13

class Singleton {      private static Singleton instance = null ;        private Singleton ( ) {      }        public static Singleton getInstance ( ) {          if ( instance == null ) {              instance = new Singleton ( ) ;          }          return instance ;      } }

(2). 緩存
程序中用到了圖片緩存、線程池、View緩存、IO緩存、消息緩存、通知欄notification緩存等。
a. 圖片緩存：見ImageCache和ImageSdCache

b. 線程池：使用Java的Executors類，經過newCachedThreadPool、newFixedThreadPool、newSingleThreadExecutor、newScheduledThreadPool提供四種不一樣類型的線程池

c. View緩存：

listView的getView緩存

經過convertView是否爲null減小layout inflate次數，經過靜態的ViewHolder減小findViewById的次數，這兩個函數尤爲是inflate是至關費時間的

d. IO緩存：
使用具備緩存策略的輸入流，BufferedInputStream替代InputStream，BufferedReader替代Reader，BufferedReader替代BufferedInputStream.對文件、網絡IO皆適用。

e. 消息緩存：經過Handler的obtainMessage回收就的Message對象，減小Message對象的建立開銷
handler.sendMessage(handler.obtainMessage(1));

f. 通知欄notification緩存：下載中須要不斷改變通知欄進度條狀態，若是不斷新建Notification會致使通知欄很卡。這裏咱們可使用最簡單的緩存
Map<String, Notification> notificationMap = new HashMap<String, Notification>();若是notificationMap中不存在，則新建notification而且put into map.

(3). 其餘
能建立基類解決問題就不用具體子類：除須要設置優先級的線程使用new Thread建立外，其他線程建立使用new Runnable。由於子類會有本身的屬性建立須要更多開銷。
控制最大併發數量：使用Java的Executors類，經過Executors.newFixedThreadPool(nThreads)控制線程池最大線程併發
對於http請求增長timeout

 

3. Layout優化
性能優化相關的一些標籤 <viewStub/>，<merge/>和<include/> 可見：http://hexen.blog.51cto.com/1110171/820197
TextView屬性優化：TextView的android:ellipsize=」marquee」跑馬燈效果極耗性能，具體緣由還在深刻源碼中
對於layout中的佈局實際效果可以使用hierarchyviewer查看
對於layout中多餘的view以及不正確的標籤可以使用android lint查看

 

4. 數據庫優化
主要包括sql優化、創建索引、使用事務、讀寫表區分
(1). sql優化
可參考http://database.51cto.com/art/200904/118526.htm

(2). 創建索引
使用CREATE INDEX mycolumn_index ON mytable (myclumn)語句在SQLiteOpenHelper子類的onCreate或onUpgrade函數建立索引，索引建立後對大數據量的查詢性能提高效果較明顯

(3). 使用事務
事務不只能保證批量操做一塊兒完成或回滾，並且在大量插入、更新、查詢時減小程序和表的交互從而提升性能

事務示例

(4). 讀寫表區分
對於查詢操做使用dbHelper.getReadableDatabase();讀表代替寫表。由於sqlite是表級鎖，因此修改和插入等寫操做的性能較差。

5. 算法優化
這個就是個博大精深的話題了，只介紹本應用中使用的。
使用hashMap代替arrayList，時間複雜度下降一個數量級

6. 延遲執行
對於不少耗時邏輯不必當即執行，這時候咱們能夠將其延遲執行。
線程延遲執行 ScheduledExecutorService scheduledThreadPool = Executors.newScheduledThreadPool(10);
消息延遲發送 handler.sendMessageDelayed(handler.obtainMessage(0), 1000);

4、本程序性能調優結果
1. ViewPager左右滑動明顯卡頓
2. GridView上下滾動明顯卡頓
(1). 去掉TextView的android:ellipsize=」marquee」
(2). 修改圖片緩存的最大線程數，增長http timeout
(3). 修改設置app是否已安裝的狀態，具體代碼修改以下：

1 2 3 4 5 6 7

List <PackageInfo> installedPackageList = getPackageManager ( ) . getInstalledPackages ( PackageManager . GET_UNINSTALLED_PACKAGES ) ; List <App> installedAppList = function ( installedAppList ) for ( App app : appList ) {      for ( App installedApp : installedAppList ) {        } }

修改成

1 2 3 4 5 6 7 8

for ( App app : appList ) {      Pair < Integer , String > versionInfo = INSTALLED_APP_MAP . get ( app . getPackageName ( ) ) ;      if ( versionInfo != null ) {        } else {        } }

從每次獲取List<PackageInfo> installedAppList = getPackageManager().getInstalledPackages(PackageManager.GET_UNINSTALLED_PACKAGES);修改成只在有應用安裝或卸載廣播時獲取應用列表，而且用hashMap代替installedAppList減小查詢時間。

將平均執行時間從201ms下降到1ms。

3. 其餘Activity返回ViewPager Activity較慢
定位：在onStart函數
解決：使用延遲策略，具體代碼修改以下：

1 2 3 4 5

@Override public void onStart ( ) {      super . onStart ( ) ;      appUpdateListAdapter . notifyDataSetChanged ( ) ; }

改成

優化後代碼

4. 網絡獲取到展示速度較慢

定位：在HttpURLConnection.getInputStream()以後的處理
解決：使用BufferedReader替代BufferedInputStream獲取時間從100ms下降到3ms，具體代碼修改以下：

1 2 3 4 5

HttpURLConnection con = ( HttpURLConnection ) url . openConnection ( ) ; InputStream input = con . getInputStream ( ) ; while ( input . read ( buffer , 0 , 1024 ) != - 1 ) {   }

改成

1 2 3 4 5 6

HttpURLConnection con = ( HttpURLConnection ) url . openConnection ( ) ; BufferedReader input = new BufferedReader ( new InputStreamReader ( con . getInputStream ( ) ) ) ; String s ; while ( ( s = input . readLine ( ) ) != null ) {   }