前言：
Android中标准帧率是60FPS，每秒刷新60帧画面，那么每帧就要在大约16ms渲染完成，如果超过了16ms，就会仍然显示上一帧画面。对于用户来说就是界面被卡住了。尤其是在连续的滑动过程中，突然掉帧，对用户来说卡顿非常明显，体验很不好。反而如果刷新一直保持在一个稳定的帧率，对用户体验来说反而影响不大，比如王者荣耀的最高帧率也就30FPS，但是由于我们的眼睛对于24fps就已经感觉到流畅了。所以对于卡顿的要求是一段稳定的帧率，而不是小于60fps就认为是卡顿.

背景：
最近项目中遇到一个卡顿的问题。需要展示一个8列的群成员列表的名称和头像。项目中使用recycleView+GridlayoutManager来实现的，但是在滑动时卡顿很明显，可以清楚的看到掉帧现象。

为了找到卡顿的原因，试了各种方法，下面记录下这次经历。本来年前就已经要写的，但是过年嘛，没心情写，所以就拖到了年后，结果年后又将年前做的东西忘记的差不多了，所以基本上是从头开始的。

帧率衡量

FPSDog

首先我想知道滑动时的帧率到底是多少，变化曲线是怎么样。为此自己开发了一个FPSDog的工具类。
使用方法如下：

mRecycleView.addOnScrollListener(new RecyclerView.OnScrollListener() {
            @Override
            public void onScrollStateChanged(@NonNull RecyclerView recyclerView, int newState) {
                if (newState != RecyclerView.SCROLL_STATE_IDLE) {
                	//开始跟踪fps
                    FPSDog.getInstance().traceFPS(recyclerView, true);
                } else {
                	//跟踪结束
                    FPSDog.getInstance().traceEnd(recyclerView);
                }
            }
         }

FPSDog目前支持悬浮显示实时帧率和平均功率，也支持logcat输出。后续还需要完善将帧率输出为一段变化的曲线，可以更直观的查看帧率变化。关于该工具后面会在写一篇文章来介绍。
上面录屏已经可以看到了悬浮的效果。从中可以看到帧率从30多到50多的变化，确实是存在掉帧现象。

SystemTrace

通过SystemTrace工具也可以来查看掉帧的情况。
在Mac版本的Android studio 3.2.1版本中没有找到DDMS的直接入口，所以打开Systemtrace工具也花费了一些功夫。
可以在~/Android/sdk/platform-tools/systrace文件中找到systrace.py文件夹。
可以直接运行python systrace.py，然后操作界面，回车停止之后就可以在当前文件夹下生产一份trace.html文件了

注意trace.html文件最好使用chrome浏览器打开。

从上图可以看到很多红色的掉帧警告。放大也可以看到一些方法，可以初步分析卡顿的原因，不过现在有更好的工具来分析卡顿

卡顿分析：

我想知道在滑动的过程中到底执行了什么方法，到底是哪些方法造成了卡顿。上面的SystemTrace工具虽然也能看到一些，但是鬼知道那些对应代码里的是哪些方法啊。也可以借用TraceView工具或者使用Debug.startMethodTracing()和Debug.stopMethodTracing()来看。
但是没找到DDMS的入口，而且由于是滑动过程中卡顿，所以就没有使用这个，而是使用Profiler工具

Profiler工具

Android studio 3.2.1版本启动Profiler工具的方式如下：

首先通过Android studio工具栏上的这个图标启动APP，启动之后就可以在底部看到Profiler窗口了

关于该工具的使用，具体可以查看官方文档：profiler
当开始record之后，操作界面会比较卡，相应的方法耗时的绝对值是大的多，所以分析时要主要使用相对值的百分比。

这里可以看到一次scrollBy导致的填充过程中有这么多次binderViewHolder和onCreateHolder过程。主要的耗时就在这里了。
那么继续查看onBindViewHolder中的方法，主要是loadImg的耗时。

    @Override
    public void onBindViewHolder(@NonNull MyHolder viewHolder, int position) {
        viewHolder.nameTv.setText(mDates.get(position).name);
        if (!viewHolder.flag) {
            Log.e("RecycleViewAdapter", "onBindViewHolder: " + position);
        } else {
            Log.i("RecycleViewAdapter", "onBindViewHolder: " + position + "------");
        }
        viewHolder.flag = true;
        //加载图片
        ImageUtil.loadImg(mContext, mDates.get(position).url, viewHolder.headIv);
    }

public class ImageUtil {

    public static void loadImg(Context context, String url, ImageView imageView) {
        Glide.with(context).load(url)
                .apply(new RequestOptions().placeholder(R.mipmap.ic_launcher)
                        .error(R.mipmap.ic_launcher)).into(imageView);
    }
}

主要是使用Glide直接去加载图片，但是这个耗时无法避免。
那既然onBinderView暂时没有找到优化的空间，那onCreateViewHolder的次数能不能减少。
这里就要涉及RecycleView的缓存问题。

总结：这篇虽然暂时没能解决recycleView+GridLayoutManager的卡顿丢帧情况，但是温故了Systemtrace，熟悉了Profiler工具的使用，而且也开发一个FPS的检测工具，收获还是有的。mark一下。
后续还会继续分析RecyclerView的缓存机制。