云音乐如何「搭」出新首页

如今可视化搭建、低代码等通过拖拉拽生产页面的方案已经很常见，然而它们大多用于活动页搭建、中后台 CURD 场景等相对来说非核心的业务场景，主要原因是 C 端核心场景对于性能、灵活性等方面都有非常高的要求，大部分基于搭建的系统难以满足。

云音乐在过去半年到一年的建设中，建设了从搭建 UI 到投放数据的灵渠搭建能力，并在新首页改版中完全覆盖了新版首页发现流、音乐流两个流量最大的核心页面和 26 个全部模块，可以说新版首页完全就是「搭」出来的。

本文将介绍我们如何通过可视化搭建系统支撑云音乐新版首页这样的核心场景，并满足其对性能、动态化和精细化运营的诉求。从中也可以看到可视化搭建、低代码等解决方案理论上能够覆盖的场景比想象中更大。

业务背景

在云音乐新框架改版中，发现流和音乐流是两个核心的信息流页面。

首页作为最大的流量入口，不同的垂直业务都会在首页上提需新增模块，从而技术上面临几个核心问题：

无法动态化，依赖发版：我们尝试过在首页使用 ReactNative 卡片来实现动态化，然而这导致首页的性能劣化严重。所以首页新增模块仍然依赖发版，这导致业务的迭代周期很长，一次完整的价值验证常常需要经过多次「双端开发-发版-放量-数据验证」的过程。
策略不能有效复用：流量分发场景投放的卡片往往是伴随着很多规则和策略的，例如针对某个人群投放、在某些时段下投放等等。这些策略大部分从原子角度看是重复的，但是不同业务却总是需要重复开发。
视图层数据和服务端不解耦，服务端总是需要介入变更：由于负责视图层 UI 和数据接口的开发同学往往是前后端不同职能的，一旦 UI 发生改变，就很可能需要服务端一起介入变更，这导致沟通协调的成本很高。
不同业务的配置后台能力需要重复建设：流量分发场景分发的资源和内容来自于不同垂直业务，而这些业务各自都需要通过自己的配置后台提供各种运营配置能力，从而最终支撑内容的投放，而这些能力建设很多相互重复。

搭投一体的需求交付流程

在常规的需求交付链路中，不同角色各司其职完成不同部分的开发，然后联调、测试并且发版上线。

这样整个链路的沟通成本、重复开发成本、以及发版、放量周期带来的时间成本都非常高。

而在云音乐新版首页的交付中，我们在灵渠平台上通过结合搭建、投放、客户端动态化 DSL 引擎的能力建设，把整个需求交付链路重构为只需要一名开发（一般是大前端开发）就能独立完成的过程。

在需求交付后，灵渠平台也能直接通过开发者的配置提供面向运营的配置表单，提供通用的资源、内容、计划配置等通用能力。

动态化 & 性能

今天动态化能力已经是各大 App 厂商不可或缺的基础能力，相比于跨端技术能够把 Android、iOS 双份开发人力缩减到一份，动态化能力允许我们在不经过「发版-放量」的过程快速进行迭代调整，对业务迭代和价值验证来说无疑更加重要。

然而，动态化能力的增强几乎同时就意味着性能上的损耗，我们可以从当前主流的几种动态化方案的能力和其性能表现看出，并不存在一劳永逸能够满足所有场景诉求的动态化方案，我们需要针对我们的业务诉求做出合适的选择。

以首页为例，核心大流量场景往往需要给垂直业务场景分发流量，这种场景有几个特点：

性能要求很高：接近 Native 水平。
偏展示，若交互：此类场景往往会把流量分发到各个垂直业务，而不是在当前场景直接完成所有的消费。
快速调整：各类业务都需要在流量入口布点，同时迅速迭代来达到业务预期的数据效果所以对于流量分发类场景来说，客户端 DSL 是最合适的客户端动态化方案。

所以对于流量分发类场景来说，客户端 DSL 是最合适的客户端动态化方案。

在具体的客户端 DSL 方案上，我们没有从头造轮子，而是基于优酷团队开源的 GaiaX 做了上层封装和定制开发。对接了云音乐内部的生态（如路由、RPC 等）。同时在此基础上封装了大量通用容器，如弹窗容器、RN 混排容器、图片分享容器等等。

可视化搭建

引入客户端 DSL 后，随之而来的问题是其带来的学习成本，GaiaX 的 DSL 本质上由三个文件组成。

这样带来的问题是，DSL 的代码本身可读性并不好，和开发者过去熟悉的技术栈都不一致，会带来非常高的开发成本。于此同时，我们也需要建设对应的配套工具（例如预览、调试、发布流程）来支持开发者开发。

GaiaX 显然也意识到了这个问题，提供了 GaiaX Studio 这个基于可视化搭建的 DSL 开发工具，但可惜的是这个工具并不开源，我们无法在此基础上开发我们需要的能力（例如对接云音乐的换肤、RPC 等等）。

于是，开发一套具备可视化搭建能力的 DSL 搭建系统，同时在这个系统上去建设开发者配套能力就成为我们的首选项。

最终的产品形态是我们建设了一套在线的可视化搭建系统，同时支持直接扫码预览、错误检查、内部系统（换肤、图片素材管理）对接、发布流程、数据 Mock 等等开发者配套，使得不同技术栈的开发者（主要是大前端同学）可以直接在线通过拖拉拽直接开发出可投放的 DSL 卡片。

数据源如何解耦

无侵入性进行数据编排，通常的做法有 SPI，Groovy脚本，第三方系统 (类似选品系统平台只提供对接)

SPI 不灵活 - 不能满足各式各样的述求，不能满足数据转换需求
Groovy脚本 - 对RPC调用不适用
第三方系统 - 需要重新建设

考虑到云音乐已经有一套完整的BFF能力, 具体可以参考之前发布的文章基于GraphQL的云音乐BFF建设实践。我们决定使用其能力，在搭建端可以选择BFF生产的对应数据源，并且在用户访问时自动完成对应的数据组装。

同时在搭建端我们也提供了可视化的数据字段选择、mock 等能力，通过这种方式让 UI 视图的开发者自己也可以开发对应 UI 字段的数据源后端。而业务后端的开发者只需要提供底层 service 即可。

卡片如何投放出去

完成了卡片的开发后，下一个问题是卡片如何被投放出去。

流量分发场景需要通过精准的目标受众定位、选择合适的投放形式、渠道和时机、设定合适的投放内容和时间，来实现投放效果最优化和投放效益的最大化。通过有效的投放策略，内容投放平台可以帮助提高资源曝光率、点击率和转化率，从而实现内容投放效果的最大化。

灵渠作为投放平台，提供了多种投放策略，以及策略规则组合配置。基于灵渠平台的策略能力，我们可以把「某个位置上面向某个人在某个时间应该出什么样的 UI」也通过策略化的能力承载。

灵渠平台具有多种投放策略，如客户端版本、人群圈选、频控策略、AB实验等，并且支持通过bff开发业务自定义策略，做到了策略的复用性以及灵活性。

整页混排容器

上面所说的都是 DSL 卡片从搭建、投放到最后端上渲染出来的链路，但并非整个页面都是由 DSL 搭建的，页面框架本身还需要考虑下拉刷新动作、数据缓存管理、列表 cell 复用等等问题。

而这些需求不仅仅是首页才有，在大部分信息流场景都是存在的，所以我们在端上封装了整页混排容器，把信息流页面大部分通用能力都封装到一起。之所以要考虑混排，是因为有时候 DSL 不能完全满足某些业务模块的诉求，所以我们允许在部分模块上使用 Native 或者 React-Native 进行开发。

质量建设

在承载了首页这样的大流量核心场景后，模块的数量、复杂度、参与人数的增加，都给稳定性带来更多的挑战。虽然引擎和系统本身的稳定性很少出问题，但是开发者在使用平台时却经常产生很多意料之外的问题。

灵渠搭建平台在不同阶段提供了不同的质量保障：

开发阶段，提供了预览功能，能通过mock数据感知样式的变化。
发布阶段，发布时候会显示距上一次发布时，模板的变更情况，哪些人员进行了变更。并且发布具有环境概念，只有发布到对应环境，对应环境才会有数据，做到了环境隔离。
上线阶段，提供了严格的卡点功能，必须通过双端的真机扫码预览后才可以发布，对于扫码中有异常的情况，不予通过。
上线后，灵渠投放平台拥有数据的监控，以及流量波动情况有告警通知出问题时，模板提供了模板回滚能力，能快速止血。并且提供发布记录对比，能快速对比搭建的UI模板差异。

在质量保证上灵渠平台还提供了配置资源位兜底，在下游发生一些异常等其他情况拿不到数据时候，能继续透出模板数据。配置如下图所示。另外还支持用户纬度的兜底数据配置，满足新首页推荐流中个性化模块兜底的场景，如最近播放。