关闭并不能捕捉到您想要使用的一个变量;它能捕捉到整个外在词汇环境的强烈参考.
任由无所管理, 环境永远不会留下记忆。
仪表板是一个复杂的数据网,是业务团队全天开放的工具.
每场比赛的头几分钟都很成功 在持续使用约20分钟后,它开始磨碎滤波器的后退,卷起口吃,最终全景变得足够迟缓,人们开始从习惯上而非诊断上刷新页面.
DOM尺寸是正常的。
网络请求很好。
实际原因是一个同步的投票循环,在组件首次挂起时设置过一次,关闭在组件初始状态上.
它从未被清理或重新同步。
每个民意测验周期,它都会通过引用数据来认真更新UI,这些数据被冻结在最初提供的元件的正毫秒处,它把原始的状态对象保存在了整个会话的记忆上,每过一分钟就会变得更僵硬更昂贵.
工程队的第一个本能是指责框架的渲染性能.
实际的根源是关闭的基本财产,大多数工程师学习了这个特性,从不把关闭当作责任来重新审视:关闭并不能捕捉你打算使用的唯一变量.
它包含了一个包含整个逻辑范畴的参考文献,只要关闭本身能够达到,范围就仍然被完全豁免于垃圾收集的记忆所固定。
关闭是JavaScript的超能力.
它们使封装、私人状态和清洁的模块模式在每一个现代框架之前成为可能。
在反应性,由事件驱动的架构中,组件上载并连续地卸载,回调活得远远长于创建它们的代码,同样的超能力是 stale state bug 和 静默的记忆bloat 的主因.
机制:关闭到底能维持什么 当一个函数在另一个函数内被定义时,它不仅在它所引用的变量,而且在它创建的整个语法环境中,在它所附加的范围上形成一个关闭.
JavaScript引擎不能有选择地保留"只是你正在使用的零件".
它保留了整个环境记录,因为它的任何部分理论上仍然可以访问.
并且从未在内部被引用,但是由于它们存在于与.的同个词典范围,V8无法证明它们无法被达到,实际上发动机通常保留了整个范围记录,而不是进行精细的可变分析.
如果被注册为回调或长寿事件收听器,那么该外域中的每一个物体只要间隔运行,就会一直活到永远,如果没人明确澄清,那就是页面的寿命.
这不是引擎里的窃听器。
这是词汇范围界定的正确、具体的行为。
问题在于建筑学:没有人决定它拖了多久,它带来的一切都应该活着。
现实世界的成本: Stale state and memory bloat, 加上上面的"仪表板"事件说明了两种故障模式的关闭同时产生,因为它们有着相同的根源.
Stale 状态同步错误 。
在初始渲染过程中注册的回调从特定执行上下文中捕捉状态变量 。
在具有被动再接力的框架中,组件在每次更新时都会重新接力有新鲜状态,但之前注册的回调并不自动知道.
它继续根据每次创建时的关闭值运作。
如果经常更新但效果的依赖数组仅包括 . , 间隔关闭会从效果上次运行时而不是当前时引用值 。
默默无声地对旧数据进行无限操作.
这恰恰是产生"我手动测试但真正使用几分钟后中断"的bug报告