【性能优化】帧率优化方法:第一步——量化

Android计算帧率的几种方法

对于性能优化来说,要优化必先量化,如果没有量化则无法判断优化方向、优化策略是否正确,也就无法知道优化后是否取得了预期的成效。
应用在使用过程的卡顿感,一直是一个让人头疼的问题,因为他涉及到系统、应用交互的方方面面。包括:

  • cpu调度是否合理
  • 方法执行时长是否合理
  • 视图结构设计是否合理:有没有绘制性能更好的布局层次
  • binder调用是否卡顿:常见的主线程调用的binder接口,因系统资源紧张出现长耗时导致卡顿
  • io操作的延迟:io wait占比是否合理
    所以,帧率优化的第一步------量化,显得尤为重要,本文总结常见的三种计算帧率的方法,用于实际帧率优化过程中的方向指导。

一、注册编舞者doFrame

Android系统每隔16ms执行一次重绘任务是VSYNC信号驱动的,invalide/requestLayout->ViewRootImpl:performMeasure->ViewRootImpl:performLayout->ViewRootImpl:performDraw->SurfaceFlinger合成,这个过程就是视图的重绘流程。而ViewRootImpl中控制ui执行重绘就是通过注册编舞者的onFrame回调来完成的,因此我们也可以采用该方式来计算到帧率数据。代码如下:

java 复制代码
private long lastFrameTimeNanos = 0;
private int frameCount = 0;
private static final long FPS_INTERVAL = 1000_000_000;
Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
    @Override
    public void doFrame(long frameTimeNanos) {
        Log.d(TAG, "doFrame: " + frameTimeNanos);
        Choreographer.getInstance().postFrameCallback(this);
        //当前的帧率
        frameCount++;
        if (lastFrameTimeNanos > 0) {
           long interval = frameTimeNanos - lastFrameTimeNanos;
           // 间隔超过1s再计算fps值
           if (interval >= FPS_INTERVAL) {
             float fps = frameCount * 1_000_000_000f / interval;
             Log.d(TAG, "doFrame: fps = " + fps);
             frameCount = 0;
             lastFrameTimeNanos = frameTimeNanos;
          }
       } else {
             lastFrameTimeNanos = frameTimeNanos;
       }
      Choreographer.getInstance().postFrameCallback(this);
   }
 });
  • doFrame方法中的frameTimeNanos代表是每一帧的开始时间戳 ,用纳秒为单位,除以1000000就是毫秒为单位了。
    输出帧率计算结果:
java 复制代码
2025-10-05 19:32:46.762 29510-29510 Chor...itor com...catchanrlog  D  doFrame: fps = 58.56009
2025-10-05 19:32:47.770 29510-29510 Chor...itor com...catchanrlog  D  doFrame: fps = 60.547974
2025-10-05 19:32:48.777 29510-29510 Chor...itor com...catchanrlog  D  doFrame: fps = 60.547493
2025-10-05 19:32:49.785 29510-29510 Chor...itor com...catchanrlog  D  doFrame: fps = 60.547493
2025-10-05 19:32:50.791 29510-29510 Chor...itor com...catchanrlog  D  doFrame: fps = 60.646725
2025-10-05 19:32:51.797 29510-29510 Chor...itor com...catchanrlog  D  doFrame: fps = 60.584347

总结:该计算方式比较只算,是按照fps的定义直接计算出来的,不足之处是只有主线程的doFrame帧率,没法体现renderThread线程的丢帧情况,有一定的局限性。

二、使用dumpsys gfxinfo pkg_name计算帧率

dumpsys gfxinfo pkg_name

输出示例:

复制代码
Applications Graphics Acceleration Info:
Uptime: 63736043 Realtime: 63736043
** Graphics info for pid 23188 [com.tcl.cyberui] **
Stats since: 56002698393874ns
Total frames rendered: 130
Janky frames: 0 (0.00%)
Janky frames (legacy): 0 (0.00%)
50th percentile: 9ms
90th percentile: 11ms
95th percentile: 11ms
99th percentile: 11ms

计算帧率方法 :丢帧数的差值除以总绘制帧数的差值,得到丢帧率,再用1-丢帧率乘以60就得到帧率,如果是120刷新率的则把60换成120即可。

60 * (1 - (Janky frames2-Janky frames1/(Total frames rendered2-Total frames rendered1)))

三、抓取trace查看帧率

  • 1、使用atrace、systrace、或者perfetto等命令抓取trace文件
  • 2、把trace文件拖入https://ui.perfetto.dev/#!/打开,计算帧率
  • 3、帧率计算方式如下:
相关推荐
叶智辽1 天前
【Three.js内存管理】那些你以为释放了,其实还在占着的资源
性能优化·three.js
BigByte2 天前
我用 6 个 WASM 编码器干掉了 Canvas.toBlob(),图片压缩率直接提升 15%
性能优化·webassembly·图片资源
DemonAvenger3 天前
Kafka性能调优:从参数配置到硬件选择的全方位指南
性能优化·kafka·消息队列
桦说编程3 天前
实战分析 ConcurrentHashMap.computeIfAbsent 的锁冲突问题
java·后端·性能优化
小马爱打代码4 天前
MySQL性能优化核心:InnoDB Buffer Pool 详解
数据库·mysql·性能优化
顾青4 天前
仅仅一行 CSS,竟让 2000 个节点的页面在弹框时卡成 PPT?
前端·vue.js·性能优化
山峰哥4 天前
吃透 SQL 优化:告别慢查询,解锁数据库高性能
服务器·数据库·sql·oracle·性能优化·编辑器
AI周红伟4 天前
周红伟:OpenAI 首席运营官,尚未真正看到人工智能渗透到企业业务流程中
人工智能·算法·性能优化
Volunteer Technology4 天前
JVM之性能优化
jvm·python·性能优化
小猿备忘录5 天前
【性能优化】人大金仓SQL优化实战:一条UPDATE语句从119分钟到2.68秒的蜕变
网络·sql·性能优化