SDUI

最近，端侧 AI 又不是重点项目了，转而去做 Markdown 组件 和 SDUI 卡片了。Markdown 在 Android 侧的渲染多多少少都有点问题，虽然有各种开源库做了很多处理，但是各大公司内部的聪明的大脑袋们，总会添加各种奇怪的规则，来彰显我方的不同，直接拿开源库来使用是万万不能的

说到这里，这个项目开始的状态就比较搞笑。具体就是，上位者 yy 了一下，觉得用蚂蚁的 markdown 就好了，默认还支持了三端！我们只要简单接入一下就万事大吉了。
当接入的时候，发现蚂蚁的这个 markdown 甚至没有发布 aar，底层依赖的是 markwon 开源库，和 自己的一部分魔改的打字机渲染，各类 span 等等，代码里甚至还充斥着各种明显是 debug 看代码执行路径的 log 等等
于是，我就在这样的情况下，开始基于这个勉强可以运行的 markdown 组件开发，开始了屎山的雕琢

markdown 的事情就不多说了，坑是一个接着一个，需求是一个比一个定制：

长图不能太长、行内图和普通图不能一样、图片的各种样式，文字长按要拖拽选中、要有选择放大镜、要有弹出的定制菜单、一个 textview 内有多个段落的话每个段落都要可以长按选中、背景和文字高亮等等…(此处省略一万字)

最让我觉得反直觉的是 SDUI，这玩意就是 DSL 卡片借尸还魂。在我刚毕业的时候就搞了这种 dsl 卡片。这种卡片的局限性很大，只能做静态展示，或者绑定简单的一次性的事件，无法或者很难去实现逻辑相关的问题，更别提属性动态刷新、数据绑定和动画等等的问题

所以，当时刚毕业的时候探索了一下 js engine 去执行逻辑，但是再往后呢？不就是 Weex/RN 等等的了么？重复的轮子罢了

现在，因为 AI Agent 火了，AI 可以输出有一定格式的数据了，那就可以让它输出 DSL，然后交给端上渲染了，摇身一变叫做 SDUI，还不是 A2UI 那种概念，SDUI 仅仅是 DSL 描述 和 静态展示，也咩有多轮上下文，具体的 DSL 也是已经设计和验收好的，并不是真的由 Agent 去自己生成

这个技术本身难度不高，但是扛不住业务乱用。底层依然是基于 yoga layout engine 和 flexbox 语法来描述布局，然后双端或者说三端埋好基础组件和样式解析。

理想是丰满的，现实是骨感的。只做静态展示是问题不大的，但是有一些副作用，特别是插在列表里的时候。

如果你在主线程解析，那么 UI 越复杂解析越慢，而且因为使用 json/xml 还是未压缩的格式，远远比系统的 xml 更慢，掉帧。 如果你在子线程解析，那么 UI 异步解析，会出现突然跳动，如果你做占位图，但是你又不知道具体有多高，还可能要解析图片等等等···

更可怕的是，当业务方拿到这个以后，特别是业务方老板，很容易直接“颅内高潮“，那我们的 UI 都用 SDUI 来写，还能动态下发，出了兼容性问题也是 SDUI 组件问题，完全甩手掌柜。然后做着做着就会要求：要有数据绑定、要有交互响应、要有业务逻辑，最终就变成了 RN 🤣

所以，在 RN 已经大规模使用的情况下，重新做一套轻量的 DSL 卡片的意义，我个人认为其实不是很大···但是如果没有新的轮子，何以晋升，中国职场就是如此魔幻···

最近又发现，其实 google 官方甚至在搞 markdown 组件，感觉未来真的不太需要客户端开发去做一些 UI，当然了，国内的话，完全看谁的屁股坐在老板椅上

我现在的经历就非常的割裂，我们的技术选型是：no cross-platform

三端代码，写三份，不用跨平台，一端写完，通过 ai 转码，转为三端，这个想法我也不知道意义是啥，为何如此坚持。如果跨平台的话，不是省过了转码这个步骤么？

总之，如今有了 AI 以后，人人都是专家，各有各自想法，但是缺乏实际工程经验的人做出的决策，总是会很奇怪···