Android性能調優實例

本文主要分享本身在appstore項目中的性能調優勢，包括同步改異步、緩存、Layout優化、數據庫優化、算法優化、延遲執行等。

目前性能優化專題已完成如下部分：

性能優化總綱——性能問題及性能調優方式

性能優化第四篇——移動網絡優化

性能優化第三篇——Java(Android)代碼優化
性能優化第二篇——佈局優化
性能優化第一篇——數據庫性能優化

性能優化實例

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函數中添加

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

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

onDestrory函數中添加

android.os.debug.stopMethodTracing();

1	android.os.debug.stopMethodTracing();

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

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

 

3、性能調優勢

主要包括同步改異步、緩存、Layout優化、數據庫優化、算法優化、延遲執行。

1. 同步改異步

這個就不用多講了，耗時操做放在線程中執行防止佔用主線程，必定程度上解決anr。

但須要注意線程和service結合（防止activity被回收後線程也被回收）以及線程的數量

線程池使用可見java的線程池

 

2. 緩存

java的對象建立須要分配資源較耗費時間，加上建立的對象越多會形成越頻繁的gc影響系統響應。主要使用單例模式、緩存(圖片緩存、線程池、View緩存、IO緩存、消息緩存、通知欄notification緩存)及其餘方式減小對象建立。

(1). 單例模式

對於建立開銷較大的類可以使用此方法，保證全局一個實例，在程序運行過程當中該類不會因新建額外對象產生開銷。示例代碼以下：

單例模式

Java

public class Singleton { private static Object obj = new Object(); private static Singleton instance = null; private Singleton(){ } public static Singleton getInstance() { // if already inited, no need to get lock everytime if (instance == null) { synchronized (obj) { if (instance == null) { instance = new Singleton(); } } } return instance; } }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

public class Singleton {       private static Object    obj      = new Object();     private static Singleton instance = null;       private Singleton(){     }       public static Singleton getInstance() {         // if already inited, no need to get lock everytime         if (instance == null) {             synchronized (obj) {                 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緩存機制

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優化

使用抽象佈局標籤(include, viewstub, merge)、去除沒必要要的嵌套和View節點、減小沒必要要的infalte及其餘Layout方面可調優勢，順帶說起佈局調優相關工具(hierarchy viewer和lint)。具體可見性能優化之佈局優化

TextView屬性優化：TextView的android:ellipsize=」marquee」跑馬燈效果極耗性能，具體緣由還在深刻源碼中

 

4. 數據庫優化

主要包括索引和事務及針對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是否已安裝的狀態，具體代碼修改以下：

Java

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

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

修改成

Java

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

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函數

解決：使用延遲策略，具體代碼修改以下：

Java

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

1 2 3 4 5

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

改成

優化後代碼

Java

public void onStart() { super.onStart(); // delay send message handler.sendMessageDelayed(handler.obtainMessage(MessageConstants.WHAT_NOTIFY_DATA_CHANGED), 100); } private class MyHandler extends Handler { @Override public void handleMessage(Message msg) { super.handleMessage(msg); switch (msg.what) { case MessageConstants.WHAT_NOTIFY_DATA_CHANGED: if (appUpdateListAdapter != null) { appUpdateListAdapter.notifyDataSetChanged(); } break; } } }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

public void onStart() { super.onStart(); // delay send message handler.sendMessageDelayed(handler.obtainMessage(MessageConstants.WHAT_NOTIFY_DATA_CHANGED), 100); }   private class MyHandler extends Handler {   @Override public void handleMessage(Message msg) { super.handleMessage(msg);   switch (msg.what) { case MessageConstants.WHAT_NOTIFY_DATA_CHANGED: if (appUpdateListAdapter != null) { appUpdateListAdapter.notifyDataSetChanged(); } break; } } }

 

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

定位：在HttpURLConnection.getInputStream()以後的處理

解決：使用BufferedReader替代BufferedInputStream獲取時間從100ms下降到3ms，具體代碼修改以下：

Java

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

1 2 3 4 5

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

改成

Java

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

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) {   }