SDUI（服务器驱动 UI）开发感受

背景

最近在参与公司的一个 SDUI 项目，参见 ：初识 SDUI（Server-Driven UI，服务端驱动 UI）_兜兜小猎犬的博客-CSDN博客）目录背景什么是 SDUI？为什么要用 SDUI？SDUI 的缺点和局限服务端的返回数据庞大，传输时间长开发和测试难度增加谁在用 SDUI？Spotify爱彼迎Lyft小结背景最近参与了公司的一个项目，要把公司的网站和 APP 整个重写一遍（我只参与其中 Web 的部分），并且新的系统是基于 SDUI（Server-Driven UI，服务端驱动 UI）的。其实在公司内部的文档中，我们的新架构被称为 Widget Architecture，但我搜了一下，发现其实 SDUI 才是真正准确的概念。什么是https://blog.csdn.net/VoisSurTonChemin/article/details/121067639

参与项目开发已经半年，项目也马上上线了。来说一下体会。

常见问题

问题 1：UI 逻辑真的完全由服务端控制吗？

事实上，并非客户端的每一个 UI 细节都由服务端控制。比如，大部分样式仍然是客户端决定的，比如颜色、间距等细节。

比如服务端会说，给我在这里渲染一个 A 组件！客户端招办，但 A 组件的样式细节完全由客户端负责，服务端不会指定。为什么呢？因为样式细节那么多，都由服务端控制的话太麻烦了。

也有少数例外，比如同样的 A 组件在不同地方的样式是不同的，这时候就需要服务端来指定样式了。我遇到过一次，同一个组件在不同页面有不同的标题字体，于是就让服务端指定标题字体。但就为了这个标题字体，还得去改 schema，先得在服务端的 schema 里加上这个属性，才能让服务端指定，很麻烦。

问题 2：真的能做到客户端不发版就改动 UI 逻辑吗？

上篇文章说过，SDUI 最大的公认优点就是，通过修改服务端返回结果，客户端不发版就可以实现 UI 逻辑的改动，从而方便 A/B 实验和快速迭代。

不过，上面也提到了，大部分样式都不是服务端控制的。所以如果你想改颜色、间距一类的东西，还是得客户端发版才行。当然，如果你预计某个地方的样式会频繁改动，那么把它改成服务端控制也是没问题的。

但即便只是简单的组件重排列，通常也会涉及一些样式改动。比如替换组件之后，组件之间的间距很可能需要调整。如果没有提前把相应样式交给服务端控制，那么就还是需要客户端发版。

当然，某些特定页面（比如推荐页面）还是非常适合客户端不发版直接修改 UI 的，毕竟推荐卡片长的都差不多，如果只是想多加一个主题推荐卡片，那会是很容易的。

问题 3：SDUI 项目的代码难读吗？

不难读，事实上还很好读，只要你理解了架构。

因为有了 BFF，客户端请求服务端只通过唯一接口，返回结果中集中了页面布局和业务数据，而且这些数据都是按照特定 schema 组织的，清晰易懂。结果里的每个组件都有其相应的实现，就像搭积木一样，把复杂页面分解成了比较简单的单元。

相反，现在再去读传统前端代码，会觉得很杂很乱，很多数据是通过不同接口获取的，数据流动环节很多。如果没看过相应 PRD 或接口文档会很懵。

小结

有点事情要出门，今天先写这么多，回头来补充。