2、性能基础：掌握帧率、延迟、内存占用、温度的基本概念、测量单位及相互影响关系

在旭日性能优化工作中，帧率、延迟、内存占用与温度是四个最核心的量化指标。它们分别从流畅度、响应速度、资源占用与热功耗四个维度刻画了系统的运行状态。然而，这四个指标并非孤立存在——帧率下降可能源于内存频繁换页，延迟飙升可能由温度触发的降频引起，而内存泄漏又会推高温度。理解它们的基本概念、测量单位以及相互之间的耦合关系，是后续进行系统性调优的前提。本章将逐一拆解这些基础概念，并建立一张完整的性能影响关系图。

2.1 核心概念与测量单位

帧率（Frame Rate） 表示图形渲染管线每秒输出的完整画面数量，单位为 fps（frames per second）或 Hz。在旭日平台上，帧率直接决定了用户视觉上的流畅度。30 fps 是交互应用的最低可接受标准，60 fps 是主流目标，而 90 fps 或 120 fps 则用于 VR 或高刷新率显示场景。测量帧率时，应区分平均帧率与1% 低帧率——后者反映最差情况下的卡顿程度，比平均值更能暴露性能问题。

延迟（Latency） 指从输入事件发生到屏幕像素更新之间的总耗时，单位为毫秒（ms）或微秒（μs）。它由输入采样延迟、渲染队列延迟、合成延迟和显示刷新延迟四段组成。在旭日系统中，触摸屏采样到 GPU 提交通常需要 20-50 ms，而端到端延迟应控制在 100 ms 以内才能保证“跟手”体验。测量延迟需要专用设备（如高速相机）或软件插桩，常用方法包括 choreographer 帧回调时间戳差值和 SurfaceFlinger 合成时间戳。

内存占用（Memory Usage） 指进程或系统当前使用的物理内存与虚拟内存总量，单位通常为 MB 或 GB，也可用占系统总内存的百分比表示。旭日平台的内存分为代码段、数据段、堆、栈和图形缓冲区等区域。关键测量指标包括：PSS（按比例分摊物理内存）、RSS（常驻内存）和 VSS（虚拟内存）。其中 PSS 最准确，因为它将共享库按进程数均摊。内存占用过高会触发系统 LMK（低内存杀手）或直接导致应用被杀。

温度（Temperature） 指 SoC 芯片结温（Tj）或外壳表面温度，单位为摄氏度（℃）。旭日 SoC 内部集成了多个温度传感器，分布在 CPU 簇、GPU、NPU 和 DDR 控制器附近。正常工作温度范围通常在 -20℃ 至 85℃ 之间，但超过 60℃ 时系统会开始采取降频措施。测量温度可通过 /sys/class/thermal/thermal_zone*/temp 节点读取，或使用红外热像仪测量外壳温度。

2.2 判断方法与操作流程

在实际调优中，需要建立一套标准化的测量流程，确保数据可复现、可对比。以下是推荐的性能基线采集流程：

1. 环境准备：将设备置于 25℃ 恒温环境，关闭后台无关应用，连接 adb 并开启 root 权限。
2. 帧率采集：运行目标场景 5 分钟，同时执行 dumpsys SurfaceFlinger --latency 每 2 秒采样一次，记录帧时间戳。
3. 延迟测量：使用自动化点击脚本触发固定操作，通过高速相机（240 fps 以上）记录手指接触屏幕到画面变化的帧数差。
4. 内存快照：在场景运行前、运行中、结束后分别执行 dumpsys meminfo <package>，记录 PSS 值变化。
5. 温度记录：每 10 秒读取一次 /sys/class/thermal/thermal_zone0/temp，同时用 top 监控 CPU 频率。

判断性能瓶颈时，应遵循“先看温度，再看帧率，最后查内存”的顺序。因为温度会触发降频，导致帧率和延迟同时恶化；而内存问题往往表现为间歇性卡顿而非持续掉帧。若温度超过 70℃ 且 CPU 频率被限制在最低档，则首要解决散热或功耗问题。

2.3 案例拆解：一场由温度引发的“连环崩溃”

背景与约束：某款基于旭日 X3 芯片的智能座舱产品，在夏季高温暴晒后启动导航应用，出现严重卡顿。约束条件：无法增加散热片（结构已定型），系统必须保证 60 fps 的导航画面流畅度。

初始现象：导航启动后前 30 秒正常，随后帧率从 60 fps 骤降至 25 fps，触摸延迟从 80 ms 飙升至 220 ms，同时内存 PSS 从 800 MB 缓慢增长至 1.2 GB。

关键数据采集：

# 温度节点读取
cat /sys/class/thermal/thermal_zone0/temp   # 输出 78000 (即 78℃)
cat /sys/class/thermal/thermal_zone1/temp   # 输出 82000 (即 82℃, GPU 附近)

# CPU 频率状态
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq  # 480000 (最低档)

# 内存快照
dumpsys meminfo com.example.navigation | grep "TOTAL PSS"  # 1200000 kB

分析判断：温度 82℃ 已超过降频阈值 75℃，CPU 被锁定在 480 MHz 最低频率。帧率下降的直接原因是 CPU 渲染能力不足，但根本原因是热约束。内存 PSS 增长至 1.2 GB 是因为导航地图缓存持续加载，但尚未触发 LMK，属于次要因素。延迟飙升至 220 ms 则是由于帧率下降导致渲染队列堆积，输入事件等待时间变长。

实际操作步骤：

1. 首先通过 echo 0 > /sys/class/thermal/thermal_zone0/mode 临时禁用温控（仅测试用），确认帧率恢复至 55 fps，验证温度是主因。
2. 优化导航应用的 GPU 渲染负载：将地图瓦片纹理从 1024×1024 降为 512×512，减少填充率开销。
3. 在应用层增加帧率自适应逻辑：当检测到温度超过 70℃ 时，自动将导航画面从 60 fps 降为 45 fps，并降低地图缩放动画的平滑度。
4. 调整系统调频策略：将 cpufreq 的 governor 从 performance 改为 schedutil，允许在非重载时主动降频降温。

结果对比：优化后，在相同 35℃ 环境温度下，SoC 结温稳定在 68℃，帧率维持在 50-55 fps（略低于 60 但可接受），延迟降至 120 ms 以内，内存 PSS 稳定在 1.0 GB 不再增长。

风险与代价：降低纹理分辨率导致地图文字在放大时轻微模糊；帧率自适应策略在快速滑动时会有感知度下降。这些代价通过 UI 层增加矢量文字渲染补偿，最终用户无感知。

复盘经验：温度是旭日平台性能的“总开关”。任何性能优化都应先确认热余量，再谈帧率和延迟优化。内存问题在此案例中不是主因，但若持续增长最终会触发 LMK 导致应用重启，因此仍需监控。

2.4 常见误区与总结复盘

误区一：只关注平均帧率，忽略帧间隔抖动。 平均 55 fps 可能由“50 fps 持续 2 秒 + 60 fps 持续 1 秒”组成，这种抖动在视觉上表现为微卡顿。正确做法是同时统计帧间隔的 P95 和 P99 值。

误区二：将内存占用等同于内存泄漏。 内存增长可能是缓存策略导致的正常现象。判断泄漏需要观察内存是否在场景停止后仍不回落，且持续增长超过 20% 以上。

误区三：延迟高就一定是渲染慢。 输入线程优先级低、触摸驱动采样率不足、显示面板响应时间慢都可能导致延迟高。应分段测量，定位具体瓶颈段。

误区四：温度越低越好。 过度追求低温会导致 CPU/GPU 频率被限制，反而降低性能。合理的做法是设定一个“性能-温度”平衡点，例如允许短时 80℃ 但持续负载时稳定在 70℃。