想优化哪段就量哪段｜GPM自定义区间精准观测任意游戏流程|gpm|代码|数据表|游戏流程|调用

大家好，今天小Q 来带你认识

GPM新功能：自定义区间统计。

用GPM的，从来不只是做性能优化的同学 —— 主程盯着架构和线上风险，制作人盯着版本质量，运营盯着活动和玩家口碑，QA盯着这版有没有变差。岗位各不相同，但有一件事出奇地一致：你们真正在意的，几乎从来不是“整局的平均数”，而是某一段具体的时刻。

制作人问的是 “新版本上线首日，玩家进游戏那几步顺不顺”；

运营担心的是 “大活动开启那一下会不会卡崩”；

主程要确认的是 “那套新框架在真实战斗里稳不稳”；

做优化的，盯的是 “那段团战的帧率到底掉多少”。

你看，没有谁在优化“整局游戏” —— 大家心里装着的，都是一段一段的“具体现场”，而不是一个笼统的整体数字。

可你打开性能看板，能切的刻度就那么几个：版本、机型、场景。它们都很有用，但有一个共同的前提 —— 边界是系统替你定好的，未必对得上你心里那一段。于是你只能挑一个“最接近”的场景名将就着看，或者干脆翻原始报告、自己对时间戳，把那一段一点点拼出来。

将就是有代价的。你看的那条边界，和你真正在乎的那条边界，一旦错位，均值就会被你根本不关心的部分稀释：你以为在优化“战斗”，其实数字里掺进了一半的待机和跑图。修了半天，你都不确定有没有修在玩家真正难受的那一段上。

所以，做到一定深度的团队，迟早会撞上同一个诉求：能不能让我自己定义“要盯的是哪一段”，而不是被现成的维度框死？

这正是GPM新上线的自定义区间统计要回答的问题。它做的事一句话：把“该量哪一段”的决定权，连同“在哪儿画线”的那支笔，一起交到你手上 —— 你在代码里圈出你真正在乎的那一段，剩下的读数它来给。（这是GPM平台上你自己动手用的功能，不是我替你跑的活；我这篇，是来帮你把“你为什么会需要它”讲明白。）

为什么场景这把尺子，

圈不出你要的那一段

先把话说透，不然你会觉得“不就是再多切一个维度嘛”。

均值这东西，是有边界的。你按什么边界去平均，它就只能回答什么边界内的问题。而现成的两把尺子，边界都不由“你要优化的这一段”说了算。

全局均值，边界是整场会话的头到尾。它告诉你“这台设备这局整体流不流畅”，但你要优化的那3秒加载、那一次团战爆发，早被几十分钟的正常帧率稀释得看不见了。

场景均值，边界是“场景切换”的那一刻。场景比全局细得多，这条边界也不一定是引擎定死的 —— 你完全可以按自己的需要去规划场景怎么划。但场景有一条改不掉的铁律：它必须串行，任何两个场景不能重叠。玩家在任一时刻只能处在一个场景里，上一段结束、下一段才开始，像一条不回头的时间线。

就是这条“不能重叠”的铁律，卡死了一大类你真正关心的问题。最典型的是团本里两个同时在场的BOSS：BOSS A血量还没清、BOSS B就登场，两段战斗在时间上叠着，你想分开看“打A卡不卡、打B卡不卡”，场景却只能把这段时间整体归给某一个 —— 你想按BOSS拆，它天生拆不开。不止BOSS —— 一段网络请求正好压在一段渲染上、一个持续的Buff特效横跨了好几波小怪，凡是“两件事在同一段时间里并行发生、你却想拆开各看各的”，场景这把尺子都无能为力。

场景是一条不回头的时间线，一段接一段、绝不重叠；可你想量的东西，常常是能叠在一起的。能不能重叠，就是你为什么需要自定义区间的那道分水岭。

自定义区间做的，就是把这条限制拿掉，再把“画线的那支笔”交回你手上。你在自己的代码里，给一段流程打上一对开始/结束标记、起个名字（对应GPM收到的 custom_interval_begin/custom_interval_end 这对事件），这一段就成了一个能被独立统计的对象。它可以跨好几个场景，可以只是一个场景里的一小截，更可以和另一个区间彼此重叠 —— BOSS A的区间还没结束，BOSS B的区间照样开得起来，两条线各算各的、互不打架。边界怎么画，全你说了算。然后GPM把千百台真机上所有被你这样标过的同名区间，聚合成一张读数：这一段的FPS均值、抖动、低帧、Jank、帧时间超100ms的比例，以及它这一段里的内存、温度、功耗、CPU/GPU表现。

你截图里那几个 test/test001/test002/test1/test2/test3 ，就是有人已经这么标过了 —— 每一行，都是一段被单独框出来、单独量过的流程。

这把尺子，具体能接住你哪些活

我把落地场景挑了最典型的五个。第一个，就是场景这把尺子永远替不了的那种。

1. 两段在时间上重叠的流程 —— 比如两个同时在场的BOSS。

这是自定义区间最不可替代的场景，因为它是场景唯一做不到的那件事。团本里BOSS A血量没清、BOSS B已经进场，两段战斗在时间上叠着；你想知道的是“打A卡不卡、打B卡不卡”，得把这两段分开量。场景做不到 —— 同一时刻只归属一个场景，它俩会被压进同一条均值，谁的锅都分不清。用两个自定义区间各自框住A、B的战斗过程，哪怕时间重叠也不打紧，两条读数各算各的：A的帧率、B的帧率、各自的卡顿和内存，清清楚楚摆成两行。凡是“多件事并行发生、你却想拆开各看各的” —— 重叠的技能结算、叠在一起的网络与渲染、横跨几波怪的持续特效 —— 都是同一类问题，也都只有自定义区间接得住。

别的尺子都在教你“怎么把一段时间切给谁”；自定义区间头一个告诉你 —— 同一段时间，可以同时属于好几个你关心的东西。

2. 一段跨场景的关键流程 —— 比如“冷启动到可操作”。

冷启动体验是留存的第一道坎，可它天然横跨加载页、主城、首次战斗好几个场景。场景表把它切成三四段，每段单看都“还行”，你却答不出“这一整段玩家等得难不难受”。把这一整段标成一个区间，你拿到的就是这条流程作为一个整体的流畅度读数 —— 哪一版变长了、哪类机型上这段最挣扎，一眼可比。你终于是在为“玩家进游戏的头30秒”负责，而不是为三个互不相干的场景名负责。

3. 一个场景内部的子阶段 —— 比如战斗里那记大招齐放。

战斗场景整体55帧，看着很健康；可玩家骂的是“团战一放技能就顿一下”。那一记大招齐放可能只占整场战斗的百分之几，均值一平摊，尖峰就没了。你把“技能爆发段”单独标成一个区间，它的低帧和Jank就从均值里被拎出来，独立成行 —— 被整场战斗盖住的那个真实痛点，这才现形。

均值最擅长的事，就是把你最该看见的那个尖峰，抹得像没发生过。

4. 两条代码路径的A/B对比 —— 比如对比两条不同参数的渲染管线。

同一个战斗场景，你想比渲染管线的“新 vs 旧”、动态阴影的“开 vs 关”、以及“A方案 vs B方案”。机型、版本、场景全一样，差别只在你那几行分支代码里 —— 这时候前面那几把尺子全都失效，因为它们切不出“哪一版代码在跑”。用两三个区间名把每条路径各自框起来，它们就并排摆成柱状图和对比表：谁的FPS更稳、谁的卡顿更少、谁更费电，不用你拿两次跑测的数据在两个浏览器标签页里来回瞪。

5. 跑测/自动化里的标定段 —— 把每一段测试跑成一张对比表。

你在自动化跑测脚本里，本来就把一次运行切成了好几个阶段。给每个阶段标上区间名（test001、test002……就是这么来的），跑完真机，按区间的横向对比就出来了：这次改动让哪一段变好了、哪一段悄悄退步了。回归有没有引入性能劣化，从“你自己对着日志比”变成“一张表摆在这儿”。

自定义区间性能页：上方按区间出柱状图

下方是逐区间的流畅度指标数据表

还有一层：不只是“量一段”，

更是“在你要的那一刻主动出手”

前面聊的都是“把一段圈出来、事后量它”。但自定义区间还有一个容易被忽略、却特别实用的身份 —— 它不只是一扇被动的测量窗口，更是一个由你亲手掌控的触发点。

GPM平时的数据采集，是按固定节奏走的：截图、部分信息的采集，系统都按内建的周期“定时定量”地做。这套默认策略省心，可它有个天生的短板 —— 它并不知道哪一刻对你最关键，只能均匀地采。你最想看清的那一帧，很可能正好落在两次定时采集的空档里，就这么错过了。

而自定义区间是你在自己代码里打下的标记，这就给了你一个天然的抓手：在这个你亲手圈定的时刻，你可以顺手调用GPM SDK的能力，主动去取你真正想要的东西 —— 比如就在这一刻抓一张截图、把这一段的采集精度临时调高、或者改变这一段要采集的信息。系统那把“到点就响”的定时快门够不着的地方，你自己按得下。

举个例子：BOSS二阶段变身那一下，你要的恰恰是那一瞬间的画面和更细的数据。指望系统的定期截图正好撞上它，多半会扑空；而在区间的标记点上主动抓一帧，它一次都不会漏。

系统的采集是“到点就采”，采的是它的节奏；自定义区间让你“要看才采”，采的是你的时刻。

你打开它会看到什么

入口是一个独立页面 —— 自定义区间性能。进去以后跟你熟悉的场景性能页几乎是一套用法，就是把你在场景页看的那套读数，换到量你的区间上。

两个指标Tab：「流畅度指标」给你FPS均值/抖动/低帧、Jank、帧时间>100ms比例；「硬件指标」给你内存、温度、功耗、电流、CPU/GPU、设备档位。上面是按区间排开的柱状图，下面是能搜索、能下载的逐区间数据表。

切到「硬件指标」Tab：同一批区间

换看PSS内存、电流、功耗、CPU/GPU/电池温度

它还是一个筛选维度：「自定义区间」和版本、机型、场景一样，进了全局筛选器。意思是你不光能在这个页面看它，还能反过来用它去切别的分析 —— “只看‘首战加载’这个区间里的机型分布”这种问法，现在也成立了。

「自定义区间」与版本/场景/机型并列进入

全局筛选维度，区间取值一目了然

有几句话，我想先说

这把尺子好用，但它有它的脾气。我宁可先跟你说清楚，也不想你用着用着觉得我藏了坑。

那两列“不支持”，不是功能漏了，是它们真的不适用。

数据表里「进入场景次数」和「场景平均加载耗时」这两列，在自定义区间下显示“不支持”。原因很实在：自定义区间不是场景，它是你标的一段begin/end，天然就没有“进入了几次场景”“场景加载花了多久”这种语义 —— 这两个指标只有对“场景切换”才讲得通。硬凑一个数字才是糊弄你，说不支持就是不支持。

标了才有数，没标就没有。

这把尺子忠实反映你画的线：你在代码里标得准、标得有意义，读数就有价值；你随手乱标、名字起得一团乱，聚合出来的也只能是一团乱。所以名字请起得规整、边界请画得讲究 —— 这把尺子有多准，取决于你的手有多稳。

它是真机线上的聚合，不是单台设备的Profiler。

它给你的是“这一段流程，在千百台真实玩家设备上，平均和分布表现如何”，是拿来定优先级、看趋势、做A/B的。它回答“哪一段该优化、在哪类机型上最该优化”；至于“这一帧的调用栈具体卡在哪个函数”，那是本地ProfilerUWA GOT Online和卡顿归因该接的活，各管一段、不越界。

区间和场景一样，是要单独算账的。

每多一个区间，GPM后台就要为它多算一套聚合（跟场景是同一个量级的成本）。所以它值得你用，但不建议你把代码里塞满几百个区间 —— 挑那些你真正会反复盯、反复对比的关键流程去标，读数干净，算得也利落。

为什么这件事，值得你认真用起来

绕了一圈，其实又回到开头那句话：不管你是什么岗位，真正在意的都是某一段具体的时刻。

差别只在于，过去你只能拿现成的刻度去“将就”那一段 —— 按场景看，你看的是引擎（或别人）划好的段落；按整场会话的均值看，你看的是一个早被稀释的平均数。于是想确认版本质量的制作人、盯着活动那一下的运营、要给新框架背书的主程、死磕帧率的优化，都可能对着一个“不完全是你要的那一段”的数字，反复琢磨半天。

自定义区间把“边界的定义权”还给你，等于让每一次测量、每一次对比，都精确对齐到你自己真正在乎的那一段：制作人盯的“进游戏头几步”、运营担心的“活动开启那一下”、主程要验的“实战里的新框架”、优化死磕的“团战那一记大招” —— 从此它们各自都是一个能被单独量、单独比、单独盯，还能在关键那一刻主动取证的对象。你在乎哪一段，就量哪一段；量得准，后面那步判断才立得住。