Chrome下游戏循环每帧function_data过高触发GC的优化咨询

DevTools内存快照中观测到的function_data，本质是V8引擎为每次函数调用生成的临时作用域上下文、函数绑定记录块——哪怕函数本身未显式定义闭包，只要调用过程中存在动态绑定、临时函数实例创建、多层作用域嵌套，V8都会为这次调用生成独立的function_data内存块，调用结束后无根引用时即被GC回收，这就是观测到每帧生成并回收大量该类内存的核心原因。

可落地优化路径 #

从根源消除每帧重复生成function_data的场景 #

• 排查核心调用链内部的临时函数定义：如果run函数及其嵌套调用的函数链中，存在循环内定义的箭头函数、普通函数字面量（例如在每帧执行的回调中写实体筛选的内联判断逻辑），哪怕这些临时函数没有引用外部变量，每次执行时V8都会创建独立的函数实例，生成配套的function_data。将这类频繁使用的回调函数全部提升到模块顶层，以静态常量引用，不在每帧执行的代码块内部动态定义函数字面量，即可彻底消除这类分配。
• 优化run函数的入参传递逻辑：如果每帧调用run时都通过字面量新建入参对象（例如传入包含大量临时构造属性的对象），V8会为这次入参绑定生成独立的作用域记录，配套生成对应的function_data。可创建一个模块级的复用入参对象，每帧调用run前直接修改该对象的属性值，不再每帧新建入参实例。
• 避免动态this绑定产生的临时函数Wrapper：如果run函数或其内部调用的逻辑，通过.bind()、内联箭头函数做临时this绑定，每一次绑定操作都会生成独立的函数包装器，附带对应的function_data。可通过Reflect.apply直接传入上下文参数调用目标函数，减少动态绑定产生的临时实例。

缩小已生成function_data的单块体积 #

• 降低函数嵌套的作用域层数：V8生成function_data时，会将当前函数可访问的所有外层作用域的变量引用全部存入对应上下文块。如果run函数嵌套在多层其他函数内部（例如在初始化函数、游戏循环入口函数内部定义run），哪怕run本身没有引用外层的变量，V8也会将这多层作用域的引用全部存入function_data，大幅提升单块内存体积。将run函数提升至模块顶层，切断不必要的外层作用域引用，让V8生成轻量化的瘦上下文块，即可缩小单块内存体积。
• 切断大对象在临时作用域中的绑定：如果run函数的局部变量、入参中直接挂载了超大的对象引用（例如完整游戏状态树、大尺寸资源对象），这些引用都会被记录到当前帧的function_data中，直接提升内存占用。将这类大对象改为模块级的全局静态引用，不通过临时作用域绑定传入，即可减少function_data中的冗余引用存储。

降低GC对帧率的影响 #

• 核心循环迁移至Worker线程运行：将run函数所在的核心游戏逻辑放入独立Worker中运行，Worker的独立堆内存中，V8对长期稳定运行的函数实例会做持久化优化，减少临时function_data的重复创建，同时Worker线程内的GC不会阻塞主线程的渲染流程。
• 避免函数触发V8去优化逻辑：如果run函数此前被V8优化为机器码执行，一旦某帧入参类型和历史调用不一致（例如原本传入数字，某帧传入字符串），V8会将函数退回解释执行模式，对应的function_data会从持久化优化对象拆分为每帧重新分配的临时对象。可通过固定入参类型、避免动态修改入参结构的方式，减少函数去优化触发的概率。

验证方式：完成优化后，持续运行10帧以上的稳定循环，查看内存快照中function_data的总量是否随循环轮次线性增长，如果总数量稳定在固定阈值，即说明对应的临时分配已被消除。

内容的提问来源于stack exchange，提问作者edbentley