本文主要分享本身在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) {
- }
复制代码
|
|