移动端渲染(Mobile DSL Runtime)

这不是一个 Java SPI。 AuraBoot 没有 MobileRendererExtensionMobilePlatform 之类的插件扩展点。移动端把同一份 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:) == nilUnsupportedBlockView;未知 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 从 OSS DslRegistry.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 真源。

相关