Android性能調優實例
本文主要分享自己在appstore項目中的性能調優點,包括同步改異步、緩存、Layout優化、數據庫優化、算法優化、延遲執行等。
一、性能瓶頸點
整個頁面主要由6個Page的ViewPager,每個Page爲一個GridView,GridView一屏大概顯示4*4的item信息(本文最後有附圖)。由於網絡數據獲取較多且隨時需要保持頁面內app下載進度及狀態,所以出現以下性能問題
a. ViewPager左右滑動明顯卡頓
b. GridView上下滾動明顯卡頓
c. 其他Activity返回ViewPager Activity較慢
d. 網絡獲取到展現速度較慢
二、性能調試及定位
主要使用Traceview、monkey、monkey runner調試,traceview類似java web調優的visualvm,使用方法如下:
在需要調優的activity onCreate函數中添加 onDestrory函數中添加 程序退出後會在sd卡根目錄下生成Entertainment.trace這個文件,cmd到android sdk的tools目錄下運行traceview.bat Entertainment.trace即可,截圖如下
從中可以看出各個函數的調用時間、調用次數、平均調用時間、時間佔用百分比等從而定位到耗時的操作。monkey、monkey runner更詳細的見後面博客介紹
三、性能調優點
主要包括同步改異步、緩存、Layout優化、數據庫優化、算法優化、延遲執行。
1. 同步改異步
這個就不用多講了,耗時操作放在線程中執行防止佔用主線程,一定程度上解決anr。
但需要注意線程和service結合(防止activity被回收後線程也被回收)以及線程的數量(後面優化介紹)
PS:請使用java的線程池(後面介紹),少使用AsyncTask,因爲AsyncTask存在性能問題(以後會單獨博文介紹)
2. 緩存
java的對象創建需要分配資源較耗費時間,加上創建的對象越多會造成越頻繁的gc影響系統響應。主要使用單例模式、緩存(圖片緩存、線程池、View緩存、IO緩存、消息緩存、通知欄notification緩存)及其他方式減少對象創建。
(1). 單例模式
對於創建開銷較大的類可使用此方法,保證全局一個實例,在程序運行過程中該類不會因新建額外對象產生開銷。示例代碼如下: (2). 緩存
程序中用到了圖片緩存、線程池、View緩存、IO緩存、消息緩存、通知欄notification緩存等。
a. 圖片緩存:見ImageCache和ImageSdCache
b. 線程池:使用Java的Executors類,通過newCachedThreadPool、newFixedThreadPool、newSingleThreadExecutor、newScheduledThreadPool提供四種不同類型的線程池
c. View緩存: 通過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);
四、本程序性能調優結果
1. ViewPager左右滑動明顯卡頓
2. GridView上下滾動明顯卡頓
(1). 去掉TextView的android:ellipsize=”marquee”
(2). 修改圖片緩存的最大線程數,增加http timeout
(3). 修改設置app是否已安裝的狀態,具體代碼修改如下: 修改爲 從每次獲取List<PackageInfo> installedAppList = getPackageManager().getInstalledPackages(PackageManager.GET_UNINSTALLED_PACKAGES);修改爲只在有應用安裝或卸載廣播時獲取應用列表,並且用hashMap代替installedAppList減少查詢時間。將平均執行時間從201ms降低到1ms。
3. 其他Activity返回ViewPager Activity較慢
定位:在onStart函數
解決:使用延遲策略,具體代碼修改如下: 4. 網絡獲取到展現速度較慢定位:在HttpURLConnection.getInputStream()之後的處理
解決:使用BufferedReader替代BufferedInputStream獲取時間從100ms降低到3ms,具體代碼修改如下: 改爲
一、性能瓶頸點
整個頁面主要由6個Page的ViewPager,每個Page爲一個GridView,GridView一屏大概顯示4*4的item信息(本文最後有附圖)。由於網絡數據獲取較多且隨時需要保持頁面內app下載進度及狀態,所以出現以下性能問題
a. ViewPager左右滑動明顯卡頓
b. GridView上下滾動明顯卡頓
c. 其他Activity返回ViewPager Activity較慢
d. 網絡獲取到展現速度較慢
二、性能調試及定位
主要使用Traceview、monkey、monkey runner調試,traceview類似java web調優的visualvm,使用方法如下:
在需要調優的activity onCreate函數中添加 onDestrory函數中添加 程序退出後會在sd卡根目錄下生成Entertainment.trace這個文件,cmd到android sdk的tools目錄下運行traceview.bat Entertainment.trace即可,截圖如下
從中可以看出各個函數的調用時間、調用次數、平均調用時間、時間佔用百分比等從而定位到耗時的操作。monkey、monkey runner更詳細的見後面博客介紹
三、性能調優點
主要包括同步改異步、緩存、Layout優化、數據庫優化、算法優化、延遲執行。
1. 同步改異步
這個就不用多講了,耗時操作放在線程中執行防止佔用主線程,一定程度上解決anr。
但需要注意線程和service結合(防止activity被回收後線程也被回收)以及線程的數量(後面優化介紹)
PS:請使用java的線程池(後面介紹),少使用AsyncTask,因爲AsyncTask存在性能問題(以後會單獨博文介紹)
2. 緩存
java的對象創建需要分配資源較耗費時間,加上創建的對象越多會造成越頻繁的gc影響系統響應。主要使用單例模式、緩存(圖片緩存、線程池、View緩存、IO緩存、消息緩存、通知欄notification緩存)及其他方式減少對象創建。
(1). 單例模式
對於創建開銷較大的類可使用此方法,保證全局一個實例,在程序運行過程中該類不會因新建額外對象產生開銷。示例代碼如下: (2). 緩存
程序中用到了圖片緩存、線程池、View緩存、IO緩存、消息緩存、通知欄notification緩存等。
a. 圖片緩存:見ImageCache和ImageSdCache
b. 線程池:使用Java的Executors類,通過newCachedThreadPool、newFixedThreadPool、newSingleThreadExecutor、newScheduledThreadPool提供四種不同類型的線程池
c. View緩存: 通過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);
四、本程序性能調優結果
1. ViewPager左右滑動明顯卡頓
2. GridView上下滾動明顯卡頓
(1). 去掉TextView的android:ellipsize=”marquee”
(2). 修改圖片緩存的最大線程數,增加http timeout
(3). 修改設置app是否已安裝的狀態,具體代碼修改如下: 修改爲 從每次獲取List<PackageInfo> installedAppList = getPackageManager().getInstalledPackages(PackageManager.GET_UNINSTALLED_PACKAGES);修改爲只在有應用安裝或卸載廣播時獲取應用列表,並且用hashMap代替installedAppList減少查詢時間。將平均執行時間從201ms降低到1ms。
3. 其他Activity返回ViewPager Activity較慢
定位:在onStart函數
解決:使用延遲策略,具體代碼修改如下: 4. 網絡獲取到展現速度較慢定位:在HttpURLConnection.getInputStream()之後的處理
解決:使用BufferedReader替代BufferedInputStream獲取時間從100ms降低到3ms,具體代碼修改如下: 改爲
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.