微信小游戏适配

---

一、一句话结论#

适合，而且比大多数休闲小游戏更适合——包体和内存根本不是约束，只需要改三处工程细节。 真正决定生死的第四件事不在工程里，在留存里。

判断依据三条，每条都是算出来的，不是感觉：

必须改的三件事（都是工程，工作量可控）：

1. HUD 避让刘海与胶囊按钮——现在的 HUD 在原生 y 0~110，会被状态栏和右上角胶囊直接盖住（见 2.1）；
2. WebP 双轨——包一张 PNG 兜底图集，防止老 iOS 解不出 WebP 时首帧是空白兔子（见 2.4）；
3. wx.onHide 落盘 + wx.onShow 无弹窗续跑——"随时能停"必须落成机制，否则它只是一句宣传语（见五、六）。

第四件事不在工程里：图鉴 30 种植物 + 10 件遗物，5~8 天收齐，收齐之后没有回来的理由。 微信小游戏是"用完即走"的生态，它比任何平台都更需要一个"回来看看"的理由。 工程适配全部做完也只是"能上"，第 ④ 层循环做不出来就是"上了也没人留"。 这一条的判断标准和取舍已经写在 循环与商业化 第二节，这里只把它列为上线门槛（见八）。

---

二、适配可行性核对表#

总表先给结论，逐条展开在后面。

外部口径来源：分包加载、 本地存储、 文件系统、 音频、 高性能模式（内存限制）、 广告开通条件。

2.1 竖屏 9:16 与屏幕适配（需要改）#

小游戏没有"设计分辨率"这回事，画布就是屏幕。所以第一步是自建一个虚拟坐标系，规则必须是可算的，不能"差不多"。

规则（三条，缺一条就会在某些机型上错位）：

1. 宽度恒为 1080 虚拟单位，高度按屏幕实际比例伸缩： H = 1080 × screenHeight / screenWidth
2. 兔子地面线距屏幕底部恒为 538 虚拟 px，不按比例算。
3. 多出来的高度全给天空带（水彩大留白正好吃这个），少掉的高度从天空带顶部裁。

第 2 条是硬要求，理由是物理参数是绝对像素：重力 1800 px/s²、小跳初速 380（跳高 40 px）、 大跳初速 520（跳高 75 px）、台阶一级 22 px。这些数字一旦被缩放，跳跃余量就变了 （大跳过 72 px 的石头只剩 3 px 余量，再缩 5% 就会撞上）。 所以世界条必须是绝对尺寸，只有天空带是可伸缩的。

实测各机型换算（基准 1080×1920）：

看最后两列就能得出结论：地面线的屏幕百分比在 68.9% ~ 78.7% 之间浮动， 但距屏底永远是 538。所以：

• ✅ 地面线、地形剖面、手账条：距底锚定，绝对尺寸（538 / 153 / 269）
• ✅ 天空带：吸收全部差额，高度区间 692 ~ 1484 px
• ⚠️ 天空带的内容必须能在 692 px 内成立（16:10 是最坏情况）：云、远山、树线、灌木 从下往上排——树线贴世界条上沿，远山在其上，云在最上面（可被裁）。 云的铺法按密度而不是固定数量，否则窄天空里会挤成一堆。

刘海屏与胶囊按钮（这是"需要改"的具体所在）：

2.2 触摸操作（✅ 能）#

本项目只有三种手势，没有摇杆、没有虚拟按键、没有多点，是触摸适配里最省事的一档。

实现要点四条：

1. 坐标一律换算到 1080 虚拟系：vx = clientX × 1080 / screenWidth。 触摸事件给的是 CSS px，不要拿它和虚拟坐标直接比，否则高 DPR 机型上点不准。
2. 热区最小 88×88 虚拟 px（≈ 44×44 CSS px，微信/苹果的最小可点尺寸）。 岔路出口牌给 240×240 虚拟 px——它要能被拇指随便点中，因为这是玩家唯一的操作。
3. 触摸按 30 Hz 读取（每 2 帧一次）就够。蓄力条不需要 60 Hz，省下来的 CPU 留给渲染。
4. 不做"滑动返回"拦截。小游戏里从左边缘右滑不会触发系统返回（没有页面栈）， 但 Android 物理返回键会直接退出小游戏——这不是要拦的东西，因为本项目 任何一秒退出都不丢东西（见五）。

2.3 音频（✅ 能）#

体积账（按 96 kbps 单声道 = 12 KB/秒）：

2.4 帧动画与 WebP（需要改）#

三个必须分清的概念，混起来会做出错误决策：

WebP 还有两个本项目特有的坑：

• 水彩半透明边缘的"灰边"：有损 WebP 的 RGB 与 alpha 是分开压的，透明区域的 RGB 值会被邻近像素污染， 合成后边缘出现一圈脏色。本项目整套风格都是半透明水彩边缘，这个问题一定看得见。 做法：导出前做颜色外扩（alpha bleeding / dilate）——把边缘像素的 RGB 往透明区扩 2~4 px 再压缩；
• 不要为了"顺手"把 5 组动作合进一张大图。理由见 4.5（兔子同一时刻只播一组动作，合图集基本零收益， 反而多占 14% 纹理）。

2.5 本地存储与云开发（✅ 能）#

存档小是因为收集态用 bitmask：30 种植物 + 10 件遗物 = 40 格 = 5 字节， base64 之后 8 个字符。整个存档（收集位图 + 花园状态 + 版本号 + 时间戳）约 0.5 KB。

这个尺寸带来一个重要结论：每次收集都同步落盘是可行的。 一次 < 1 KB 的 setStorageSync 耗时 < 1 ms，一局最多 40 次收集，累积开销可以忽略。 不需要做"攒起来定时写"，也就不会出现"闪退丢最后几格"。

2.6 分包加载（✅ 能，且不需要妥协）#

详细的分包方案见第三节。

2.7 广告接入点（✅ 能，难在克制）#

本作唯一成立的激励视频位（详细论证见 循环与商业化 3.2）：

技术要点：激励视频实例必须复用单例（createRewardedVideoAd 返回单例）， onClose 里用 res.isEnded 判断是否完整观看； show() 失败要能静默退回（不弹错误、不阻塞流程），这是零失败原则在广告上的延伸。 广告加载失败时不提示、不降级成别的广告，直接当"这个按钮今天不在"。

2.8 分享与好友（需要改）#

本项目不做排行榜、不做数值攀比，社交只做两件 （这条不只是设计偏好，也是合规上的低风险选择，见七）：

---

三、包体预算表#

3.1 素材清单与实测体积#

3.2 主包预算（首包）#

主包 = 首次启动必须有、且不能等 的东西。

不放进主包的东西：30 种花的素材、10 件遗物、12 种小游戏、季节内容。 理由：第一次启动时玩家只看得到 5 种花和 1 只兔子，其余全部可以边跑边下。

冷启动下载时间估算（主包必须启动前下完）：

对比"把主包塞满 4 MB"的情况，弱网下省掉约 4.4 秒。这是"不引引擎"带来的直接收益。

3.3 分包方案#

总计（主包 + 常用分包）= 4 623 KB ≈ 4.51 MB，占 30 MB 上限的 15%。 加上 PNG 兜底轨也只有 5.88 MB。

不再需要 CDN 的理由：季节内容已经进了分包 C。剩下的边角（未来的第 3 季、限定外观） 再考虑走 wx.downloadFile 落到 wx.env.USER_DATA_PATH（200 MB 空间）， 那是上线半年后的事，现在不需要为它设计。

3.4 纹理内存估算#

这是包体之外的另一本账：磁盘体积 ≠ 内存占用。图片进内存后统一是 RGBA8888（4 字节/像素）。

对照官方口径：iOS 高性能模式下，2 GB RAM 机型（6s / 7 / 8）内存限制 1 GB，3 GB 以上机型 1.4 GB。

本作水位 ≈ 15.2 MiB  /  1000 MiB  =  1.5%

---

四、性能优化清单（按收益排序）#

4.0 先把成本算出来（不然排序是瞎排）#

竖屏横版是满屏重绘：每一帧整个屏幕都要重画。按 1080×1920 的虚拟坐标算每帧填充量：

60 fps → 296 M px/s。而且水彩画风是大面积半透明混合（alpha blending）， GPU 实际成本还要再乘一个系数。这就是本作唯一真实的性能风险所在—— 不是对象多，不是帧动画，是"一个屏幕上叠了太多层"。

同一项目此前在无 GPU 的测试机上量出的成本模型是 耗时(ms) ≈ 0.0221 × 实例数 + 14.8 × 百万像素——像素项的权重远大于实例项。 （那台机器是软件光栅化，绝对值不能直接用，但"往像素上使劲"这个方向是对的。）

所以下面按减少填充量排序，而不是按"看起来优雅"排序。

---

① 背景视差从 4 层降到 2 层，预烘焙成可平铺位图（收益最大）#

做法：把「云 + 远山」预渲染成一张 2160×884 的离屏位图（2160 = 两屏宽，保证无缝平移）， 「树线 + 灌木」再一张。每帧只做 drawImage 平移 blit，不再每帧走矢量路径画云和山。

收益：

推荐 2 层：保住视差（"风景即线索"需要纵深线索），拿到 −39%； 低端机档位再降到 1 层拿满 −58%。

额外收益：矢量绘制 → 位图 blit，省掉每帧的路径计算与渐变重算。 如果现在的云和远山是代码画的（本项目灰蓝水彩天空极可能是渐变 + 路径）， 这一项的收益可能比 39% 还大，因为它省的不只是填充，还有 CPU 侧的绘制命令构建。

注意：预烘焙位图要按虚拟高度分段（884 / 1304 / 1484 三档）， 为每档出一张，而不是用一张拉伸——拉伸会把水彩的纸纹和线条拉变形，破坏 美术规范 的验收标准。

---

② 低端机三档降级 + 自适应（性价比第二）#

三个旋钮的收益都是乘性的，叠加起来非常猛：

三项叠加（DPR 1 + 1 层 + 30 fps）= 高端的 1/16。

分档规则：

检测：wx.getSystemInfoSync().benchmarkLevel 只在 Android 有效 （取值 -2 / 0 = 该设备无法运行小游戏，-1 = 未知，≥1 越大越好）。 iOS 上恒为 -1，所以 iOS 必须靠首 60 帧的帧时间滑动平均自适应：

若 滑动均值 > 22 ms → 降一档（有 10 秒冷却，避免抖动）
只降不升（升档会来回横跳，体验比一直低画质更差）

顺带一提：低端机降 DPR 到 1 时，画布变成 540×960， 这时候 64×64 的序列帧和 128×128 在屏幕上是一样清楚的—— 所以"降 DPR"和"降烘焙尺寸"要同时降，这是本作最省的一刀（一次改动，填充率和纹理内存双降）。

---

③ 对象池：横向滚动不要每帧 new（收益在 p99，不在均值）#

要池化的东西：世界条里循环滚动的所有物件。

池容量怎么算（不要拍脑袋）：

最密情况：世界条宽 1080 虚拟 px ÷ 最小物件间距 60 px = 18 个/层
地形有 6 个高度层（−2 ~ 3），但同屏不重复铺满 → 有效层数取 4
物件池 = 18 × 4 = 72 → 取 80
粒子池（摘花飞出、落地尘土） = 32
兔子 + 阴影 = 2
────────────────────────────
池总容量 = 114 个实例，启动时一次分配，之后永不 new / 永不 delete

回收策略（关键）：物件移出屏幕左侧时不是销毁，而是"重新绑定"：

if (obj.x < -80) { obj.x += 世界条总长; 重新绑定物种/尺寸/随机相位; }

收益：GC 触发次数从"每帧若干次"降到 0 次。 这项的收益不体现在平均帧时间上，而在 p99 抖动： 16.7 ms 的预算下，一次 5 ms 的 GC 就是一次可见掉帧。 验收方式不是看平均 fps，而是看帧时间 p99 ≤ 20 ms。

顺带：粒子、飘字、收集格高亮这些反馈全部用代码画，零素材 （这是 玩法 已经写死的约定），所以它们的池化成本只是几个浮点数组。

---

④ 地形高度图的渲染优化#

数据结构：地形高度层 −2~3 共 6 层，一级 22 px，总落差 66 − (−44) = 110 px。 跳跃水平距离是 127 px（小跳）/ 173 px（大跳），所以高度采样间距取 8 px 足够—— 一屏世界条宽 1080 → 135 个采样点。

三条优化：

1. 等高段合并（RLE）：渲染前把高度数组压成"连续等高的段"， 典型一屏只有 5~15 段，地形绘制调用从 135 次降到 ≤15 次（−89%）。
2. 草皮顶边预渲染成 6 张切片位图（每层一张，宽 128 可横向平铺）， 拼接绘制。不再每帧重画草叶的锯齿边——这些细节每帧都在变的话，肉眼看是"抖"的。
3. 土壤剖面（153 px 高）用一张可平铺的纹理位图，每帧只 blit 一次。

收益：地形绘制耗时预计 −60~75%，且顺带把画面稳定性提上来。

---

⑤ 帧动画图集合并（收益小，但顺手就做）#

这一条要如实说，不能为了显得"优化了"就把它排到前面：

结论：兔子不要合图集，合了反而多占 14% 纹理内存。

真正值得合的是常驻场景物件的 17 张——它们是同屏同时出现的：

该不该做？做。 理由是它不增加包体（合并后 WebP 通常更小，因为共享调色板）， 纹理 +0.39 MiB 在 15.2 MiB 的水位里毫无感知，而 bindTexture 的次数从 17 降到 1 对低端机的驱动开销是有意义的（移动 GPU 的纹理切换比桌面贵得多）。

但不要为了这一项把图集开到 2048×2048（16 MiB）——用 512×512 紧排， 浪费 19% 空间换取一整档内存，比"图集整齐"重要得多。

---

⑥ 首帧与冷启动#

---

⑦ 音频池（顺带）#

固定 8 个 InnerAudioContext 实例复用（stop() + play()，不重建）， BGM 独立 1 个。原因见 2.3：Android 同时播放上限是 10 个， 每次新建实例的写法在连续收集时会迅速撞上限，表现是"音效时有时无"，非常难查。

---

优化优先级排序（一页版）#

---

五、操作与交互适配#

5.1 三种手势的落地#

本作没有摇杆、没有虚拟按键、没有多点，三种手势各管一件事，互不重叠：

三条实现约束：

1. 所有触摸坐标换算到 1080 虚拟系（vx = clientX × 1080 / screenWidth）；
2. 最小热区 88×88 虚拟 px，出口牌 240×240——因为这是玩家唯一的手部操作， 点不中会让整个游戏变成"我在跟 UI 较劲"；
3. 触摸按 30 Hz 读取，不需要 60 Hz。

5.2 "随时能停"怎么从特性变成优势#

微信的核心场景是**"用完即走"：秒开、随时放下、下次再来。 大多数游戏和这个场景是对抗**的（体力、冷却、连续登录、限时活动，都是在阻止你走）， 本作是唯一不需要对抗的——它把"停下来"的成本做到了 0：

这四条合起来的效果：打开这个游戏的心理成本 ≈ 0，所以启动次数会高。 而微信生态里，"一天打开 3 次 × 4 分钟"比"一周打开 1 次 × 12 分钟"健康得多。

技术上必须落成机制，否则以上全是宣传语：

5.3 上线后指标要按"碎片化"来定#

---

六、登录与存档#

6.1 登录：本作没有"登录"这个动作#

6.2 存档结构（约 0.5 KB）#

6.3 三级存档与同步策略#

冲突合并：取并集。 collectMask = localMask | cloudMask，gardenStage = max(local, cloud)， lastVisitTs = max(local, cloud)。

6.4 "7 天不登录花园不会枯萎"怎么落地#

做法：绝对时间戳 + 分段函数，不模拟。

elapsed = now − lastVisitTs
stage   = f( min(elapsed, 7 天) )     ← 封顶在 7 天

为什么封顶在 7 天，两条理由都成立：

1. 不封顶 → 离线 30 天回来一口气跳过全部内容，内容被浪费，玩家也没看到过程；
2. 不封顶 → 反过来就得做"退化"（太久不来就枯萎），那就直接违反零失败铁律。

封顶函数是单调不减的：f(7天) = f(30天) = f(365天)。 离线一年回来，花园停在第 5 阶段，不会更差，也不会更满。

三条实现细节：

• 不需要"领取"。离线长出来的东西直接就在那里，玩家打开就能看见。 一旦需要点一下领，它就从"发现"变成"打卡"——那就变回每日签到了；
• 离线不推进关卡。花园按时间走，关卡进度冻结（回来还是原来那一步）；
• 不做每日签到（设计铁律，见 循环与商业化 第五节）。 花园自己长已经提供了"回来"的理由，而且不需要玩家做任何事。

---

七、发布与合规清单#

7.1 主体与类目#

7.2 资质与门槛清单#

7.3 内容合规注意点#

7.4 分享技术的合规边界（和 2.8 呼应）#

---

八、上线节奏建议#

8.1 五个阶段#

8.2 什么叫"成功了"（每个数字都要能埋点算出来）#

8.3 30 项自动化验收怎么搬过来#

现有的 30 项验收跑在无头 Chrome CDP 上，小游戏里没有等价的成熟工具链。不要赌，拆成两层：

---

九、风险清单#

---

十、下一步工单（按依赖排序）#

---

相关文档#

• 玩法 —— 自动跑跳的物理参数、竖屏三段式布局
• 关卡与解谜 —— 岔路谜题与选错的兜底
• 小游戏 —— 12 种小游戏与"只有一种操作"的准入标准
• 收集手册 —— 30 种植物、10 件遗物、花园成长
• 循环与商业化 —— 第 ④ 层循环、广告位取舍、版号路线
• 美术规范 —— 色板、线条规则、序列帧规范与验收标准