背景
随着可视化需求的增多，以及可视化行业商业化的发展。从前小作坊式的纯手工生产不能再满足大量的业务需求，这时一些业界优秀的企业纷纷开始了对可视化页面的工业化生产。本文粗略的介绍一些可视化前端的工业化体系。
基础设施建设阶段
所有工业体系均是由制作工具开始。反应到可视化上以大屏为例，这里的基础工具、基础设施可能包括：用于大屏应用分辨率自适应容器，基础图表库，适应性主题，基础UI组件，数据流管理器，事件响应机制等。
其中以基础图表最为基础，一些图表的有机结合构成了一个大屏应用的核心元素。在图表库这个基础设施上有大量的第三方库，例如最常用的ECharts、d3等等。在基础设施建设初期的团队可能主要在第三方库的基础上做一些组件封装。例如成批量的封装一些折柱饼等。在经过一定量的封装了之后这些第三方图表库的一些问题都会相继暴露，例如d3代码量太多，ECharts不够灵活。同时这些第三方的图表库都会存在一些对业务的支撑力不足的问题。这时候一般团队一方面会对业务需求进行梳理，对视觉元素进行一些归纳，以行成一些通用风格雏形，例如“平面科技蓝”，“渐变立体动效”。另一方面也开始着手对第三方库进行一些针对性的改造，例如进行一些高层封装以减少代码量，进行一些接口预留以适配通用主题等。同时通用风格的雏形也会衍生出一些主题。到这里会渐渐的生成一些自己的“图表库”，可能叫a-charts，b-charts等等。经过几版迭代之后一个提高了业务支撑力，降低开发成本的vis-graph图表库的诞生标志着基础设置建设的初级阶段的完成。
在图表库这个基础设施上，大多数的团队都会针对已有的第三方库进行一些抽象、封装以行成自己的图表库。考虑到成本因素很少有团队会从底层渲染做起来构建自己的图表库，同时也有一些团队会对第三方库进行魔改，个人不建议这种方式，修改第三方库固然可以解决一些问题的同时可能会引入一些不可测的其他问题，而且魔改后的库很难跟随主库升级。
在适应性框架上常见的方案有，以scale为核心对页面进行整体的缩小、扩大。优点是足够灵活，缺点是容易失真，一些特定浏览器兼容性不是特别好，以720P,1080P,2k屏等标准屏进行适配动态生成每个图表的像素大小来传递给各个图表去适配屏幕。优点是不容易失真，缺点是对一些异型屏支持不够完善。由于技术难度和解决方案门槛较低，这里基本各个团段人手一套。
数据流管理器，一般会基于redux、vuex等一些现代框架的状态管理器针对大屏的特性做一些封装，已形成自己的数据流管理器。
在UI组件上antd,element-ui其实更通用化一些，在大屏上有些组件使用很少，而使用很多的title,panel,dialog,button,img等支持又不够丰富，大多数团队会选择自己造一套。
标准和规范的制定阶段
还是以图表为例，可以制定一些标准图表，规范一些可配置项。例如大多数图表都可以分为单色系和多色系，有隔线无隔线、有背景无背景。那么就可以形成规范去制定有哪些色系、哪些隔线、哪些背景。这些对应规范的组合，比如无背景无隔线的单色图表，有提示有标注的多色图表就可以形成标准。根据标准去制作一些标准图表，一方面使图表形成成套的独一无二的风格，另一方面也使图表默认好看更加通用。
很多团队在工业化进程中有意或无意的丢失了标准制定阶段。或者认为这个阶段不重要，不必投入太长时间。这其实是一种错误的认知，下文会花一点时间去啰嗦什么是标准和规范，为什么需要它以及如何如制定。
标准和规范本质上是一种经验，是从业务需求中归纳常规需求，从解决方案中提取通用方案。用通用的解决方案解决常规需求的一种经验。标准和规范的制定本质上是为了项目结果可预期，项目产出可衡量，使项目流程有迹可循。
我想一些团队肯定遇见过基础设施的某些部分使用率低，认可度不高。本质原因在于缺乏对业务需求的梳理，对解决方案的总结。在基础设施的建设上，一方面在一些重复功能或不必要的细节上投入过多的人力，一方面又在一些必要的功能上不够强壮。
标准和规范并不是一成不变的。
业务需求是标准的直接推动方，举个简单的例子比如某团队大多数的大屏布局需求都是核心布局即中央是主视图、上方是标题，旁边是四个或六个辅助视图。有少量的隐藏式布局即整屏都是地图或主视图，屏幕四周有一些边缘吸附的隐藏式辅助视图，以及极少数的非对称式布局。这时候就可以归纳一种规范，那种业务场景、哪类客户更喜欢哪类布局。以便以后套用。当然随着核心布局的大量使用，审美疲劳加重，新的布局诉求必然会出现，这时候就需要适当的对标准和规范做更新以适应新场景新业务。
标准和规范约束基础设施的发展，并不是完全限制基础设施的发展，要肯定基础设施上做出的合理创新，在对应的业务场景上小范围的推广获得良好反馈后要及时纳入标准体系。
平台搭建阶段
经过基础设施建设阶段和标准和规范的制定阶段已经积累了大量可用的基础组件，这时候其实已经极大的提高了生产力，一些已积累的组件的排列组合可以完全组成非常多的应用，也足以应付绝大多数需求。不过存在的问题是仍需要手工产出代码，并没有完全脱离手工作坊模式。好在低代码,无代码,平台化的概念还算广为人知，无论前边的两个步骤是否已经完工，是否已经完全具备搭建平台的条件。绝大对多数团队都会在团队内部或者外部主推自家的平台。这里简单介绍一些基础设施衍生出来的平台以供参考。以及平台的常见的两种应用模式。
组件开发平台负责组件的所见即所得的快速开发，用于备份未纳入标准体系的组件库，作为团队的总案例库。用于开发者查看图表、分享图表，学习图表、开发图表。
图表作为一个大屏的核心内容，即便已经有了标准和规范也不见得能完全满足需求。这时候一个可以基于web开发，所见即所得的组件开发平台就有了应用场景。其实已经有类似的产品和平台了，类似codepen，sandboxie，stackblitz。之类他们可能原生集成了一些框架，angular，react，vue 等。组件开发平台在框架支持上不需要太多，支持团队内部技术栈并原生集成一些常规图表库以方便二次开发即可。平台搭建完毕之后用户，也就是开发者就可以直接基于web所见即所得开发一些简单的demo，图表。由于本身基于web，所以二次开发也好，分享嵌入也好相对来说都容易实现，而且也可以作为一个内部的案例库。用于备份一些尚未纳入规范的且常用的图表。
GUI界面的样式编辑主题导出平台用于设计师所见即所得的配置主题、导出主题。
UI库也好、图表库也好，样式、主题永远是核心，性能可能有优化的上限，但样式没有。而这一部分工作普遍由设计师来完成，设计师本身一般不负责编码，也不擅长编码。面对频繁更新变动的样式，每次都有设计师提出，交给开发来实现是十分低效的。这时候一个GUI界面的样式编辑主题导出平台就十分有必要了。如果基础设施建设阶段,和标准和规范的制定阶段完成度较高，该平台就相对容易实现，如果标准制定的相对规范已经给出了哪些常修改项，那些样式基本不动，标准组件库也都根据标准预留了接口。 GUI界面的样式编辑主题导出平台本身的搭建其实并不复杂，只需要将可配置项GUI化即可然后就可以交给设计师去将配置项做排列组合了。如果前边两个步骤完成度不高，这里就会相对比较痛苦。
大屏可视化构建平台用于快速拖拽图表、配置数据、配置样式。生成大屏应用程序，导出部署包。
这个平台集成了基础组件库，作为大屏应用的核心内容。UI库提供了日常交互类组件、弹窗类组件、容器类组件、装饰类组件等。状态管理器用于管理从数据源接入的数据，提供数据转换，交互状态监控等功能。事件管理器用于提供各个组件之间的联动，这部分和状态管理器有些相似，区别是事件管理器更偏向于组件之间的事件派发，状态管理器更偏向于页面级的数据派发和状态修改。
数据管理平台用于保存一些常用的公开数据，示例数据。提供数据库、接口的接入常规接入形式。
大数据大数据核心是数据，做前端可视化由于距离数据层相对后端来说较远，有时候客观或者主观的很容易忽略对数据的收集和积累。长期来说其实是放弃了很多可能性。对于一些有权限的业务数据，或者一些甲方提供的小量脱敏的示例数据。做好数据存储和权限管理。会对以后的业务有所启发。
平台的应用方式一般有两种，一是仅自己团队、或公司内部使用，目的是提升生产力，以业务模式盈利。在承接大屏业务后，由平台来开发，导出部署包交付。极大的减少开发时间，也就意味着可以以更低的报价来拿到项目。二直接将平台放于公网，以服务形式盈利。按时间，按项目数量收费。
平台互通相互赋能
顾名思义平台互通就是打通各个各个平台，使各个平台的产物可以自由流通。其实严格意义上讲平台互通并不能单独成为一个阶段，在平台建设阶段，无论各个平台是先后建设还是同时开发，产物基本都是可以互通，而且在长期的开发过程当中自然而然的也会总结出各个平台之间应该如何打通的经验，这里举几个简单的例子不做过多介绍。
开发组件平台赋能大屏可视化构建平台，组件开发平台提供导出的组件功能，或基于云进行组件统一管理，大屏可视化构建平台直接可以接入开发组件平台这样就大大的增加了组件的数量，同时也为下一步市场化提供了基础开发套件。
数据管理平台提供公共接口各个平台可自由调用就可以做到实用化组件，即拉出来的组件就可以直接满足业务需求不再用任何的样式设置和数据配置操作。
样式开发平台导出的主题文件可按级别直接应用于标准组件，业务大屏。
市场化&智能化
在经过平台化之后易见的发展方向有两条。
一是市场化，如果业务准备开展面向中小企业或者干脆2C业务同时组件开发平台和大屏应用构建平台足够健壮。在技术上就具备了市场化的条件。开放组件开发平台增加审核机制，大屏应用构建平台组件库除了提供第一方的标准组件之外直接将组件市场接入，完成组件商业化，大屏商业化。这个方向的优势在于描绘了一个很大的市场，如果能够迅速占领，就不难吸引优秀的开发者开发图表。大量的优秀开发者设计师提供的个性化图表又会吸引更多的客户从而抢占更多的市场。如果能够进入良性循环就很容易行成实质上的半垄断或垄断，描绘的前景非常美好。缺点在于可视化业务本身基于成体系成系统的数据。这些数据小型公司或个人可能不具备可视化的条件，2C就更需要寻求场景的创新。甚至有时会有将平台推送到公网之后很少有客户会去学习使用，进行深度操作的可能都是业界同行的尴尬局面。
二是智能化，智能化又分图表智能化和大屏智能化，这方便阿里做的很好，图表智能化方面可以直接看AutoChart(AVA)解决了自增数据在不同数据量下的适应问题、提供常规的关联分析增强分析方案。大屏智能化可以见马良解决大屏可视化的辅助设计和开发问题。根据手绘稿可直接生成大屏应用。
有意思的是在市场化方向探索不错的也是阿里。
业务体系
仅以B/S端为例，业务体系可以按横向纵向划分。横向分为图表组件库，UI库，样式库，数据管理仓库，相对独立的智能体系，各个业务纵向可以以，标准库->标准和规范->平台方向来衍生。最终和平台级产品可能包含组件开发平台，样式编辑导出平台，大屏可视化构建平台，数据管理平台。
结语
本文浅显的描述了一些可视化前端工业体系，主要来源于自身经验以及对业界一些优秀团队和产品的分析归纳，并没有多少实质性的原创内容。截至本文撰写期间业界的优秀团队基本都已经完成了各大平台的搭建工作，开始了相关智能化、市场化探索。个人感觉大屏可视化领域已完成了从手工产出到工业化产出的转变，也就意味着蓝海时代已经结束，接下来竞争的将是如何规模化生产、做业务创新、降低人员成本、甚至如何开拓新的市场。在本文的撰写期间笔者也陆续经历、了解到了一些大数据公司的欠薪、降薪、裁员事件。这些公司并不是小公司在业界有广泛知名度和很靠前的排名。大潮褪去方知到底谁在裸泳。即便在业务上升期也一定不能盲目乐观，盲目追求新概念，脚踏实地做实事，构筑技术壁垒，扩展业务领域，在左右看对比同行的同时更要向前看，趁还有钱，趁业务良好勇敢的去探索一些新的技术、业务。最后，不创新真的会死。