活动可视化搭建系统——你的KPI被我承包了

前言

对于C端业务偏多的公司来讲，在增加、运营等各方同窗的摧残下永远绕不过去的一个坑就是大量的H5页面开发，它多是一个下载、需求告知、产品介绍、营销活动等页面。此类需求都有几个明显的缺点：

• 开发性价比极低、上线时间紧，每次须要指派单独同窗支持。
• 沟通成本高，而业务逻辑高度类似。
• 高频次的需求

有句话怎么说来着，世界是"懒人"创造的，当咱们烦透了无休止的重复工做时，一些"偷懒"的想法就会蹦出来。对研发而言咱们不想花费过多的时间在此类简单重复的工做上；对运营而言他们须要活动更快的迭代、发版，脱离研发的排期等限制；于公司而言节省人力成本就是节省财务成本，更大的提升效率就能够支撑配合更多增加营销策略。

因此从技术赋能业务的角度出发，一套可视化活动编辑系统是每一个中大型公司必备的生产利器。

首先让咱们来挑几个表明性的页面简单分析一下...

以下图：

先从页面上作个分析：

• 图一、3都属于简单的引流下载页

• 图二、4属于普通活动页

• 图5无任何交互逻辑，只是单纯的一个静态告知页

• 图6从页面结构和业务逻辑来讲，属于复杂活动页

接下来抛开UI细节层面不谈，对页面进行一个拆解

• 图一、3 组合方式 （ 背景图 + 按钮 + [ ios、安卓 ]下载连接 ）

• 图二、4 组合方式 （ 背景 + 按钮 + 活动规则 + 领券逻辑 ）

• 图5 组合方式 （ 背景 + 活动规则 ）

• 图6 组合方式 （ 背景 + 业务模块 + 活动规则 ）

综上分析可见，每一个页面由多个小模块构成，能够是基础UI组件，也能够是一个复杂的业务组件，且组合方式多种多样，能够预想到当咱们将这些不一样组件像组件库那样整合在一块儿且能够在页面进行可视化的编辑操做时，不一样的组件不一样的排列便可生成一个全新的活动，就像积木同样拥有无限种可能，开发效率将会大大提升，本文将这两个月鼓捣lego活动可视化搭建系统（如下简称lego）从0到1的心路历程整理出来供各位有相关需求的小伙伴参考，也欢迎大神交流指正。

核心方案

Lego采用Vue框架开发，经过对组件物料进行拆分再统一管理，造成一个可编辑的组件库。JSON schema 来定义组件JSON规范，配合Vue的动态组件特性来实现动态的页面渲染。动态表单用于根据不一样组件特性生成对应配置表单。最后打包并优化多页面，每一个页面单独配置域名，一个负责内部编辑、一个负责对外展现。经过活动id获取对应活动JSON数据动态渲染在活动展现页面。

渲染流程： 多页面流程： 关于最后的活动页面展现除了多页面外其实还有特别多种方案可选，选择最合适本身业务的就好，后边内容会细说这几种展现方案。

关键词：JSON schema、动态渲染、动态表单、组件管理、多页面

技术方案

动态渲染

is

如何将不一样的组件打散后再从新拼装并渲染在页面上是整个技术方案最核心的点，好在Vue提供了动态渲染组件方案，经过内置组件conpontent，渲染一个“元组件”为动态组件并根据 is 的值，来决定哪一个组件被渲染。

props

大部分组件的可配置项无非就样式、连接、事件、文案这几种，咱们将它们抽离成一个config对象，经过props的方式传递给子组件用于渲染样式或者加一些点击事件等，好比bind绑定传进来的style样式，固然在这以前必定要定好基础config的规范。

渲染函数

因为一些业务的缘由，Lego除基础组件外其它部分开放的自由度并不算高，因此props的方案目前能够知足咱们的需求，但若是你想开放更高的自由度，释放系统的彻底编程能力，好比配置一些点击事件，事件执行交互等等。那能够试试Render渲染函数。根据官网对它的描述，它比模板要更接近编译器。而它的可配置对象足够你肆意发挥了。

布局方案

可视化布局的方案抛开大厂不谈，根据公司人员配比，建议大部分中小公司只须要如下两种方案的一种便可。根据不一样的优缺点来选择最适合你的方案，若是条件容许也能够两者结合实现。

抽屉式

自上而下顺序排列，能够更换组件位置，但不能实现元素定位，没有层级概念，遇到复杂布局或者须要叠放元素时不够灵活，若是须要实现复杂页面的效果则须要引入复合UI组件的概念，它须要大量现成的UI组件。优势是将可操做程度限定在了一个可控的范围内，对非设计人员来讲只须要经过现有UI组件进行拼装便可生成一个美观度较高的页面，lego即采用的是此方案。

自由式

彻底可随意拖拽元素位置，自由度高，只需几个基础UI组件便可，存在层级概念，可任意叠放拼装，在无成品UI组件的状况下diy出复杂页面。但页面不可控，对操做人员的美感要求更高。更适合UI同窗操做使用。下图只是一个复杂布局的例子，关注布局便可先不要管业务逻辑如何实现。

关于自由度

结合布局方案聊一下关于可编辑自由度的问题，编辑自由度应该综合实际状况进行考量。

对于lego而言，UI同窗仅参与组件设计的工做而不会去使用此系统去编辑发布活动，而当UI同窗不直接参与最后的拼装上线时，高自由度的编辑操做对咱们而言实际上是个鸡肋，直接开放高自由度给运营人员，因为存在层级叠放且可自由拖拽，这样就会有可能面临着大量的不可控的页面样式，即便在编辑完后UI同窗对页面效果把关，但相较于改起来的时间成本和活动质量来讲是得不偿失的。并且高自由度带来的是更多的技术的考量和实现成本，嵌套组件的层级规则、拖拽方案、组件定位等等….因此当你的团队技术实力和你能获得支持的资源不是那么充分时，也许抽屉式的半自由度方案更加适合你。

半自由度从布局方案到组件的可配置项上来讲开放程度有限，组件方面针对基础UI组件开放相对高的配置编辑项，同时积累大量的成品UI组件可选。在编辑时不须要考虑太细节的样式问题，保证页面质量。

当开发人力和资源和部门协同、工做流程都到位且规范的状况下，两种方式结合实际上是最佳的方案。能够提供不一样模式来供不一样人员使用，甚至能够实如今线编辑器来供研发人员直接进行代码调整。

组件分类

Lego将组件分为了两大类：UI组件、业务组件

UI组件细分为基础组件和复合组件，UI组件仅用来作静态展现用。原则是自身不包含任何业务逻辑，因为采用半开放的布局方案，对于复杂样式来讲咱们又基于基础组件封装了不少不一样功能不一样用处的复合型UI组件用以知足更复杂页面的需求。好比不一样主题的标题、按钮、均可以单独封装出来直接用于拼装。

业务组件是指那些和服务端有交互的有业务逻辑在里的组件，属于独立的功能模块，能够理解成每一个业务组件都是一个单独的活动，好比购卡、抽奖、分享等等。lego针对业务组件的惟一原则就是不在系统内提供业务相关可配置入口，仅开放基础样式配置，如大小、主题色等。将权限回收至研发手中，每一个业务组件在营销后台中配置数据，经过不一样活动id进行区分渲染。由于每一个业务组件发布前都通过了QA的完整测试流程，能够最大程度保证活动的稳定性，而不至于影响到业务。

配置项

每一个组件根据自身特性拥有着不一样的配置项，在选中组件后展现对应的配置表单是经过动态表单完成的，Lego系统使用了IView的组件库，每一个组件除自身属性外还会对应一份配置对象，经过匹配配置对象来描述这个表单的结构，最后仍是经过compontent对表单组件进行循环渲染。

通讯

对页面配置、组件增删、某个元素的配置项等全部编辑后的变化经过Vuex作统一管理进行通知。须要注意的是不少状况下只是改变某个对象下的一个属性，watch监听不到这种对象属性变化，而像是某个样式的其中一个属性变更是很频繁的，因此能够经过添加一个changeStatus的状态，每次属性被改变后能够更改监听changeStatus的状态来通知Vuex进行对应更新，但要注意作好防抖。

输出页面

当编辑完组件并拼装好整个页面后，如何将这个页面最终暴露给用户，在这个问题上咱们设计过两种方案：

A方案：

从公司现有的活动项目新建一个页面，将组件库打包发布到私有npm仓库进行管理并在此处引入，提供一个获取活动配置的接口给它，全部的活动都使用这个页面做为落地页，经过不一样的活动id来获取不一样的活动配置信息进行动态渲染。好处是上线方便，只要在lego系统进行发布后拿到发布后的活动id进行拼接便可，而无需进行页面部署。缺点也很明显，须要等待接口请求成功后才能进行渲染，一旦接口服务报错线上全部活动所有都会失效，并且渲染速度势必要比静态页面慢。这个方案咱们最终放弃了，由于除了上述问题，最关键的阿是从技术方面，咱们的node服务开发经验较少，从技术方案到架构方面都比较薄弱，并且最开始从设计之初没有考虑服务并发和数据库压力等，一旦像是经过公众号推送的活动，它承载的的并发是很是很是高的。因此在没有获得服务端同窗参与的状况下没有轻易采用此方案。

B方案

大致思路同上，仍是经过活动id取配置信息渲染页面。但把请求node服务拿配置的方式改为了访问本地json文件，并在落地页的归属上作了一些调整。步骤以下：

1. 将lego分为两部分：编辑系统、落地页，配置多页面打包。
2. 优化多页面打包，作好文件分割，两部分各自引用自身须要文件，提高页面加载速度。
3. 两个页面分别配置一个域名，一个负责对内编辑，一个暴露对外做为落地页展现
4. 每次上线活动打包前将配置数据拉到本地储存为json，落地页访问本地的静态资源。

这个方案实现了组件库和公共方法的公用，同时针对每一个页面作了分割，实现按需加载，保证页面性能。将网络请求node服务改成本地json，解决了并发的性能问题。缺点是当活动愈来愈多的时候，本地的json会愈来愈大，若是不及时清理无用数据，会致使页面加载愈来愈慢。lego目前采用的是这个方案，后续会再进行优化。

多页面优化

关于多页面的优化使用了splitChunk进行文件的分离，将系统端用到的各类资源单独进行分离。这样一来每一个页面只要加载自身须要的便可。

1. 删除默认配置
2. 单独导出chunk
3. 指定多入口页面单独进行配置chunk

优化后的页面速度

总结

1. 就这个系统来讲还有不少缺陷，但已经能够落地使用。像是落地页的方案目前还有明显缺陷，既配置数据保存在本地在必定程度上会拖慢加载速度。社区里的SSR服务端渲染方案、每一个活动打包为单独静态页的方案均可以进行尝试。但仍是那句话，根据当前团队的技术实力以及你能动用的资源综合进行方案的比较，有时候最好的方案不必定适合你如今的状况。
2. 活动搭建系统在必定意义上能够解决90%的简单页面，但复杂的多页面联动的活动仍是没法作到。
3. 组件的积累才是重中之重，在物料不丰富的状况下，开发效率提升有限，而一旦运行一年半载组件库丰富起来，效率将会肉眼可见的提升。
4. 不要以为本身的方案必定比别人的差，能够参考社区的大佬们优秀的技术方案和思路，但要从中找到自身须要的点便可。
5. 坚持独立思考、重视基础建设使技术赋能业务是每一个开发人员应有的素质，与公司无关与团队无关，只要你有想法总会有办法将方案推进落地，自身的思考和实现的过程当中的经验积累才是最宝贵的财富。