精品化组件｜全局运营浮层

01 背景

贝壳体系中之前一直没有一套统一的投放运营服务，整个B端有20多个app，每个app提供给不同职能的经纪人进行系统作业，每个产品线的产品和运营都有各种不同运营类、通知通告类和作业类的弹窗和浮层的功能，需求期望对指定经纪人精准的进行信息触达，每个需求都需要等app发版周期来开发，上线、下线都需要发版，且相同的弹窗浮层无法做到页面迁移，后期维护成本非常高。

基于上述所有痛点，平台设计了一个全局浮层SDK，为贝壳体系中B端所有app提供一套统一的投放运营服务能力。

02 价值

全局浮层SDK是贝壳体系中一套统一的投放运营服务，核心能力是能够与业务解耦，客户端0人力开发，无需发版即可实现在任何页面、任何人群、任何时间、以及权重优先级等策略进行投放自定义样式的弹窗和浮层。

03 发展轨迹

UI 样式：

触达页面：

触发方式：

04 系统结构视图

4.1 整体架构

监听app整个生命周期，根据冷启动或push或router接收的浮层数据和投放策略，并结合了频次、优先级、是否强制等控制策略等信息，当进入某个指定页面时或router触发时，动态插入可支持jsbridge双向通信的H5浮层的通用能力，利用投放中台能力直接实时触达展示给指定的人群。

4.2 投放系统架构

投放平台可分为两种处理方式：一种是以App端主动拉取的方式，一种是投放平台主动push到App端的方式。

App端拉取的方式：通过在配置平台配置好的订单存储到投放平台，App端通过接口获取投放内容，投放平台对数据进行组装返回给App端，App端展示浮层。

投放平台主动push的方式：和App端主动拉取不同，主动push的方式需要有事件去触发，投放平台接收到事件后存储推送记录，根据投放策略进行内容组装，投送节点会区分是即时投送还是延时投送，然后进行人群拆解，最终通过IM服务将消息传递到App端，App端收到IM消息后去投放平台再次拉取数据，收到后App端展示浮层。

4.3 kePopLayer的设计

这里我们从技术上看一下它的整体设计过程：

1. 打开app时，请求浮层配置数据，并建立im push长链接支持浮层数据的实时投放。      

2. 当打开app拉取到数据，或者app运行过程中收到投放浮层数据，将浮层数据按照其配置的页面位置信息，存入各个页面浮层缓存数据队列列表中。  

3. Hook监听各页面的进入，退出，及生命周期，记录当前所在页面的名称。      

4. 当进入某一页面时若命中了缓存的浮层数据，则根据优先级顺序弹出相应的浮层，弹出native的浮层，或者将对应的Webview加载到Activity/Controller页面上。

4.3.1 投放数据浅析及相关概念

投放数据：

相关概念：

1）投放页面位置: posPage（androidPage、iosPage、h5Page、flutterPage）    

• any页面：当浮层数据通过im push到客户端上，在客户端上任意页面（当前页面）立马展示，当浮层数据是客户端冷启动从接口拉取到数据时，拉取数据后，在客户端第一个显示的页面展示。用于紧急事件，能够打断用户当前操作。     

• 具体某一页面位置：当用户进入到某一个页面时，在该配置的页面展示。用于具体的业务活动提示。      

2）浮层生命周期类型: popType      

• 强制浮层: 浮层出现后，如果用户没有完成指定的业务流程操作，浮层将不能够被关闭，冷启动后，服务端将继续下发该浮层数据。该浮层具有强制打断性。      

• 非强制浮层：浮层出现后，如果用户观看或者点击关闭后，在app本次生命周期内关闭，重新冷启动，服务端也不会继续下发该浮层数据。  

浮层UI及容器

1）native弹窗

由客户端预先写好几种模板集成进app中，通过服务端下发数据调用不同的模板。 

优点：固定UI样式native内置，无需前端同学开发，展示速度快。

缺点：模板只有预置的几种，如果需要复杂多样的弹窗UI样式，需要客户端开发发版解决。

如上图所示，native弹窗的标题、内容、点击文案、跳转链接等内容均可配置；

native弹窗的用户交互行为：      

• 关闭按钮是否显示、及是否可以滑动退出均可配置。      

• 此外根据弹窗是否是强制弹窗，来设定点击跳转后弹窗是否消失。 

如上图所示，点击“去签收”、“开启验证”等按钮，均可跳转到对应的业务流程去处理，若是非强制弹窗，点击跳转的同时关闭弹窗；若是强制弹窗，点击跳转的同时不关闭弹窗，业务流程结束时，可通过业务方调用服务端接口通过im push关闭弹窗，或者有业务方直接调用router关闭。

2）WebView容器承载的H5浮层（推荐使用）

包括H5弹窗 和H5浮球。由H5开发实现浮层的UI, 用客户端的WebView容器承载H5弹窗页面，设计根据H5页面浮层的业务需求配置，来拦截或传递WebView点击滑动事件。

优点：样式灵活，可以由H5、javascript实现复杂多样的H5浮层、无需发版立即上线。

缺点：网络环境较差时，H5加载较慢。    

如上图所示h5浮层的容器为WebView容器，其UI结构处于页面最顶端全屏View，Android代码实现是添加在Activity ContentView的最上层，iOS是添加在当前window上，不修改原有页面的层级结构。

H5弹窗的用户交互行为 ：

当用户的触摸事件到来时，我们会根据浮层的透明度，与对应的阈值去做判断，如果不透明度超过了阀值，拦截它交给kePopLayer的H5处理，用户就点击到H5上的元素；如果没有超过这个阈值，则将此次事件拦截放弃处理，将该事件交给下层的native页面做相对应的逻辑。 

4.3.2 kePopLayer生命周期

下面来谈一下kePopLayer的触发方式：

• 方式一：上文有提到，可以通过监听页面切换来判断在新的页面上是否有活动需要展示，因此页面切换是最常用的，大多数场景都采用这一方式去触发；  

• 方式二：是可以通过im 长连接push通道实时推送消息方式触发，能够在用户停留在某个页面时，实时展现在用户面前。

•  方式三：在有的情况下，例如，在新房客源录带看页面并不是用户切换到该页面就弹出活动，而是用户点击某个按钮或滑动到某个位置等操作，才弹出某个活动，这时可以通过native触发，然后发送router路由消息来触发kePopLayer的弹出。  

与触发对应的是关闭机制，kePopLayer关闭方式包括四种情况：

• 情况一：当首页有一个kePopLayer，从首页切换到其他页面时，会关闭首页的kePopLayer；

• 情况二：业务方还可以通过服务端推送im消息进行关闭；

• 情况三：kePopLayer还为H5提供了Close API，H5浮层的H5页面可以通过调用该API来关闭kePopLayer； 

• 情况四：业务方也可以在业务流程结束时，直接调用router来关闭弹窗。 

此外，我们还支持页面豁免配置。有一些特殊场景，比如直播页面、支付页面等提供豁免配置，在这些页面可配置不弹出浮层。

4.3.3 缓存策略

我们监听hook页面进出，来展示对应页面的浮层，因此对于服务端下发的浮层数据我们按页面维度来进行缓存。设计以“页面名称”为key，"页面浮层队列"为value的map类型存储结构。页面名称可以是activity、fragment、flutter、H5的页面名称。  

由于同一个浮层，可以配置在多个页面投放，我们设计有n个页面投放该浮层我们创建n个对象，插入到各个页面的缓存队列中，把这几个对象的唯一id保持一致，若同一个浮层被关闭，其对应的其他的对象也不再展示。缓存结构如下图：其中弹窗b在配置在多个页面投放。  

4.3.4 动态优先级排序方案

所有的浮球、弹窗浮层下发遵循优先级排序，每个页面的浮层优先级队列如下：

服务端下发的多个浮球，叠加展示，有多少展示多少，浮球之间优先级不做要求。现有弹窗类型为native弹窗、H5弹窗，全部遵循优先级以one by one 形式展示，即完成一个弹窗流程当前弹窗关闭后，再按优先级展示下一个。

图（1）~（5）展示了客户端在收到push推送的浮层数据（浮球x，弹窗y，弹窗z）后，按照其配置弹出的页面（页面x，any页面）及优先级顺序插入对应页面的缓存队列中并按优先级动态排序进行展示的过程。

图（6）~ （7）展示了当用户完成弹窗y所对应的业务后，关闭弹窗y，回到页面x后重复之前的排序继续展示下一个最高优先级弹层的过程。

4.3.5 kePopLayer的性能

05 业务落地场景

1、随机弹人脸

对于风控团队提出的需求：在检测到风险时，希望能够实时地去引导用户去做人脸识别进行风控验证的需求，我们支持了”随机弹人脸的风控弹窗“，能够在风控服务端检测到风险时，实时在任意页面下发弹窗打断用户的操作，进行人脸验证。

2、反垄断实时上线 

对于新房业务：09月17日收到政府监管要求，需要在十一假期前后，报备作业页面发布“结佣告知”主动通知，降低佣金相关风险。时间紧迫，若紧急修改报备这类重度核心作业模块，风险很高，采用我们的全局浮层投放能力，不用修改代码，只需经过投放测试，即可上线，完成需求。

3、信用分规则触达

信用分规则涉及到经纪人自身的利益，要宣讲到位，因为信用分规则触达不到位，导致仲裁赔付40w+，所以需要使用投放能力进行触达经纪人，与其他供应商谈下来要花10w+，所以后来使用了我们全局浮层的能力进行投放，不仅完成了触达还节省了成本。

4、全国全量经纪人合规承诺签收

品质的业务方提了一个合规承诺书签署需求，面向全量的40万经纪人去签署。使用了我们的全局浮层的投放能力，大概10天，40万经纪人，签收比率达到80%。

5、红星任务“重庆经纪人象限项目”投放

通过分析经纪人的商机量以及商机转化率，将经纪人划分在不同的象限，比如高商机高转化、高商机低转化、低商机高转化和低商机低转化。先前城市已经在线下宣导透传了两三个月，但是从线下的反馈，经纪人很多还是不知道这个项目是什么，后来通过我们平台的投放能力来帮助城市触达经纪人，从数据上来看，曝光率已经达到90%，经纪人也开始来咨询城市了。

6、房江湖客源隐号录入引导浮层

在进行隐号录入时有提示引导浮层告知经纪人，快捷高效录客。

7、商户加盟合作到期A+弹窗提醒

二手商户加盟合作临到期在A+上提示弹窗。

06 总结

目前为止，全局浮层已经接入了Link、A+、21世纪、房江湖、DE（驱驰引擎）、D+、案场、寓江湖、必行等项目当中，各方面都带来了很大的收益： 

1、效率提升

（1）研发效率的提升：

• 之前的弹层开发由Android、iOS双端开发, 转为H5开发，减少一半开发成本，后期随着前端低代码的应用，H5的研发成本也会降低。      

• 业务自身形成闭环，链路上少了一个环节，大大减少了沟通成本和联调成本，尤其对于复杂业务。        

• 提供了统一的机制，所有的场景实现了一次投入重复使用。      

（2）运营效率的提升： 

• 从提前一个版本进行排期，到随时开发, 随时上线，需求从提出到上线的时间由30天以上缩短为3天以内。        

• 随着流程改善和前端低代码的模板不断丰富，从运营提出需求到最终上线有望从几天缩短到几小时。

2、质量提升

• 运营活动是多变的、不稳定的，如果耦合在核心业务流程里，运营活动的上线、下线或变更都会对核心业务造成影响，把稳定的核心业务和不稳定的弹层业务进行了解耦，增强了系统的稳定性。   

• 各自业务开发水平参差不齐，也不会对性能有太多关注，公司内部统一成一套，每次只需要修改一处，而且可以不断迭代优化。 

3、体验提升

• 版本升级：对于B端来说，遇到紧急或重要事件就让经纪人强制升级版本，体验会非常差，对于C端来说，下载渠道来自应用市场，需要审核，不允许应用内升级，用户可以长期不升级，即使有部分动态化UI能力，跟H5相比也有局限性。提前预埋能力对体验的提升非常重要。     

• 频率和优先级控制：业务自己开发弹窗并且投放，业务之间互相无感知，会造成弹窗过多、优先级无法统一控制等问题。 

4、赋能业务

• 功能场景的完善，为业务创新提供更多的可能性。       

  例如：顶部通知公告，底部广告位，挂角，用户调研，浮窗通知公告，新功能引导页，指定页面置灰，任何页面红包雨等等，h5页面可自定义支持各种业务场景。      

• 商机转化：和用户行为结合，沉淀和提炼数据规则，比如用户停留在一个房源较久，或者反复查看，说明比较感兴趣，这时弹出一个优惠券，就有可能为成交加码。

最后，特别指出下，目前业务方用到的大部分是弹窗或浮层的展示，H5变换下样式就可以支持更多场景，比如新功能引导、无干扰的页面级的用户调研、广告位、特定的通知等，有待于我们更多去应用，才能更大程度上提高效率。