dual-engine-transport-simulation

1. 实验目标

用纯 Java CLI 仿真「双 WebView 引擎运输层抽象」（对应 docs/05-bridge-hybrid/10）：

• 用一个轻量 shim 屏蔽底层 WebView 实现差异（能力全的引擎 vs 回退引擎）
• H5 只调用统一协议 shim.postMessage，不感知底层是哪种引擎
• 由 useInApp 标志 + shim 内部转调吸收差异；注入时机差异由 waitForBridge 兜底

2. 工程要点

• BridgeTransport 接口：两种引擎实现（InAppTransport / FallbackTransport），注入时机不同
• BridgeShim：H5 统一入口，内部转调当前运输层
• 关键点：H5 不感知引擎；差异收敛到一个 shim + 一个标志位

3. 关键实现速览

// shim 统一 H5 调用入口，内部转调当前运输层
static class BridgeShim {
    BridgeTransport transport;
    boolean useInApp; // 等价于 window.__USE_INAPP_TRANSPORT__
    String postMessage(String handler, String payload) {
        return transport.call(handler, payload); // H5 不感知底层引擎
    }
}

为什么看这段：这就是「运输层抽象」的最小骨架——H5 永远只认 postMessage，引擎差异被封装在 transport 后面；换引擎只需换 transport 实现，H5 代码零改动。

4. 运行方式

cd labs/java/bridge-hybrid/dual-engine-transport-simulation
javac -d out src/DualEngineTransportSimulation.java
java -cp out DualEngineTransportSimulation

5. 预期控制台输出

=== 场景1：主键引擎就绪，shim 走 inappwebview ===
  window.__USE_INAPP_TRANSPORT__ = true
  shim.postMessage('getDeviceInfo','{}') -> [inapp]getDeviceInfo({})
=== 场景2：回退引擎未就绪，shim 仍走统一协议（注入时机差异）===
  window.__USE_INAPP_TRANSPORT__ = false
  运输层 ready=false（onPageStarted 才注入，H5 需 waitForBridge）
  shim.postMessage('getDeviceInfo','{}') -> [fallback]getDeviceInfo({})
=== 结论 ===
  · H5 只调用 shim.postMessage，不感知底层是哪种 WebView
  · 差异由 useInApp 标志 + shim 内部转调屏蔽；注入时机差异由 waitForBridge 兜底

6. 常见误区

误区	实际情况
H5 直接调原生 callHandler 就行	多引擎并存时 H5 必须走统一 shim，否则每换引擎就要改 H5
注入时机不重要	回退引擎在 onPageStarted 才注入，H5 需用 waitForBridge 兜底，否则早期调用丢失

7. 对应知识库文档

• 理论主文档：双 WebView 引擎运输层抽象

8. 完整源码

• DualEngineTransportSimulation.java