整理中文文档结构与索引
This commit is contained in:
235
doc/debug/传感器现状总结.md
Normal file
235
doc/debug/传感器现状总结.md
Normal file
@@ -0,0 +1,235 @@
|
||||
# 传感器现状总结
|
||||
|
||||
本文档用于说明当前小程序版本已经接入并实际使用的传感器/输入源、它们在系统中的作用，以及当前阶段的稳定边界。
|
||||
|
||||
## 1. 当前正式在用的传感器/输入源
|
||||
|
||||
### 1.1 GPS 定位
|
||||
|
||||
当前作用：
|
||||
|
||||
- 当前定位点显示
|
||||
- GPS 轨迹线绘制
|
||||
- 到目标点距离计算
|
||||
- 打点半径判定
|
||||
- 地图锁定跟随
|
||||
- 自动转图中的前进方向判断
|
||||
- 速度、里程、卡路里等 telemetry 统计
|
||||
|
||||
当前涉及层：
|
||||
|
||||
- `LocationController`
|
||||
- `TelemetryRuntime`
|
||||
- `MapEngine`
|
||||
- `RuleEngine`
|
||||
|
||||
说明：
|
||||
|
||||
- 这是当前地图和玩法系统最核心的输入源。
|
||||
|
||||
### 1.2 Compass 罗盘
|
||||
|
||||
当前作用：
|
||||
|
||||
- 指北针
|
||||
- 静止或低速时的地图朝向
|
||||
- 真北 / 磁北参考切换相关显示
|
||||
|
||||
当前涉及层：
|
||||
|
||||
- `CompassHeadingController`
|
||||
- `MapEngine`
|
||||
|
||||
说明：
|
||||
|
||||
- 当前自动转图的稳定主来源之一。
|
||||
|
||||
### 1.3 Gyroscope 陀螺仪
|
||||
|
||||
当前作用：
|
||||
|
||||
- 提供设备旋转速率调试数据
|
||||
- 为设备朝向可信度提供辅助参考
|
||||
- 为后续更稳的自动转图平滑能力预留输入
|
||||
|
||||
当前涉及层：
|
||||
|
||||
- `GyroscopeController`
|
||||
- `TelemetryRuntime`
|
||||
|
||||
说明：
|
||||
|
||||
- 当前已接入并显示，但还没有直接主导地图旋转。
|
||||
|
||||
### 1.4 DeviceMotion 设备方向
|
||||
|
||||
当前作用：
|
||||
|
||||
- 提供设备朝向角参考
|
||||
- 参与 `deviceHeadingDeg`
|
||||
- 参与 `headingConfidence`
|
||||
- 用于调试观察姿态相关信息
|
||||
|
||||
当前涉及层：
|
||||
|
||||
- `DeviceMotionController`
|
||||
- `TelemetryRuntime`
|
||||
|
||||
说明：
|
||||
|
||||
- 当前不直接接管自动转图，主要作为辅助与调试输入。
|
||||
|
||||
### 1.5 BLE 心率带
|
||||
|
||||
虽然不是手机内置传感器，但当前已经是正式输入源。
|
||||
|
||||
当前作用：
|
||||
|
||||
- 实时心率采集
|
||||
- HUD 颜色分区
|
||||
- 卡路里估算
|
||||
- 橙 / 红警戒边框
|
||||
- 后续心率相关玩法
|
||||
|
||||
当前涉及层：
|
||||
|
||||
- `HeartRateController`
|
||||
- `HeartRateInputController`
|
||||
- `TelemetryRuntime`
|
||||
- HUD / Feedback
|
||||
|
||||
## 2. 当前正式在用的模拟输入源
|
||||
|
||||
### 2.1 模拟 GPS
|
||||
|
||||
当前作用：
|
||||
|
||||
- 室内测试路线与打点
|
||||
- 模拟移动
|
||||
- 测试规则、HUD、自动转图
|
||||
|
||||
说明：
|
||||
|
||||
- 与真实 GPS 并列，是正式的开发调试输入源。
|
||||
|
||||
### 2.2 模拟心率
|
||||
|
||||
当前作用：
|
||||
|
||||
- 测试心率颜色区间
|
||||
- 测试卡路里累计
|
||||
- 测试边框警示
|
||||
- 测试第二块 HUD
|
||||
|
||||
说明：
|
||||
|
||||
- 与真实心率带并列，是正式的开发调试输入源。
|
||||
|
||||
## 3. 当前没有纳入正式能力的传感器
|
||||
|
||||
### 3.1 Accelerometer 加速度计
|
||||
|
||||
当前状态：
|
||||
|
||||
- 在当前微信小程序运行时 / 设备环境下不稳定
|
||||
- 启动时出现 `startAccelerometer:fail, has enable, should stop pre operation`
|
||||
- 已从当前第一阶段正式方案中移出
|
||||
|
||||
结论：
|
||||
|
||||
- 当前小程序版本不依赖加速度计
|
||||
- 后续更完整的姿态 / 运动融合，建议放到原生 Flutter 端实现
|
||||
|
||||
## 4. 当前地图上真正直接起作用的核心输入
|
||||
|
||||
如果只看当前会直接影响地图行为和玩法行为的核心输入，主要是：
|
||||
|
||||
- `GPS`
|
||||
- `Compass`
|
||||
- `Heart Rate (BLE)`
|
||||
|
||||
其中：
|
||||
|
||||
- `GPS` 负责位置、轨迹、速度、距离、打点、跟随、前进方向
|
||||
- `Compass` 负责当前稳定的地图朝向与指北针
|
||||
- `Heart Rate` 负责 HUD 颜色、卡路里和警戒反馈
|
||||
|
||||
而：
|
||||
|
||||
- `Gyroscope`
|
||||
- `DeviceMotion`
|
||||
|
||||
当前更多是为后续更稳的朝向融合能力做准备。
|
||||
|
||||
## 5. 当前阶段的稳定边界
|
||||
|
||||
小程序第一阶段推荐稳定边界如下：
|
||||
|
||||
- 保留：
|
||||
- `Location`
|
||||
- `Compass`
|
||||
- `Gyroscope`
|
||||
- `DeviceMotion`
|
||||
- `BLE Heart Rate`
|
||||
- `Mock GPS`
|
||||
- `Mock Heart Rate`
|
||||
- 放弃：
|
||||
- `Accelerometer`
|
||||
|
||||
结论：
|
||||
|
||||
- 小程序端以稳定为优先
|
||||
- 更完整的原始传感器融合，放在原生 Flutter 端推进
|
||||
|
||||
## 6. 一句话总结
|
||||
|
||||
当前小程序版本已经正式使用的核心传感器 / 输入源是：
|
||||
|
||||
- `GPS`
|
||||
- `Compass`
|
||||
- `Gyroscope`
|
||||
- `DeviceMotion`
|
||||
- `Heart Rate (BLE)`
|
||||
- `Mock GPS`
|
||||
- `Mock Heart Rate`
|
||||
|
||||
其中真正直接驱动地图行为的核心仍然是：
|
||||
|
||||
- `GPS`
|
||||
- `Compass`
|
||||
|
||||
其余能力更多承担辅助、调试、反馈和后续扩展输入的角色。
|
||||
|
||||
---
|
||||
|
||||
## 7. 当前主体能力边界补充
|
||||
|
||||
最近排查已经确认：
|
||||
|
||||
- 当前最初使用的是**个人主体**小程序
|
||||
|
||||
这会影响部分设备能力的可用性与稳定性，尤其是：
|
||||
|
||||
- `Compass`
|
||||
- `Accelerometer`
|
||||
- 与 `web-view` 相关的扩展体验链
|
||||
|
||||
因此当前这份传感器结论要加一个前提：
|
||||
|
||||
**它不仅受到代码实现影响，也受到小程序主体能力边界影响。**
|
||||
|
||||
这意味着：
|
||||
|
||||
- 某些 Android 上的样本异常，不一定是算法错误
|
||||
- 某些 H5 / 传感器问题，不一定能在个人主体下彻底解决
|
||||
|
||||
当前建议：
|
||||
|
||||
- 原生主流程继续开发
|
||||
- 传感器高级能力与 H5 接入先保留设计与代码入口
|
||||
- 等企业主体切换完成后，再做专项回归
|
||||
|
||||
详细说明见：
|
||||
|
||||
- [platform-capability-notes.md](D:/dev/cmr-mini/doc/debug/平台能力说明.md)
|
||||
|
||||
145
doc/debug/平台能力说明.md
Normal file
145
doc/debug/平台能力说明.md
Normal file
@@ -0,0 +1,145 @@
|
||||
# 平台能力与主体限制说明
|
||||
|
||||
本文档用于记录当前项目在 **微信小程序平台能力** 上已经确认的边界，避免后续把环境或主体限制误判成代码问题。
|
||||
|
||||
---
|
||||
|
||||
## 1. 当前已确认的关键事实
|
||||
|
||||
当前项目最初使用的是**个人主体**小程序。
|
||||
|
||||
在这个前提下，已经出现并确认了以下问题：
|
||||
|
||||
- `web-view` 无法打开指定 H5 页面
|
||||
- 某些传感器能力在不同设备上表现异常或不稳定
|
||||
- 部分能力在 `iOS` 与 `Android` 上差异极大
|
||||
|
||||
这些问题在排查后，已经基本确认不完全是代码链路问题，而与 **小程序主体能力边界** 直接相关。
|
||||
|
||||
---
|
||||
|
||||
## 2. 当前确认受影响的能力
|
||||
|
||||
### 2.1 WebView / H5 定制内容
|
||||
|
||||
现象：
|
||||
|
||||
- 浏览器中 H5 页面可正常打开
|
||||
- 小程序 `web-view` 中提示：
|
||||
- `无法打开该页面`
|
||||
- `不支持打开 https://...`
|
||||
|
||||
当前结论：
|
||||
|
||||
- 这不代表 H5 页面本身有问题
|
||||
- 也不代表内容体验链路本身有问题
|
||||
- 在个人主体下，即使同域名下配置可读，`web-view` 仍可能不可用或受限
|
||||
|
||||
### 2.2 传感器相关能力
|
||||
|
||||
现象：
|
||||
|
||||
- `Compass` 在不同平台表现不一致
|
||||
- `Accelerometer` 启动异常
|
||||
- 某些 Android 设备上指北针样本不稳定
|
||||
|
||||
当前结论：
|
||||
|
||||
- 这类问题不能简单归因为算法
|
||||
- 其中一部分和小程序主体能力、平台能力边界有关
|
||||
- 在企业主体完成前，不宜继续对这类问题做过度代码优化
|
||||
|
||||
---
|
||||
|
||||
## 3. 为什么“同域名能读配置”不代表“能开 H5”
|
||||
|
||||
这是排查中最容易误判的点。
|
||||
|
||||
在微信小程序里：
|
||||
|
||||
- 读取配置、请求接口，依赖的是：
|
||||
- `request` 相关域名能力
|
||||
- 打开 `web-view`，依赖的是：
|
||||
- `业务域名`
|
||||
|
||||
这两者不是同一条能力链。
|
||||
|
||||
因此会出现：
|
||||
|
||||
- 配置文件能正常读取
|
||||
- 同域名 H5 页面却无法在 `web-view` 中打开
|
||||
|
||||
这个现象本身并不矛盾。
|
||||
|
||||
---
|
||||
|
||||
## 4. 当前开发策略
|
||||
|
||||
在企业主体审核完成前，建议采用以下策略：
|
||||
|
||||
### 4.1 原生能力优先
|
||||
|
||||
继续优先开发：
|
||||
|
||||
- 地图主流程
|
||||
- 打点逻辑
|
||||
- HUD
|
||||
- 指北针与自动转图
|
||||
- 原生内容卡兜底
|
||||
- 原生结果页兜底
|
||||
|
||||
### 4.2 H5 与高级传感器相关能力先按“接口预留”处理
|
||||
|
||||
当前阶段可以继续做：
|
||||
|
||||
- 文档
|
||||
- 模型
|
||||
- 配置结构
|
||||
- Bridge 设计
|
||||
- 容器页
|
||||
|
||||
但不要再花大量时间试图用当前个人主体把所有能力彻底打通。
|
||||
|
||||
### 4.3 企业主体通过后再做专项回归
|
||||
|
||||
企业主体切换完成后，应专项回归：
|
||||
|
||||
- `web-view`
|
||||
- `Compass`
|
||||
- `Accelerometer`
|
||||
- 其它之前表现异常的能力
|
||||
|
||||
---
|
||||
|
||||
## 5. 企业主体切换后的回归建议
|
||||
|
||||
建议回归顺序：
|
||||
|
||||
1. 最小 `web-view` 测试页
|
||||
2. H5 内容体验页自动弹出
|
||||
3. H5 点击内容页
|
||||
4. `Compass` 样本接收
|
||||
5. 自动转图
|
||||
6. `Accelerometer`
|
||||
|
||||
如果最小 `web-view` 测试页仍失败，再继续查：
|
||||
|
||||
- 业务域名
|
||||
- 当前 appid
|
||||
- 当前环境版本
|
||||
- 真机微信缓存
|
||||
|
||||
---
|
||||
|
||||
## 6. 一句话结论
|
||||
|
||||
当前阶段已经确认：
|
||||
|
||||
**个人主体会直接影响 `web-view` 和部分传感器能力的可用性与稳定性。**
|
||||
|
||||
因此在企业主体审核完成前，最合理的做法是：
|
||||
|
||||
- 原生主流程继续开发
|
||||
- H5 和高级传感器按“预留 + 待验证”处理
|
||||
- 待企业主体生效后，再统一回归验证
|
||||
|
||||
126
doc/debug/模拟器调试日志方案.md
Normal file
126
doc/debug/模拟器调试日志方案.md
Normal file
@@ -0,0 +1,126 @@
|
||||
# 模拟器调试日志方案
|
||||
|
||||
## 目标
|
||||
|
||||
复用现有 GPS 模拟器 websocket，在不污染地图调试面板的前提下，把高频、临时、开发期日志输出到外部模拟器。
|
||||
|
||||
第一阶段只做最小闭环：
|
||||
|
||||
- 复用 `tools/mock-gps-sim` 现有 websocket
|
||||
- 增加 `debug-log` 消息类型
|
||||
- 小程序侧增加最小 logger
|
||||
- 第一批只发送 `gps-logo` 范围日志
|
||||
|
||||
## 设计原则
|
||||
|
||||
- 调试面板看“当前状态”
|
||||
- 模拟器日志看“变化过程”
|
||||
- 日志链只在开发/调试期间启用
|
||||
- 不进入正式玩法逻辑
|
||||
- 不把高频临时日志继续塞进页面 WXML
|
||||
|
||||
## 协议
|
||||
|
||||
消息类型：
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "debug-log",
|
||||
"timestamp": 1712345678901,
|
||||
"scope": "gps-logo",
|
||||
"level": "info",
|
||||
"message": "wx.getImageInfo success",
|
||||
"payload": {
|
||||
"src": "https://example.com/logo.png",
|
||||
"path": "wxfile://tmp_xxx"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
字段说明：
|
||||
|
||||
- `type`
|
||||
固定为 `debug-log`
|
||||
- `timestamp`
|
||||
毫秒时间戳
|
||||
- `scope`
|
||||
日志分类，例如 `gps-logo`、`h5`、`compass`
|
||||
- `level`
|
||||
`info / warn / error`
|
||||
- `message`
|
||||
简短可读说明
|
||||
- `payload`
|
||||
可选附加对象，用于排查细节
|
||||
|
||||
## 第一阶段 scope
|
||||
|
||||
第一批只接：
|
||||
|
||||
- `gps-logo`
|
||||
|
||||
典型日志点：
|
||||
|
||||
- logo 未配置
|
||||
- 当前风格不是 `badge`
|
||||
- 开始加载 logo
|
||||
- `wx.getImageInfo` 成功
|
||||
- `wx.getImageInfo` 失败
|
||||
- 图片 `onload`
|
||||
- 图片 `onerror`
|
||||
|
||||
## 小程序侧实现
|
||||
|
||||
新增：
|
||||
|
||||
- `miniprogram/engine/debug/mockSimulatorDebugLogger.ts`
|
||||
|
||||
职责：
|
||||
|
||||
- 复用 mock GPS simulator websocket 地址
|
||||
- 负责连接、断开、简单队列、发送 `debug-log`
|
||||
- 只在调试 UI 开启时启用
|
||||
|
||||
接入点：
|
||||
|
||||
- `MapEngine`
|
||||
- 调试 UI 开启时启用 logger
|
||||
- 调试 UI 关闭时关闭 logger
|
||||
- mock bridge 地址变化时同步 logger 地址
|
||||
- `CourseLabelRenderer`
|
||||
- 发送 `gps-logo` 相关日志
|
||||
|
||||
## 模拟器侧实现
|
||||
|
||||
复用：
|
||||
|
||||
- `tools/mock-gps-sim/server.js`
|
||||
- `tools/mock-gps-sim/public/index.html`
|
||||
- `tools/mock-gps-sim/public/simulator.js`
|
||||
|
||||
最小能力：
|
||||
|
||||
- websocket 接收 `debug-log`
|
||||
- UI 新增“调试日志”区域
|
||||
- 仅显示 `debug-log`
|
||||
- 保留最近若干条，避免无限增长
|
||||
|
||||
## 后续扩展
|
||||
|
||||
第二阶段可以再补：
|
||||
|
||||
- `compass`
|
||||
- `h5`
|
||||
- `content-card`
|
||||
- `heart-rate`
|
||||
|
||||
第三阶段再补：
|
||||
|
||||
- scope 过滤
|
||||
- level 过滤
|
||||
- 暂停滚动
|
||||
- 导出日志
|
||||
|
||||
## 当前结论
|
||||
|
||||
先把 `gps-logo` 调试链打通，再回头用模拟器日志查 logo 为什么不显示，比继续把临时字段堆在调试面板里更稳。
|
||||
|
||||
213
doc/debug/罗盘排障记录.md
Normal file
213
doc/debug/罗盘排障记录.md
Normal file
@@ -0,0 +1,213 @@
|
||||
# 罗盘问题排查记录
|
||||
|
||||
## 背景
|
||||
|
||||
本项目在微信小程序中使用罗盘驱动：
|
||||
|
||||
- 指北针针头
|
||||
- 指北针顶部角度数字
|
||||
- `heading-up` 自动转图
|
||||
|
||||
在一次围绕顶部提示窗、传感器显示链和性能优化的修改后，出现了以下问题：
|
||||
|
||||
- iOS 端偶发正常，偶发异常
|
||||
- Android 端罗盘长期无样本
|
||||
- 指北针不转
|
||||
- `heading-up` 自动转图一起失效
|
||||
|
||||
## 最终结论
|
||||
|
||||
这次问题的主因不是算法本身，而是：
|
||||
|
||||
**Android 微信环境下，罗盘监听需要被持续保活；之前将多处看似冗余的 `compassController.start()` 清理掉后，Android 的罗盘样本链被破坏了。**
|
||||
|
||||
也就是说：
|
||||
|
||||
- iOS 对罗盘监听更宽容
|
||||
- Android 对罗盘监听更脆弱
|
||||
- 之前稳定，不是因为链路更“干净”，而是因为老代码里存在一条实际有效的“罗盘保活链”
|
||||
|
||||
## 现象总结
|
||||
|
||||
### 失效期
|
||||
|
||||
- Android 调试面板里 `Compass Source` 为 `无数据`
|
||||
- iOS 仍可能有 `罗盘` 样本
|
||||
- 若强行用 `DeviceMotion` 兜底，会出现：
|
||||
- 指针会转
|
||||
- 但方向不准
|
||||
- 自动转图方向错误
|
||||
|
||||
### 恢复后
|
||||
|
||||
- Android `Compass Source` 恢复为 `罗盘`
|
||||
- 指北针针头恢复
|
||||
- 顶部角度数字恢复
|
||||
- `heading-up` 恢复
|
||||
|
||||
## 误判过的方向
|
||||
|
||||
以下方向在本次排查中都被考虑过，但最终不是根因或不是主要根因：
|
||||
|
||||
### 1. `DeviceMotion` 兜底方案
|
||||
|
||||
问题：
|
||||
|
||||
- `DeviceMotion` 可以给出设备姿态角
|
||||
- 但不能稳定代替“指向北”的绝对罗盘
|
||||
- 用它兜底会导致：
|
||||
- 能转
|
||||
- 但方向明显不准
|
||||
|
||||
结论：
|
||||
|
||||
**`DeviceMotion` 不能作为正式指北针来源。**
|
||||
|
||||
### 2. 加速度计 / 其他传感器互斥
|
||||
|
||||
曾排查：
|
||||
|
||||
- `Accelerometer`
|
||||
- `Gyroscope`
|
||||
- `DeviceMotion`
|
||||
- `Compass`
|
||||
|
||||
结论：
|
||||
|
||||
- 加速度计在当前微信 Android 环境下不稳定，已放弃
|
||||
- 但这不是这次罗盘彻底失效的主因
|
||||
|
||||
### 3. 算法问题
|
||||
|
||||
曾尝试调整：
|
||||
|
||||
- 角度平滑
|
||||
- 设备方向单位解释
|
||||
- motion fallback 算法
|
||||
|
||||
结论：
|
||||
|
||||
这些会影响“顺不顺”、“准不准”，但**不能解释 Android 完全无罗盘样本**。
|
||||
|
||||
## 真正修复的方法
|
||||
|
||||
将之前被清理掉的多处 `this.compassController.start()` 恢复回去。
|
||||
|
||||
这些调用点主要分布在：
|
||||
|
||||
- `commitViewport(...)`
|
||||
- `handleTouchStart(...)`
|
||||
- `animatePreviewToRest(...)`
|
||||
- `normalizeTranslate(...)`
|
||||
- `zoomAroundPoint(...)`
|
||||
- `handleRecenter(...)`
|
||||
- `handleRotateStep(...)`
|
||||
- `handleRotationReset(...)`
|
||||
|
||||
这些调用在代码审美上看起来像“重复启动”，但在 Android 微信环境里，它们实际上承担了：
|
||||
|
||||
**重新拉起 / 保活罗盘监听**
|
||||
|
||||
的作用。
|
||||
|
||||
## 当前工程判断
|
||||
|
||||
本项目当前应当采用以下原则：
|
||||
|
||||
### 1. 罗盘主来源只使用 `Compass`
|
||||
|
||||
不要再让：
|
||||
|
||||
- `DeviceMotion`
|
||||
- 其它姿态角
|
||||
|
||||
参与正式指北针和自动转图的主方向链。
|
||||
|
||||
### 2. `DeviceMotion` 只保留为辅助或调试输入
|
||||
|
||||
可用于：
|
||||
|
||||
- 调试面板显示
|
||||
- 设备姿态观察
|
||||
- 未来原生端姿态融合参考
|
||||
|
||||
但不要直接驱动指北针。
|
||||
|
||||
### 3. Android 端罗盘需要保活
|
||||
|
||||
后续不要再把这些 `compassController.start()` 当成纯冗余逻辑随意清掉。
|
||||
|
||||
如果要优化代码，应该：
|
||||
|
||||
- 保留现有行为
|
||||
- 将其收口为有明确语义的方法
|
||||
|
||||
例如：
|
||||
|
||||
- `ensureCompassAlive()`
|
||||
- `refreshCompassBinding()`
|
||||
|
||||
而不是直接删掉。
|
||||
|
||||
## 与生命周期相关的硬约束
|
||||
|
||||
以下约束必须保持：
|
||||
|
||||
### 单实例
|
||||
|
||||
页面层必须保证任意时刻只有一个 `MapEngine` 活跃实例。
|
||||
|
||||
### 完整销毁
|
||||
|
||||
`MapEngine.destroy()` 中必须完整执行：
|
||||
|
||||
- `compassController.destroy()`
|
||||
- 其它传感器 `destroy()`
|
||||
|
||||
防止旧监听残留。
|
||||
|
||||
### 调试状态不应影响罗盘主链
|
||||
|
||||
调试面板开关不应再控制：
|
||||
|
||||
- 罗盘是否启动
|
||||
- 罗盘是否停止
|
||||
|
||||
否则容易再次引入平台差异问题。
|
||||
|
||||
## 推荐保留的调试字段
|
||||
|
||||
以下字段建议长期保留，便于后续定位：
|
||||
|
||||
- `Compass Source`
|
||||
- `sensorHeadingText`
|
||||
- 顶部角度数字
|
||||
- `heading-up` 开关状态
|
||||
|
||||
其中 `Compass Source` 至少应显示：
|
||||
|
||||
- `罗盘`
|
||||
- `无数据`
|
||||
|
||||
避免再次将问题误判为算法问题。
|
||||
|
||||
## 后续优化建议
|
||||
|
||||
如果后面要继续优化这段代码，推荐方向是：
|
||||
|
||||
### 可做
|
||||
|
||||
- 将分散的 `compassController.start()` 收口成命名明确的方法
|
||||
- 为 Android 罗盘链补一层更可读的“保活机制”注释
|
||||
- 保留当前稳定行为前提下做重构
|
||||
|
||||
### 不建议
|
||||
|
||||
- 再次移除这些重复 `start()` 调用
|
||||
- 用 `DeviceMotion` 正式兜底指北针
|
||||
- 让调试开关影响罗盘主链启动
|
||||
|
||||
## 一句话经验
|
||||
|
||||
**在微信小程序里，Android 罗盘监听的稳定性比 iOS 更脆；某些看似冗余的 `start()` 调用，实际是平台兼容补丁，不应该在没有真机回归的情况下清理。**
|
||||
|
||||
34
doc/debug/调试文档索引.md
Normal file
34
doc/debug/调试文档索引.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# 调试文档索引
|
||||
|
||||
这一组文档用于记录：
|
||||
|
||||
- 平台能力边界
|
||||
- 传感器问题排查
|
||||
- 模拟器日志方案
|
||||
- 当前调试约束和回归重点
|
||||
|
||||
## 当前主文档
|
||||
|
||||
- [平台能力说明](/D:/dev/cmr-mini/doc/debug/平台能力说明.md)
|
||||
用于记录主体能力、`web-view`、传感器等平台边界。
|
||||
- [模拟器调试日志方案](/D:/dev/cmr-mini/doc/debug/模拟器调试日志方案.md)
|
||||
用于说明 mock simulator 的日志旁路与 `debug-log` 协议。
|
||||
- [传感器当前状态总结](/D:/dev/cmr-mini/doc/debug/传感器现状总结.md)
|
||||
用于看当前已确认的传感器状态与调试结论。
|
||||
- [罗盘问题记录](/D:/dev/cmr-mini/doc/debug/罗盘排障记录.md)
|
||||
用于回看 Android / iOS 罗盘保活链的排查过程。
|
||||
|
||||
## 推荐阅读顺序
|
||||
|
||||
1. [platform-capability-notes.md](/D:/dev/cmr-mini/doc/debug/平台能力说明.md)
|
||||
2. [sensor-current-summary.md](/D:/dev/cmr-mini/doc/debug/传感器现状总结.md)
|
||||
3. [mock-simulator-debug-log-proposal.md](/D:/dev/cmr-mini/doc/debug/模拟器调试日志方案.md)
|
||||
4. [compass-debugging-notes.md](/D:/dev/cmr-mini/doc/debug/罗盘排障记录.md)
|
||||
|
||||
## 使用建议
|
||||
|
||||
- 看“当前限制”和“为什么会这样”，优先看平台能力说明。
|
||||
- 看“现在系统是什么状态”，优先看传感器现状总结。
|
||||
- 看“以后日志怎么打”，优先看模拟器日志方案。
|
||||
- 看“为什么罗盘以前坏过”，再去看罗盘问题记录。
|
||||
|
||||
Reference in New Issue
Block a user