1. 引言
    1.1. 编写目标
    HTML5 作为以后“最火”的跨平台、跨终端(硬件)开发语言，越来越受到前端开发者 的器重，无论是 PC 端还是以后“炽热”的挪动端，其前端开发人员的占比均越来越高。此 消彼长，HTML5 开发者的减少天然导致 WPF / Flex / QT 等前端技术开发人员的缩减。为了 解决前端“跨平台”的问题，并应答开发人员稀缺的困境，咱们迫切的须要抉择或更换新的 技术路线，而 HTML5 当为首选。本次测试目标是为了验证应用 HTML5 作为前端技术路线，能 否满足大屏(高分辨率，超过 8K)可视化的展现需要。
    1.2. 测试背景
    因为 WPF 技术越来越边缘化，开发人员越来越少，老本越来越高，为了当前产品的降级 换代，咱们迫切需要寻找支流前端技术的替代品。目前来看HTML5技术可能是将来前端技术 的支流，其对于挪动端、桌面端、还有三维方面都具备良好的兼容性。
    1.3. 测试指标
     测试各大支流浏览器，当图形工作站的输入分辨率超过8K时是否失常的显示WEB页面， 并晦涩的显示动画成果。
     测试各大支流浏览器对脚本语言(JAVASCRIPT)的解析性能。
     测试各大支流浏览器对HTML5个性的反对水平。
     综合思考上述因素抉择最佳浏览器进行测试，得出结论:是否满足大屏展现需要。
    1.4. 专业术语

  1. 测试环境
    为了保障测试后果的有效性，联合现有的硬件资源，选取三台机器作为本次测试的硬件
    环境，别离蕴含一台笔记本、一台台式机、一台图形工作站。
    2.1. 笔记本配置
    类型 规格
    内存 16GB
    显卡 NVIDIA GTX1050 4GB
    CPU INTEL I7-7700HQ 2.8GHZ 4 外围
    分辨率 1920 x 1080(2K)
    操作系统 Windows 10 专业版

2.2. 台式机配置
类型 规格
内存 32GB
显卡 AMD WX5100 8GB
CPU INTEL I7-7700 3.6GHZ 4 外围
分辨率3840 x 2160(4K)
操作系统 Windows 10 专业版

2.3. 图形工作站配置

类型 规格
内存 64GB
显卡 AMD FirePro W9000 6GB
CPU E5-2643 V4 3.4GHZ 6 外围
分辨率 7680 x 3240(8K)
操作系统 Windows 8.1 专业版

  1. 浏览器选型
    抉择浏览器最次要的是抉择浏览器内核，通常所说的浏览器内核是指渲染引擎 (Rendering Engine)，除此之外，浏览器内核还蕴含一个十分重要的局部——脚本(JS) 解析引擎，二者独特决定了网页加载和显示的性能。
    目前支流的浏览器内核有四种，别离是:Trident、Webkit、Gecko、Presto。其代表浏 览器别离为:Microsoft Edge / IE(微软浏览器)、Safari(苹果浏览器) / Chrome(谷 歌浏览器)、Firefox(火狐浏览器)、Opera(欧朋浏览器)。国产浏览器均是基于上述浏 览器内核开发，本次浏览器选型中不思考国产浏览器。另外，因 Windows10 操作系统并未普 及，本次测试不蕴含 Microsoft Edge 浏览器。
    阐明:本次测试应用的浏览器均为以后最新版本。
    3.1. 业余网站测试3.1.1. Html5 兼容性测试
    以下是 Html5 权威测试网站对各大支流浏览器的测试后果，评分的分值代表了浏览器 对 Html5 个性的反对水平，分值越高兼容性越好，网站地址:http://html5test.com。
    依据该权威网站的测试后果:Chrome57 对 Html5 个性的兼容性最好;其后顺次是 Opera，Firefox，Edge，Ssfari。IE11 作为最初的 IE 版本，对 Html5 的兼容性只有 312 分，大量的Html5 新个性在 IE11 中并不反对。思考到尽可能的晋升大屏展现零碎的性能和视觉效果，
    浏览器对 Html5 个性反对的越多对开发帮忙越大，越能节俭工时。
    依据该权威网站对各大支流浏览器的评分记录，随着工夫的推移，各大浏览器对 Html5个性的反对越来越欠缺，因而咱们能够正当的预期:Html5 在将来几年可能会成为所有浏览 器的反对规范，所有的 Html5 标准均会失去各大浏览器的反对。
    依据该网站对各大浏览器对 Html5 的兼容性统计(评分)，咱们能够得出结论:
     Chrome57:对Html5的兼容性最好。
     Opera45:对Html5的兼容性其次。
     FireFox53:对Html5的兼容性第三。
     Edge15:对Html5的兼容性第四。
     Safari10.1:对Html5的兼容性第五。
     IE11:对Html5的兼容性最差。
    论断:从 Html5 的兼容性角度思考，首选 Chrome 浏览器，其次是 Opera 浏览器。
    3.1.2. Canvas 绘图性能测试测试发现在禁用硬件加速的状况下，Chrome、Opera、Firefox、Safari、IE 均无奈绘
    制 7680 x 3240 分辨率的页面，浏览器体现出页面显示不全的景象，纯软件绘制时 CPU 利用率十分高，达到 80%以上。依据现场的图形工作站配置，显卡都具备硬件加速性能，所以本 次测试均在启用硬件加速的条件下进行。
    论断:未启用硬件加速时，所有浏览器均无奈应用 Canvas 绘制 7680 x 3240 分辨率的页面， 应用软件绘制时 CPU 利用率高达 80%以上。

为了测试浏览器的绘图性能，应用微软开发的性能测试网页进行测试，该网页能保障全 屏刷新，并能实时统计网页渲染的 FPS，比照各大浏览器在雷同 FPS 的条件下能反对的对象 数量，渲染的对象越多，浏览器的绘图性能越好。网站地址:https://testdrive-archive.azu...
保障刷新频率为 60FPS，测试后果如下:
 Firefox:3300–3500个对象，CPU利用率8%-9%，内存150MB。
 Chrome:2300-2500个对象，CPU利用率10%-12%，内存150MB。
 Opera:2000–2100，CPU利用率10%-11%，内存200MB。
 Safari:在Windows零碎下无奈失常的渲染页面，体现出卡顿，页面显示不全的景象。
 IE11:650-700个对象，CPU利用率3%-3.5%，内存160MB。
论断:从绘图性能角度思考，首选 Firefox 浏览器，其次是 Chrome 浏览器。
3.1.3. JA V ASCRIPT 脚本解析性能测试
浏览器对脚本(JAVASCRIPT)的解析与分辨率无关，为防止分辨率对解析后果产生影 响，理论测试过程中，浏览器分辨率均被设置为:7680 x 3240。测试原理是执行多个简单的 算法，每个算法代码行数不同，测试网站地址:http://chrome.360.cn/test/v8/... 试后果截图，理论测试过程中，重复测试屡次，并屡次重启浏览器测试，在同一台机器上测 试后果相差不大，最终分值越高，脚本解析性能越好。
 Firefox浏览器:测试过程中CPU继续在8%-10%。


 Chrome浏览器:测试过程中CPU继续在8%-10%。

 Opera浏览器:测试过程中CPU继续在8%-10%。

 IE浏览器:测试过程中CPU继续在9%-11%。

 Safari:测试过程中CPU继续在8%-10%。

论断:从脚本解析性能角度思考，首选 Firefox 浏览器，其次是 Chrome 浏览器。
3.2. 浏览器选型论断
综合思考浏览器在各方面的性能，Firefox 在绘图渲染和脚本解析方面性能最高，联合 对 Html5 的兼容性思考，本次测试过程抉择 Firefox 和 Chrome 两种浏览器进行测试。本文 前面的测试后果均示意在 Firefox 和 Chrome 的最新版本下的测试后果。

  1. CHART 选型
    本次测试选取以后最风行的三种 CHART 进行比照，它们别离是 Anychart，Highcharts，
    Echarts。
    4.1.CHART 性能和易用性比照

4.2.CHART 性能比照
因无奈准确计算出图表控件渲染图形所耗费的工夫，只能应用计时器或者秒表大抵估算出渲染工夫，为保障测试的严谨性，测试后果对立应用“估算工夫”进行比拟。
4.2.1 8K 分辨率下的 CHART 绘图性能

上图是在雷同分辨率下，三种图表绘制不同数据量时的估算工夫比照，横轴示意数据量， 纵轴示意渲染的估算工夫(单位:毫秒)。从图中能够看出，当数据量越多时，echart 的 性能最好，Anychart 在 1 万条数据时无奈显示，hightchart 在 1w 条数据时用时 25 秒显示 进去。尽管理论应用时呈现万级数据量的状况较为少见，但咱们也不得不思考。
论断:在 8K 分辨率下，当数据量低于 1 万时，Highchart 绘图性能最好，Anychart 绘图性 能最差;当数据量高于 1 万时，EChart 绘图性能最好。

上图是在雷同分辨率下，三种图表绘制不同的图形个数的估算工夫比照，横轴示意图形 个数，纵轴示意渲染工夫(单位:毫秒)。从图中能够看出，图形个数对渲染工夫有肯定的 影响，当页面中应用 10 个以上的图形时，Highchart 性能最好，EChart 其次。
论断:在 8K 分辨率下，当图形数量大于 10 个时，Highchart 绘图性能最好，Anychart 绘图 性能最差。
4.2.2 4K 分辨率下的 CHART 绘图性能

上图是在 4K 分辨率下，三种图表绘制不同数据量的估算工夫比照，横轴示意数据量， 纵轴示意渲染工夫。
论断:在 4K 分辨率下，当数据量低于 1 万时，Highchart 绘图性能最好，EChart 其次;当数据量超过 1 万时，Highchart 和 Anychart 无奈显示。

上图是在 4K 分辨率下，三种图表绘制不同的图形个数的估算工夫比照，横轴示意图形 个数，纵轴示意渲染工夫。
论断:在 4K 分辨率下，当图形个数超过 10 个时，EChart 绘图性能最好;Highchart 其次; Anychart 性能最差。
4.3.CHART 选型论断
依据 8K、4K 两种分辨率下的图表性能比照，综合其余因素(易用性，是否免费等)考
虑，抉择 EChart 作为本次图表测试控件。本次测试应用 EChart 的最新版本 3.7.2。

  1. EChart 数据量测试
    5.1. 8K 分辨率下的数据量测试
    本测试在图形工作站上进行，配置信息如下:
     总分辨率:7680 x 3240
     拼接屏:3x4，共12块屏
     单屏分辨率:1920 x 1080
     EChart 图表大小:1920 x 1080
    5.1.1. 单屏刷新测试
    以下为 8K 分辨率下，刷新单屏(1920 x 1080)EChart 图表数据的测试工夫，工夫单
    位:毫秒。

    以上测试工夫为程序主动计算失去，取屡次测试后果的平均值作为最终记录后果。理论 单屏刷新工夫应加上浏览器的渲染工夫，渲染工夫随点数的减少而减少，当单个 EChart 图 表的点数大于 5000 点时，渲染工夫在 1 秒左右，因而上述工夫加上浏览器的理论渲染工夫 才为最终的单屏刷新工夫。
    屡次测试后发现，当EChart单个图表的数据大于1万时，整个页面的加载速度十分慢， 因而当单个图表的曲线数量大于 6 条，且单条曲线的点数大于 2000 时，未计算单屏的刷新 工夫。
    论断:
     在8K的分辨率下，单屏(1920x1080)的刷新工夫随EChart点数的减少而减少，呈 正相干趋势。
     当单个EChart图表的点数大于10000时，单屏页面的刷新工夫大于1.5秒。 在雷同的点数下，EChart应用的曲线越多，性能越高，单屏刷新工夫越短。
    5.1.2. 全屏刷新测试
    以下为 8K 分辨率下，刷新全屏(7680 x 3240)所有 EChart 图表的测试工夫，工夫单 位:秒。

    以上测试工夫为程序主动计算失去，理论全屏刷新工夫应加上浏览器的渲染工夫，渲染 工夫随 EChart 点数的减少而减少，当单个 EChart 图表的点数大于 5000 点时，渲染工夫在 1秒左右，因而上述工夫加上浏览器的理论渲染工夫才为最终的全屏刷新工夫。
    屡次测试后发现，当EChart单个图表的数据大于1万时，整个页面的加载速度十分慢， 因而当单个图表的曲线数量大于 6 条，且单条曲线的点数大于 2000 时，未计算单屏的刷新 工夫。
    论断:
     在8K分辨率下，全屏(7680x3240)的刷新工夫随EChart点数的减少而减少，呈正 相干趋势。
     当EChart单个图表的的点数大于5000点时，全屏页面的刷新工夫大于5秒。 在雷同的点数下，EChart应用的曲线越多，性能越高，全屏刷新的工夫越短。
  2. 动效测试
    6.1.8K 分辨率下的动画测试
    当单个 EChart 图表(1920 x 1080)的点数大于 2000 点时，在 8K 的分辨率下刷新单屏 无奈显示动画成果。
    当单个 EChart 图表(1920 x 1080)的点数大于 500 点时，在 8K 的分辨率下刷新全屏， 无奈显示动画成果。
  3. 测试论断汇总
    本次测试过程中所应用的程序框架均为以后最新版本，版本清单如下:
     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点时，无奈显示动画成果。
  4. 危险评估
    本次测试过程中未测试图片资源，网络申请等对WEB页面的性能影响，当WEB页面中使 用大量的图片时，是否会对页面刷新或图表的重绘造成性能影响，不得而知。
    以后的硬件配置反对浏览器显示 8K 的页面较为勉强，页面的开发者须要对 WEB 页面的 性能点十分理解，否则对 WEB 页面的性能优化将会消耗大量的开发工夫。
    当整屏画面的数据量大于 10 万点时，页面加载或刷新过程可能十分慢(大于 10 秒)， 对性能要求较高的我的项目须要慎重考虑。
    可能遇到无奈冲破的性能瓶颈，尤其在动画特效方面。
  5. 参考资料
    1、 SVG与Canvas如何抉择:https://msdn.microsoft.com/zh...

2、如何为您的网站在 Canvas 和 SVG 之间做出抉择:https://msdn.microsoft.com/zh...

3、介绍 Chrome 的硬件加速机制:
http://www.chromium.org/devel...
-in-chrome。
4、从 GPU 诞生说起:AMD 对立渲染架构回顾及瞻望:
http://news.mydrivers.com/1/1...
5、显卡帝详解显卡全参数:
http://vga.zol.com.cn/227/227...