1.编写目的

HTML5作为当前“最火”的跨平台、跨终端（硬件）开发语言，越来越受到前端开发者的重视，无论是PC端还是当前“火热”的移动端，其前端开发人员的占比均越来越高。此消彼长，HTML5开发者的增加自然导致WPF / Flex / QT等前端技术开发人员的缩减。为了解决前端“跨平台”的问题，并应对开发人员稀缺的窘境，我们迫切的需要选择或更换新的技术路线，而HTML5当为首选。本次测试目的是为了验证使用HTML5作为前端技术路线，能否满足大屏（高分辨率，超过8K）可视化的展示需求。 

2.测试背景

由于WPF技术越来越边缘化，开发人员越来越少，成本越来越高，为了以后产品的升级换代，我们迫切需要寻找主流前端技术的替代品。目前来看HTML5技术可能是未来前端技术的主流，其对于移动端、桌面端、还有三维方面都具有良好的兼容性。

3.测试目标

• 测试各大主流浏览器，当图形工作站的输出分辨率超过8K时能否正常的显示WEB页面，并流畅的显示动画效果。
• 测试各大主流浏览器对脚本语言（JAVASCRIPT）的解析性能。
• 测试各大主流浏览器对HTML5特性的支持程度。
• 综合考虑上述因素选择最佳浏览器进行测试，得出结论：能否满足大屏展示需求。

4.专业术语

5.测试环境

为了保证测试结果的有效性，结合公司的硬件资源，选取三台机器作为本次测试的硬件环境，分别包含一台笔记本、一台台式机、一台图形工作站。

5.1.笔记本配置

5.2.台式机配置

5.3.图形工作站配置

6.浏览器选型

选择浏览器最主要的是选择浏览器内核，通常所说的浏览器内核是指渲染引擎（Rendering Engine），除此之外，浏览器内核还包含一个非常重要的部分——脚本（JS）解析引擎，二者共同决定了网页加载和显示的性能。

目前主流的浏览器内核有四种，分别是：Trident、Webkit、Gecko、Presto。其代表浏览器分别为：Microsoft Edge / IE（微软浏览器）、Safari（苹果浏览器） / Chrome（谷歌浏览器）、Firefox（火狐浏览器）、Opera（欧朋浏览器）。国产浏览器均是基于上述浏览器内核开发，本次浏览器选型中不考虑国产浏览器。另外，因Windows10操作系统并未普及，本次测试不包含Microsoft Edge浏览器。

说明：本次测试使用的浏览器均为当前最新版本。

6.1专业网站测试

6.1.1 HTML5兼容性测试

以下是Html5权威测试网站对各大主流浏览器的测试结果，评分的分值代表了浏览器对Html5特性的支持程度，分值越高兼容性越好，网站地址：HTML5test - How well does your browser support HTML5?。

​

根据该权威网站的测试结果：Chrome57对Html5特性的兼容性最好；其后依次是Opera，Firefox，Edge，Ssfari。IE11作为最后的IE版本，对Html5的兼容性只有312分，大量的Html5新特性在IE11中并不支持。考虑到尽可能的提升大屏展示系统的性能和视觉效果，浏览器对Html5特性支持的越多对开发帮助越大，越能节省工时。

​

根据该权威网站对各大主流浏览器的评分记录，随着时间的推移，各大浏览器对Html5特性的支持越来越完善，因此我们可以合理的预期：Html5在未来几年可能会成为所有浏览器的支持标准，所有的Html5规范均会得到各大浏览器的支持。

根据该网站对各大浏览器对Html5的兼容性统计（评分），我们可以得出结论：

• Chrome 57：对Html5的兼容性最好。
• Opera 45：对Html5的兼容性其次。
• FireFox 53：对Html5的兼容性第三。
• Edge 15：对Html5的兼容性第四。
• Safari 10.1：对Html5的兼容性第五。
• IE11：对Html5的兼容性最差。

结论：从Html5的兼容性角度考虑，首选Chrome浏览器，其次是Opera浏览器。

6.1.2 Canvas绘图性能测试

测试发现在禁用硬件加速的情况下，Chrome、Opera、Firefox、Safari、IE均无法绘制7680 x 3240分辨率的页面，浏览器表现出页面显示不全的现象，纯软件绘制时CPU利用率非常高，达到80%以上。根据现场的图形工作站配置，显卡都具备硬件加速功能，所以本次测试均在启用硬件加速的条件下进行。

结论：未启用硬件加速时，所有浏览器均无法使用Canvas绘制7680 x 3240分辨率的页面，使用软件绘制时CPU利用率高达80%以上。

为了测试浏览器的绘图性能，使用微软开发的性能测试网页进行测试，该网页能保证全屏刷新，并能实时统计网页渲染的FPS，对比各大浏览器在相同FPS的条件下能支持的对象数量，渲染的对象越多，浏览器的绘图性能越好。

网站地址：HTML5 Fish Bowl。

保证刷新频率为60FPS，测试结果如下：

• Firefox：3300 – 3500个对象，CPU利用率8% - 9%，内存150MB。
• Chrome：2300 - 2500个对象，CPU利用率10% - 12%，内存150MB。
• Opera：2000 – 2100，CPU利用率10% - 11%，内存200MB。
• Safari：在Windows系统下无法正常的渲染页面，表现出卡顿，页面显示不全的现象。
• IE 11:650 - 700个对象，CPU利用率3% - 3.5%，内存160MB。

结论：从绘图性能角度考虑，首选Firefox浏览器，其次是Chrome浏览器。

6.1.3JAVASCRIPT脚本解析性能测试

浏览器对脚本（JAVASCRIPT）的解析与分辨率无关，为避免分辨率对解析结果产生影响，实际测试过程中，浏览器分辨率均被设置为：7680 x 3240。测试原理是执行多个复杂的算法，每个算法代码行数不同，测试网站地址：V8基准套件测试。

以下测试结果截图，实际测试过程中，反复测试多次，并多次重启浏览器测试，在同一台机器上测试结果相差不大，最终分值越高，脚本解析性能越好。

• Firefox浏览器：测试过程中CPU持续在8% - 10%

​

• Chrome浏览器：测试过程中CPU持续在8% - 10%

​

• Opera浏览器：测试过程中CPU持续在8% - 10%

​

• IE浏览器：测试过程中CPU持续在9% - 11%

​

• Safari：测试过程中CPU持续在8% - 10%

​

结论：从脚本解析性能角度考虑，首选Firefox浏览器，其次是Chrome浏览器

6.1浏览器选型结论

综合考虑浏览器在各方面的性能，Firefox在绘图渲染和脚本解析方面性能最高，结合对Html5的兼容性考虑，本次测试过程选择Firefox和Chrome两种浏览器进行测试。本文后面的测试结果均表示在Firefox和Chrome的最新版本下的测试结果。

7.CHART选型

本次测试选取当前最流行的三种CHART进行对比，它们分别是Anychart，Highcharts，Echarts

7.1 CHART功能和易用性对比

7.2 CHART性能对比

因无法精确计算出图表控件渲染图形所消耗的时间，只能使用计时器或者秒表大致估算出渲染时间，为保证测试的严谨性，测试结果统一使用“估算时间”进行比较。

7.2.1 8K分辨率下的CHART绘图性能

​

上图是在相同分辨率下，三种图表绘制不同数据量时的估算时间对比，横轴表示数据量，纵轴表示渲染的估算时间（单位：毫秒）。从图中可以看出，当数据量越多时，echart的性能最好，Anychart在1万条数据时无法显示，hightchart在1w条数据时用时25秒显示出来。虽然实际使用时出现万级数据量的情况较为少见，但我们也不得不考虑。

结论：在8K分辨率下，当数据量低于1万时，Highchart绘图性能最好，Anychart绘图性能最差；当数据量高于1万时，EChart绘图性能最好。

​

上图是在相同分辨率下，三种图表绘制不同的图形个数的估算时间对比，横轴表示图形个数，纵轴表示渲染时间（单位：毫秒）。从图中可以看出，图形个数对渲染时间有一定的影响，当页面中使用10个以上的图形时，Highchart性能最好，EChart其次。

结论：在8K分辨率下，当图形数量大于10个时，Highchart绘图性能最好，Anychart绘图性能最差。

7.2.2 4K分辨率下的CHART绘图性能

图是在4K分辨率下，三种图表绘制不同数据量的估算时间对比，横轴表示数据量，纵轴表示渲染时间。

结论：在4K分辨率下，当数据量低于1万时，Highchart绘图性能最好，EChart其次；当数据量超过1万时，Highchart和Anychart无法显示。

​

上图是在4K分辨率下，三种图表绘制不同的图形个数的估算时间对比，横轴表示图形个数，纵轴表示渲染时间。

结论：在4K分辨率下，当图形个数超过10个时，EChart绘图性能最好；Highchart其次；Anychart性能最差。

7.2 CHART选型结论

根据8K、4K两种分辨率下的图表性能对比，综合其他因素（易用性，是否收费等）考虑，选择EChart作为本次图表测试控件。本次测试使用EChart的最新版本3.7.2。

8.EChart数据量测试

8.1 8K分辨率下的数据量测试

本测试在图形工作站上进行，配置信息如下：

• 总分辨率：7680 x 3240
• 拼接屏：3 x 4，共12块屏
• 单屏分辨率：1920 x 1080
• EChart图表大小：1920 x 1080

8.1.1单屏刷新测试

以下为8K分辨率下，刷新单屏（1920 x 1080）EChart图表数据的测试时间，时间单位：毫秒。

以上测试时间为程序自动计算得到，取多次测试结果的平均值作为最终记录结果。实际单屏刷新时间应加上浏览器的渲染时间，渲染时间随点数的增加而增加，当单个EChart图表的点数大于5000点时，渲染时间在1秒左右，因此上述时间加上浏览器的实际渲染时间才为最终的单屏刷新时间。

多次测试后发现，当EChart单个图表的数据大于1万时，整个页面的加载速度非常慢，因此当单个图表的曲线数量大于6条，且单条曲线的点数大于2000时，未计算单屏的刷新时间。

结论：

• 在8K的分辨率下，单屏（1920 x 1080）的刷新时间随EChart点数的增加而增加，呈正相关趋势。
• 当单个EChart图表的点数大于10000时，单屏页面的刷新时间大于1.5秒。
• 在相同的点数下，EChart使用的曲线越多，性能越高，单屏刷新时间越短。

8.1.2 全屏刷新测试

以下为8K分辨率下，刷新全屏（7680 x 3240）所有EChart图表的测试时间，时间单位：秒。

以上测试时间为程序自动计算得到，实际全屏刷新时间应加上浏览器的渲染时间，渲染时间随EChart点数的增加而增加，当单个EChart图表的点数大于5000点时，渲染时间在1秒左右，因此上述时间加上浏览器的实际渲染时间才为最终的全屏刷新时间。

多次测试后发现，当EChart单个图表的数据大于1万时，整个页面的加载速度非常慢，因此当单个图表的曲线数量大于6条，且单条曲线的点数大于2000时，未计算单屏的刷新时间。

结论：

• 在8K分辨率下，全屏（7680 x 3240）的刷新时间随EChart点数的增加而增加，呈正相关趋势。
• 当EChart单个图表的的点数大于5000点时，全屏页面的刷新时间大于5秒。
• 在相同的点数下，EChart使用的曲线越多，性能越高，全屏刷新的时间越短。

8.1.3 动效测试

8K分辨率下的动画测试

当单个EChart图表（1920 x 1080）的点数大于2000点时，在8K的分辨率下刷新单屏无法显示动画效果。

当单个EChart图表（1920 x 1080）的点数大于500点时，在8K的分辨率下刷新全屏，无法显示动画效果。

9.测试结论汇总

本次测试过程中所使用的程序框架均为当前最新版本，版本清单如下：

• jquery：3.2.1
• echart：3.7.2
• firefox：56.0.1
• chrome：62.0.3202.62
• 48.0

本次测试得到如下结论：

• 在当前的硬件性能下，使用Html5开发的WEB页面能在8K的分辨率下正常显示。
• 使用Html5作为WEB页面的开发语言时，所使用的浏览器必须支持硬件加速，图形工作站必须配备支持加速的显卡。
• 使用EChart作为WEB页面的主要图表控件时，单个图表控件的数据量最好不超过5000点，当单个图表的点数超过2000点时，应禁用动画效果。
• WEB页面应采用局部刷新的方式进行数据更新，避免全屏刷新。
• 当页面元素较多时，应避免执行全屏动画。
• 动画效果所影响的区域面积越小，动画效果越流畅。
• 当单个EChart图表的点数超过2000点时，无法显示动画效果。

10.风险评估

本次测试过程中未测试图片资源，网络请求等对WEB页面的性能影响，当WEB页面中使用大量的图片时，是否会对页面刷新或图表的重绘造成性能影响，不得而知。

当前的硬件配置支持浏览器显示8K的页面较为勉强，页面的开发者需要对WEB页面的性能点非常了解，否则对WEB页面的性能优化将会耗费大量的开发时间。

当整屏画面的数据量大于10万点时，页面加载或刷新过程可能非常慢（大于10秒），对性能要求较高的项目需要慎重考虑。

可能遇到无法突破的性能瓶颈，尤其在动画特效方面。

11.参考资料

1、 SVG与Canvas如何选择：SVG vs canvas: how to choose (Windows) | Microsoft Docs

​

2、如何为您的网站在Canvas和SVG之间做出选择：如何为您的网站在 Canvas 和 SVG 之间做出选择 | Microsoft Docs。

​

3、介绍Chrome的硬件加速机制：http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome。

4、从GPU诞生说起：AMD统一渲染架构回顾及展望：从GPU诞生说起：AMD统一渲染架构回顾及展望-AMD,ATI,统一渲染,显卡,架构,回顾,展望-驱动之家

5、显卡帝详解显卡全参数：http://vga.zol.com.cn/227/2278852_all.html#p2279101

​