网站首页 > 技术文章正文

前端实现最佳截图方案(上) 前端截取图片

btikc 2024-10-11 11:17:45 技术文章 2 ℃ 0 评论

作者：蜀中亮子

转发链接：https://mp.weixin.qq.com/s/ghXm-dySERTFsXEWw79afA

“旧闻重发，由于上一次的图片有些糊，这次分为上下两篇发送，不至于阅读压力太大”

开篇

平时很多时候，需要把当前页面或者页面某一部分内容保存为图片分享出去，也或者有其他的业务用途，这种在很多的营销场景和裂变的过程都会使用到，那我们要把一个页面的内容转化为图片的这个过程，就是比较需要探讨的了。

首先这种情况，想到的实现方案就是使用canvas来实现，我们探索一下基本实现步骤：

把需要分享或者记录的内容绘制到canvas上；
把绘制之后的canvas转换为图片；

这里需要明确的一点就是，只要把数据绘制到canvas上，这就在canvas画布上形成了被保存在内存中的像素点信息，所以可以直接调用canvas的api方法toDataURL、toBlob，把已经形成的像素信息转化为可以被访问的资源uri，同时保存在服务器当中。这就很轻松的解决了第二步（把canvas转为图片链接），下面是代码的实现：

在实现了第二步的情况之下，需要关注的就是第一步的内容，怎么把内容绘制到canvas上，我们知道canvas的绘图环境有一个方法是ctx.drawImage，可以绘制部分元素到canvas上，包含图片元素Image、svg元素、视频元素Video、canvas元素、ImageBitmap数据等，但是对于一般的其他div或者列表li元素它是不可以被绘制的。

所以，这不是直接调用绘图的api就可以办到的，我们就需要思考其他的方法。在一般的实现上，比较常见的就是使用html2canvas，那么我们先来聊聊html2canvas的使用和实现。

html2canvas的使用及实现html2canvas使用实现

使用

首先看一下html2cavas的使用方法：

调用html2canvas方法传入想要截取的dom，执行之后，返回一个Promise，接收到的canvas上，就绘制了我们想要截取的dom元素。到这一步之后，我们再调取canvas转图片的方法，就可以对其做其他的处理。

这里它的html2canvas方法还支持第二个选项传入一些用户的配置参数，比如是否启用缓存、整个绘图canvas的宽高值等。

在这个转换的过程，在html2canvas的内部，是怎么把dom元素绘制到canvas上的，这是咱们需要思考的问题！

实现

首先咱们先献上一个内部的大致流程图：

对比着内部的流程图，就可以理一下整体的思路，整体的思路就是遍历目标节点和子节点，收集样式，计算节点本身的层级关系和根据不同的优先级绘制到画布中，下面基于这个思路，咱们深入一下整个过程：

调用html2canvs函数，直接返回一个执行函数，这一步没有什么；
在执行函数的内部第一步是构建配置项defaultOptions，在合并默认配置的过程中，有一个缓存的配置，它会生成处理缓存的方法；

处理缓存类，对于一个页面中的多个不同的地方渲染调用多次的情况做优化，避免同一个资源被多次加载；
缓存类里面控制了所有图片的加载和处理，包括使用proxy代理和使用cors跨域资源共享这两种情况资源的处理，同时也对base64和blob这两种形式资源的处理。比如如果渲染dom里面包含一个图片的链接类型是blob，使用的方式就是如下处理，然后添加到缓存类中，下次使用就不需要再重新请求。

在上一步生成了默认配置的情况之下，传入需要绘制的目标节点element和配置到DocumentCloner里面，这个过程会克隆目标节点所在的文档节点document，同时把目标节点也克隆出来。这个过程中，只是克隆了开发者定义的对应节点样式，并不是结合浏览器渲染生成特定视图最后的样式。

如上这个.box的元素节点，定义的样式只有高度，但是在浏览器渲染之下，会对它设置默认的文字样式等等

基于上一步的情况，就需要把克隆出来的目标节点所在的文档节点document进行一次浏览器的渲染，然后在收集最终目标节点的样式。于此，把克隆出来的目标节点的document装载到一个iframe里面，进行一次渲染，然后就可以获取到经过浏览器视图真实呈现的节点样式。

在这个过程中，就可以通过`window.getComputedStyle`这个API拿到要克隆的目标节点上所有的样式了(包含自定义和浏览器默认的结合最终的样式)；

目标节点的样式和内容都获取到了之后，就需要把它所承载的数据信息转化为canvas可以使用的数据类型，比如某一个子节点的宽度设置为50%或者2rem，在这个过程中，就需要根据父级的宽度把它计算成为像素级别的单位。同时对于每一个节点而言需要绘制的包括了边框、背景、阴影、内容，而对于内容就包含图片、文字、视频等。这个过程就需要对目标节点的所有属性进行解析构造，分析成为可以理解的数据形式。

如上图片这种数据结构和我注释一样，在它内部把每一个节点处理成为了一个container，它的上面有一个styles字段，这个字段是所有节点上的样式经过转换计算之后的数据，还有一个textNodes属性，它表示当前节点下的文本节点，如上，每一个文本的点的内容使用text来表示，位置和大小信息放置在textBounds中。对于elements字段存放的就是当前节点下除了文本节点外，其他节点转换成为的container，最后一个就是bounds字段，存放的是当前节点的位置和大小信息。可以看一下container这个类的代码：

基于这种情况，每一个container数据结构的elements属性都是子节点，整个节点就够构造成一个container tree。

在通过解析器把目标节点处理成特定的数据结构container之后，就需要结合canvas调用渲染方法了，我们在浏览器里面创建多个元素的时候，不同的元素设置不同的样式，最后展示的结果就可能不一样，比如下面代码：

这个代码的展示结果如下：

此时，如果修改了代码中.sta1元素节点的opacity属性为0.999，此时整个布局的层级就会发生大变化，结果如下：

这个是什么原因？因为canvas绘图需要根据样式计算哪些元素应该绘制在上层，哪些在下层。元素在浏览器中渲染时，根据W3C的标准，所有的节点层级布局，需要遵循层叠上下文和层叠顺序的标准。当某一些属性发生变化，层叠上下文的顺序就可能发生变化，比如上列中透明度默认为1和不为1的情况（对于如何形成一个层叠上下文此处不做深入讲解，可以自行研究）。

更加直白的理解就是一部分属性会使一些元素形成一个单独的层级，不同属性的层级有一定的排列顺序。如下就是我们对应的顺序：

形成层叠上下文环境的元素的背景与边框（相当于整个文档的背景和边框）
拥有负 z-index 的子层叠上下文元素（负的越高越层叠上下文层级越低）
正常流式布局，非 inline-block，无 position 定位（static除外）的子元素
无 position 定位（static除外）的 float 浮动元素
正常流式布局， inline-block元素，无 position 定位（static除外）的子元素（包括 display:table 和 display:inline ）
拥有 z-index:0 或者auto的子堆叠上下文元素
拥有正 z-index: 的子堆叠上下文元素（正的越低层叠上下文层级越低）
在正常的元素情况下，没有形成层叠上下文的时候，显示顺序准守以上规则，在设置了一些属性，形成了层叠上下文之后，准守谁大谁上(z-index比较)、后来居上(后写的元素后渲染在上面)

此处，在清楚了元素的渲染需要遵循这个标准的情况之下，canvas绘制节点的时候，就需要先计算出整个目标节点里子节点渲染时所展现的不同层级。先给出来内部模拟层叠上下文的数据结构StackingContext：

以上就是某一个节点对应的层叠上下文在内部所表现出来的数据结构。很多属性都会形成层叠上下文，不同的属性形成的上下文，有不同的顺序，所以需要对目标节点的子节点解析，根据不同的样式属性分配到不同的数组中归类，比如遍历子节点的container上的styles，发现opacity为0.5，此时会形成层叠上下文，然后就把它构造成为上下文的数据结构StackContext。添加到zeroOrAutoZIndexOrTransformedOrOpacity这个数组中，这样一个递归查看子节点的过程，最后会形成一个层叠上下文的树。

基于上面构造出的数据结构，就开始调用内部的绘图方法了，一下代码是渲染某一个层叠上下文的代码：

如上绘图函数中，如果子元素形成了层叠上下文，就调用renderStack，这个方法内部继续调用了renderStackContent，这就形成了对于层叠上下文整个树的递归。

如果子元素没有形成层叠上下文，而是正常元素，就直接调用renderNode或者renderNodeContent。这两个的区别是renderNodeContent只负责渲染内容，不会渲染节点的边框和背景色。

对于renderNodeContent这个方法就是渲染一个元素节点里面的内容，可能是正常元素、图片、文字、svg、canvas、视频、input、iframe。对于图片、svg、视频、canvas这几种元素，直接通过调用前文提到的api，对于input需要根据样式计算出绘图数据来模拟完成，文字就直接根据提供的样式来绘制。重点需要提一下的是iframe，如果需要绘制的元素中包含了iframe，就相当于我们需要重新绘制一个新的文档document，处理方法是在内部调用html2canvas的api，绘制整个文档。

以下为多个不同类型的元素的绘制方式：

对于文字的绘制方式：

对于图片、SVG、canvas元素的绘制：

对于代码中调用renderReplacedElement方法内部的处理逻辑，就是调用canvas的drawImage方法绘制以上三种数据形式；

对于需要绘制的元素是iframe的时候，做的处理逻辑就如同重新调用整个绘制方法，重新渲染页面的过程：

对于单选或者多选框的处理情况，就是根据是否选中，来绘制对应状态的样式:

对于input输入框的情况，首先需要绘制边框，然后把内部的文字绘制到输入框中，超出部分需要剪切掉，所以需要使用到canvas的clip绘图API:

对于最后一种需要考虑的就是列表，对于li、ol这两种列表，都可以设置不同类型的list-style，所以需要区分绘制。

以上整个过程，就是html2canvas的整体内部流程，最后的操作都是不同的线条、图片、文字等等的绘制，概括起来就是遍历目标节点，收集样式信息，转化为绘制数据，并且根据一定的优先级策略递归绘制节点到canvas画布上。

实现

在捋顺了整个大流程的情况之下，咱们来看看html2canvas的一些缺点

不支持的一些场景

box-shadow属性，支持的不好，因为对于canvas的阴影API没有扩散半径。所以对于样式的阴影支持不是特别好；
边框虚线的情况也不支持，这一点源码里面没有使用setLineDash，是因为大多数浏览器原本不支持这个属性，chrome也是64版本之后才支持这个属性；
css中元素的zoom属性支持也不是也特别好，因为换算会出现问题;
计算问题是最大的问题！！！因为每一次计算都会有精确度的省略问题，比如父元素的宽度是100像素，子元素是父元素的30%，这个时候转化为canvas绘图单位像素的时候，就会有省略的过程，在有多次省略的情况之下，精确度就会变得不精确。并且还涉及到一些圆弧的情况，这种弧度的计算，最后模仿出来，都会有失去精确度的问题。对于正常的浏览器渲染节点，渲染的内部逻辑，直接是由浏览器处理，但是对于html2canvas的方案，需要先计算为像素单位，然后绘制到canvas上，最后canvas元素还要经过浏览器的一次处理，才能够渲染出来。这个过程不止是换算单位失去精度，渲染也会失去精度。

解决方案，详见下一篇