Commit Graph
77 Commits
Author SHA1 Message Date
joywayer 45a8f483bc Phase 1.14.a:替换 AppIcon 为 docs/res 内 msext 旧版图标
从 docs/res/Images.xcassets/AppIcon-1.appiconset 拷贝 9 个 png +
Contents.json 到 ylgamehall/Assets.xcassets/AppIcon.appiconset,替换
Xcode 默认空 universal 1024 模板。

- 9 个 png 覆盖 iPhone 29x29 / 40x40 / 57x57 / 60x60 三档分辨率 ×
  @1x/@2x/@3x 组合(msext 历史素材,分辨率名 "129x29" 等是文件名
  artifact,实际对应规格表里的 29x29)
- Contents.json 沿用旧版 iPhone-specific idiom,含 iOS marketing
  1024 占位(无文件名)
- BuildProject 通过,actool 3 个 warning 暂不处理(iPad 76/83.5
  缺失 → iOS 自动用 iPhone 缩放;1024 marketing 缺失 → App Store
  上架要求,企业签不强制);Phase 10 上线前 polish 时补齐
- 顺手发现 BridgedWebView.swift:88 用 WKProcessPool 在 iOS 15+ 被弃用,
  Phase 1.14.d 实施 WebContainer 时一并清理

Plan §5 1.14.a / §8 进度已勾选
2026-06-22 02:36:59 +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 87304552c3 docs:勾选 Plan §5 / §8 Phase 1.10-1.13 进度 + CLAUDE.md 新增「进度同步规范」
把 Plan 任务清单和进度追踪 checklist 同步到当前实际进度(1.10-1.13
均已完成 + 实测验证),并在 CLAUDE.md 写入"每完成 Phase 子项必须立即
更新 Plan 进度"的硬约束。

- Plan §5 Phase 1.10-1.13 任务清单 [ ] → [x]
- Plan §8 进度追踪同步:标注算法名 / 端到端实测结果(260→261 验证)
- CLAUDE.md 新增「进度同步规范」节,规定:
  - Plan §5 + §8 每完成子项立即勾选,与 commit 同 commit 内完成
  - 任务描述与实现有差异时同步修订(不允许 Plan 与代码长期不一致)
  - commit message 末尾备注"Plan 进度已勾选"
  - 理由:Plan 是项目记忆的唯一权威进度视图,新人 clone 后看 Plan
    §8 即可知整体进度;与 commit log 双写互为校验

Plan 进度已勾选
2026-06-22 02:30:31 +08:00
joywayer 0887088bb8 Phase 1.13:LobbyZipUpgrader 完成 H5 zip 升级端到端链路
Phase 1 远程配置链路(1.10-1.13)最后一环:把 VersionResolver 解出的
gameZip URL 下载 + 解压 + 原子 rename 到 lobbyRoot,触发条件是远端
gameVersion > 本地 version.xml /game/version@value。

- 新增 ylgamehall/Source/Resource/LobbyZipUpgrader.swift
  - public actor,单例 LobbyZipUpgrader.shared
  - upgradeIfNeeded(resolved:) async throws -> Outcome
    - .noop:远端版本 ≤ 本地,或 gameZip nil / 非法 URL,直接返回
    - .upgraded(from:to:):完成升级,附前后版本号
  - URLSession.download(from:) 异步下载(60s 请求 / 300s 资源超时),
    HTTP 状态码非 2xx 抛 .httpStatus
  - 解压到 caches/lobby-staging-{UUID}/ 隔离目录(不直接覆盖 lobbyRoot,
    msext "removeItem + ZipArchive overWrite:YES" 半途崩溃会留半残;
    我们 staging 完整解压成功后才 rename)
  - 原子 rename:fm.removeItem(lobbyRoot) → fm.moveItem(staging,
    to: lobbyRoot);任一步失败抛 .stagingMoveFailed,调用方决定回退
  - 类型化 UpgradeError 5 种:badGameZipURL / downloadFailed /
    httpStatus / unzipFailed / stagingMoveFailed
  - 实现照搬 msext NewRootVC.m:1789-1869 downFileFromServer + unzip
    + unzipDone 的语义,但用现代 async + 原子 rename 替代 ASIHTTPRequest
    + detachNewThreadSelector + ZipArchive overWrite:YES
- RootViewController 烟雾测试串接 LobbyZipUpgrader:
  调 upgradeIfNeeded → switch outcome → 升级后重新读 version.xml 验证
- 真机实测端到端链路:
  第一次:本地 260 vs 远端 261 → 升级完成 261,耗时 2.007s
    (下载 11.5 MB HTTP zip + ZIPFoundation 解压 + 原子 rename)
    重新读 version.xml = 261 ✓ lobbyIndex 仍存在 ✓
  第二次:本地 261 vs 远端 261 → .noop,耗时 0.001s(幂等验证)

Phase 1 远程配置链路(1.10-1.13)完整闭环。下一步 Phase 1.14
WebContainer 把这条链路插到 viewDidLoad 之前 + 16:9 letterbox 加载
lobbyIndex,第一次让真实大厅 H5 渲染出来。
2026-06-22 02:27:48 +08:00
joywayer 9e50c38323 Phase 1.12:LocalVersionReader 读 version.xml + ATS 全局放行
新增 LocalVersionReader 读两个本地版本号 + Info.plist 加
NSAllowsArbitraryLoads 全局放行 HTTP(为 Phase 1.13 zip 下载链路准备)。

- 新增 ylgamehall/Source/Resource/LocalVersionReader.swift
  - public enum LocalVersionReader,nonisolated static 命名空间
  - localAppVersion: Int 从 BundleConfig.shared.appVersion 转 Int
    (沿用 ChannelConfig.plist 注入),解析失败返回 0
  - localGameVersion: Int 用 Foundation XMLParser SAX 风格解析
    SandboxPaths.lobbyVersionXML 的 /game/version@value 节点,
    缺失 / 损坏返回 0(msext NewRootVC.m:664-682 `[nil intValue]=0`
    兜底语义,是首装后首次升级的关键机制)
  - subGameVersion(dir:start:) 子游戏版本号读取,Phase 6 用
  - 内部 VersionXMLHandler 标 nonisolated(Swift 6 严格并发下
    XMLParserDelegate 跨边界),SAX 风格只在 didStartElement 抓
    version 节点的 value 属性
- Info.plist 加 NSAppTransportSecurity / NSAllowsArbitraryLoads = true
  - 企业签 / 超签分发场景,后端域名易变(zip CDN / 配置服 /
    七牛 / 错误日志上报等),白名单维护成本高于安全收益
  - 全局放行的副作用主要影响第三方 SDK 流量;本项目无意外引入未审计
    SDK,且第三方 SDK 自身一般也走 HTTPS,不受影响
  - 详见 ADR-008 决策上下文与 CLAUDE.md「不上架 App Store,企业签 /
    超签 / TF 分发」契约
- RootViewController 烟雾测试串接 LocalVersionReader:打印本地 vs 远端
  对比 + IPA / zip 升级判定
- 真机实测(现网 .txt 本地 + 当前 IPA 内 gamehall.zip 解压物):
  - 本地 appVersion = 43, 远端 = 43 → 不升级
  - 本地 gameVersion = 260(IPA 内 2023-12 zip 的 version.xml),
    远端 = 261 → 需要 zip 升级。Phase 1.13 将实现下载 +
    解压 + 替换链路
2026-06-22 02:24:22 +08:00
joywayer dfbc26a024 Phase 1.11:VersionResolver chulishengji 双子树合并算法
实现 msext NewRootVC.m:1372-1538 的 chulishengji 双子树合并算法的纯
函数 Swift 版本,把远端 RemoteConfig 化简为 5 个目标字段决策结果
(appVersion / appDownload / gameVersion / gameZip / showmessage)。

- 新增 ylgamehall/Source/Network/VersionResolver.swift
  - public enum VersionResolver + 纯函数 static func resolve
  - public struct ResolvedVersion: Sendable 含 5 字段
  - 内部 SubtreeExtract 中转 4 字段累加结果(每层非空才覆盖)
  - extractAgentSubtree 4 层(agent → channel → market → game 嵌
    market 命中后)按 NewRootVC.m:885-1013 复刻
  - extractGameSubtree 4 层(game → game-self → channel → market)
    按 NewRootVC.m:1015-1180 复刻
  - mergeIPA 默认 agent 赢;game.appVersion > agent.appVersion 时
    game 赢(NewRootVC.m:1416)
  - mergeZip 默认 game 赢;agent.gameVersion > game.gameVersion 时
    agent 赢(NewRootVC.m:1456)
  - showmessage 任意子树非空就用,最后写赢;回退到 config.showmessage
- 字段名 game_download vs game_zip 由 SubtreeExtract.gameZip 统一吸收,
  Codable 模型已用 gameZip 命名,故无需重复查两个 key
- RootViewController 烟雾测试串接 RemoteConfigClient + VersionResolver,
  打印 chulishengji 合并后的 5 字段
- 真机实测(现网 .txt JSON):
  - appVersion = 43 → 等于本地 BundleConfig.appVersion,不触发 IPA 升级
  - gameVersion = 261 → 远端最新版(本地 version.xml 待 Phase 1.12 读取
    后对比;首装后 version.xml 实测 261 等于本地)
  - gameZip = http://tsgames.daoqi88.cn/zip2/gamehall.zip
    (HTTP,Phase 1.13 下载需 ATS NSExceptionDomains daoqi88.cn)
  - appDownload = itms-services://... 企业签 manifest URL
  - showmessage = ""(无运营公告)
- 单测目前未写(等 Phase 0.2 单测 target 建立后补齐),但生产数据
  已验证算法正确
2026-06-22 02:18:27 +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 65505b0a79 Phase 1.9:BridgedWebView 封装 WKWebView + JS 注入 + BridgeBus
WebContainerViewController(Phase 1.10)的视图层依赖项:把 WKWebView 配置 /
WVJB.js 注入 / 桥总线 / scrollView 契约配置 4 件事一锅端打包成单一 UIView,
后续大厅 / 子游戏 / 弹层 VC 直接 add 进自己的内容区即可。

- 新增 ylgamehall/Source/WebView/BridgedWebView.swift
  - @MainActor final class,继承 UIView
  - 内含 public let webView: WKWebView 与 public let bridge: BridgeBus
  - init() 全自动:
    - WKWebViewConfiguration 按契约 §4.1:
      defaultWebpagePreferences.allowsContentJavaScript = true(iOS 14+
      现代 API,替代已弃用的 preferences.javaScriptEnabled)、
      javaScriptCanOpenWindowsAutomatically = NO、minimumFontSize = 10、
      allowsInlineMediaPlayback = true、processPool = SharedProcessPool.shared
    - 用 WKUserScript(.atDocumentStart) 把 WebViewJavascriptBridge.js 注入
      所有加载的 H5 页面,确保 H5 业务代码运行前 bridge 已就绪
    - 创建 BridgeBus,自动向 controller 注册 WVJBHandler 通道
    - scrollView:bounces=NO / isScrollEnabled=NO(契约硬约束,漏则 H5
      上下滑动失控)/ contentInsetAdjustmentBehavior=.never / 双向无指示器
    - WebView 撑满 self,自动布局
  - SharedProcessPool 命名空间:跨 WebView 共享 WKProcessPool,Cookie /
    资源缓存复用,启动加速(Design §3.5)
- BuildProject 通过,下一步 Phase 1.10 WebContainerViewController 用
  BridgedWebView 嵌入 + 16:9 letterbox + 加载 lobbyIndex
2026-06-22 00:19:51 +08:00
joywayer af1a2028e5 Phase 1.8:WebViewJavascriptBridge.js 协议源码入 Bundle
H5 端桥协议实现,与 BridgeBus 的消息格式 1:1 对齐:
H5 → Native 走 window.webkit.messageHandlers.WVJBHandler.postMessage(...),
Native → H5 走 window.WebViewJavascriptBridge._handleMessageFromObjC(base64)。

- 新增 ylgamehall/Resources/JS/WebViewJavascriptBridge.js(~130 行)
  - bridge.registerHandler(name, fn):H5 注册等待 Native callHandler
  - bridge.callHandler(name, data, responseCallback):H5 主动调 Native
  - bridge._handleMessageFromObjC(b64):Native 入口,base64 → JSON parse
    → 派发到 H5 handler 或匹配响应 responseCallbacks
  - base64 解码用 decodeURIComponent + atob 处理 UTF-8 多字节字符
  - 兼容 marcuswestin 旧式 window.WVJBCallbacks 队列握手:注入后
    立即 flush 队列(H5 业务代码无需修改)
- RootViewController 加 Phase 1.8 烟雾测试:Bundle.main.url 找到 JS 文件
  并打印 bytes / head;synchronized group 会把 Resources/JS/ 子目录
  扁平化到 bundle 根,注释里说明此约束
- BuildProject 通过,bundle/WebViewJavascriptBridge.js 实际存在
- 下一步 Phase 1.9 BridgedWebView 用 WKUserScript(.atDocumentStart) 注入
  本文件到所有 H5 页面,桥真正生效
2026-06-22 00:16:55 +08:00
joywayer 4a6b1e1631 Phase 1.7:BridgeBus 实现 H5↔Native 消息总线 + WKScriptMessageHandler
桥核心的运行时层:把 BridgeProtocol 落到 WKWebView 上,承担 JS → Native
消息分发 + Native → H5 主动调用 + 双向 callback 配对。

- 新增 ylgamehall/Source/Bridge/BridgeBus.swift
  - @MainActor final class,BridgeProtocol + WKScriptMessageHandler 双重
    conform;init(webView:, controller:) 自动向 controller 注册 WVJBHandler
    通道
  - JS → Native(userContentController:didReceive:)
    - body 兼容单条 dict 与 batch [[dict]]
    - 优先识 responseId → 查 pendingCallbacks 派给 Native 端 callback
    - 否则按 handlerName 查 handlers,构造异步 responseCallback 闭包,
      handler 是 @Sendable async 用独立 Task 执行
  - Native → H5(call(_:data:callback:))
    - 拼 payload {handlerName, data, callbackId?},base64 后注入
      WebViewJavascriptBridge._handleMessageFromObjC('<base64>')
    - callback 用 nativeCallbackCounter 递增成 objc_cb_<n> 入
      pendingCallbacks,等 JS 响应回收
  - sendResponseToJS:拼 {responseId, responseData} 走同一通道
  - makeResponseCallback 辅助方法:把多层嵌套闭包拆出来,避免
    Swift 6 类型推断在深嵌套 + actor 隔离上 ICE
- 资源生命周期:webView 弱引用避免循环;BridgeBus 由 controller.add(self)
  retains,WebView 释放后 controller 一并清空 handler 列表自然 release
- BuildProject 通过,Swift 6 严格并发 0 warning;下一步 Phase 1.8 注入
  marcuswestin/WVJB JS 端配套协议即可双向消息打通
2026-06-22 00:11:54 +08:00
joywayer f740274d59 Phase 1.6:BridgeProtocol + BridgeData 协议骨架
桥核心的纯类型层,不依赖 WKWebView,便于 Phase 1.7 BridgeBus 实现与
单测注入 mock 都基于此抽象。

- 新增 ylgamehall/Source/Bridge/BridgeProtocol.swift
  - protocol BridgeProtocol: AnyObject, Sendable
    - register(_:handler:) 注册 H5 → Native handler,重复名覆盖
    - call(_:data:callback:) Native → H5 主动调用,callback 可选
  - typealias BridgeHandler = @Sendable (BridgeData?, BridgeCallback?)
    async -> Void,允许 handler 内部 await
  - typealias BridgeCallback = @Sendable (BridgeData?) -> Void
  - enum BridgeData: Sendable 六态(string/number/bool/null/array/object),
    与 JSON 值同构
- BridgeData JSON 互转:
  - init?(jsonObject:) 从 JSONSerialization 输出递归构造;NSNumber
    Bool/Double 鉴别用 CFGetTypeID 避免 NSNumber(value:true) 被当 1.0
  - var jsonObject: Any 反向,供 evaluateJavaScript 拼 JSON 字符串
- BridgeData 访问语法糖:asString/asInt/asDouble/asBool/asArray/asObject
  + subscript(key:) 对象字段访问 + subscript(index:) 数组访问
- BridgeData 字面量构造:ExpressibleByStringLiteral/IntegerLiteral/
  FloatLiteral/BooleanLiteral/ArrayLiteral/DictionaryLiteral,
  fixture / handler 代码 ["k": 1, "v": true] 直接构造 .object
- BuildProject 通过,Sendable 全自动派生
2026-06-22 00:05:26 +08:00
joywayer 463f0fc6fe Phase 1.5:ResourceUnzipper 解压 gamehall.zip 到 Caches 全链路打通
启动期完成「ChannelConfig.plist 读 → SandboxPaths 算路径 →
gamehall.zip 解压」三步,lobbyIndex 真实存在于沙盒 Caches,
为 Phase 1.10 WebContainer file:// 加载就绪。

- 新增 ylgamehall/Source/Resource/ResourceUnzipper.swift
  - public actor,全局单例 ResourceUnzipper.shared
  - ensureReady() async throws:检查 lobbyVersionXML 不存在则调
    FileManager.unzipItem (ZIPFoundation 扩展) 解压 Bundle 内
    gamehall.zip 到 SandboxPaths.lobbyRoot
  - UnzipError 类型化错误(bundleZipNotFound / unzipFailed)
  - 幂等:已就绪直接 return,并发调用安全(actor 串行)
- 新增 ylgamehall/Resources/gamehall.zip:从 docs/res 拷一份入
  Bundle(11.5 MB,2023-12 旧版;上线前由 H5 团队替换最新版,
  ADR-002 已记录)
- Swift 6 严格并发适配:
  - SandboxPaths:所有 static 成员标 nonisolated(无状态命名空间,
    从 actor / 非 MainActor 上下文都能直接读 caches/documents/bundle
    及 lobby 路径计算)
  - BundleConfig:class 整体 nonisolated(Sendable + all-let 属性,
    跨 actor 边界安全),允许 ResourceUnzipper actor 读 channel 配置
- RootViewController 补 ResourceUnzipper 烟雾测试 Task:
  await ensureReady() 后打印耗时 + lobbyIndex 是否真实存在
- 真机验证(iOS Simulator):首次 1.266s 解压成功,二次启动 0s 跳过
2026-06-22 00:01:08 +08:00
joywayer b866ee212c Phase 1.4:引入 ZIPFoundation SPM 依赖(v0.9.20)
ResourceUnzipper(Phase 1.5)的前置:用 ZIPFoundation 替代旧 ZipArchive
解压 gamehall.zip。ADR-006 纯 SPM + Vendor 策略下的首个 SPM 依赖。

- 引入:https://github.com/weichsel/ZIPFoundation
  - 版本 0.9.20(Up to Next Major,commit 22787ffb59de)
  - License: MIT;纯 Swift 实现,Xcode 26 原生兼容
  - 链接到 target ylgamehall
- pbxproj:XCRemoteSwiftPackageReference + XCSwiftPackageProductDependency
  写入;Package.resolved 锁定版本,多机 / CI 复现
- BuildProject 通过;ZIPFoundation 全部 .swift 由 SwiftCompile 实际
  参与构建,与 ylgamehall target 链接完成
- 附带:ChannelConfig.plist 移除内联说明注释(Phase 1.1 commit 后由
  维护者整理),不影响 plist 数据结构
2026-06-21 23:56:32 +08:00
joywayer 730574a2e2 Phase 1.3:SandboxPaths 统一沙盒 / Bundle / H5 路径入口
集中管理 NSSearchPathFor... 调用,避免散落,方便后续 ResourceUnzipper
(Phase 1.5)与 WebView 加载(Phase 1.10)复用。

- 新增 ylgamehall/Source/Resource/SandboxPaths.swift
  - 基础:caches / documents / bundle
  - 大厅 H5:lobbyRoot / lobbyIndex / lobbyVersionXML(基于 BundleConfig
    当前渠道值动态拼接)
  - 子游戏 H5:subGameRoot(_:) / subGameIndex(_:_:)(Phase 6 调用,
    入参传 SwitchOverGameData 解出的 dir/start)
  - 全部 enum + static,无状态,Swift 6 严格并发零负担
- RootViewController.viewDidLoad 补 SandboxPaths 烟雾打印 6 项路径,
  便于首次启动 console 校验:
  - lobbyIndex 应为 {Caches}/FtJf073.../gamehall/index.html
  - lobbyVersionXML 应为 {Caches}/FtJf073.../gamehall/version.xml
- BuildProject 通过,synchronized group 自动收编新文件
2026-06-21 23:52:23 +08:00
joywayer dcc12bb76d Phase 1.2:BundleConfig 读 ChannelConfig.plist 完成 11 项渠道注入加载
- 新增 ylgamehall/Source/Resource/BundleConfig.swift
  - 11 个 public let 属性(qiniuDomain / gameId / channel / gameDir
    / gameStart / gameConfig / market / agent / appVersion / other
    / appleConfig)
  - public init(bundle: Bundle = .main) —— 默认走 main bundle,单测
    可注入 mock bundle 验证不同 plist fixture
  - PropertyListSerialization 反序列化 ChannelConfig.plist
  - final class + Sendable(all-let,String 是 Sendable,Swift 6
    严格并发下编译器静态校验通过)
  - 单例 BundleConfig.shared,业务统一通过此访问
- RootViewController.viewDidLoad 加烟雾测试 print 11 项值,首次运行
  真机/模拟器即可在 console 验证读取正确
- BuildProject 通过,synchronized group 自动收编 BundleConfig.swift
  为 source(.swift 文件类型走 SwiftCompile,不再卡 plist 那样的
  resource 扁平化问题)
- 单元测试待 Phase 0.2 单测 target 建立后补齐
2026-06-21 23:47:23 +08:00
joywayer c25a7514c7 fix(ChannelConfig.plist):注释去掉 -- 双连字符避免 XML parse 错误
XML 注释规范禁止 -- 出现在注释内,原注释包含的 codesign 命令示例
(--force / --sign / --entitlements)触发解析错误,Xcode 直接打开
plist 报 "XML Parse Error: Comment must not contain '--'"。

把详细命令示例移除,只保留单行简短指引,命令示例已在 Design
§7.0.3 写过,不在 plist 重复。
2026-06-21 23:45:38 +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 4e4290ded6 建立 .gitignore,清理误入库的 xcuserdata
- 标准 iOS/Swift 模板:忽略 build/DerivedData/xcuserdata、
  SPM .build、CocoaPods Pods/、签名证书、本地敏感配置
- 保留 Package.resolved / Podfile.lock / Vendor/ 入库
  以保证多人 + CI 依赖锁定与闭源 SDK 可分发
- 同时把误入库的 xcuserdata/xcschememanagement.plist 从
  版本控制移除(本地文件保留)
2026-06-21 20:05:21 +08:00
joywayer 7a84223841 M0:项目基础配置就绪(横屏锁定、Swift 6、代码启动)
- 锁定 iPhone/iPad 仅横屏(LandscapeLeft/Right),契合 H5 端
  1280×720 设计分辨率;UIRequiresFullScreen=true 防 iPad
  多任务下方向不锁
- Swift Language Version 升到 6.0(配合已启用的
  Approachable Concurrency + MainActor 默认隔离)
- 删除默认 Main.storyboard / ViewController.swift 模板,
  改用 SceneDelegate 代码创建 RootViewController 启动,
  Build Settings 同步清空 INFOPLIST_KEY_UIMainStoryboardFile
- Info.plist 补齐契约项 UIStatusBarHidden=NO、
  UIViewControllerBasedStatusBarAppearance=YES,配合
  AppDelegate 启动时设置 applicationSupportsShakeToEdit=true
  覆盖契约 §4.2.1 摇一摇前置
- BuildProject 通过验证
2026-06-21 20:03:33 +08:00
joywayer 1da2884358 CLAUDE.md:新增「及时提交」规则到提交规范
每完成一个可独立验证的工作单元(bug 修复 / 配置变更 /
文档更新 / 依赖升级 / M 里程碑子项)就主动提议提交,
BuildProject 通过 / 关键路径手测通过即立即提议。

理由:项目处于 greenfield 重写阶段,commit 颗粒越小
回滚成本越低;CLAUDE.md / docs 与 git log 一起构成
项目记忆,commit message 是"为什么"的第一现场。
2026-06-21 20:03:14 +08:00
joywayer beb05ab451 添加文档和CLAUDE.md 2026-06-21 19:39:22 +08:00
joywayer 108b359f96 Initial Commit 2026-06-21 19:37:33 +08:00