移动端渲染(Mobile DSL Runtime)
这不是一个 Java SPI。 AuraBoot 没有
MobileRendererExtension、MobilePlatform之类的插件扩展点。移动端把同一份 Page schema 用原生 runtime 渲染,渲染能力以平台DslRegistry为真源。下面是真实机制。
同一份 schema,原生渲染
你在 Page Designer 里拖出来的页面 schema(kind / blocks / 字段),在 iOS / Android 上由移动 DSL runtime 原生渲染——不是 WebView 套壳,也不需要为移动端单独建模。
能力真源 = 平台 DslRegistry
每一种 DSL 渲染能力(BlockType / ChartType / PageKind / FieldType)的唯一真源是平台 Web 的 DslRegistry(Java)。移动 app 把这些重声明为原生枚举(iOS Swift 的 MobileBlockType 等),按 code 一一对应到原生渲染器。
要让移动端支持某个 Block / Chart / 字段类型,就是在移动 app(Swift / Kotlin)里实现一个原生 renderer,其 code 对齐 DslRegistry。
静默 fallback 风险 + parity 门禁
如果 Web 的 DslRegistry 新增了能力、移动端没跟上,移动渲染器会静默降级:MobileBlockType(rawValue:) == nil → UnsupportedBlockView;未知 chart → 一律退化成 bar。这种漂移(blockType 17 vs 30)正是历史上一轮 iOS gap 的根因。
为此有一道 parity 门禁 check-dsl-mobile-parity.mjs(apps/ios/scripts/):
- 把已提交的 Web 能力快照与 iOS 原生枚举对比,任何 Web 有、iOS 既不渲染也未显式声明的 code,直接 fail CI;
- 显式的有意分歧写进
dsl-mobile-parity.allow.json(标nativeElsewhere/desktopOnly/deferred),不允许静默; --refresh从 OSSDslRegistry.java重生成快照,--check-snapshot检测跨仓漂移。
典型错误
- Web 涨能力没同步移动端:产生静默 fallback(
UnsupportedBlockView/ blanket bar),而不是报错。靠 parity 门禁在 CI 拦住。 - 裸数量比对:只比「Web 30 vs iOS 28」会漏——必须按真实 code 集合比对(哪个 code Web 有而 iOS 没有)。
- 把移动渲染当 Java 扩展点找:没有
MobileRendererExtension——renderer 在移动 app 里,平台只提供 schema 与DslRegistry真源。
相关
- 自定义页面 Block —— Block 类型与前端渲染注册表
- Page 与布局 —— 页面 schema 结构
- 系统总览 —— 一份 schema 渲染到多端