本文主要分享本身在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函數中添加
- <font style="background-color:rgb(254, 253, 231)"><font face="Georgia,">android.os.debug.startMethodTracing("Entertainment");</font></font>
複製代碼
onDestrory函數中添加
- <font style="background-color:rgb(254, 253, 231)"><font face="Georgia,">android.os.debug.stopMethodTracing();</font></font>
複製代碼
程序退出後會在sd卡根目錄下生成Entertainment.trace這個文件,cmd到android sdk的tools目錄下運行traceview.bat Entertainment.trace便可,截圖以下<ignore_js_op>
從中能夠看出各個函數的調用時間、調用次數、平均調用時間、時間佔用百分比等從而定位到耗時的操做。monkey、monkey runner更詳細的見後面博客介紹 3、性能調優勢 主要包括同步改異步、緩存、Layout優化、數據庫優化、算法優化、延遲執行。 1. 同步改異步 這個就不用多講了,耗時操做放在線程中執行防止佔用主線程,必定程度上解決anr。 但須要注意線程和service結合(防止activity被回收後線程也被回收)以及線程的數量(後面優化介紹) PS:請使用java的線程池(後面介紹),少使用AsyncTask,由於AsyncTask存在性能問題(之後會單獨博文介紹) 2. 緩存 java的對象建立須要分配資源較耗費時間,加上建立的對象越多會形成越頻繁的gc影響系統響應。主要使用單例模式、緩存(圖片緩存、線程池、View緩存、IO緩存、消息緩存、通知欄notification緩存)及其餘方式減小對象建立。 (1). 單例模式 對於建立開銷較大的類可以使用此方法,保證全局一個實例,在程序運行過程當中該類不會因新建額外對象產生開銷。示例代碼以下:
- class Singleton {
- private static Singleton instance = null;
- private Singleton() {
- }
- public static synchronized 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緩存:
- @Override
- public View getView(int position, View convertView, ViewGroup parent) {
- ViewHolder holder;
- if (convertView == null) {
- convertView = inflater.inflate(R.layout.type_item, null);
- holder = new ViewHolder();
- holder.imageView = (ImageView)convertView.findViewById(R.id.app_icon);
- holder.textView = (TextView)convertView.findViewById(R.id.app_name);
- convertView.setTag(holder);
- } else {
- holder = (ViewHolder)convertView.getTag();
- }
- holder.imageView.setImageResource(R.drawable.index_default_image);
- holder.textView.setText("");
- return convertView;
- }
- /**
- * ViewHolder
- */
- static class ViewHolder {
- ImageView imageView;
- TextView textView;
- }
複製代碼
經過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). 使用事務 事務不只能保證批量操做一塊兒完成或回滾,並且在大量插入、更新、查詢時減小程序和表的交互從而提升性能
- SQLiteDatabase db = dbHelper.getWritableDatabase();
- db.beginTransaction();
- try {
- // add to do
- db.setTransactionSuccessful();
- } catch (Exception e) {
- Log.e(TAG, e.toString());
- } finally {
- db.endTransaction();
- }
複製代碼
(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是否已安裝的狀態,具體代碼修改以下:
- List<PackageInfo> installedPackageList = getPackageManager().getInstalledPackages(PackageManager.GET_UNINSTALLED_PACKAGES);
- List<App> installedAppList = function(installedAppList)
- for (App app : appList) {
- for (App installedApp : installedAppList) {
- }
- }
複製代碼
修改成
- 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函數 解決:使用延遲策略,具體代碼修改以下:
- @Override
- public void onStart() {
- super.onStart();
- appUpdateListAdapter.notifyDataSetChanged();
- }
複製代碼
4. 網絡獲取到展示速度較慢定位:在HttpURLConnection.getInputStream()以後的處理 解決:使用BufferedReader替代BufferedInputStream獲取時間從100ms下降到3ms,具體代碼修改以下:
- HttpURLConnection con = (HttpURLConnection)url.openConnection();
- InputStream input = con.getInputStream();
- while (input.read(buffer, 0, 1024) != -1) {
- }
複製代碼
改成
- HttpURLConnection con = (HttpURLConnection)url.openConnection();
- BufferedReader input = new BufferedReader(new InputStreamReader(con.getInputStream()));
- String s;
- while ((s = input.readLine()) != null) {
- }
複製代碼
|
|