关于持续生成快照的一些想法

[zhishaofei3]

作者好！

我最近在用rrweb生成回放，用到了checkoutEveryNth，看到生成的数据比较大，所以产生了一些想法。

我的经验是，如果需要给服务端发送events，checkoutEveryNth数量并不是越小越好，因为在每次触发isCheckout重新制作快照的时候，会重新制作整个页面的快照，这样如果传递最后两个events数组，实际数据中会包含两次整个页面的快照，如果页面结构本身比较复杂，那么内容就会非常大。

可否在options中增加maxEventsLength参数，然后在触发到Events长度最大值的时候，对之前的数据和原有快照进行合并？这样能保证当前的events中完整的DOM树快照只有一个，避免多次制作完整快照，节省传输成本和大量空间。

或者提供一个合并events的方法，由用户手动将任意个events进行合并，这样更加灵活，传输数据量也更小。

不知道是否可行？

[Yuyz0112]

“将一个快照 + 多个增量 events 合并为一个新的时间点的快照”，这个做法是理论可行的。

从设计上来说，不太想使用浏览器 API 做这件事情，因为可能会对被录制应用的运行时产生一定的影响（例如创建一个不可见的 iframe，在里面进行回放，到指定时间点再重新制作快照）。

更好的方式应该是使用一个特定实现的 DOM： #419

[zhishaofei3]

假如我设置checkoutEveryNth: 50，
现在的问题是当isCheckout触发的时候会重建events，假设页面发生报错时第二个数组只收集到了10个event，这就导致新的events数组中event数量会非常少，不足生成回放。

但是取两个50 + 10的数据量又远远大于设置checkoutEveryNth: 60的数据量，所以现在的切换是不连续的，应该想办法不重新制作快照。

你说的rrdom我理解在录制时也需要收集当前DOM吧？