本文已参与「新人创作礼」活动，一起开启掘金创作之路。
前言
相信很多接触保险的小伙伴在2020年都有收到下面这条消息，简单描述就是：互联网保险在销售过程中的用户操作行为需要被记录和保存。
近期《中国银保监会关于规范互联网保险销售行为可回溯管理的通知》（以下简称“《通知》”）正式发布，并定于10月1日起正式实施，其与2017年发布的《保险销售行为可回溯管理办法》一起，构建起保险销售行为可回溯管理的基础制度框架，把线下、线上乃至电话销售等渠道的销售行为有机统一在一起。
刚听到消息的时候还有点懵，‘十月一号前必须实现啊，不然业务就没法做了’；‘我们要实现这个可回溯系统’；‘研究一下，看看能不能做，不行就买别人的’，噼里啪啦各种消息就塞到我的脑中。
‘需求还没提出来，盲猜是要做类似埋点收集？’，这时候我已经开始风暴可行的方案了，心里直犯嘀咕的时候收到了某保险公司的方案，看了看很眼熟，原来就是之前研究埋点时候见过的rrweb，于是很有底气的汇报了一句‘我试试’。
要做什么？
回归正题，我们要做什么？
先理解需求，我们需要记录用户在网页中的操作，以便后期回溯查看。后期查看具体要是什么形式？如果没有要求那不是行为埋点就可以满足？明确回复：以视频形式回放。
仔细思考，最终要以视频形式回放，那么我们就需要捕捉用户的每一次操作，页面的每一次变化，保存下来最终一帧一帧的播放，这样就能实现类似播放视频的效果。
怎么做？
清楚了要做什么，那么怎么做呢？
恐怕大家最直接的想法就是用canvas绘制每帧页面保存下来吧，但仔细想想会发现其中的问题：
由于人眼的特殊生理结构，当所见到的画面帧率高于每秒约 10-12 帧的时候，就会认为是连贯性的视频或动画效果，此现象被称之为视觉暂留。
一般的动画为每秒24帧，换算一下我们大约40ms就需要绘制一次页面，然后把绘制出的图片需要发送到服务端，要知道这是在用户侧进行的操作，会不会引发性能问题？
就算用户设备足够强大，网络足够通畅，接下来面临的就是服务端的存储问题。假设用户完成一次投保操作需要十分钟，则需要次绘制，服务器就要保存15000张图片，而图片的大小与页面内容量有关，这一笔的交易回溯算下来怎么都是一笔不小的开销了
还能想到什么方法呢？
既然保存图片有性能问题，那我们能不能保存html和css,回放的时候还原是不是就可以了，毕竟回放时候只需要看到页面结构样式，而不需要有交互。
没错，这样实现也是可以的，但这时候又引发了我的思考。如果用户一直停留在一个页面仅仅只是进行简单的点击切换选项操作，每40ms保存一次，每次都保存完整的页面html和css，这种情况下岂不是有大量相同代码被保存？如果正好是比较复杂的页面，那这个体积也不会小。
那我们能不能在每个页面加载完保存一次全量的代码，每次操作引发内容变化的时候保存增量变化的部分，这样不就可以减少重复代码达到减小体积的目的了吗？
确实这是一个比较合理的解决方案，rrweb最基础的设计思路也是如此。
讲到现在貌似都是些比较虚的内容哦，篇幅倒占了不少
来点干的
rrweb就是利用了浏览器的MutationObserver，该接口提供了监视对DOM树所做更改的能力，初始化的时候依照document.readyState状态先全量记录, 然后根据这个接口记录下DOM的变化过程。
有兴趣的同学可以去了解一下哦，相信会有一些奇思妙想。
相关材料：
篇幅原因就先写到这里（摸鱼摸累了，下回摸鱼继续更）
写在最后
这是我的第二篇文章，好像都在划水，但也花时间思考过写了出来不是么。
感谢大帅老猿领进门，让我开始有想法在这划水～
关于我（资深划水，顶级潜水员，不定期更新，写啥随意）
谢谢大家！
