整理中文文档结构与索引
This commit is contained in:
382
doc/experience/原生与H5桥接规范.md
Normal file
382
doc/experience/原生与H5桥接规范.md
Normal file
@@ -0,0 +1,382 @@
|
||||
# 原生与 H5 Bridge 协议草案
|
||||
|
||||
本文档定义当前项目中 **原生小程序** 与 **H5 定制内容页** 之间的基础通信协议。
|
||||
|
||||
目标：
|
||||
|
||||
- 让 H5 能获取当前游戏上下文
|
||||
- 让 H5 能请求原生能力
|
||||
- 让原生能接收 H5 的结果回传
|
||||
- 保持协议简单、稳定、可版本化
|
||||
- 为后续拍照、录音、小游戏、结果页等扩展留出空间
|
||||
|
||||
---
|
||||
|
||||
## 0. 当前适用前提
|
||||
|
||||
本规范当前属于：
|
||||
|
||||
- 协议与实现预留
|
||||
- 容器与回退机制先行
|
||||
|
||||
最近排查已经确认，当前最初使用的是**个人主体**小程序。
|
||||
在这个前提下，`web-view` 能力本身可能受限。
|
||||
|
||||
因此：
|
||||
|
||||
- Bridge 规范仍然应该先定义
|
||||
- 容器页与回退机制也应该先实现
|
||||
- 但在企业主体审核通过前，不应把 H5 接入是否成功完全归因于 bridge 代码本身
|
||||
|
||||
详细说明见：
|
||||
|
||||
- [platform-capability-notes.md](D:/dev/cmr-mini/doc/debug/平台能力说明.md)
|
||||
|
||||
---
|
||||
|
||||
## 1. 协议原则
|
||||
|
||||
### 原则 1：Bridge 要版本化
|
||||
|
||||
建议先固定：
|
||||
|
||||
- `content-v1`
|
||||
- `result-v1`
|
||||
|
||||
后续升级时：
|
||||
|
||||
- 新增 `content-v2`
|
||||
- 新增 `result-v2`
|
||||
|
||||
不要直接改旧协议。
|
||||
|
||||
### 原则 2：请求能力最小化
|
||||
|
||||
先只开放真正需要的能力，不要一开始做成“大而全总线”。
|
||||
|
||||
### 原则 3：原生控制核心状态
|
||||
|
||||
Bridge 只能做：
|
||||
|
||||
- 展示
|
||||
- 上报
|
||||
- 请求能力
|
||||
|
||||
不能让 H5 直接改比赛核心状态。
|
||||
|
||||
### 原则 4：消息必须可回执
|
||||
|
||||
每个请求都应有明确成功/失败返回，不允许 H5 靠超时猜测。
|
||||
|
||||
---
|
||||
|
||||
## 2. 通道模型
|
||||
|
||||
建议统一按“请求 / 响应 / 事件”三类消息组织：
|
||||
|
||||
- `request`
|
||||
H5 请求原生能力
|
||||
- `response`
|
||||
原生返回能力执行结果
|
||||
- `event`
|
||||
原生主动推送状态变化
|
||||
|
||||
推荐消息外壳：
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "req-001",
|
||||
"channel": "request",
|
||||
"type": "getGameContext",
|
||||
"payload": {}
|
||||
}
|
||||
```
|
||||
|
||||
响应：
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "req-001",
|
||||
"channel": "response",
|
||||
"type": "getGameContext",
|
||||
"ok": true,
|
||||
"payload": {}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 原生注入给 H5 的基础上下文
|
||||
|
||||
建议至少包含：
|
||||
|
||||
```json
|
||||
{
|
||||
"bridgeVersion": "content-v1",
|
||||
"eventId": "sample-score-o-001",
|
||||
"mode": "score-o",
|
||||
"sessionId": "session-001",
|
||||
"sessionStatus": "running",
|
||||
"controlId": "control-3",
|
||||
"controlKind": "control",
|
||||
"title": "湖边步道",
|
||||
"body": "这里适合短暂停留观察周边地形。",
|
||||
"theme": "default-race"
|
||||
}
|
||||
```
|
||||
|
||||
对于结果页，可扩展为：
|
||||
|
||||
```json
|
||||
{
|
||||
"bridgeVersion": "result-v1",
|
||||
"eventId": "sample-score-o-001",
|
||||
"mode": "score-o",
|
||||
"sessionId": "session-001",
|
||||
"summary": {
|
||||
"title": "比赛结束",
|
||||
"heroValue": "120",
|
||||
"rows": []
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. H5 -> 原生：第一阶段推荐动作
|
||||
|
||||
建议第一阶段只支持这几个：
|
||||
|
||||
### `close`
|
||||
|
||||
作用：
|
||||
|
||||
- 关闭当前 H5 页面
|
||||
|
||||
示例：
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "req-001",
|
||||
"channel": "request",
|
||||
"type": "close",
|
||||
"payload": {}
|
||||
}
|
||||
```
|
||||
|
||||
### `getGameContext`
|
||||
|
||||
作用：
|
||||
|
||||
- 让 H5 主动获取最新上下文
|
||||
|
||||
### `takePhoto`
|
||||
|
||||
作用：
|
||||
|
||||
- 请求原生拍照
|
||||
|
||||
### `recordAudio`
|
||||
|
||||
作用：
|
||||
|
||||
- 请求原生录音
|
||||
|
||||
### `submitResult`
|
||||
|
||||
作用：
|
||||
|
||||
- 把 H5 内的任务结果、表单或作品结果提交回原生
|
||||
|
||||
示例：
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "req-002",
|
||||
"channel": "request",
|
||||
"type": "submitResult",
|
||||
"payload": {
|
||||
"taskId": "photo-task-1",
|
||||
"status": "completed",
|
||||
"assetId": "img-001"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 建议第二阶段可扩展动作
|
||||
|
||||
等第一阶段跑稳后，再逐步加入：
|
||||
|
||||
- `uploadImage`
|
||||
- `uploadAudio`
|
||||
- `getLocation`
|
||||
- `openMiniGame`
|
||||
- `submitForm`
|
||||
- `share`
|
||||
- `restartSession`
|
||||
|
||||
这些先不要第一阶段全开。
|
||||
|
||||
---
|
||||
|
||||
## 6. 原生 -> H5：统一返回结构
|
||||
|
||||
建议统一返回：
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "req-002",
|
||||
"channel": "response",
|
||||
"type": "takePhoto",
|
||||
"ok": true,
|
||||
"payload": {
|
||||
"assetId": "img-001",
|
||||
"url": "https://example.com/assets/img-001.jpg"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
失败时：
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "req-002",
|
||||
"channel": "response",
|
||||
"type": "takePhoto",
|
||||
"ok": false,
|
||||
"error": {
|
||||
"code": "USER_CANCELLED",
|
||||
"message": "用户取消拍照"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. 原生 -> H5：推荐事件
|
||||
|
||||
原生可按需主动推送轻量事件：
|
||||
|
||||
- `contextUpdated`
|
||||
- `sessionFinished`
|
||||
- `sessionExited`
|
||||
- `networkChanged`
|
||||
|
||||
但第一阶段要克制，避免高频推送。
|
||||
|
||||
不建议第一阶段主动高频推：
|
||||
|
||||
- GPS 实时位置流
|
||||
- 指北针实时角度
|
||||
- HUD 高频数字
|
||||
|
||||
这些不适合让 H5 主导。
|
||||
|
||||
---
|
||||
|
||||
## 8. 错误码建议
|
||||
|
||||
建议第一阶段统一几类错误：
|
||||
|
||||
- `USER_CANCELLED`
|
||||
- `PERMISSION_DENIED`
|
||||
- `NETWORK_ERROR`
|
||||
- `UNSUPPORTED_ACTION`
|
||||
- `BRIDGE_NOT_READY`
|
||||
- `INTERNAL_ERROR`
|
||||
|
||||
这样 H5 侧更容易统一处理。
|
||||
|
||||
---
|
||||
|
||||
## 9. 安全与边界
|
||||
|
||||
### 9.1 H5 不直接改核心比赛状态
|
||||
|
||||
H5 不能直接决定：
|
||||
|
||||
- 是否打点成功
|
||||
- 是否跳点成功
|
||||
- 是否比赛结束
|
||||
|
||||
### 9.2 H5 只能请求能力
|
||||
|
||||
原生决定是否执行：
|
||||
|
||||
- 拍照
|
||||
- 录音
|
||||
- 上传
|
||||
- 页面关闭
|
||||
|
||||
### 9.3 Bridge 能力按页面类型开放
|
||||
|
||||
例如：
|
||||
|
||||
- 内容页开放 `takePhoto`
|
||||
- 结果页不一定开放
|
||||
|
||||
后续可做按 `bridgeVersion` 或 `pageType` 的能力白名单。
|
||||
|
||||
---
|
||||
|
||||
## 10. 第一阶段推荐支持范围
|
||||
|
||||
建议第一阶段只正式支持：
|
||||
|
||||
- `close`
|
||||
- `getGameContext`
|
||||
- `takePhoto`
|
||||
- `recordAudio`
|
||||
- `submitResult`
|
||||
|
||||
这样足够承接：
|
||||
|
||||
- 文创详情
|
||||
- 拍照任务
|
||||
- 语音留言
|
||||
- 结果页回传动作
|
||||
|
||||
---
|
||||
|
||||
## 11. 不建议第一阶段支持的内容
|
||||
|
||||
先不要一上来开放：
|
||||
|
||||
- 任意写比赛状态
|
||||
- 任意切换玩法
|
||||
- 任意修改地图行为
|
||||
- 任意控制打点
|
||||
- 高频实时 telemetry 推送
|
||||
|
||||
这些都属于核心状态，应该继续由原生掌控。
|
||||
|
||||
---
|
||||
|
||||
## 12. 当前建议实施顺序
|
||||
|
||||
1. 先实现一个通用 H5 容器页
|
||||
2. 先跑通 `content-v1`
|
||||
3. 先支持 5 个最小动作
|
||||
4. 再跑通一个简单结果页
|
||||
5. 最后再扩桥接能力
|
||||
|
||||
---
|
||||
|
||||
## 13. 当前建议结论
|
||||
|
||||
Bridge 的第一阶段目标，不是做成万能总线，而是：
|
||||
|
||||
**稳定承接定制内容页与结果页的最小需求。**
|
||||
|
||||
先把：
|
||||
|
||||
- 关闭
|
||||
- 获取上下文
|
||||
- 拍照
|
||||
- 录音
|
||||
- 结果提交
|
||||
|
||||
这 5 条做稳，就足够支撑第一波客户定制需求。
|
||||
|
||||
512
doc/experience/混合体验架构方案.md
Normal file
512
doc/experience/混合体验架构方案.md
Normal file
@@ -0,0 +1,512 @@
|
||||
# 混合体验架构方案
|
||||
|
||||
本文档用于说明当前项目在 **结果页、文创内容页、客户定制体验页** 上的长期承载方案。
|
||||
|
||||
核心结论：
|
||||
|
||||
**不做“原生还是 H5 二选一”，而是采用三层混合方案：**
|
||||
|
||||
- 原生模板
|
||||
- 原生有限 DSL
|
||||
- H5 扩展页
|
||||
|
||||
当前阶段已经进一步定案：
|
||||
|
||||
- **即时内容弹窗：原生**
|
||||
- **详情页 / 互动任务页：H5**
|
||||
- **结算页：原生兜底 + H5 全屏增强**
|
||||
|
||||
---
|
||||
|
||||
## 1. 为什么需要混合方案
|
||||
|
||||
当前项目已经确认：
|
||||
|
||||
- 结果页经常会变
|
||||
- 打点弹出内容经常会变
|
||||
- 样式、内容、交互形式会随着客户需求变化
|
||||
- 有些内容还会带动作：
|
||||
- 拍照上传
|
||||
- 语音留言
|
||||
- 小游戏
|
||||
- 表单与任务
|
||||
|
||||
如果全部原生写死：
|
||||
|
||||
- 改版成本高
|
||||
- 每次都要改页面代码
|
||||
- 客户变化一多就会拖慢开发
|
||||
|
||||
如果全部交给 H5：
|
||||
|
||||
- 核心体验不稳
|
||||
- 地图主流程会割裂
|
||||
- 性能和权限整合更麻烦
|
||||
|
||||
因此最适合的方案是：
|
||||
|
||||
**核心高频体验保留原生，灵活变化部分分层处理。**
|
||||
|
||||
---
|
||||
|
||||
## 2. 总体结构
|
||||
|
||||
建议未来的体验承载层分成三层：
|
||||
|
||||
### 2.1 原生模板层
|
||||
|
||||
用于承接：
|
||||
|
||||
- 最小结果页
|
||||
- 最小内容卡
|
||||
- 高频、必须稳的体验页
|
||||
|
||||
特点：
|
||||
|
||||
- 结构固定
|
||||
- 数据可变
|
||||
- 主题可换
|
||||
- 性能最好
|
||||
- 原生能力最完整
|
||||
|
||||
### 2.2 原生有限 DSL 层
|
||||
|
||||
用于承接：
|
||||
|
||||
- 结构变化较多，但组件种类有限的页面
|
||||
- 结果页区块组合
|
||||
- 内容页区块组合
|
||||
|
||||
特点：
|
||||
|
||||
- 不是万能布局引擎
|
||||
- 只支持有限区块和有限顺序配置
|
||||
- 比固定模板灵活
|
||||
- 比 H5 更稳
|
||||
|
||||
### 2.3 H5 扩展层
|
||||
|
||||
用于承接：
|
||||
|
||||
- 强定制内容
|
||||
- 富图文内容
|
||||
- 品牌化包装
|
||||
- 富交互任务页
|
||||
- 定制结算页
|
||||
|
||||
特点：
|
||||
|
||||
- 自由度最高
|
||||
- 改版速度最快
|
||||
- 最适合客户高频定制
|
||||
- 但必须有原生兜底
|
||||
|
||||
---
|
||||
|
||||
## 3. 三层分别适合什么
|
||||
|
||||
## 3.1 原生模板适合
|
||||
|
||||
- 高频结果页
|
||||
- 高频内容卡
|
||||
- 游戏过程中的即时反馈页
|
||||
- 必须流畅、必须可离线的页面
|
||||
|
||||
示例：
|
||||
|
||||
- 最小顺序赛结算页
|
||||
- 最小积分赛结算页
|
||||
- 控制点原生内容卡
|
||||
- 默认结束页
|
||||
|
||||
## 3.2 原生有限 DSL 适合
|
||||
|
||||
- 区块顺序常变
|
||||
- 字段组合常变
|
||||
- 样式变化不至于重做到 H5
|
||||
|
||||
示例：
|
||||
|
||||
- 结果页：
|
||||
- 先显示成绩还是先显示摘要
|
||||
- 哪些统计项出现
|
||||
- 操作区放几个按钮
|
||||
- 内容页：
|
||||
- 是否显示图片
|
||||
- 是否显示引用说明
|
||||
- 是否显示附加说明区块
|
||||
|
||||
## 3.3 H5 适合
|
||||
|
||||
- 品牌化结算页
|
||||
- 长图文故事页
|
||||
- 原生内容卡上的“查看详情”页
|
||||
- 拍照上传任务
|
||||
- 语音留言页
|
||||
- 小游戏互动页
|
||||
- 活动专题页
|
||||
- 高自由度客户定制页
|
||||
|
||||
---
|
||||
|
||||
## 4. 边界原则
|
||||
|
||||
## 4.1 原生负责核心游戏体验
|
||||
|
||||
原生必须继续负责：
|
||||
|
||||
- 地图
|
||||
- GPS / 指北针 / 自动转图
|
||||
- 打点逻辑
|
||||
- HUD
|
||||
- 核心状态机
|
||||
- 最小结果页
|
||||
- 最小内容页
|
||||
|
||||
## 4.2 H5 只负责增强体验
|
||||
|
||||
H5 不应该负责：
|
||||
|
||||
- 打点是否成功
|
||||
- 比赛是否结束
|
||||
- 核心状态推进
|
||||
- 实时地图交互
|
||||
|
||||
H5 只负责：
|
||||
|
||||
- 内容展示
|
||||
- 任务互动
|
||||
- 品牌包装
|
||||
- 富交互增强体验
|
||||
|
||||
## 4.3 原生永远保底
|
||||
|
||||
无论 H5 是否接入，原生都必须保证：
|
||||
|
||||
- 打点后至少能看到原生内容
|
||||
- 结束后至少能看到原生结果页
|
||||
- H5 打不开时，主流程不受影响
|
||||
|
||||
## 4.4 不再尝试 H5 弹窗本体
|
||||
|
||||
真机验证后，当前项目已经明确：
|
||||
|
||||
- 小程序 `web-view` 不适合作为“原生弹窗里的局部 H5 内容区”
|
||||
- 它更适合作为整页/全屏体验容器来使用
|
||||
|
||||
因此这条边界正式定为：
|
||||
|
||||
- 原生内容卡负责即时弹窗体验
|
||||
- H5 不直接顶替原生弹窗
|
||||
- H5 只通过原生 CTA 进入详情页/任务页
|
||||
|
||||
---
|
||||
|
||||
## 5. 推荐的数据流
|
||||
|
||||
建议统一做成：
|
||||
|
||||
```text
|
||||
游戏状态 / 内容数据 / 结果数据
|
||||
↓
|
||||
ViewModel
|
||||
↓
|
||||
Native Template / Native DSL / H5
|
||||
↓
|
||||
用户界面
|
||||
```
|
||||
|
||||
这里最关键的是：
|
||||
|
||||
- 数据模型稳定
|
||||
- 展示方式可换
|
||||
|
||||
也就是：
|
||||
|
||||
**先稳定 ViewModel，再让模板与承载方式变化。**
|
||||
|
||||
当前内容体验链已经调整成：
|
||||
|
||||
```text
|
||||
控制点触发
|
||||
↓
|
||||
原生内容卡（template）
|
||||
↓
|
||||
CTA: 查看详情（可选）
|
||||
↓
|
||||
H5 详情页 / 互动任务页
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. ViewModel 的作用
|
||||
|
||||
ViewModel 是原生模板、原生 DSL、H5 都共用的中间层。
|
||||
|
||||
例如结果页：
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "result-summary",
|
||||
"title": "比赛结束",
|
||||
"subtitle": "校园积分赛",
|
||||
"hero": {
|
||||
"label": "总分",
|
||||
"value": "120"
|
||||
},
|
||||
"stats": [
|
||||
{ "key": "duration", "label": "用时", "value": "23:18" },
|
||||
{ "key": "distance", "label": "里程", "value": "3.2km" },
|
||||
{ "key": "controls", "label": "完成点", "value": "8/8" }
|
||||
],
|
||||
"actions": [
|
||||
{ "key": "restart", "label": "再来一局" },
|
||||
{ "key": "close", "label": "返回地图" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
例如内容页：
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "content-card",
|
||||
"title": "湖边步道",
|
||||
"body": "这里适合短暂停留观察周边地形。",
|
||||
"image": "",
|
||||
"cta": "继续"
|
||||
}
|
||||
```
|
||||
|
||||
这样以后无论：
|
||||
|
||||
- 原生模板
|
||||
- 原生 DSL
|
||||
- H5
|
||||
|
||||
都可以消费同一份结构化数据。
|
||||
|
||||
---
|
||||
|
||||
## 7. 原生模板层建议
|
||||
|
||||
建议先做有限几个模板：
|
||||
|
||||
### 结果页模板
|
||||
|
||||
- `result-minimal`
|
||||
- `result-rich`
|
||||
|
||||
### 内容页模板
|
||||
|
||||
- `content-card-minimal`
|
||||
- `content-card-story`
|
||||
|
||||
模板负责：
|
||||
|
||||
- 布局
|
||||
- 区块顺序
|
||||
- 基础动画与交互
|
||||
|
||||
模板不负责：
|
||||
|
||||
- 业务逻辑
|
||||
- 数据计算
|
||||
|
||||
---
|
||||
|
||||
## 8. 原生有限 DSL 建议
|
||||
|
||||
不要做万能布局引擎，只做有限区块编排。
|
||||
|
||||
例如结果页：
|
||||
|
||||
```json
|
||||
{
|
||||
"templateType": "result-native-dsl",
|
||||
"sections": [
|
||||
{
|
||||
"type": "hero",
|
||||
"field": "score"
|
||||
},
|
||||
{
|
||||
"type": "stats-grid",
|
||||
"fields": ["duration", "distance", "controls"]
|
||||
},
|
||||
{
|
||||
"type": "actions",
|
||||
"items": ["restart", "close"]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
例如内容页：
|
||||
|
||||
```json
|
||||
{
|
||||
"templateType": "content-native-dsl",
|
||||
"sections": [
|
||||
{ "type": "title" },
|
||||
{ "type": "body" },
|
||||
{ "type": "image" },
|
||||
{ "type": "actions", "items": ["continue", "openH5"] }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
原则是：
|
||||
|
||||
- 区块种类有限
|
||||
- 顺序可配置
|
||||
- 不支持无限自由布局
|
||||
|
||||
---
|
||||
|
||||
## 9. H5 扩展层建议
|
||||
|
||||
H5 主要用于高自由度需求。
|
||||
|
||||
建议先只承接两类页面：
|
||||
|
||||
### 9.1 Content Experience Page
|
||||
|
||||
用于：
|
||||
|
||||
- 打点后的定制内容页
|
||||
- 富图文详情
|
||||
- 拍照上传任务
|
||||
- 语音留言
|
||||
- 小游戏互动
|
||||
|
||||
### 9.2 Result Experience Page
|
||||
|
||||
用于：
|
||||
|
||||
- 定制结算页
|
||||
- 成绩包装页
|
||||
- 奖章 / 排名 / 分享页
|
||||
|
||||
但要注意：
|
||||
|
||||
- H5 只是增强页
|
||||
- 原生始终保留最小兜底
|
||||
|
||||
---
|
||||
|
||||
## 10. 推荐优先级
|
||||
|
||||
不建议直接跳到 H5 大量实现。
|
||||
|
||||
推荐顺序：
|
||||
|
||||
### 第一步
|
||||
|
||||
先把原生模板层打稳：
|
||||
|
||||
- 原生最小结果页
|
||||
- 原生最小内容卡
|
||||
|
||||
### 第二步
|
||||
|
||||
再做原生有限 DSL：
|
||||
|
||||
- 支撑中等复杂的客户差异化需求
|
||||
|
||||
### 第三步
|
||||
|
||||
最后再把 H5 扩展层接稳：
|
||||
|
||||
- 处理真正高自由度场景
|
||||
|
||||
---
|
||||
|
||||
## 11. 对当前项目的建议
|
||||
|
||||
结合当前项目现状，建议：
|
||||
|
||||
### 当前优先做
|
||||
|
||||
- 原生内容卡继续完善
|
||||
- 原生结果页继续完善
|
||||
- 先把 ViewModel 定稳
|
||||
|
||||
### 中期做
|
||||
|
||||
- 原生结果页的有限 DSL
|
||||
- 原生内容页的有限 DSL
|
||||
|
||||
### 后期做
|
||||
|
||||
- H5 内容页
|
||||
- H5 结果页
|
||||
- Bridge 能力逐步扩充
|
||||
|
||||
---
|
||||
|
||||
## 12. 一句话结论
|
||||
|
||||
最适合当前项目的长期方案不是单押 H5，也不是所有东西都原生写死，而是：
|
||||
|
||||
**原生模板保底、原生有限 DSL 承担中度变化、H5 承担高定制内容。**
|
||||
|
||||
这三层结合起来，既能保证核心体验稳定，也能承接客户高频变化需求。
|
||||
|
||||
---
|
||||
|
||||
## 13. 当前运行时分层
|
||||
|
||||
结合目前已经落地的实现，当前项目的运行时分工已经比较明确：
|
||||
|
||||
### 13.1 游戏中途内容
|
||||
|
||||
- 即时弹出的内容：原生内容卡
|
||||
- 内容卡模板：原生模板系统
|
||||
- 内容卡上的 CTA：再进入 H5 详情页或互动任务页
|
||||
|
||||
也就是：
|
||||
|
||||
```text
|
||||
控制点触发
|
||||
↓
|
||||
原生内容卡
|
||||
↓
|
||||
查看详情 / 开始互动
|
||||
↓
|
||||
H5 详情页或任务页
|
||||
```
|
||||
|
||||
### 13.2 结果页
|
||||
|
||||
- 原生结果页始终保底
|
||||
- H5 结果页只做增强版
|
||||
- H5 打不开时，结果仍然可在原生层完整查看
|
||||
|
||||
### 13.3 H5 壳子
|
||||
|
||||
经过真机验证，`web-view` 不再承担局部弹窗职责。
|
||||
|
||||
当前应统一按：
|
||||
|
||||
- 内容详情页：整页 H5
|
||||
- 互动任务页：整页 H5
|
||||
- 定制结果页：整页 H5
|
||||
|
||||
来理解它。
|
||||
|
||||
---
|
||||
|
||||
## 14. 当前主文档与归档关系
|
||||
|
||||
当前建议优先阅读：
|
||||
|
||||
- [hybrid-experience-architecture.md](D:/dev/cmr-mini/doc/experience/混合体验架构方案.md)
|
||||
- [native-h5-bridge-spec.md](D:/dev/cmr-mini/doc/experience/原生与H5桥接规范.md)
|
||||
|
||||
已归档但仍可回看的阶段性方案：
|
||||
|
||||
- [content-experience-layer-proposal.md](/D:/dev/cmr-mini/doc/archive/experience/内容体验层方案.md)
|
||||
- [result-scene-proposal.md](/D:/dev/cmr-mini/doc/archive/experience/结果页方案.md)
|
||||
- [experience-shell-proposal.md](/D:/dev/cmr-mini/doc/archive/experience/体验壳子方案.md)
|
||||
- [h5-experience-integration-proposal.md](/D:/dev/cmr-mini/doc/archive/experience/H5体验接入方案.md)
|
||||
|
||||
Reference in New Issue
Block a user