帧率是什么
FPS是图像畛域中的定义，是指画面每秒传输帧数，艰深来讲就是指动画或视频的画面数
帧率的影响是什么
咱们用华为解读的《软件绿色联盟利用体验规范3.0》原话来解释：利用界面的刷新帧率，尤其是滑动时，如果帧率较低，会带来卡顿的感觉，所以放弃一个绝对较高的帧率会带来更晦涩的体验。还有刷新频率越低，图像闪动和抖动的就越厉害，眼睛疲劳得就越快。
那么影响帧率的是什么呢
当初的Android旗舰机都做到了120HzZ的刷新率，但实际上，咱们须要这么高的刷新率吗？其实咱们对帧率的要求，不同的场景要求不太一样，电影做到24Hz就能够失常观看了，游戏的话须要最低30Hz，想要晦涩的感觉就须要>60Hz，这也是为啥王者光荣要达到60Hz左右才不会卡顿的起因。那么反过来再想，到底是什么在影响帧率呢？
- 显卡，FPS越高则须要的显卡能力越高
- 分辨率，分辨率越低，越容易做到高帧率
有个公式，提供了帧率的计算方法：显卡的解决能力= 分辨率×帧率，举个例子：分辨率是1024×768 帧率是24帧/秒，那么须要：
1024×768×24=18874368 一千八百八十七万个像素量/秒 的显卡解决能力，想达到50HZ 就须要三千九百万的像素解决能力。
帧率多少属于失常呢
软件绿色联盟利用体验规范3.0 -性能规范中提到如下规范：
- 一般利用的帧率应≥55fps
- 游戏类、地图类和视频类的帧率应≥25fps
游戏类不是达到60Hz才感觉晦涩吗，看到绿色联盟对游戏要求倒是很低，哈哈。
如何监控Android手机的帧率呢？
既然放弃高帧率对用户体验如此重要，那么咱们如何实时监控手机的帧率呢？一种最简略的形式就是手机外面的开发者模式中，关上HWHI出现模式分析，抉择屏幕条形图，或者adb shell输入都行。具体介绍在这里：
应用 GPU 渲染模式分析工具进行剖析
但这如同也不是咱们这次关怀的重点，咱们更想从代码的角度来剖析，那么如何实现呢？答案就是Choreographer，谷歌在 Android API 16 中提供了这个类，它会在每一帧绘制之前通过FrameCallBack 接口的形式回调doFrame办法，且提供了以后帧开始绘制的工夫(单位：纳秒)，代码如下：
/** * Implement this interface to receive a callback when a new display frame is * being rendered. The callback is invoked on the {@link Looper} thread to * which the {@link Choreographer} is attached. */ public interface FrameCallback { /** * Called when a new display frame is being rendered. * <p> * This method provides the time in nanoseconds when the frame started being rendered. * The frame time provides a stable time base for synchronizing animations * and drawing. It should be used instead of {@link SystemClock#uptimeMillis()} * or {@link System#nanoTime()} for animations and drawing in the UI. Using the frame * time helps to reduce inter-frame jitter because the frame time is fixed at the time * the frame was scheduled to start, regardless of when the animations or drawing * callback actually runs. All callbacks that run as part of rendering a frame will * observe the same frame time so using the frame time also helps to synchronize effects * that are performed by different callbacks. * </p><p> * Please note that the framework already takes care to process animations and * drawing using the frame time as a stable time base. Most applications should * not need to use the frame time information directly. * </p> * * @param frameTimeNanos The time in nanoseconds when the frame started being rendered, * in the {@link System#nanoTime()} timebase. Divide this value by {@code 1000000} * to convert it to the {@link SystemClock#uptimeMillis()} time base. */ public void doFrame(long frameTimeNanos); }通过正文就发现，的确如上形容的那样。咱们再深挖一下，到底是什么能源促使有了doFrame的回调呢？而后再想一想如何计算出帧率。
Choreographer背地的能源
这就须要理解Android的渲染原理，Android的渲染也是通过Google长期的迭代，一直优化更新，其实整个渲染过程很简单，须要很多框架的反对，咱们晓得的的底层库如：Skia或者OpenGL，Flutter就应用了Skia绘制，但它是2D的，且应用的是CPU，OpenGL能够绘制3D，且应用的是GPU，而最终出现图形的是Surface。所有的元素都在 Surface 这张画纸上进行绘制和渲染，每个窗口Window都会关联一个 Surface，WindowManager 则负责管理这些Window窗口，并且把它们的数据传递给 SurfaceFlinger，SurfaceFlinger 承受缓冲区，对它们进行合成，而后发送到屏幕。
WindowManager 为 SurfaceFlinger 提供缓冲区和窗口元数据，而 SurfaceFlinger通过硬件合成器 Hardware Composer 合成并输入到显示屏，Surface会被绘制很多层，所以就是下面提到的缓冲区，在 Android 4.1 之前应用的是双缓冲机制；在 Android 4.1 之后，应用的是三缓冲机制。
然而这还没完，Google 在 2012 年的 I/O 大会上发表了 Project Butter 黄油打算，并且在 Android 4.1 中正式开启了这个机制，也就是VSYNC 信号，这是个什么货色呢？先来看一张图，你会发现一次屏幕的绘制，须要通过CPU计算，而后GPU，最初Display，VSYNC 像是一个队列（生产者消费者模型），一个个随着工夫累加，一个个又立即输入后被生产，咱们晓得最终的Buffer数据是通过SurfaceFlinger输入到显示屏的，而VSYNC在这期间起到的作用其实就是有序布局渲染流程，升高延时，而咱们还晓得一个VSYNC的工夫距离是16ms，超过16就会导致页面绘制停留在上一帧画面，从而感觉像是掉帧
为什么要16ms呢？这起源一个计算公式：
1000ms/60fps 约等于 16ms/1fps，而Choreographer的doFrame办法失常状况下就是16ms一次回调。且它的能源就是来源于这个VSYNC信号。
怎么通过Choreographer计算帧率
因为doFrame办法失常是16ms被调一次，那么咱们就能够顺着这个特点来做个计算，看段代码来梳理下整个思路：
//记录上次的帧工夫private long mLastFrameTime;Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() { @Override public void doFrame(long frameTimeNanos) { //每500毫秒从新赋值一次最新的帧工夫 if (mLastFrameTime == 0) { mLastFrameTime = frameTimeNanos; } //本次帧开始工夫减去上次的工夫除以100万，失去毫秒的差值 float diff = (frameTimeNanos - mLastFrameTime) / 1000000.0f; //这里是500毫秒输入一次帧率 if (diff > 500) { double fps = (((double) (mFrameCount * 1000L)) / diff); mFrameCount = 0; mLastFrameTime = 0; Log.d("doFrame", "doFrame: " + fps); } else { ++mFrameCount; } //注册监听下一次 vsync信号 Choreographer.getInstance().postFrameCallback(this); }});为什么要按500毫秒计算呢？其实也能够用一秒来算哈，你本人决定，总之doFrame办法，如果在一秒内被回调60次左右，那就根本失常哦。好了晓得了如何用代码测算帧率，那么咱们就来开始剖析，Matrix的帧率检测代码。看看他都做了哪些。
Matrix 帧率检测代码剖析
帧率检测的代码必定是在trace canary中，首先来看下整体目录，咱们发现了ITracer形象
分包有，AnrTracer、EvilMethodTracer、FrameTracer、StartupTracer四个，看名字应该就能判断出FrameTracer必定和帧率相干，于是咱们关上FrameTracer，并检索fps字段，发现如下代码：
FrameTracer类中的公有类FrameCollectItem
private class FrameCollectItem { long sumFrameCost; int sumFrame = 0; void report() { // 这里计算帧率，1000.f * sumFrame / sumFrameCost 公式和咱们之前的 // double fps = (((double) (mFrameCount * 1000L)) / diff) 是不是有殊途同归之处？ // sumFrameCost应该是动静的时间差常量，能够是500毫秒也能够是1秒。 float fps = Math.min(60.f, 1000.f * sumFrame / sumFrameCost); MatrixLog.i(TAG, "[report] FPS:%s %s", fps, toString()); try { //这里就是生成Json报告，就不看了。 TracePlugin plugin = Matrix.with().getPluginByClass(TracePlugin.class); if (null == plugin) { return; } JSONObject dropLevelObject = new JSONObject(); dropLevelObject.put(DropStatus.DROPPED_FROZEN.name(), dropLevel[DropStatus.DROPPED_FROZEN.index]); dropLevelObject.put(DropStatus.DROPPED_HIGH.name(), dropLevel[DropStatus.DROPPED_HIGH.index]); dropLevelObject.put(DropStatus.DROPPED_MIDDLE.name(), dropLevel[DropStatus.DROPPED_MIDDLE.index]); dropLevelObject.put(DropStatus.DROPPED_NORMAL.name(), dropLevel[DropStatus.DROPPED_NORMAL.index]); dropLevelObject.put(DropStatus.DROPPED_BEST.name(), dropLevel[DropStatus.DROPPED_BEST.index]); JSONObject dropSumObject = new JSONObject(); dropSumObject.put(DropStatus.DROPPED_FROZEN.name(), dropSum[DropStatus.DROPPED_FROZEN.index]); dropSumObject.put(DropStatus.DROPPED_HIGH.name(), dropSum[DropStatus.DROPPED_HIGH.index]); dropSumObject.put(DropStatus.DROPPED_MIDDLE.name(), dropSum[DropStatus.DROPPED_MIDDLE.index]); dropSumObject.put(DropStatus.DROPPED_NORMAL.name(), dropSum[DropStatus.DROPPED_NORMAL.index]); dropSumObject.put(DropStatus.DROPPED_BEST.name(), dropSum[DropStatus.DROPPED_BEST.index]); JSONObject resultObject = new JSONObject(); resultObject = DeviceUtil.getDeviceInfo(resultObject, plugin.getApplication()); resultObject.put(SharePluginInfo.ISSUE_SCENE, visibleScene); resultObject.put(SharePluginInfo.ISSUE_DROP_LEVEL, dropLevelObject); resultObject.put(SharePluginInfo.ISSUE_DROP_SUM, dropSumObject); resultObject.put(SharePluginInfo.ISSUE_FPS, fps); Issue issue = new Issue(); issue.setTag(SharePluginInfo.TAG_PLUGIN_FPS); issue.setContent(resultObject); plugin.onDetectIssue(issue); } catch (JSONException e) { MatrixLog.e(TAG, "json error", e); } finally { sumFrame = 0; sumDroppedFrames = 0; sumFrameCost = 0; } } } 我跟着这段代码，找一下sumFrame被调用的中央，看看都做了什么，上面能够疾速看，因为没有具体代码，起因是咱们曾经晓得了能够通过Choreographer.FrameCallback来注册监听，为了疾速验证Matrix Trace 帧率的实现计划，咱们跳过细节，间接找到外围逻辑再贴代码。
找到了一个函数collect，做了++操作，再往上找发现，FrameTracer又一个外部类FPSCollector
再往上，发现doReplay办法调用了doReplayInner
持续后，发现了IDoFrameListener在调用doReplay函数
而且FPSCollector就是继承自IDoFrameListener，再来看IDoFrameListener
和咱们之前剖析的不太一样，并没有找到Choreographer.FrameCallback的影子，计算形式倒是差不多。我不信，我还要再往上找一下
看到这里，发现了doFrame函数，仿佛找到了FrameCallback的影子，却又不是。持续看
发现了UIThreadMonitor类，持续往上
发现在init函数中被调用，来该看代码了
LooperMonitor.register(new LooperMonitor.LooperDispatchListener() { @Override public boolean isValid() { return isAlive; } @Override public void dispatchStart() { super.dispatchStart(); UIThreadMonitor.this.dispatchBegin(); } @Override public void dispatchEnd() { super.dispatchEnd(); UIThreadMonitor.this.dispatchEnd(); } });LooperMonitor是个什么鬼，为啥能感知帧率？看下它是个啥？
class LooperMonitor implements MessageQueue.IdleHandler查问一下发现MessageQueue.IdleHandler，它能够用来在线程闲暇的时候，指定一个操作，只有线程闲暇了，就能够执行它指定的操作，这跟咱们之前的计划是不是就不一样了，咱们可没有思考线程是否是闲暇，随时都在计算帧率，看到这里，我算是晓得了它基本没有用FrameCallback，而是通过另一种形式来计算的，先不说是什么，咱们再跟踪一下LooperDispatchListener
发现一个LooperPrinter，它散发的，来看LooperPrinter
class LooperPrinter implements Printer //打印？public interface Printer { /** * Write a line of text to the output. There is no need to terminate * the given string with a newline. */ void println(String x);}看看这个LooperPrinter是怎么创建对象的，找到如下援用
具体看下代码
private synchronized void resetPrinter() { Printer originPrinter = null; try { if (!isReflectLoggingError) { originPrinter = ReflectUtils.get(looper.getClass(), "mLogging", looper); if (originPrinter == printer && null != printer) { return; } } } catch (Exception e) { isReflectLoggingError = true; Log.e(TAG, "[resetPrinter] %s", e); } if (null != printer) { MatrixLog.w(TAG, "maybe thread:%s printer[%s] was replace other[%s]!", looper.getThread().getName(), printer, originPrinter); } //setMessageLogging用来记录Looper.loop()中相干log信息，给他设置一个printer， //那岂不是打印的工作就交给了LooperPrinter looper.setMessageLogging(printer = new LooperPrinter(originPrinter)); if (null != originPrinter) { MatrixLog.i(TAG, "reset printer, originPrinter[%s] in %s", originPrinter, looper.getThread().getName()); } }我顺着这个looper，找到了这个
对的就是主线程的Looper，咱们都晓得主线程，始终负责UI的刷新工作，原来如此，它利用这Looper提供的日志机制，且思考到在线程闲暇时来解决数据，来监控帧率和其余。很不错的设计，值得借鉴学习。而我还发现了一个细节，其实它还是用到了Choreographer来计算帧率，且利用反射来获取字段信息如：
//帧间隔时间frameIntervalNanos= ReflectUtils.reflectObject(choreographer, "mFrameIntervalNanos", Constants.DEFAULT_FRAME_DURATION);//vsync信号承受vsyncReceiver = ReflectUtils.reflectObject(choreographer, "mDisplayEventReceiver", null);下面doFrame函数回调中的 frameTimeNanos 其实就是从 vsyncReceiver中拿到的。源码截图，看来计算帧率必定是离不开Choreographer
那么问题又来了。
为什么Looper提供的日志机制能够计算帧率
你是不是跟我一样有这个疑难，我带你看看Choreographer的源码你就明确了，来
private static final ThreadLocal<Choreographer> sThreadInstance = new ThreadLocal<Choreographer>() { @Override protected Choreographer initialValue() { Looper looper = Looper.myLooper(); if (looper == null) { throw new IllegalStateException("The current thread must have a looper!"); } Choreographer choreographer = new Choreographer(looper, VSYNC_SOURCE_APP); if (looper == Looper.getMainLooper()) { mMainInstance = choreographer; } return choreographer; } };从这段代码剖析咱们得出：
Choreographer 是线程公有的，因为ThreadLocal创立的变量只能被以后线程拜访，也就是说 一个线程对应一个Choreographer，主线程的Choreographer就是mMainInstance。再来看一段代码
private Choreographer(Looper looper, int vsyncSource) { mLooper = looper; mHandler = new FrameHandler(looper); mDisplayEventReceiver = USE_VSYNC ? new FrameDisplayEventReceiver(looper, vsyncSource) : null; mLastFrameTimeNanos = Long.MIN_VALUE; mFrameIntervalNanos = (long)(1000000000 / getRefreshRate()); mCallbackQueues = new CallbackQueue[CALLBACK_LAST + 1]; for (int i = 0; i <= CALLBACK_LAST; i++) { mCallbackQueues[i] = new CallbackQueue(); } // b/68769804: For low FPS experiments. setFPSDivisor(SystemProperties.getInt(ThreadedRenderer.DEBUG_FPS_DIVISOR, 1)); }这是Choreographer结构，这里其实咱们发现，Choreographer是通过Looper创立的，它俩是一对一的关系，也就是在一个线程中有一个Looper也有一个Choreographer，这外面两个比拟重要 FrameHandler，FrameDisplayEventReceiver 当初还不晓得他俩用来干嘛，往下看代码
private final class FrameHandler extends Handler { public FrameHandler(Looper looper) { super(looper); } @Override public void handleMessage(Message msg) { switch (msg.what) { case MSG_DO_FRAME: doFrame(System.nanoTime(), 0); break; case MSG_DO_SCHEDULE_VSYNC: doScheduleVsync(); break; case MSG_DO_SCHEDULE_CALLBACK: doScheduleCallback(msg.arg1); break; } } } void doFrame(long frameTimeNanos, int frame) { final long startNanos; synchronized (mLock) { if (!mFrameScheduled) { return; // no work to do } if (DEBUG_JANK && mDebugPrintNextFrameTimeDelta) { mDebugPrintNextFrameTimeDelta = false; Log.d(TAG, "Frame time delta: " + ((frameTimeNanos - mLastFrameTimeNanos) * 0.000001f) + " ms"); } long intendedFrameTimeNanos = frameTimeNanos; startNanos = System.nanoTime(); final long jitterNanos = startNanos - frameTimeNanos; if (jitterNanos >= mFrameIntervalNanos) { final long skippedFrames = jitterNanos / mFrameIntervalNanos; if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) { Log.i(TAG, "Skipped " + skippedFrames + " frames! " + "The application may be doing too much work on its main thread."); } final long lastFrameOffset = jitterNanos % mFrameIntervalNanos; if (DEBUG_JANK) { Log.d(TAG, "Missed vsync by " + (jitterNanos * 0.000001f) + " ms " + "which is more than the frame interval of " + (mFrameIntervalNanos * 0.000001f) + " ms! " + "Skipping " + skippedFrames + " frames and setting frame " + "time to " + (lastFrameOffset * 0.000001f) + " ms in the past."); } frameTimeNanos = startNanos - lastFrameOffset; } if (frameTimeNanos < mLastFrameTimeNanos) { if (DEBUG_JANK) { Log.d(TAG, "Frame time appears to be going backwards. May be due to a " + "previously skipped frame. Waiting for next vsync."); } scheduleVsyncLocked(); return; } if (mFPSDivisor > 1) { long timeSinceVsync = frameTimeNanos - mLastFrameTimeNanos; if (timeSinceVsync < (mFrameIntervalNanos * mFPSDivisor) && timeSinceVsync > 0) { scheduleVsyncLocked(); return; } } mFrameInfo.setVsync(intendedFrameTimeNanos, frameTimeNanos); mFrameScheduled = false; mLastFrameTimeNanos = frameTimeNanos; } try { Trace.traceBegin(Trace.TRACE_TAG_VIEW, "Choreographer#doFrame"); AnimationUtils.lockAnimationClock(frameTimeNanos / TimeUtils.NANOS_PER_MS); mFrameInfo.markInputHandlingStart(); doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos); mFrameInfo.markAnimationsStart(); doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos); mFrameInfo.markPerformTraversalsStart(); doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos); doCallbacks(Choreographer.CALLBACK_COMMIT, frameTimeNanos); } finally { AnimationUtils.unlockAnimationClock(); Trace.traceEnd(Trace.TRACE_TAG_VIEW); } if (DEBUG_FRAMES) { final long endNanos = System.nanoTime(); Log.d(TAG, "Frame " + frame + ": Finished, took " + (endNanos - startNanos) * 0.000001f + " ms, latency " + (startNanos - frameTimeNanos) * 0.000001f + " ms."); } }通过代码咱们发现，FrameHandler它接管音讯，而后解决音讯，调用Choreographer的doFrame函数，这个doFrame非postFrameCallback的FrameCallback的doFrame，而通过代码的搜寻，我发现FrameCallback的doFrame 就是通过这里触发的，在doCallbacks函数中。这个细节不带你们看了，咱们来看这个FrameHandler的音讯是谁触发的，接着看FrameDisplayEventReceiver
private final class FrameDisplayEventReceiver extends DisplayEventReceiver implements Runnable { private boolean mHavePendingVsync; private long mTimestampNanos; private int mFrame; public FrameDisplayEventReceiver(Looper looper, int vsyncSource) { super(looper, vsyncSource); } @Override public void onVsync(long timestampNanos, int builtInDisplayId, int frame) { // Ignore vsync from secondary display. // This can be problematic because the call to scheduleVsync() is a one-shot. // We need to ensure that we will still receive the vsync from the primary // display which is the one we really care about. Ideally we should schedule // vsync for a particular display. // At this time Surface Flinger won't send us vsyncs for secondary displays // but that could change in the future so let's log a message to help us remember // that we need to fix this. if (builtInDisplayId != SurfaceControl.BUILT_IN_DISPLAY_ID_MAIN) { Log.d(TAG, "Received vsync from secondary display, but we don't support " + "this case yet. Choreographer needs a way to explicitly request " + "vsync for a specific display to ensure it doesn't lose track " + "of its scheduled vsync."); scheduleVsync(); return; } // Post the vsync event to the Handler. // The idea is to prevent incoming vsync events from completely starving // the message queue. If there are no messages in the queue with timestamps // earlier than the frame time, then the vsync event will be processed immediately. // Otherwise, messages that predate the vsync event will be handled first. long now = System.nanoTime(); if (timestampNanos > now) { Log.w(TAG, "Frame time is " + ((timestampNanos - now) * 0.000001f) + " ms in the future! Check that graphics HAL is generating vsync " + "timestamps using the correct timebase."); timestampNanos = now; } if (mHavePendingVsync) { Log.w(TAG, "Already have a pending vsync event. There should only be " + "one at a time."); } else { mHavePendingVsync = true; } mTimestampNanos = timestampNanos; mFrame = frame; Message msg = Message.obtain(mHandler, this); msg.setAsynchronous(true); mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS); } @Override public void run() { mHavePendingVsync = false; doFrame(mTimestampNanos, mFrame); } }onVsync 检索源码发现这个函数是由android.view包下DisplayEventReceiver触发，DisplayEventReceiver理论是在C++层初始化，并监听Vsync信号，其实是由SurfaceFlinger传递过去，所以这里我晓得了，FrameDisplayEventReceiver用来接管onVsync信号，而后通过mHandler也就是下面的FrameHandler触发一次音讯的传递。然而你是不是有点狐疑不对劲，因为下面的case MSG_DO_FRAME 才会触发doFrame函数，这里没有设置这样的音讯mHandler.obtainMessage(_MSG_DO_FRAME_)，这样就会触发对吧，但认真看Message.obtain(mHandler, this)，这里的this就是FrameDisplayEventReceiver，而FrameDisplayEventReceiver实现Runnable，那么就会导致FrameHandler在收到音讯后，执行FrameDisplayEventReceiver的run函数，而这个函数就是调用了doFrame，那么就通了。
好了，能够总结下为什么能够了：
Choreographer的onVsync 音讯生产其实就是通过所在线程中的Looper中解决的，那么咱们监控主线程中的looper音讯，同样也能监控到帧率。就是这样的情理。
小结
- Main Looper 中设置 Printer来做散发
- 散发起初计算帧率
- 通过MessageQueue.IdleHandler避开线程繁忙的工夫，期待闲时解决
大抵就这么多，如果你有什么新发现，或者我有不对的中央，欢送评论执教。