关于前端:我在淘宝做弹窗2022-年的回顾与展望

本篇文章作者向各位介绍了本人退出 PopLayer 我的项目一年多工夫以来，为产品所奉献的一份力量，既蕴含了站在产品视角对产品性能，易用性和将来倒退的考量，也包含了站在技术视角，对技术架构，编程范式和性能实现上的思考。

在我刚入职大淘宝技术用户增长团队时，弹窗作为用增站外触达的一种无效伎俩，须要一种零碎的解决方案来晋升弹窗的开发效率，扩大弹窗的应用场景，并通过联合唤端能力，扩充应用人群，为大盘奉献 AAC 增量。经外部重复探讨，咱们初步确定了由「弹窗编辑器」产出「弹窗形容数据」，搭配 H5，小程序侧「数据渲染引擎」在终端即时渲染弹窗的技术架构，产品名暂定为「全域 POP 搭投平台」。

淘宝老牌弹窗搭投平台 PopLayer 团队成员在听闻该想法后，被动提出单干，心愿将淘宝端内外弹窗搭投能力对立收口于 PopLayer 平台，为用户提供一站式端内外弹窗搭投体验。通过重复的沟通交流，咱们最终评估通过了这一计划的可行性。我从此成为 PopLayer 团队的一员，并作为产品设计（前期）和开发者推动 PopLayer 平台从 3.0 版本到 4.0 版本的降级革新工作。

在下文中，我将具体地介绍我在此次平台降级的过程中，面临的问题，对应的思考以及最终的解决方案。

工作的价值在于解决问题，在退出 PopLayer 团队后，首先要做的事是理解状况，「明确当下的问题」。理解了我的项目背景的读者曾经晓得，咱们曾经有一个明确待实现的指标「使弹窗搭建能力复用至端内外场景」。但因为咱们采纳基于现有产品革新降级的策略，就不可避免的须要在此之前，先解决一些历史包袱，轻装上阵。与此同时，跨团队单干也使得团队成员可能从不同角度从新扫视平台现状，从而对平台的降级注入更多期待和想法。

通过踊跃与团队成员沟通交流，咱们最终演绎总结出如下 4 个本次降级迭代亟待的问题：

平台不易扩大的问题：PopLayer 平台作为淘宝老牌的弹窗搭投平台，在弹窗域积攒了丰盛的畛域教训，但平台自身几经团队轮替，其代码也日益变得不易扩大和保护。但另一方面，咱们能显著的察看到，近些年行业内弹窗的视觉和交互体验正在一直晋升，业务方对弹窗的性能也提出了更多要求，因而，使 PopLayer 平台具备高扩展性以满足行业倒退须要，是平台需首要解决的问题；
平台应用体验不佳的问题：平台应用体验差，会导致平台答疑老本晋升，更有可能会使一些用户因为较高的应用老本对平台望而生畏，这对于平台和用户都会造成损失：更少的用户意味着更少的需要输出，会导致平台本身倒退遭逢瓶颈，而用户也会因为抉择手动开发而节约不必要的人力；
平台数据不足演绎整顿的问题：PopLayer 平台作为线上稳固运行多年，撑持亿级业务量的淘宝外围产品，积年累月积攒了大量的弹窗域相干数据，如何将这些数据无效地利用起来，从而领导一次弹窗投放流动拿到更好的业务后果，也是平台适应精细化经营时代趋势不得不思考的问题；
平台现有架构未充分利用的问题：在进一步理解 PopLayer 产品技术架构时，咱们发现 PopLayer 的技术架构与之前咱们初步确定的「通过弹窗形容数据（一段 JSON 格局的 DSL 数据）解耦弹窗生产和渲染」的思路不约而同。该架构的益处有以下三点：
a、通过将弹窗的生产与渲染拆散，能够将弹窗的生产通过无代码或低代码的形式转交给创立弹窗流动的需求方，从而在大幅升高弹窗开发成本的同时，保障弹窗迭代效率满足业务灵活性须要；
b、通过「弹窗形容数据」作为弹窗生产的标注输入，弹窗渲染的规范输出，使得弹窗在渲染侧能够不拘泥于特定的技术选型，从而适配各类需要场景，例如为端外开发 H5 渲染引擎，为端内开发 Native 渲染引擎，为小程序开发小程序渲染引擎等，从而在各场景用最适宜的技术做一件事，实现业务收益的最大化；
c、当业务提出新的业务场景时，能够通过在 DSL 层疾速迭代，渲染层疾速实现的形式，高效地满足业务的麻利须要；

然而，目前 PopLayer 平台尽管基于此种技术架构，却因为种种原因仅提供端侧 Weex 弹窗渲染能力，没有将该技术计划的价值最大化，有待进一步拓展。

在设计产品和进行架构设计时，仅仅是发现问题，提出计划，解决问题是不够的。特地是从 0 到 1 设计一个产品时更是如此。咱们须要跳脱出最不言而喻的「问题层面」，去思考「问题背地的问题」。只有这样，能力取得一个鸟瞰的视角，分明地晓得哪些问题是更重要的，并发现那些不那么不言而喻但却重要的问题。

正如亨利·福特所形容的：

当他问及过后的人们：“您须要一个什么样的更好的交通工具？”时，简直所有人的答案都是：“我要一匹更快的马”。

当取得一种鸟瞰的视角后，将会有更多机会发现汽车而非一匹更快的马。因而，我与团队在一直尝试为弹窗提供一个正当的业务模型和定位。

最终我是这样定义的：弹窗是一种用于疏导用户行为的交互控件。而弹窗所对应的事实参照则是「传单」：例如，健身房的销售们会在健身房门口向判断有健身动向的行人派发传单，从而心愿吸引他们去健身房参观并最终购买健身卡。这正是互联网上绝大多数弹窗须要做的事件，在适合的场合，向适合的人，展现低成本但有吸引力的内容，从而吸引用户最终产生经济行为。

发传单的例子是考虑弹窗倒退方向的优良模型（图片来源于网络）

因而在弹窗域咱们外围要做的事件也就高深莫测：

降低生产老本：晋升弹窗的开发，迭代效率；
扩大投放渠道：使弹窗能在任何业务须要的场景稳固地投放；
实现精准投放：现实状况下，弹窗应该只对对其内容感兴趣的人群曝光，从而使对用户的打搅降到最低，收益达到最高；
丰盛弹窗内容：弹窗内容越有吸引力，弹窗的成果就越好，弹窗成果越好，商业指标就越容易满足；
晋升用户体验：弹窗的体验越差，弹窗对用户的吸引力就越低。弹窗的性能，展现形式，微交互等都与弹窗的体验非亲非故；
数据驱动经营：互联网是有记忆的，通过一直积淀的流动数据，咱们有能力一直优化流动投放中的种种细节，从而使一次流动投放的收益最大化；

您该当能够发现，在「面临的问题」这一章中所列举的种种问题实际上也不过是咱们在实现上述指标中的一些绊脚石而已。通过想明确了弹窗域所须要解决的问题，以及它的终极状态。咱们终于能够循序渐进，井井有条的开展 PopLayer 产品的降级迭代工作了。

通过稍后浏览的内容您不难发现，咱们在这一年多中所做的所有事件都与这 6 个指标非亲非故。

在形容了咱们面临的问题，以及对问题的思考后。接下来便是解决「做什么」和「如何做」的问题。对此，我的思路是优先解决平台扩展性的问题，并在解决问题的过程中，解决平台易用性的问题，当这两者的问题都解决结束之后，不断完善，裁减产品性能。

之所以这样判断，是因为察看到行业弹窗日益透出的复杂化，精细化趋势必然在将来会对弹窗的表达能力提出更高的要求，而现有的平台因为历史起因不具备与之相应的扩展性。因而遵循「清扫好屋子再请客」的思路，优先在技术架构上为平台将来的倒退打好「地基」。而之后一直扩大新性能时，则能够释怀的把楼越盖越高，让更多的业务方安心入住。

对于有肯定复杂度的平台而言，晋升扩展性，大多数状况下意味着须要批改其原有架构。产品设计师不得不在基于原有产品，大刀阔斧的革新和罗唆重整旗鼓，从零开始搭建产品之间进行艰巨取舍。通过团队外部的重复商议，咱们最终抉择了后一计划，从 0 开始打造新版的 PopLayer 弹窗搭建平台。

通过先前的介绍您应该明确，弹窗搭建平台应该是一个使用户可视化实现弹窗搭建工作的低代码或无代码工具。它的产出物，在技术上体现为一份 JSON 格局的弹窗形容数据。因而，在创立弹窗搭建平台之前，咱们首先要做的，就是从新设计一套简洁优雅，蕴含弹窗域全副语义并可能轻松扩大的数据结构（DSL）。为此，我做了如下工作：

要想设计一份正当，优雅地 DSL，就首先要对特定畛域有深入细致的理解。为此，我收集了 1～2 年范畴内 PopLayer 投放过的弹窗，仔细观察梳理其款式与交互，摸索共性与差别。最终依据各弹窗的个性，将其进行如下分类：

弹窗类型分类不同弹窗类别的特色，视觉展现都被演绎至一篇名为《弹窗类型学》的文档中，能够帮忙用户迅速确认需要弹窗所属的类型。

通过演绎总结历史弹窗款式，交互和性能，一方面能够使我更有自信地设计具备良好扩展性的弹窗形容数据，另一方面，稍后能够看到，通过为不同类型的弹窗，提供不同类型的弹窗模版，既能够帮忙用户晋升弹窗搭建效率，也给产品减少了一个有着深远意义的数据维度，使咱们有能力能够比照同类型弹窗数据，并从中摸索法则促成业务优化。

弹窗模版市场

在搞清楚业务域的畛域边界和畛域内容后，就能够开始着手进行 DSL 的设计了，这也是本次我的项目革新降级的外围环节。DSL 设计的好坏，将间接决定整个我的项目是否有能力在一直倒退变动的业务诉求中始终保持稳定和麻利。我认为一份好的 DSL 设计，应该同时满足以下因素：

字段设计应合乎「奥卡姆剃刀」准则，如非必要，勿增实体：尽可能让数据字段精简，明确，同时，数据组织要正当；
数据模块之间应满足「高内聚，低耦合」准则，尽量避免批改某一个字段时，牵一发而动全身，导致大面积的字段批改；
需严密围绕特定畛域进行设计，既要防止适度设计导致数据结构简单和字段收缩，但同时也要充分考虑到将来可能呈现的种种可能；现实状况下，将来倒退出的新的业务诉求，只需「更新」DSL 的属性值，而非属性；

基于以上三个外围设计准则，最终咱们产出了淘宝弹窗形容数据标准。其大抵能够分为如下 7 个模块：

根底信息模块：蕴含弹窗的根本信息，如名称，类型等；
组件模块：蕴含弹窗域所需组件的形容，通过剖析历年弹窗域流动内容，咱们演绎总结出图片，文字，倒计时，热区，容器，iframe，视频，状态和敞开按钮共 9 种组件，每种组件都围绕弹窗域需要与手淘基础架构设置了特定的字段，例如对于文字组件，可设置行数与内容，对于倒计时组件可设置是否显示毫秒位，倒计时完结后行为，超过某个临界值是否显示文本等；定制化组件使用户能够十分直观便当地应用各组件实现弹窗搭建工作；
款式模块：负责形容组件的 UI，因为不确定终端渲染环境，因而在款式属性，款式单位的设计上就要充分考虑到不同场景，不同技术选型的限度。通过与客户端同学沟通交流，咱们最终将款式属性确定为能满足三端（H5，iOS，Android）与弹窗须要的最小款式汇合；
申请模块：申请模块涵盖了对手淘内常见申请形式的结构化形容，并将该形容同时应用在弹窗曝光前与曝光后，数据内容笼罩了弹窗域申请所需关注的所有关注点，并反对串行，并行申请的配置；
行为模块：与大多数搭建平台不同的是，PopLayer 弹窗搭建所产出的数据，是对弹窗款式，行为，配置的全面形容。在行为模块中，咱们通过梳理历史弹窗行为，对弹窗行为进行结构化定义，从而使弹窗行为能够被简略，清晰地形容，并通过彼此的排列组合，能够灵便适配各类业务须要；
动画模块：前文有提到过，行业整体的倒退，要求更细腻的弹窗展示模式和交互，同时，也要求弹窗对用户有更强的吸引力。为此，咱们引入动画模块，通过清晰，灵便的数据结构满足不同场景的动画须要；
其余功能模块：这里则次要蕴含其余与弹窗域相干的附加功能模块，例如渐进式曝光，承接页预渲染模块等，是对外围模块的裁减；

目前，淘宝弹窗形容数据一级数据共有 17 个，分类如下：

淘宝弹窗形容数据一级字段

每个字段均有清晰，及时更新的文档阐明与之对应。上面我将以行为模块的设计为例，让读者对 DSL 的设计有进一步的感触。

行为模块的设计
行为模块形容弹窗对用户行为的响应，在数据结构的设计上，站在被响应物体的角度，形容了物体应响应什么，响应的指标以及响应的内容，具体字段设计如下：

type：示意响应事件的类型，如点击（click），Tab 切换（tabSwitch）等；
behavior：示意弹窗的行为类别，通过咱们长时间的演绎总结，可将弹窗行为分类为：
1、goto：页面跳转；
2、switch：弹窗外部状态切换；
3、call：端外环境唤端至端内；
4、request：发送申请；
5、close：敞开弹窗；
6、doNothing：什么也不做（默认）；
7、show：显示；
8、hide；暗藏；
target：示意弹窗行为对象，会依据 behavior 字段的不同而领有不同语义，例如当 behavior 为 switch 时，target 示意待切换的状态 ID；
content：示意弹窗行为的内容，例如当 behavior 值为 goto，target 值为 app，content 值为 https://www.taobao.com 时，表明事件产生时，页面需跳转至端内首页；

通过这样的数据结构设计，咱们能够最大限度的清晰表白弹窗的行为，并通过根底字段的扩大和组合，在不扭转数据结构的状况下灵便，高效地反对各式各样的新需要。

一般而言，弹窗针对用户行为仅会有一次响应。但随着咱们对淘宝场景，用户行为感知能力的一直提醒，在极少数场景下开始呈现须要弹窗响应多个行为的需要。在衡量场景的稀有性和 DSL 的扩展性后，咱们针对这种非凡场景开拓了 actions 字段，数据结构如下：

{
    actions:[ 
        {
            "type": "click",
            "content": [
                {
                    "id": "1",
                    "target": "State_2",
                    "behaivior": "switch",
                    "content": "","nextActions": ["2"],"fallbackActions": []},
                {
                    "id": "2",
                    "target": "","behaivior":"close","content":"",
                    "nextActions": [],
                    "fallbackActions": [],}
            ]
        }
    ]
}

通过调整数据结构，复用 action 字段并同时扩大 nextActions 与 fallbackActions 字段，咱们能够轻松实现一个树状的行为形容，最低老本的实现并行或串行行为的形容。

DSL 的保护
值得一提的是，在设计好一个有着良好架构的 DSL 只不过是实现了万里长征的第一步。随着业务的一直倒退，开发者对畛域常识的更加深刻地了解。DSL 以后的构造总会面临着新的挑战，此时，设计者的外围责任则在于，严格的把控 DSL 的复杂度，保持仅在必要的时候才会对 DSL 的构造做正当的，小幅的批改。

如果设计者在漫长的保护岁月中逐步丢失定力，那么这份一开始精心设计的 DSL，最终也会像绝大多数蹩脚设计一样，迅速收缩，变得俊俏，难以了解，不易保护。所以设计者应该始终保持高度的责任感，实现如下事宜：

撰写粗疏，敌对的文档，并定时更新；
文档应及时表明某些字段的特殊性，如已废除或反对不齐全，防止其余开发者踩坑；
在波及 DSL 的变更时，须要庄重思考变更的合理性，变更形式和潜在隐患，谨小慎微，科学规范的进行迭代；

以上，便是对本次产品升级的外围 — DSL 从新设计的一些教训分享，在确定好一份能够清晰形容各类弹窗，具备良好扩展性的数据之后，下一步工作则是提供一个面向用户，用于产出满足数据标准数据的弹窗搭建平台。

弹窗搭建平台的外围功能在于「降低生产老本」。但从产品架构设计的角度登程，还须要保障产品在将来演进的过程中，始终保持可能高效，稳固地迭代性能。因而对于弹窗搭建平台从 0 到 1 的建设，始终须要兼顾以下两个问题：

产品设计上：如何让用户更顺畅地应用产品？
技术架构上：如何让产品更不便地继续扩大？

对于第一个问题，将留待下一章阐明，在本章的残余篇幅，我将向您介绍我是如何在技术架构设计上保障产品的稳定性与扩展性的。

下方是弹窗编辑器 xEditor 的技术架构图：

xEditor 技术架构图

从架构图中能够清晰地看到，xEditor 的整体架构能够分为数据层，逻辑层和工程层三个局部，要想让整个利用始终保持稳定性与高扩展性，我在每层做了如下设计：

数据层设计
数据层次要蕴含编辑器外部状态的治理以及对外的数据交互。因为编辑器的性能在于产出满足 DSL 标准的数据，因而对外的数据交互较为简单，外围应关注外部状态的治理。

为了保障状态变更的有序性和可维护性，我通过 immutable.js 将用户的每一次操作后果保留为一个「数据快照」，并压入栈中。因为每一个快照都是一份不可变的满足 DSL 标准的数据，因而快照的每一次更新都能够促使预览模块即时渲染出最新的弹窗款式。从而通过严格的数据驱动渲染使整个利用的状态颠三倒四。并且因为预览模块采纳了和线上统一的渲染引擎，因而还能够真正实现「所见即所得」的成果。

基于不可变数据结构的状态治理

同时，因为用户的每次操作构造都被保留下来，因而整个利用还能够轻松实现用户行为记录，回退性能，进一步晋升用户体验。

逻辑层设计
在逻辑层要解决的外围问题是让利用具备灵便的扩大能力，为此，我将整个用户界面依照功能模块拆分成一个个有标准化接口的组件，并通过在底层实现一个有标准化「插槽」的 Layout 基座，使得每个功能模块都能以相似插件的形式，通过插拔模式拼装出一个具备残缺性能的利用界面。

插件模块用于灵便插拔性能面板

通过这样的设计，使得每个性能区块均彼此独立，且可依据需要迅速扩大或移除，开发者不用放心会影响其余模块性能，并且利用还能够依据不同用户辨别所要对外裸露的性能（稍后咱们还会看到对于这项个性的一个实例）。

工程层设计
在工程层上，整个利用采纳 TypeScript 束缚变量类型并为开发者提供接口提醒，并对外围工具类函数进行单元测试。通过集成团体 AppLint 标准，使代码在格调和应用上对齐淘宝最佳实际，从而最大限度减缓利用代码在屡次迭代后的腐烂速率。

除了代码上的种种束缚外，撰写清晰的产品，技术文档，并持续保持文档的陈腐水平，也是保障利用始终维持在可保护可扩大程度的重要因素。

下方展现了 PopLayer 整体计划的相干产品，技术文档目录，蕴含了用户，开发者所需理解的简直所有内容。

PopLayer 4.0 官网文档

以上便是弹窗搭建平台 xEditor 在技术架构上的一些思考和设计，正是基于这些设计，xEditor 在能在业务疾速迭代的过程中，始终保持麻利，将弹窗搭建能力赋能给越来越多的业务。

在介绍完技术架构上为产品可扩展性作出的种种致力后，本章将着重介绍弹窗搭建平台 xEditor 是如何在产品设计上为用户服务，大幅晋升弹窗搭建效率。

在产品设计之初，我就受到各方搭档的质询？这个产品是给谁用？这显然是个十分好的问题，想分明为谁设计，永远是产品设计的第一步。对此，我的思考是，基于线上弹窗的复杂程度不一，弹窗的搭建工作也必然不可能齐全由经营实现，因而，对于简略的弹窗应该提供足够合乎直觉的交互界面，让无技术背景的用户能够轻松实现搭建，而对于交互简单的弹窗，能够容许有肯定技术背景的用户实现，但整个利用的交互复杂度要要尽量管制在非技术用户在通过文档培训后便能胜利搭建。

鉴于产品的用户既可能是经营或产品，也可能是开发，因而在产品的界面设计上，就不能偏差任何一方，而是要抉择一个尽量合乎两方操作习惯和认知零碎的设计。为此，我调研了团体与行业内各类搭建平台（iceluna，云凤蝶，xEditor 等）和设计工具（Axure，Sketch，Photoshop 等），最终决定在产品界面上参照 Axure 的界面设计，应用拖拽 + 配置的外围交互模式。

之所以这样抉择，次要因为以下三点：

拖拽 + 配置生成视觉因素是一种合乎用户直觉的 UI 创立形式，很多年来 Axure，Sketch，Photoshop 等利用已帮忙用户建立了心智模型；
Axure 的界面设计非常经典，大多数用户对此非常相熟；
Axure 作为业界业余的原型设计工具，自身笼罩的性能就根本能满足弹窗搭建须要，因而 follow 其性能设计规范，是站在伟人的肩膀上，能最大限度防止将来踩坑；

上面是最终的产品界面展现：

xEditor 交互界面

除了在界面上尽量遵循用户应用习惯，正当分区排布性能外，xEditor 另一个值得一提的交互设计优化便是可能依据弹窗模版类型的不同，为用户展现不同的交互界面，对于一个展现类型的弹窗（即弹窗自身不发送申请，仅展现内容，点击弹窗后跳转），用户看到的界面将是这样：

留神到了吗？相较于「齐全体」的编辑器而言，展现类弹窗模版缺失了右上角的「数据中心」面板，并在左侧「组件库」中也仅展现了必要的三个组件。这所有都归功于 xEditor 插拔式模块的技术架构，通过这种形式，咱们能够尽量升高用户的了解老本，让用户仅需关怀本人须要关怀的事件。通过将产品乐音降至最低，咱们能够实现对于纯展现类弹窗，用户的搭建老本不超过 1 分钟。

相较于理论开发中我的项目启动，注册埋点，性能实现和测试的工夫，xEditor 至多节俭了 2 人日的弹窗开发工作量！

除了为不同需要的用户提供恰到好处的性能之外，咱们还新增了一些性能用来进一步晋升用户的搭建效率，并将更多过来无奈通过搭建模式创立的弹窗需要纳入新的搭建体系。在泛滥性能中，比拟有代表性的是以下两个：

数据 MOCK 性能
当弹窗波及与服务端的申请交互时，特地是弹窗的内容取决于服务端返回的字段时，以往的弹窗编辑器均不能很好的解决这样的情景，只能兜底返回 undefined 这样的字段，毁坏所见即所得的应用体验。

而 xEditor 通过新增数据 mock 性能来解决这个问题，通过在配置接口时，容许用户填充与线上响应数据统一的 mock 数据，即时显示对应的弹窗款式，从而防止重复扫码真机预览所带来的工夫损耗。

基于数据 mock 性能，xEditor 还能够在搭建侧轻松实现「前后端拆散」的生产成果，即当服务端接口尚在开发中时，只有单方约定统一的数据结构，经营或开发就能够依照该数据提前搭建好弹窗款式，待接口结束后无缝连接上线。

留神到了吗？用户甚至能够增加多份 mock 数据，并任意切换，视图会依据抉择的 mock 数据即时更新！这在弹窗对不同响应数据响应不同款式时就会十分便当，并且用户也能够通过成心设置非凡的数据值，来测试测验弹窗的款式是否失常。

留神：所设置的 mock 数据仅在编辑器中失效。

复合条件判断性能
除了在弹窗上间接展现服务端返回的数据之外，在一些场景下，弹窗须要依据服务端返回的数据展现不一样的界面，并且对数据的判断逻辑也较为简单。此时，就是 xEditor 复合条件判断性能退场的好时机了。

通过 xEditor 提供的多状态切换 + 状态曝光条件判断 + 数据 mock 性能，用户能够十分直观且不便的搭建蕴含简单逻辑判断的弹窗。

除此之外，状态的条件判断性能实践上反对有限嵌套，可能满足各类复合条件判断需要。

可有限延长的数据判断面板

最终的复合条件将会体现为如下数据结构：


{
  "condition": {
    "left": {"left": "{{store.$username.nickname}}",
      "operator": "=",
      "right": "kongtang"
    },
    "operator": "&&",
    "right": {"left": "{{store.$age}}",
      "operator": ">=",
      "right": "20"
    }
  }
}

在对产品的扩展性，易用性进行系统升级后，下一步要做的就是不断丰富弹窗的性能。如果将后面做的事件比作「打地基」，那么这一步以及之后所要做的事件就是基于这个松软的地基，将房子越盖越高，以满足更多，更简单的弹窗搭建需要。
无论是增加什么新性能，在渲染侧咱们的外围指标始终围绕以下两个主题：

丰盛弹窗内容；
晋升用户体验；

通过这两点，咱们心愿尽量减少用户对弹窗抵触情绪，带给用户更舒服，离奇地体验，从而更好的促使弹窗的疏导指标达成。对弹窗性能建设的量化指标，最终将落地在以下两个方面：

用户满意度，来源于定期用研数据；
弹窗的曝光率，点击率以及弹窗点击后承接页的达到率；

上面将介绍一些本次产品升级中一些较有代表性的新增性能。

弹窗曝光是弹窗胜利疏导用户行为的第一层漏斗，弹窗曝光率的晋升，会使更多用户有机会看到弹窗内容，意味着某种业务策略或用意可能影响更多的用户。因而晋升弹窗曝光率，将弹窗曝光率迫近 100% 的现实值，是弹窗域永恒摸索的方向。

为了晋升弹窗曝光率，有以下两个方向可供摸索：

投放侧：优化投放通道，晋升流动配置的命中率和响应工夫；
渲染侧：晋升弹窗的渲染性能，或至多在体验上为让用户认为弹窗响应速度很快；

因为投放侧的建设目前正在进行中，上面将次要为各位分享一些渲染侧性能的实现与成果。

在与 PopLayer 团队开展单干之初，咱们首要解决的问题便是买通弹窗搭建的站外投放链路。因而，基于新版 DSL 标准开发的第一个渲染引擎在技术选型上自然选择了 H5 计划。因为站外环境的不确定性，以及对性能的刻薄要求，渲染引擎在实现上抉择尽量避免第三方框架和库的应用，外围逻辑全副应用原生 JavaScript 实现。

而因为技术选型上抉择应用原生 JavaScript 实现，那么就必须要在技术架构和代码构造上精心设计，从而保障代码的稳定性，健壮性以适应将来业务倒退继续的性能迭代须要。为此，在渲染引擎的编码范式上，我借鉴了函数式编程的思维，将渲染引擎的各个性能封装成一个个纯函数，并通过管道式调用的形式，让代码的各个性能在接口上保持一致，在性能上放弃内聚。无论是将来出于 debug 须要，还是要新增性能，都能够通过批改，新增，删除「管道」的形式对利用进行稳固，高效的迭代。

xRender 代码结构图

通过展现的 xRender 代码结构图能够看到，整个 xRender 都能够近似看成一个「纯函数」，对立的 DSL 数据输出，会生成统一的弹窗行为和款式。从下方的代码截图能够看出，理论的代码通过函数式编程范式，也和整体设计放弃一一映射的关系。

xRender 主逻辑代码

通过线上验证，由原生 JavaScript 开发的 H5 弹窗渲染引擎，渲染工夫在十几毫秒几十几十毫秒之间（不蕴含异步数据申请），整体的弹窗业务数据与老的 Weex 1.0 渲染引擎保持一致。

在 xRender 上线稳固退役一段时间后，咱们开始摸索更极致的渲染侧弹窗性能优化之路，通过综合评估，咱们决定基于新版 DSL 数据标准，在端侧开发仅满足弹窗域渲染所需的，轻量化弹窗渲染引擎，从而节俭其余计划所必须的容器启动工夫，提供更极致的渲染体验。

要买通 Native 渲染，须要对 DSL 的局部字段进行更强的束缚，并且，因为三端在局部场景下渲染计划存在微小差别，还需在尽量不更改原先 DSL 构造的根底上，对 DSL 进行扩大，以满足三端渲染的一致性须要。通过团队外部的重复探讨和打磨，测试同学的谨严测试，Native 轻量化渲染引擎胜利应运而出，稳固服务线上业务场景，并逐步笼罩更多业务。

通过在非大促期间不同工夫投放同一流动的 Weex 1.0 渲染版本与 Native 轻量化渲染版本数据，咱们发现 Native 轻量化渲染引擎可促使弹窗曝光率晋升 26 pt，特地是双十一期间「88 VIP 开卡弹窗」的单日 PV 曝光减少 43 pt。

除了千方百计晋升弹窗的曝光率，弹窗的业务指标最终是否实现，还是要落在用户是否无效点击弹窗上。因而，弹窗域要解决的另一个外围问题在于如何晋升弹窗点击率。

为此，咱们的摸索方向是多维度的，次要蕴含以下几个层面：

通过与设计师独特制订淘宝弹窗款式，交互标准，使搭建侧产出的弹窗始终保持标准化的弹窗款式和交互行为。例如规定弹窗尺寸，敞开按钮大小和地位等，从而为用户带来更好的体验，加强用户的点击志愿。通过弹窗模版，搭建侧能够强制束缚弹窗的根本款式和交互；

通过增加动画模块，使用户可能借助快捷增加弹窗动效能力，在弹窗点击成果不佳时，多一种无效调控伎俩；

通过接入 UCP 智能管控，通过端智能算法，使弹窗曝光给点击志愿更强的用户；

上面将次要介绍动画模块的设计和线上成果。

动画模块

咱们对动画模块的设计要求有以下三点准则：

足够简略，仅反对个别常见动画；
足够正当，能保障三端均可实现统一的动画成果；
足够灵便，能满足弹窗域多变的繁难动画需要；

最终，基于以上准则，咱们确定了动画形容 DSL 标准。使弹窗元素具备疾速增加动画的能力，除此之外，咱们还与端侧同学单干，取得端侧用户行为感知能力，能够使弹窗感知到，用户在端内的滑动，切换 Tab 等行为，通过为不同的用户行为绑定对应的动画成果，咱们有能力为弹窗带来更细腻的视觉和交互体验。

上面展现一些具备代表性的事例：

2021 年双十一购物车开奖揭示弹窗：该弹窗原本采纳动态图片形式出现后，上线后发现点击数据不佳，后决定增加摇一摇动效，因为该动效在之前的业务中已积淀为可复用的动画模块，因而此次迭代只需数分钟便可实现上线。动效弹窗上线后，促使弹窗点击率晋升 3.6 个百分点。
淘宝二楼飘条：通过将滑动感知与动画模块相结合，咱们能够依据用户的滑动轨迹触发弹窗对应的动效，从而给用户带来更细腻的体验：

除了从弹窗曝光率，点击率动手以期为业务带来更大价值外。在团队同学的倡议下，咱们还开拓了弹窗域可摸索的新场景：弹窗承接页的达到率优化。还用发传单的例子，咱们之前所做的事件是在尽可能低成本地印刷对指标用户有吸引力的传单，并尽可能在更多场合，向指标用户稳固派送，而「承接页达到率优化」则是在用户拿到弹窗，产生趣味，然而因为指标地点太远正在当机立断时，将用户霎时传送至指标地点，间接打消用户的顾虑，缩小犹豫和期待中可能的用户散失。

为了实现承接页达到率优化，咱们借用会场预加载能力，在弹窗曝光时对页面进行「预加载」，待用户点击后，便能间接看到加载好的页面。

基于该技术原理，我制订了两期的我的项目迭代打算：

一期迭代：疾速跑通技术链路，线上验证业务价值
本期迭代蕴含以下内容：

端侧买通 POP 预加载接口；
在 xEditor，xRender 上集成预加载相干性能；
推动承接页埋点革新；
梳理对齐全流程埋点，通过 A/B 试验测试技术计划的业务成果；

一期迭代的外围在于通过残缺的设计，将会场预加载计划与 POP- 承接页技术体系相交融，并确定整条链路的数据如何串联，与外围关注指标，保障数据科学性。通过团队外部的重复探讨，咱们最终通过约定 URL 参数标识的形式残缺串联整个数据链路，整个数据链路和外围指标如下图所示：

POP 承接页预加载数据链路图

通过清晰定义数据的串联形式和外围关注指标，咱们能够很高效的与数据团队对接，疾速，精确地掂量，评估这次技术改造所带来的业务价值。通过选取一周的线上业务 A/B 试验数据证实，POP 承接页预加载性能促使页面达到率晋升约 12.58pt，促使页面可视耗时均匀升高 1.76 秒，并间接晋升承接页点击 UV 2.47pt。根本合乎预期，达成承接页秒开成果，取得了正向的业务收益。

二期迭代：承接页秒开常态化
在疾速验证承接页预加载技术能为业务带来正向价值后，接下来我须要做的外围事项就是大力推广该性能，让更多业务可能高效，稳固的享受技术带来的业务增量，因而，二期迭代次要蕴含如下内容：

推动 native 轻量化渲染引擎实现预加载相干性能；
为通过埋点革新的页面默认开启承接页秒开性能，为未通过埋点革新的页面提供革新计划以及手动开启性能的入口；
推动淘宝新人版，银发版等版本日常开启承接页预加载接口；
借用一休 ER A/B 试验能力，在每次承接页秒开能力开启时，主动创立低流量空桶进行成果比对，让技术带来的业务收益看得见，可掂量，也不便后续的一直优化。

整个程序的运行时序图如下：

承接页秒开二期时序图

从用户视角来看，当 xEditor 在弹窗公布前检测到用户弹窗蕴含不在白名单，但无效的跳转链接时，会对用户进行性能提醒，由用户判断是否开启该性能：

页面不在白名单时，提醒用户感知性能

而当 xEditor 检测到弹窗的跳转页面曾经实现预加载埋点革新后，则会默认创立 ER A/B 试验，对大流量桶开启预加载性能，并在公布前告诉用户。

当页面在白名单时，默认开启承接页预加载

同时，当 xEditor 检测到页面有多个无效的跳转链接时，则会给用户提醒，让用户被动抉择须要针对哪个页面开启性能：

通过承接页秒开我的项目的二期迭代，咱们胜利做到对于已实现埋点革新页面，平台默认赋能预加载性能，从而让更多业务享受页面达到率晋升带来的增量价值。与此同时，通过默认的 ER 试验分流，平台也能够清晰感知到所赋能的业务数量以及发明的价值增量。

自从我入职以来，团体就在鼎力推动平安生产。对于弹窗这种须要疾速迭代，流动期间亿级流量的产品而言，如何更好地晋升产品稳定性，更是我在产品设计和开发过程中始终思考的问题。

得益于 PopLayer 平台作为老牌的淘宝弹窗搭投平台，在稳定性保障上的建设曾经足够优良，所谓珠玉在前，木椟在后，我能做的也只有在搭建侧和渲染侧作出如下优化：

晋升 xRender 测试覆盖率，接入 JSTracker 与舆情管控，并在每次迭代时进行严格的回归测试，确保利用线上稳固运行，如有异样，及时报警；
在 xEditor 中自动检测用户填入的跳转链接地址是否为预发地址或有效地址，若发现则在用户公布时及时给用户反馈，同时，在渲染侧对首屏图片资源的加载状态进行监控，当图片加载失败时，阻止弹窗曝光；

当监测到用户填写预发地址时，被动预警

在用户公布弹窗时，为用户展现疲劳度等弹窗全局配置，防止用户因为疏忽大意，谬误配置导致线上弹窗行为与预期不符；

公布前外化全局配置，防止非系统性危险

通过一年多工夫团队成员在 PopLayer 扩展性，易用性，功能丰富度和稳定性上的独特建设，现在回首看来，咱们在弹窗域获得了以下成就：

【大盘数据】自 2021 年 8 月 PopLayer 4.0 版本正式上线以来，至今共承接手淘端内外各类弹窗流动 46 个，并涵盖具备动效，场景感知等原搭建无奈反对类型，至多节俭 92 人日人力老本，期无线上故障；
线上局部弹窗流动示例
【零碎扩大】实现了 PopLayer 从 3.0 至 4.0 版本的大版本升级，通过重构底层 DSL，从 0 到 1 开发弹窗编辑器，使整个零碎变得更加强壮并可能继续响应业务倒退须要，疾速，稳固扩大性能，反对更多业务场景；
【生产效率】通过从 0 到 1 开发弹窗编辑器，大幅晋升弹窗搭建效率，以及可搭建弹窗的覆盖范围，对于简略弹窗，实现了无技术背景用户搭建时长 < 1 分钟，大幅节约了人力老本（至多 2 人日 / 个），取得了用户的高度认可；
【触达范畴】通过开发 H5 渲染引擎并买通端外投放渠道，实现了弹窗搭建链路的端内外全场景笼罩；
【精准投放】通过在引擎侧接入端智能算法管控 SDK，营销型弹窗可能通过算法调控，实现精准投放，升高用户打搅的同时晋升弹窗点击；
【极致性能】通过 H5 原生渲染引擎，保障端外弹窗性能，通过 Native 轻量化渲染引擎，晋升端内弹窗曝光率 26pt，通过 POP 承接页预渲染性能晋升承接页达到率 12.58pt，点击率 1.82pt；
【丰盛内容】通过新增动画模块，淘宝场景感知模块，为弹窗搭建提供了通过增加动效晋升弹窗点击的经营策略抉择；
【体验晋升】通过在搭建侧为弹窗提供对立的视觉交互标准，进一步晋升弹窗用户体验；

尽管通过一年多在弹窗域的深耕，咱们获得了一些看得见的成绩，然而间隔将 PopLayer 打造为淘宝弹窗解决方案的指标，仍然还有很多中央须要持续摸索。归纳起来，次要有如下几个方面：

尽管通过 Native 轻量化渲染引擎能够显著晋升弹窗曝光率，但引擎自身波及版本覆盖率的问题，在版本尚未笼罩到业务可承受的范畴之前（一般而言 > 95%），如何使弹窗尽可能笼罩到足量人群是咱们须要面对的外围问题。

对于这个问题，咱们以后给出的解决思路是，继续摸索 H5 渲染计划在淘宝首页直出场景下的性能优化计划，并在平台侧建设引擎主动分流机制，使满足 Native 渲染条件的弹窗应用 Native 轻量化渲染引擎渲染，而不满足条件的弹窗主动降级为 H5 渲染计划。从而使搭建侧用户无感知的取得最大限度的业务收益。

目前依据咱们的教训，是否增加动效与弹窗点击率晋升之间并没有必然的相关性。但在一些场景中，咱们能够显著看到弹窗从动态转为蕴含动效的动静弹窗后，弹窗的点击率有显著晋升。因而，至多咱们能够说，动效能够作为一种晋升弹窗点击率，更好达成业务指标的一种无效伎俩。

但更进一步的问题是，除了有助于晋升用户体验之外，到底动效与弹窗点击率之间的相关性是什么？目前咱们在这方面的摸索仍稍显有余，为了答复这个问题，咱们接下来会在以下方面继续摸索和建设：

进一步买通 A/B 试验能力，使平台和用户可能疾速创立弹窗 A/B 试验，摸索和验证弹窗动效与点击率的相关性；
建设罕用动效模版，在搭建侧提供疾速为弹窗组件增加动效能力，晋升业务迭代敏捷性；
联合行业察看与业界最佳实际，继续摸索更适宜弹窗域的动效表达方式；

通过在弹窗动效上的继续摸索，心愿可能在晋升弹窗体验的同时，为弹窗内容的表白提供更丰盛的技术支持，从而加强弹窗吸引力，晋升用户点击志愿。

目前淘宝端内弹窗，还有约 30% 左右的流动因为其状态，交互复杂度超出弹窗搭建能力的覆盖范围，只能通过开发者采纳编码方式手动进行开发。针对这些业务场景，咱们须要继续摸索如何通过持续扩大搭建能力或其余形式最大限度的升高弹窗的开发成本，并给终端用户提供稳固，高性能，丰盛的内容。

与此同时，进一步升高简单交互弹窗的搭建老本，也是咱们须要继续摸索的重要课题。

回顾我在本章结尾局部提到的弹窗域的 6 大外围业务指标：

降低生产老本；
扩大投放渠道；
实现精准投放；
丰盛弹窗内容；
晋升用户体验；
数据驱动经营；

咱们这一年对最初一个指标的建设还稍显有余，尚未有一个能够清晰展现淘宝弹窗散布，弹窗状态与数据的视图，可能让咱们比照同类型弹窗的成果数据，发现法则为经营提供改良倡议。也尚为建成一个高效的 A/B 试验创立通道，让用户可通过一直试验，继续优化弹窗数据。

但好消息是，这些正是咱们接下来的建设方向，咱们正在通过淘宝弹窗管控平台，摸清整个淘宝端内外弹窗的散布，状态，类型和成果数据，并在投放侧设计，建设高效的弹窗域 A/B 试验计划。还请各位用户关注咱们的后续开发进展。

在本篇文章中，我向各位介绍了我退出 PopLayer 我的项目以来，在一年多工夫里，为产品所奉献的一份力量。既蕴含了站在产品视角对产品性能，易用性和将来倒退的考量，也包含了站在技术视角，对技术架构，编程范式和性能实现上的思考。通过这一年多工夫，和团队独特打磨一款产品的经验，着实令我受害良多，在很多方面都有了可喜的提高，并且也发现了本人在做事办法上的一些有余。这些都积淀为我贵重的教训。

通过这篇文章，尽管不算是事无巨细，但也算是零碎的，把我目前能想到的一些教训以及做事的办法积淀下来，心愿可能给各位读者带来一些灵感和播种。

最初感激各位读者能保持将这篇近 2 万字的文章浏览到最初，心愿您能感觉不虚此行，也欢迎您和我交换您浏览后的感触或提出倡议。祝您工作欢快。

关于前端:我在淘宝做弹窗2022-年的回顾与展望

前言

面临的问题

业务上的思考

做了什么以及如何做

扩展性建设

演绎总结历史弹窗款式性能

设计新版弹窗形容数据

开发无代码弹窗搭建平台 xEditor

易用性建设

交互设计优化

新增易用性能

性能建设

弹窗曝光优化

H5 原生弹窗渲染引擎 – xRender

Native 轻量化渲染引擎

弹窗点击优化

承接页达到率优化

稳定性建设

成绩，有余与倒退布局

成绩展现

有余与倒退布局

解决 Native 轻量化渲染引擎版本覆盖率问题

增强动效能力建设

进一步扩充弹窗搭投链路的场景覆盖率

淘宝全域弹窗数据体系建设

总结