daoqi/youle_app_ios_v2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
39 Commits 1 Branch 0 Tags
c6221d30ca1f839b2d81438d453d3950f9bf9e9a
Commit Graph
12 Commits
Author SHA1 Message Date
joywayerandClaude Opus 4.7 c6221d30ca Design §8.4.1：补 DeviceKit 9 项接口实现骨架 
覆盖 §3.1 异步 handler 6 项 + §3.2 反向 callback 3 项，含本轮全文 audit
新发现的 3 项反向 callback（前一轮 audit 漏列）：

§3.1 异步 handler 6 项（DeviceHandlers.register）：
  - 【10】vibrator           — AudioServicesPlaySystemSound + cb "vibrator"
  - 【11】repeatvibrator     — 同 vibrator（msext RootVC.m:1820 沿用历史）
  - 【12】canclevibrator     — AudioServicesDisposeSystemSoundID + cb "canclevibrator"
  - 【13】gamepastetext      — UIPasteboard.general.string → cb 返回内容
  - 【14】gameCopytext       — UIPasteboard.general.string = data + cb "gameCopytext"
  - 【21】getphoneInfo       — cb "getphoneInfo"（大写 I）+ bridge.call("getphoneinfo"
                              小写 i！，data: 表 A 6 字段)
                              ※ 大小写 i 不一致是 msext 历史契约，严格保持

§3.2 反向 callback 3 项（DeviceHandlers.bindReverseCallbacks）：
  - 【2】 getBattery   — UIDevice.batteryLevelDidChangeNotification
                        data: String(format: "%.2f", level) 0~1
  - 【3】 getnetwork   — NWPath 变化 data: "1"无网/"2"WiFi/"3"蜂窝
  - 【4】 appservice   — App 前后台 data: "1"=后台/"2"=前台（命名错位沿用）

辨析 polyfill 与 callback 同名问题：契约 §3.4.1 polyfill 的同步 getter
`getbattery()` / `getnetwork()` 与 §3.2 反向 `getBattery` / `getnetwork`
名字重合但语义不同（前者 H5 同步问当前值，后者 Native 事件推变化），
两条路径并存互不矛盾。在 §8.4.1 新增辨析段澄清。

支撑组件骨架：BatteryMonitor / AppLifecycleMonitor（NetworkMonitor 已在
§8.4 现有）；§8.4.2 与 msext 6 维度差异表。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-06-22 07:28:34 +08:00
joywayerandClaude Opus 4.7 82bad8a85d Design §3.4.1：补 window.settings 同步 getter polyfill（9 项含 getothername） 
audit 第二轮发现：Contract §附录 A 旧桥 JSExport 共 28 方法，与 §3.1
异步主桥去重后多出 9 项 H5 同步只读 getter。前一轮 audit 只覆盖 §3.1
主表的 22 项异步 handler，这 9 项 getter 在 Design 完全无覆盖：

  - getchannelName / getmarketname / getOther / getothername(name)
  - getcompareCode / getbattery / getnetwork
  - getGameinstall(name) / getGameplay(jsondata)

这些接口 H5 端形式是同步表达式（var ch = window.settings.getchannelName()），
WKWebView 无法同步返回 JS 值。唯一不破契约（H5 端零修改）的路径：
documentStart 注入数据快照 + 纯 JS getter polyfill，本地查询零延迟。

§3.4.1 新增覆盖：
  - 9 项 getter 业务语义 + 数据源映射表（驳到 BundleConfig / DeviceKit /
    SandboxPaths.installedSubGames）
  - 数据快照时机：静态字段（11 项渠道注入）启动期一次；动态字段
    （battery / network / installedGames）每次 loadFileURL 前重新快照
  - SettingsBridgePolyfill.makeUserScript 完整 JS 注入骨架
  - WebContainerViewController 接入点（runBootPipelineSteps 末尾、
    loadFileURL 前调 installSettingsPolyfill）
  - 与原 msext JSExport 5 维度差异表

待 Phase 2 实施时查清：getcompareCode 在 msext RootVC.m:1560 附近的真实
返回值语义（业务校验码，可能与 zip 版本号或固定值相关）。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-06-22 07:24:01 +08:00
joywayerandClaude Opus 4.7 92298b657e Design §8.1：补 AudioKit 4 项 handler 完整实现骨架（方案 A 示范） 
H5↔Native 接口实现层缺口补全启动（用户选 A：分散到各 module 章节补）。
本 commit 作为风格示范，后续 commit 按相同模板补 DeviceKit / Location /
Shake / OpenurlTitleData 共 11 项 handler。

§8.1 末尾新增两小节：

§8.1.1 — H5 audio handlers 实现骨架（185 行）
  - AudioHandlers struct 集中注册 4 项 handler，便于发现 / 单测
  - 【3】srcIsloop  入参解析 src/isloop → SandboxPaths.lobbyAssets/wav
        + AudioPlayer.playOnce / loopBackground / stopBackground 三态
        + responseCallback "Response from srcIsloop"
  - 【4】prepareaudio  权限三态分支（denied → bridge.call alertMessage
        而非原生弹窗，契约 §6.2 ifauth 语义）+ recordAndUpload
        + getaudiourl 反向 callback（time 字段必须 string，契约硬约束）
  - 【5】mediaTypeAudio  voiceCenter 总开关短路 + 下载 → AMR→WAV
        → playVoice with onStart/onEnd 桥到 gameui_play_voice/
        gameui_stop_voice；失败也补 stop_voice 避免 H5 UI 卡"播放中"
  - 【6】voicePlaying  actor VoiceCenter 隔离 isEnabled 状态

§8.1.2 — 与原 msext 的差异（不要照抄的部分）
  - 录音 UI / 上传后端 / 状态共享 / 总开关 / 路径拼接 5 维度对照表

骨架级别（结构 + 关键调用 + 注释 + 契约引用），不是产品代码 — 实施
Phase 2 时按此骨架落地真实代码。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-06-22 07:14:15 +08:00
joywayer 2280462a22 docs：Plan + Design 扩展 Phase 1.14 为 5 子项（含 AppIcon / LaunchScreen / progress / splash UI） 
原 Phase 1.14 仅含"WebContainer 16:9 letterbox + 串接整链路"，
漏掉了用户实际能看到的三件事：AppIcon / LaunchScreen 启动图 / zip
下载进度条。msext 上线时这三件都有，新外壳上线必须对齐。按用户偏好
方案 A 合并到 Phase 1.14，避免做两遍 WebContainer。

- Plan §5 Phase 1.14 拆为 1.14.a–e 五个子项
  - 1.14.a AppIcon：拷贝 docs/res/Images.xcassets/AppIcon-1.appiconset
    (9 个 png + Contents.json) 到 ylgamehall/Assets.xcassets
  - 1.14.b LaunchScreen：Default-568h@2x~iphone.png → SplashImage
    imageset；改写 LaunchScreen.storyboard 横屏铺满 UIImageView
  - 1.14.c LobbyZipUpgrader 加 onProgress 回调（@Sendable (Double) -> Void）
  - 1.14.d WebContainerViewController：splash 覆盖层（启动图 +
    UIProgressView + 状态文字）+ 16:9 letterbox + 启动流水线串接
  - 1.14.e webView didFinish 淡出 splash（0.3s 动画 + removeFromSuperview）
- Plan §8 进度追踪同步：5 个子项独立勾选条目
- Design §6.3.5 WebContainer 调用串完整重写：
  - Splash UI 6 状态切换表（拼命启动中... / 拉取配置中... /
    下载更新中 XX% / 加载大厅... / 淡出）
  - runBootPipeline 完整 swift 骨架：含 .shortText 短文本响应处理 /
    showmessage 阻塞处理 / IPA 升级 alert / zip 升级 onProgress 回调
  - 所有失败 / 阻塞终态都用 UIAlertController（非 splash 文字）：
    短文本 / showmessage / IPA 升级 / 网络错误 / zip 下载失败
    各场景的按钮文案 + tap 行为表
 2026-06-22 02:35:37 +08:00
joywayer 1bc287bafc Phase 1.10：RemoteConfigClient 完整版（HTTPS + cache-busting + 短文本 + FlexibleString） 
第二轮调研 daoqi/NewRootVC.m 全文核对后，把对原项目远程配置流程的精确
理解固化进 ADR-008 + Design §6.3.2，并补齐 RemoteConfigClient 缺失的
3 个契约（cache-busting query、短文本响应识别、字段类型混乱兼容）。

核心修正：线上热路径是 chulishengji 双子树合并算法（NewRootVC.m:1372-1538），
不是 onnet 简单 4 层覆盖。viewWillAppear 与 gonet 都会强制把当前 agent 的
gamelist 提到 self.gamelist，只要服务器 JSON 含 agent.gamelist（线上 100% 都有），
self.gamelist 就非 nil，走 else 分支 → chulishengji。本次烟雾测试实测：
agent[0].gamelist = 7 个，完美印证 chulishengji 必要性。

- RemoteConfigClient 新增 cache-busting query：?vXXXXXXXXYYYYYYYY（两段 8 位 hex
  连写，无 =，照搬 msext NewRootVC.m:1226 契约），每次重试都重新生成
- 新增 RemoteConfigOutcome enum：.parsed(RemoteConfig) 与 .shortText(String)
  两种成功状态。短文本响应（trim 后 utf16.count ≤ 100）是服务端运营杀手锏 #1，
  msext 当 alert 文本弹窗 + 停止重试（NewRootVC.m:1239-1243）
- UTF-8 解码 + trim 跟 msext NewRootVC.m:1237-1238 严格对齐
- 所有 String? 字段改用 decodeFlexibleStringIfPresent 扩展（兼容 number-as-string）：
  agentid / channelid / marketid / gameid / showmessage / appVersion / appDownload
  / gameVersion / gameZip 全部 9 字段。msext 用 NSNumber.intValue/description 静默
  吞下 number，新外壳 Codable 严格类型必须显式处理
- 远端 URL 从 http 改为 https（后台已切，无需 ATS 例外）
- Plan ADR-008 修订为含 9 个子节（A-I）的精确决策记录，含 chulishengji
  双子树算法、agent 子树结构、game 子树结构、字段级合并优先级、决策顺序、
  与 msext 差异表
- Design §6.3.2 VersionResolver 重写：从"简单 4 层 reduce"改为"chulishengji
  双子树合并 + 字段级合并"，附 13 项单测覆盖矩阵
- RootViewController 烟雾测试切换为 outcome enum switch case，覆盖 .parsed
  与 .shortText 两条路径
- 实测烟雾：HTTPS 拉到 30 KB JSON 解析 .parsed 成功（耗时 2.7s 含 TLS 握手），
  agent[0].gamelist 含 7 个 game 节点，证明 chulishengji 路径是热路径
 2026-06-22 02:14:57 +08:00
joywayer 5f032342e7 docs：Plan / Design 补 Phase 1 远程配置 + zip 升级流水线（ADR-008） 
调研 daoqi/msext 原项目 NewRootVC.m:1551-1621 viewWillAppear、1372-1492
chulishengji、1789-1869 downFileFromServer 三段核心代码后发现 Plan 初版
Phase 1 漏掉了启动流程里最关键的一环——从 gameconfig 拼远端 .txt 拉
真实配置、做 agent → channel → market 4 级覆盖、对比本地版本、必要时
下载并替换 H5 zip。不做的代价是：上线后用户永远停留在 IPA 内打包瞬间
的 H5 旧版本，H5 团队任何更新都到达不了。

- Plan Phase 1 任务清单从 13 项扩为 17 项，插入 4 个新子项：
  - 1.10 RemoteConfigClient（actor，URLSession async + 指数退避）
  - 1.11 VersionResolver（纯函数 + 单测，reduce 实现 4 级覆盖）
  - 1.12 LocalVersionReader（解析 version.xml）
  - 1.13 LobbyZipUpgrader（actor，原子 rename）
  原 1.10-1.13 后移为 1.14-1.17。已完成的 1.1-1.9 标记为 ✅
- Plan 新增 ADR-008 完整记录决策背景 / 触发事件 / 与 msext 实现差异
  对照表 / 守护条款 / 子游戏复用规划
- Design §6.3 整节重写：从原"ConfigService 一锅端"扩为完整 4 模块流水线
  (§6.3.1-6.3.7)，含 Codable RemoteConfig 模型、纯函数 VersionResolver、
  nonisolated LocalVersionReader、actor LobbyZipUpgrader、WebContainer
  调用串、与 msext 差异表、子游戏 Phase 6 复用规划
- 关键设计纠正：
  - 远端 URL 不带 SERVERNew 前缀，仅 gameconfig.replace("-","/") + ".txt"
  - 4 级覆盖：顶层 → agent → channel → market 深层胜出 + game 子树覆盖
    agent 子树
  - 解压策略：staging-{uuid}/ 临时目录 + 原子 moveItem rename，不学
    msext "目录名 +1" 累积 hack
 2026-06-22 00:42:30 +08:00
joywayer 8c2ffa3106 Phase 1.1：渠道注入用 ChannelConfig.plist 替代 msext 目录树（ADR-007） 
契约 §0.3 描述 msext 把 11 个渠道值编码为 Bundle 根的 11 个空目录
子文件夹名（目录名本身就是值）。在 Xcode 26.5 默认的 synchronized
group 下，此机制不兼容（子目录被扁平化、11 个 .gitkeep 撞名；
folder reference 拖入流程失效；Run Script Phase 受 sandbox 阻碍且
默认 Based on dependency analysis 让 clean build 也不跑）。

CLAUDE.md 原则 B 落地——原生内部自由重构，不照搬 msext。改用单一
plist 存储等价语义，H5 端通过 app_data.js 看到的 11 个 JS 全局变量
行为完全不变（契约边界在 BundleConfig.shared.xxx，与底层无关）。
多渠道分发用 plutil -replace + 重签 + 重打包，工作量与 mv 目录名
重签完全相同。

- 新增 ylgamehall/Resources/ChannelConfig.plist：11 个 string key
  含母包默认值（沿用 msext 现网值）；synchronized group 自动入 Bundle
- Design §7.0 / §7.2 重写为 plist 方案；BundleConfig 代码骨架改为
  PropertyListSerialization + init(bundle:) 可注入式
- Plan §5 Phase 1.1 任务清单从 4 个子项简化为 1 项；ADR-004 文字
  同步；新增 ADR-007 完整记录决策背景 / 触发事件 / 工程兼容性分析
  / 理由 / 守护条款
- pbxproj：ENABLE_USER_SCRIPT_SANDBOXING 残留为 NO（前期 Run Script
  方案探索时关闭，plist 方案下不再需要，但未恢复以避免再次 UI 操作；
  无 Run Script 故无实际安全暴露面，未来可随时改回 YES）
- BuildProject 验证：plist 已落在 .app 根，plutil -p 输出 11 个键值
  完整
 2026-06-21 23:41:25 +08:00
joywayer cabdc1ed42 docs：剥离 docs/res/ 为私人素材池，废止仓库根 Resources/ 假设 
明确 docs/res/ 是项目维护者的私人原始素材池，与项目架构无关；项目
代码 / 构建脚本 / Xcode 工程都不感知它的存在，需要时从中拷一份到
项目按现代实践规划的位置。原 ADR-004「Resources/ 在仓库根 +
Build Phase 引入」语义已崩塌（gamehall.zip / Images.xcassets / Res/
均被挪入 docs/res/），修订为「项目内资源目录由各 Phase 按需落地」：
静态 Bundle 资源走 ylgamehall/Resources/、原生 Asset Catalog 走
ylgamehall/Assets.xcassets/、渠道注入产物走 ylgamehall/ChannelInjection/
（.gitignore + Scripts/inject_channel.sh 生成）、闭源 SDK 走 Vendor/。

- CLAUDE.md 原「Resources/ 目录约定」节改写为「docs/res/ 与项目
  资源的关系」，禁止把 docs/res 当项目资源目录使用
- Design §7.0 整节重写为「项目资源目录约定」三小节（docs/res
  与项目无关 / 项目内资源目录在 Phase 实施时按需落地 / 渠道注入
  运行时路径）
- Plan ADR-004 修订为「项目资源目录由各 Phase 按需落地」；ADR-002
  / §2.2 / Phase 1.1.a-d / 1.5 同步调整为 docs/res → ylgamehall/Resources
  的拷贝模型；Phase 1 任务清单细化渠道注入由 Scripts/inject_channel.sh
  生成
- 物理迁移：仓库根 Resources/gamehall.zip / Images.xcassets / Res/
  全部 rename 到 docs/res/（git rename detection 自动识别）
 2026-06-21 22:32:38 +08:00
joywayer 17a8b96cf8 docs：依赖管理改为纯 SPM + Vendor，移除 CocoaPods（ADR-006） 
调研发现 Qiniu SDK 已官方支持 SPM（https://github.com/qiniu/objc-sdk
v8.9.x），AMap 仍仅支持 CocoaPods 或手动 XCFramework；CocoaPods 1.15.2
不兼容 Xcode 26 的 PBXFileSystemSynchronizedRootGroup，需绕道 Bundler
才能升到 1.16+。综合性价比决定不引入 CocoaPods 工具链，所有闭源 SDK
（含 AMap）统一走 Vendor .xcframework 手动接入。

- Design §14.1 三层策略改写为两层（SPM + Vendor），新增 Vendor 接入
  标准流程 6 步法
- Design §14.2 AMap 接入方式从 CocoaPods 改为 Vendor，Qiniu 标注 SPM
  URL 与版本
- Plan §2.3 / §5 Phase 5.1 / §6.1 / §8 同步 AMap Vendor 化
- Plan 新增 ADR-006 完整决策记录
- CLAUDE.md 新增「依赖管理约定」节，禁止引入 CocoaPods
 2026-06-21 21:46:19 +08:00
joywayer 2a3d985dd7 调整极光 2026-06-21 20:48:41 +08:00
joywayer d18ea4f1c5 新增所需资源，修改优化文档 2026-06-21 20:40:46 +08:00
joywayer beb05ab451 添加文档和CLAUDE.md 2026-06-21 19:39:22 +08:00