这件事的开头，就是一句话：
“把这个打包成手机安装包。”
我当时已经在 Chrome 里玩过 The Browsing of Isaac，也有自己的存档和 mod。想法很直接：把游戏文件装进 APK，在手机上离线玩。再搭一个自己的网页，让朋友也能复制这份初始配置，各自继续玩。
网页移植的底座来自 chiikabu 的项目。我和 Codex 后续折腾的，是手机操作、运行环境、资源加载、存档和发布。这些事情后来占了大部分时间。
第一版 APK 装上去，先迎来了这个报错：
The module failed to load，下面还有一句 piece 0:0: invalid whole response。等到能进游戏，又发现帧率只有几帧，角色操作也不完整。安装包生成成功，只能算第一步。为了看清手机上的实际情况，我们折腾了浏览器对照、日志和无线调试。我用的是 Redmi K70 Ultra，手边没找到合适的数据线，最后走了无线连接。中间还反复遇到手机休眠、调试端口变化、电脑连不上的情况。手机上显示已经配对过，电脑照样可能连不上当前地址。
后来 APK 用上了独立的 Chromium 内核，游戏资源也一起放进安装包，最后的包大约 624 MB。包确实不小，但下载、安装完成后，游戏本身可以离线运行。至于具体帧率和手感，还是得拿手机玩了才知道。
能跑起来以后，触控很快成了另一个大问题。选项往上滑，结果往反方向切。射击往左拖，有时却朝右。还有一些操作在电脑上按一下键就行，到了手机上根本找不到入口。
我起初也在想，要不要把键盘上能用的键都加出来。继续玩才发现，游戏本来就有触控区域，道具、炸弹、卡牌和药丸都可以利用游戏里的位置操作。额外按钮主要补确认、Ctrl、丢弃和工具，没必要再把一套方向键铺到屏幕上。
按钮补齐后，又开始挡画面。
有一版四个按钮挤成两排，直接压在左上角的游戏信息上。我给的反馈很直接：“你这按钮什么意思，都遮挡了，就不能竖着排吗？”横屏两边明明有黑边，最后就让这四个按钮在左侧黑边竖排，保留半透明背景，字体颜色也统一下来。回溯和终端则收进了可展开的工具菜单里。
再玩，又发现会误触。手指只是经过按钮，操作就已经执行了。于是改成在按钮内完成一次点按才触发，按下后拖动、滑出，或者游戏状态已经变化，就取消这次操作。“碰到就执行”和“点完再执行”，放到手机上差别很明显。
首页也跟着改了几轮。我想要的是有以撒地下室味道的界面，人物却一度画得完全不像。最后保留了纸张、地下室门和简单的卡通画法，重新调整了角色。能用之外，这也是我想继续改下去的一部分：打开它的时候，至少应该像在准备玩以撒。
相比之下，性能排查就没有这么直接了。
我先注意到，帧率高的时候，游戏速度似乎也跟着变快。加入节奏控制后，另一些卡顿又让我怀疑，是不是新改的刷新逻辑出了问题。手机上进新房间、触发机关、使用道具，都可能突然掉帧，过一会儿又恢复。
我当时很笃定地说，以前没这么卡，肯定和刚改的东西有关。但关掉新增的限帧做对照，仍然会卡。这一步至少让我不能再只盯着限帧逻辑。
继续看等待记录，发现卡住的时候存在资源读取等待，也就是游戏要用某个文件时，它还没准备好。后来把完整资源提前下载下来，我在手机上的体感明显好了。这是一条有用的线索，但还不能据此说所有卡顿都找到了根因。怪多的房间、mod 和设备本身，仍然可能影响运行。
预下载解决了一部分等待，也带来了新的麻烦：约 373 MiB 的游戏资源，第一次下载要花时间。最初首页准备一次配置，进游戏页又出现加载，看起来像是又下了一遍，体验很差。
于是把存档、mod 和游戏资源都放到首页统一准备。进度条会显示速度和预计剩余时间，可以暂停，完成的分段会保留下来，再次打开时接着下。资源按 1 MiB 分段下载，完整文件再做 SHA-256 校验。下载好以后，进入游戏主要做本地资源检查和引擎启动，不再重复展示一套下载过程。
下载慢的时候，我还拿手机上的下载器 ADM 做对比，问 Codex 为什么我们只能四路。后来确认，那是我们自己写的全局分段并发上限。现在默认 16 路，最高可以选到 128 路，暂停后再调整。
不过，“支持 128 路”没有让我得到一个可靠的最快档位。后续测速里，CDN 节点发生了变化，我这边还有其他网络上传，和下载器的对照也没完整跑完，就被我叫停了。所以这一版保留了可调选项，没有把某个档位写成已经证明最快。
存档的问题比掉帧更让我在意。有一次进隐藏房后崩溃，重载回来，这一层要从原来的起点重新打。手机上复制一长段报错日志又很麻烦，后来网页里补了诊断入口，可以看资源等待、存档写入和最近的错误，也能导出报告。
保存流程也加了检查：等本地数据库事务提交完成，再确认写入成功，失败时保留待写的数据并重试。但这依然不等于每个房间都会自动保存。游戏自己还没生成存档的进度，网页也恢复不出来。这一点最后直接写进了 README，避免把“存档保护”说得太满。
整个过程里，我做得最多的事情，就是在手机和电脑上玩，发现问题，然后继续追问 Codex。有时候是一个功能缺了，有时候只是按钮太大、太丑，或者位置不顺手。这些反馈往往没法靠读代码提前确认。
我也反复催它多开几个 agent。后来把界面、性能排查和 APK 分开处理，各自在独立的 worktree（同一份代码分出来的独立工作目录）里改，最后再整合。我的 Mac 不适合一边干别的事，一边反复跑完整构建，所以构建和检查都放到了 GitHub Actions。这样依然要等 CI，但至少能看到具体哪里通过、哪里失败。自动检查能覆盖按键、资源和保存流程，手机好不好操作，还得继续实机确认。
到发布时，又遇到一件之前没想到的事：APK 已经构建成功，签名和资源检查也过了，GitHub Actions 却提示产物存储配额满了，文件存不下来。
最后改用私有 Release 草稿暂存成品，再把文件转到公开仓库。中间试过用本机中转，速度慢，还会抢我其他上传任务的带宽，最终换成在 GitHub 云端直接复制。APK、对应源码和校验文件都传好以后，才正式公开。
现在项目叫 isaac-web-mobile，网页放在 isaac.hllqk.cn，原来的博客继续留在主域名。Android r2 也已经发布，沿用原来的包名和签名，README 里补上了真实截图、操作说明和已知问题。
它还不完美。网页版和 APK 各自保存进度，没有跨端自动同步，偶发崩溃也还不能保证全部消失。回头看，这次从一句“打包成安装包”开始，真正花时间的是打包之后的事：按钮挡不挡画面，点下去会不会误触，卡的时候到底在等什么，崩了以后存档还在不在。这些大多是我拿着手机一局一局玩出来的。我先把这一版发出来，让朋友能打开网页或者装上 APK，复制初始存档和 mod 以后，各自继续玩。
评论加载中…