4.优化 - 卡顿之FPS、慢函数监控

  之前提到用户对于界面流畅度的敏感度是比较高的,而界面的流畅度可以用 fps 来量化。在 Android 上,60 fps 是最常见的,而在一些高端的机子上正在追求 90 fps 甚至 120 fps,相当于要在一样的时间内做更多次的刷新渲染界面的操作。
  界面刷新渲染在 Android 中是接收来自与 SF 进程的 vsync 信号,从而触发界面的刷新渲染。而 fps 可以用 1s 内接收了多少次 vsync 来表示。具体的实现是与 Choreographer 类有很大的关系。

FPS 的计算

public class FPSMoniter implements Choreographer.FrameCallback {

    private final String TAG = "FPSMoniter";

    private long endTime;
    private int fps;

    private ILog logImpl;
    private FPSinterface fpSinterface;

    public FPSMoniter(ILog logImpl, FPSinterface fpSinterface) {
        this.logImpl = logImpl;
        this.fpSinterface = fpSinterface;
    }

    public void start() {
        Choreographer.getInstance().postFrameCallback(this);
    }

    /**
     * 1s 内调用了几次
     */
    private void calFPS() {
        if (System.currentTimeMillis() < endTime) {
            fps++;
        } else {
//            logImpl.Loge(TAG,"fps is "+fps);
            fpSinterface.fpsCallback(fps);
            endTime = System.currentTimeMillis() + 1_000;
            fps = 0;
        }
    }

    @Override
    public void doFrame(long frameTimeNanos) {
        Choreographer.getInstance().postFrameCallback(this);
        calFPS();
    }

    public interface FPSinterface {
        void fpsCallback(int fps);
    }
}

  Choreographer.getInstance().postFrameCallback(this); 将一个事件放进 Choreographer 的一个数组内,当 vsync 在 Choreographer 类里面回掉会依次执行数组内的一些事件(主要是输入事件,界面渲染,动画转场相关的),
所以当 vsync 回调时,会执行到我们放进去的 runable,而我们可以统计 1s 内执行 runable 的次数就可以算出 app 的 fps 。

慢函数的捕捉

  卡顿的本质就是函数执行的时间过长,导致了没有时间给 SF 进程相应的界面渲染数据,最后的结果就是还在显示上一帧的数据,所以对于慢函数的捕捉就很有必要,原理也是类似与 anr 的监控一样,当函数执行的时间超过一定的阈值是触发。
  因为主线程所有的事件都是由 main handler 来分发执行的,所以只要找到一个点来监控 handler 就可以得到函数的耗时。查看源码可以执行主线程事件都是放在了 MessageQueue 里面,从 MessageQueue 中取出的事件交给了 handler 来执行。在循环取 MessageQueue 事件中有一个 Printer 接口,在 handler 执行事件前后分别打印相应的 log,所以可以借助与 Printer 接口来统计函数的耗时,从而筛选出耗时比较长的函数。

            final Printer logging = me.mLogging;
            if (logging != null) {
                //开始事件前打印
                logging.println(">>>>> Dispatching to " + msg.target + " " +
                        msg.callback + ": " + msg.what);
            }
            ...
            try {
                //事件交给 handler 执行
                msg.target.dispatchMessage(msg);
                if (observer != null) {
                    observer.messageDispatched(token, msg);
                }
                dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
            } catch (Exception exception) {...} finally {...}
            ...
            if (logging != null) {
                //开始事件后打印
                logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
            }

代码实现

public class SlowMethodMoniter implements Printer {
    //在上线的 app 中感觉函数耗时很容易达到 0.1s,可以再设置大一些
    private static final long SLOW_METHOD_TIME = 100;
    private final String TAG = "SlowMethodMoniter";
    private Handler handler;

    private SlowMethodTask slowMethodTask;
    private long startTime;
    private String msg;

    private ILog logImpl;

    public SlowMethodMoniter(ILog logImpl) {
        this.logImpl = logImpl;

    }

    public void start() {
        handler = new Handler(Looper.getMainLooper());
        //要不要看看原来的有没有,可看
        handler.getLooper().setMessageLogging(this);
        slowMethodTask = new SlowMethodTask();
    }

    public void stop() {
        handler = null;
        //更好的办法是反射比原来的拿出来,stop的时候再将原来的放回去
        handler.getLooper().setMessageLogging(null);
    }

    public void report(Exception e) {
        logImpl.Loge(TAG, "slow method is " + e);
        e.printStackTrace();
    }

    @Override
    public void println(String x) {
        if (x.startsWith(">>>>>")) {
            startTime = System.currentTimeMillis();
            msg = x;
            slowMethodTask.addSlowMethodTask();
        } else if (x.startsWith("<<<<<")) {
            if (System.currentTimeMillis() - startTime > SLOW_METHOD_TIME) {
                Exception exception = new RuntimeException(msg);
                StackTraceElement[] stack = slowMethodTask.getStackTrace();
                if (stack != null) {
                    exception.setStackTrace(stack);
                }
                report(exception);
            }
            slowMethodTask.removeSlowMethodTask();
        }
    }

    public static class SlowMethodTask implements Runnable {

        private Handler handler;
        private HandlerThread handlerThread = new HandlerThread("SlowMethodTask");
        private StackTraceElement[] stackTrace;

        public SlowMethodTask() {
            handlerThread.start();
            handler = new Handler(handlerThread.getLooper());
        }


        @Override
        public void run() {
            //到了阈值还没有被移除,表示该函数的耗时大于阈值,拿主线程的堆栈
            stackTrace = Looper.getMainLooper().getThread().getStackTrace();
        }

        public StackTraceElement[] getStackTrace() {
            return stackTrace;
        }

        public void addSlowMethodTask() {
            stackTrace = null;
            handler.postDelayed(this, SLOW_METHOD_TIME);
        }

        public void removeSlowMethodTask() {
            handler.removeCallbacks(this);
        }
    }
}
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • 努比亚技术团队原创内容,转载请务必注明出处。当用户抱怨手机在使用过程中存在卡顿问题的时候,会严重影响用户对手机品牌...
    努比亚技术团队阅读 34,662评论 12 174
  • 卡顿是非常直观的用户体验,它的特点是:产生原因错综复杂,线上问题难以复现。基于这个特点,卡顿优化主要是三方面工作:...
    Stan_Z阅读 16,706评论 6 30
  • 卡顿原因 人眼能感觉到的帧率是每秒24帧,而屏幕每16毫秒会刷新一次,也就是每秒会刷新60次。当每秒刷新次数少于6...
    Archer_J阅读 2,915评论 0 16
  • 大多数用户感知到的卡顿等性能问题的最主要根源都是因为渲染性能。Android系统每隔大概16.6ms发出VSYNC...
    zcwfeng阅读 555评论 0 2
  • Android高手笔记-屏幕适配 & UI优化 屏幕与适配 由于Android碎片化严重,屏幕分辨率千奇百怪,而想...
    今阳说阅读 660评论 1 2