3. 座舱软件平台概览

帧率这东西，说白了就是座舱交互流畅度的“体温计”。用户觉得卡不卡，最终都会落到FPS这个数字上。但怎么测、用什么测、在什么场景下测，这里面的门道可不少。我这些年踩过的坑，今天一次性给你讲透。

3.1 工具链选择：选对工具，事半功倍

市面上能测帧率的工具不少，但真正适合座舱场景的，我个人习惯就两把“尖刀”：PerfDog 和 Snapdragon Profiler。它们各有侧重，我一般搭配着用。

3.1.1 PerfDog：快速上手与关键配置

PerfDog最大的好处就是“傻瓜式”。连上设备，选好应用，点开始就行。但有几个参数你得注意：

• 采样间隔： 默认100ms就够了，别设太细，数据量太大反而不好看趋势。
• 关注指标： 除了FPS，一定要同时勾选 Jank（卡顿次数）和 BigJank（严重卡顿）。FPS 60不代表不卡，Jank数才是用户体验的“照妖镜”。
• 数据导出： 我习惯导出CSV，方便后续做统计分析。

3.1.2 Snapdragon Profiler：深度定位利器

这个工具稍微有点门槛，但它是高通平台的“核武器”。它能告诉你每一帧的GPU渲染时间、顶点数、像素填充率、带宽占用……说白了，它能让你看到“卡顿到底是谁干的”。

我一般用它做这几件事：

1. 抓取单帧渲染流水线： 看看是Vertex Shader慢，还是Fragment Shader慢。
2. 分析Overdraw： 座舱的HMI界面经常有层层叠叠的控件，Overdraw一高，帧率直接崩。
3. 看带宽瓶颈： 纹理太大、压缩格式不对，都会导致带宽打满，帧率上不去。

3.2 测试场景设计：别在“理想环境”里自欺欺人

很多团队测帧率，就在实验室里开着空调，屏幕只显示一个静态桌面，然后告诉我“帧率60，很稳”。嗯，这种数据，我一般只看一眼就扔了。为什么？因为用户在实际开车时，场景远比这复杂。

我个人习惯把测试场景分为三类：

你想想看，用户最常抱怨卡顿的时候，是不是就是在导航时突然来个电话，或者一边充电一边用高德地图？所以，压力场景才是我们真正要攻克的堡垒。

3.2.1 动态场景设计要点

动态场景不是随便划两下就完事。我总结了一套“标准化操作脚本”：

• 地图缩放与平移： 从1:5000缩放到1:100，再平移500公里，重复3次。
• 列表快速滚动： 从列表顶部快速滑到底部，记录滚动过程中的帧率曲线。
• 应用冷启动与热切换： 连续打开/关闭5个应用，记录每次切换的帧率恢复时间。

3.3 数据采集与分析：别只看平均值

数据采集完了，怎么分析？很多人只看一个“平均帧率”，比如平均58帧，就觉得没问题。但用户感知到的卡顿，往往发生在帧率突然掉到20帧的那一瞬间。所以，我们要看的是帧率曲线，而不是一个孤立的数字。

我一般会关注这几个核心指标：

3.4 帧率评估知识体系图

下面这张图，是我自己梳理的帧率评估全流程。你可以把它当作一个检查清单，每次做评估时对照着来。

3.5 数据采集实操步骤

最后，我分享一下我自己的数据采集标准流程。你照着做，基本不会漏掉关键信息。

1. 环境准备： 确保车机处于稳定温度（避免过热降频），连接好USB线，关闭后台不必要的应用。
2. 工具启动： 打开PerfDog或Snapdragon Profiler，选择目标进程，开始记录。
3. 执行测试脚本： 按照预定的静态、动态、压力场景顺序，逐一操作。每个场景持续至少2分钟。
4. 数据标记： 在每个场景切换时，手动打一个标记（Mark），方便后续分析时定位。
5. 数据导出： 导出CSV和截图，保存到项目文件夹，命名规则：项目名_场景名_日期_版本号。
6. 初步分析： 先看平均FPS和Jank次数，如果异常，立刻用Snapdragon Profiler抓取对应时间段的GPU细节。