一个人做微信小游戏这件事听起来很美好但实际上绝大多数时间都是在跟工具链和平台规则搏斗。我自己从零搭了一个一人工作室白天上班晚上和周末写代码用Unity做了三款微信小游戏前两款的评价是“能玩但不能火”第三款总算跑通了留存和广告变现。这一路踩过的坑尤其是Unity微信小游戏打包、视频播放、广告接入、排行榜这些环节几乎每个都能单独写一篇复盘。如果你也准备走这条路或者正在做类似的东西这篇实战笔记应该能帮你少走不少弯路。我先说结论微信小游戏依然是小团队和个人开发者最值得尝试的方向之一原因不是技术门槛低而是分发链路短、社交裂变强、变现闭环完整。但它的难点也恰恰藏在这些“看起来很简单”的外壳之下——包体限制、运行环境差异、广告组件接入、数据回流每个环节都有一堆反直觉的细节。这篇文章我会按我实际开发的顺序把从选型到打包从视频方案到广告设计再到排行榜、分享和常见坑一次性讲透。1. 一人工作室做微信小游戏先把这些事想清楚1.1 为什么是微信小游戏而不是App或者Steam做独立游戏的人都有过平台选择的纠结。我的判断逻辑其实很朴素一个人开发最缺的是流量和分发能力。Steam和App Store的上架门槛不高但发现机制对新手极不友好上架之后没人下载才是常态。微信小游戏则完全不同它天生长在微信的社交关系链里用户玩完一关随手分享到群里被朋友点开就是一次新增这种传播效率是其他平台给不了的。另一个关键点是变现。微信小游戏对个人开发者开了一个口子——只要满足一定用户规模条件就能开通流量主接入广告系统无需版号针对一些轻度休闲品类在特定政策下相对更宽松实际操作仍需遵守最新规定但确实比独立App买量变现的门槛低很多。你不需要做内购、不需要对接支付系统流量主的激励视频、插屏、Banner广告把变现链路完全标准化了。我当时给自己定了一个目标先用一个周末做出可玩原型一个月内上线三个月内验证广告变现模型。这个节奏在App或Steam上根本跑不动但在微信小游戏里是真实可行的。1.2 技术选型Unity、Cocos还是纯微信原生微信小游戏本质上是一个运行在浏览器环境里的JavaScript应用所以Cocos和Laya这类以JS/TS为母语的引擎天然更契合社区里也有大量现成模板。但我最终还是选了Unity原因很个人化我的主力语言是C#Asset Store里有大量现成的美术资源和插件3D能力也是三选一里最强的。微信公众号官方提供了“微信小游戏Unity转换插件”可以把Unity工程转换成能在小游戏环境运行的包体这条路是官方长期维护的。这个选择有一个必须提前接受的代价Unity转微信小游戏不是“导出一次就完事”而是把Unity WebGL内容包在微信小游戏容器里跑。听起来绕但官方插件把大部分工作都自动化了你要做的是理解它的边界——哪些API能用、哪些不能用、性能损耗在哪里、包体如何压缩。选Unity意味着你拥有了3D和复杂2D表现的上限代价是调优成本更高。还有一点如果你完全不会Unity纯做2D休闲游戏Cocos Creator其实上手更快。一个人工作室的关键是“以最低成本做出能上线的产品”引擎只是工具别在这个环节纠结太久。2. Unity微信小游戏打包全流程从安装插件到真机预览2.1 环境准备Unity版本、微信开发者工具、转换插件我用的Unity长期支持版本是2021.3 LTS转换插件在Package Manager里直接搜索“wechat”就能出来安装“WeChat Mini Game”这个官方包。这里有个坑插件版本和Unity版本有兼容性要求装不上或者Build报错先看官方文档的兼容表别急着升级Unity。微信开发者工具必须装稳定版它会负责加载你Build生成的小游戏包提供模拟器和真机调试。我建议首次接触的人先在微信公众平台注册一个小游戏AppID测试阶段可以用测试号因为后面所有能力——广告、开放数据域、分享——都需要一个真实的AppID才能调通。插件的第一个作用是自动生成game.js、game.json等小游戏必需文件第二个作用是把Unity的WebGL产物转译成微信小游戏能加载的模块。安装好插件之后Unity菜单栏会出现一个“微信小游戏”菜单这就是打包入口。2.2 打包配置里的几个关键开关打包前必须改几项配置否则后面全是泪Player Settings - Other Settings里把Scripting Backend切到IL2CPP。Unity转微信小游戏走的是WebGL分支只能用IL2CPP。Api Compatibility Level选.NET Standard 2.0选了.NET Framework的话编译会报一堆API不兼容。主动设置一个你拥有的Bundle Identifier格式不要带下划线微信对包名的校验比较严格。勾选“Strip Engine Code”能明显减小包体但配合后文的link.xml使用。配置好后点“微信小游戏”菜单下的“Build”弹窗里填写AppID选好导出目录。第一次Build会拉取微信小游戏的基础模板之后等待编译顺利的话会生成一个包含game.js、unity-namespace.js和一堆Unity WebGL文件的目录。Build完成后打开微信开发者工具导入这个目录模拟器里就能跑起来。如果画面正常再点“真机预览”扫码手机上测一遍。这是每人必做的第一道关卡很多人第一版就卡在这里——不是白屏就是黑屏我后面会讲排查方法。2.3 包体4MB限制和远程资源方案微信小游戏的主包限制是4MB总包也有上限这一点是所有Unity转小游戏开发者的头号敌人。Unity一个空项目Build出来就接近20MB如果不做资源拆分连预览都过不去。我的做法是主包只放核心代码和启动场景所有美术、音频、视频全部打成AssetBundle放到CDN或者自己的服务器上。启动时先展示一张加载图同时用UnityWebRequest下载所需AB包下载完成后再进入游戏。这里有一个关键策略AB包要按功能拆不要一个包塞到底。我拆成“公共UI”“角色动画”“关卡美术”“音频”四类每个关卡的资源单独打包玩家到第5关才下载第5关的资源首启下载量控制在3MB以内加载时间控制在2到3秒。微信对远程资源有域名白名单要求下载用的资源地址必须填到微信公众平台后台的“downloadFile合法域名”里而且必须是HTTPS。缓存方面我用了微信小游戏提供的文件系统接口把AB包存到本地带版本号命名每次启动先请求一个版本配置文件发现新版本再增量下载。自己写这套逻辑不复杂但一定要处理断网、下载失败和缓存损坏三种异常否则玩家会在加载页卡死。2.4 代码裁剪和AOT那个绕不开的坑Unity转微信小游戏后C#代码会被编译成WebAssemblyIL2CPP自带的代码裁剪会把没被直接引用的类和成员全部删掉。如果代码里用了反射、动态加载或者某个库的特性运行时会报“MissingMethodException”或“FileNotFoundException”。我在第一个项目里用Newtonsoft.Json做解析发布后频繁报错查了很久才发现是代码裁剪把JsonConvert的相关方法裁掉了。解决办法是在Assets目录下建一个link.xml文件把需要的程序集和类型显式保留。另一个更隐蔽的坑是AOT泛型类在某些路径下无法生成代码表现是本地编译没问题真机上特定操作直接崩。预防方法是在开发阶段多用真机测试并且避免在热更新路径里写过于复杂的泛型嵌套。打包文档里有一个“剥离类型”的开关默认是开的如果你的游戏逻辑大量依赖反射先关掉试试。3. 微信小游戏里的视频播放我踩了一遍坑终于跑通3.1 为什么Unity自带的VideoPlayer不能直接用做游戏剧情、过场动画、新手引导时视频是最直观的表现手段。但Unity的VideoPlayer在微信小游戏环境里并不可靠。原因有三一是视频文件不能塞进包体放远程的话VideoPlayer的跨域请求在浏览器环境里经常被拦截二是即使能播放视频画面渲染在多线程环境里会被卡顿声音也不同步三是视频无法稳定显示在Unity UI之上特别是当你需要视频和游戏UI叠加时。我的结论是不要试图用Unity方案解决视频播放直接调用微信小游戏提供的原生视频组件。3.2 正确方案用jslib调用wx.createVideo微信小游戏本身有视频组件可以实现原生播放器支持全屏、进度控制、封面等功能。要在Unity里调用它需要通过插件提供的“jslib互调机制”让C#代码调用JavaScript函数。我在Unity工程里建了一个Plugins/WebGL目录写了一个minigame-video.jslib文件里面把wx.createVideo封装成了一个C#可以调用的方法。核心逻辑是这样C#端传入视频URL和播放位置JS端创建或复用微信视频组件设置src、poster、objectFit等属性然后播放。同时把onEnded、onError等事件函数注册好回调到Unity侧。对应的C#封装可以放在一个MonoBehaviour里暴露出Init(url)、Play()、Pause()、Stop()方法。这套机制的要点是理解C#与JS是异步交互C#不能同步等待视频状态所有状态都要通过事件回调。我在回调里使用UnityMainThreadDispatcher把事件派发回主线程再更新游戏逻辑避免跨线程操作Unity对象导致的崩溃。3.3 视频层级、生命周期和协议那些细节微信小游戏的原生视频组件是一个UI组件永远显示在Unity渲染画面之上。这意味着你不能指望视频上面再盖Unity UI否则层级会乱。我的处理方式是视频播放时把Unity UI整体隐藏或置灰不播放时把视频组件彻底销毁而不是暂停隐藏。销毁是必须的否则它会一直悬浮在界面上。生命周期方面小游戏切后台、微信窗口最小化、锁屏这些场景都会让视频组件状态异常。我监听wx.onHide事件自动暂停视频回到前台时根据业务需求决定是继续播放还是重播。还有协议问题视频地址必须是HTTPS同时要加到“downloadFile合法域名”或业务域名里。编码建议用H.264AAC的MP4iOS和Android兼容性最好尽量用低码率版本可以减少加载缓冲时间。3.4 内容和广告视频要分开处理内容视频比如剧情过场和广告视频是两套逻辑。内容视频用上面的自定义方案。广告视频则直接走微信广告组件你在代码里调用wx.createRewardedVideoAd传入广告位ID即可不需要自己处理播放器UI。广告视频和内容视频混用播放器会互相干扰尤其是激励视频的播放优先级很高我建议二者彻底解耦分别管理状态。4. 广告接入与激励视频设计一个人也要把变现想明白4.1 微信小游戏广告类型和开通条件微信小游戏流量主支持多种广告形态我实际用下来最核心的是激励视频、插屏和Banner。激励视频用户主动点击观看完整观看后获得奖励。单价最高是休闲游戏的主要收入来源。插屏在游戏自然切换时弹出按展示计费用户反感度较高要控制频率。Banner常驻或自动展示单价低但稳定适合挂在结算页面。开通流量主有用户规模门槛一般是累计注册用户数达到一定标准后后台会开放申请入口。个人开发者和企业开发者在广告单价、类目权限上有一些差异但个人主体完全够用。想要在开发阶段测试广告流程可以用微信广告后台提供的“测试广告位ID”请求到的是测试广告不会产生真实收入。4.2 激励视频点位怎么设计才不惹人烦激励视频的收益模型其实是单位时长收益所以设计的核心不是“把广告塞满”而是“让用户心甘情愿看完”。我失败过一次第一款游戏在关卡失败时强制弹出激励视频用户点击“再来一次”就自动拉取广告结果次留特别低。后来看数据才发现用户不是反感广告而是反感被绑架的感觉。第二款游戏我改成这样设计点位复活看广告玩家失败后提供一个“看广告复活保留当前进度”的按钮玩家主动点击才触发。双倍奖励每日签到、关卡结算时看广告领双倍金币。额外抽卡抽角色或道具时看广告增加一次抽卡机会。免费体力体力耗尽时看广告立即恢复。这样每个广告都对应一个明确的用户目标看广告是达成目标的“捷径”而不是“惩罚”。另外必须做频率控制同一个激励视频广告位在短时间内不能重复触发。微信后端也有频控但自己还是要在代码里加一层避免广告组件在onClose回调里再次show时返回错误码这是很多人会踩的bug。4.3 用数据优化广告收入渗透率比ECPM重要做过流量主的人都会盯一个指标ECPM千次展示收入。但ECPM是平台侧决定的你能干预的空间很小。真正能优化的是渗透率和人均展示次数。渗透率观看激励视频的人数/活跃人数。我给自己的及格线是25%优秀线是40%。人均展示次数则取决于游戏深度和奖励点位数量。我第三款游戏的活跃用户人均激励视频展示在5到7次之间广告填充率能到95%以上。如果某个点位人均展示能达到2次以上说明这个位点设计得合理如果低于0.5次就该换位置或换奖励。广告代码里也要处理onError回调填充失败时不要让用户等待直接关闭广告并发放一个安慰奖励这样至少不会流失玩家。5. 排行榜、分享裂变和数据分析让小游戏活起来5.1 开放数据域好友排行榜的实现细节微信小游戏里“好友排行榜”是很多玩家愿意反复刷的核心驱动力但它的实现和普通游戏完全不同。出于隐私保护主域不能直接获取好友的微信信息所有“好友关系数据”只能在开放数据域里读取和绘制。开放数据域和主域是两个隔离环境。主域通过wx.setUserCloudStorage把当前玩家的得分写到微信的云端存储里开放数据域通过wx.getFriendCloudStorage拿到好友的分数列表。由于开放数据域里不能运行Unity排行榜界面只能用canvas或WebGL自行绘制再用OpenDataContext.postMessage把玩家自己的分数传进去决定是否刷新。我第一次实现时遇到一个奇怪现象排行榜只要一显示Unity界面就变模糊。后来才知道开放数据域的canvas是永久的2D画板显示排行榜时需要把它当做一个普通UI元素用并且要控制它的渲染帧率别每帧重绘。具体节奏是收到主域postMessage后OpenDataDataContext重新拉取一次好友数据绘制一帧之后不再持续重绘这样可以大幅降低性能消耗。5.2 分享裂变让玩家主动帮你拉新分享是微信小游戏最核心的传播机制。我用过最有效的套路是“互惠型分享”玩家在关卡里碰到一个限时奖励分享到群后奖励翻倍。这里的细节在于分享动作本身不一定真的成功onShareAppMessage只是发起分享用户可能分享到任意会话或取消。为了防刷可以请求分享场景但个人开发者能做的校验有限我的思路是让分享的奖励“小额多次”即便被刷损失也可控。还有一个容易忽略的点分享出去的卡片文案和图片要精心设计。微信会截取当前游戏画面作为分享图但这张图切在UI卡住的瞬间很容易变成一张黑屏。我特意做了一个“分享专用截屏”在分享时隐藏敏感UI展示角色和分数文案里带上“你能超过我吗”这类挑战信息点击率能提升一倍。5.3 数据埋点和留存分析微信公众平台自带的基础数据能看访问来源、用户画像但这远远不够。我在游戏里埋了十几个自定义事件全部上报到自己的日志接口启动、完成新手引导、通过第几关、观看广告、分享成功、领取奖励。每天花十分钟看一眼这些数据就能知道玩家卡在哪一关、广告点在哪些位置被触发。最关键的是留存曲线。次日留存低于20%说明新手引导或核心玩法有问题七日留存低于8%说明内容深度不够。我会用关卡漏斗来定位问题玩家从第1关到第2关的流失率超过50%那一定是难度曲线太陡如果活跃用户人均在线时长小于5分钟就要考虑增加可玩点或增加让人想“再玩一把”的机制。数据能给你一个客观的调整方向而不是自我感觉良好。6. 电脑上查看小游戏资源包以及那些必须进速查表的坑6.1 电脑微信里的小游戏资源到底能不能看很多人玩微信小游戏后想找安装包里的美术、音频资源学习或者检查自己发布的版本有没有丢资源。电脑版微信在聊天和浏览小游戏后会在本地留下该小游戏的资源缓存目录通常在微信数据目录下的一个以小游戏AppID命名的文件夹里内部是打包好的文件资源。这个资源目录对个人开发者最大的用处是调试当你怀疑线上包和本地包不一致时可以在这里核对版本号和资源哈希确认是否上传了正确版本。作为学习参考也能看到其他开发者是怎么组织资源结构和压缩素材的。但必须说清楚游戏资源和代码是别人的智力成果拿来做逆向和抄袭是违规的我建议仅仅把它当作自查工具不要动歪心思。查看方式也很简单打开电脑微信的设置找到文件管理里的“打开文件夹”按钮按AppID定位目录只在需要的场景下使用。6.2 高频报错排查速查表我自己整理了一份高频问题表几乎每次有新成员加入开发流程都会发一遍问题现象排查方向解决办法真机白屏模拟器正常看真机Console日志多半是资源下载跨域或API版本过低升级基础库版本检查HTTPS和合法域名加资源下载容错视频播放黑屏但有声音视频格式或编码不支持或objectFit不对统一H.264AAC的MP4检查poster是否设置正确广告拉取失败error code 1004广告位ID错误、测试广告位失效、网络问题检查广告位ID确认测试广告位没有过期onError里友好降级包体超限无法预览未开启资源远程化或场景里引用了大资源主包只留启动场景AB资源全部远程化开启Strip Engine Code微信开发者工具内存溢出场景纹理过大或脚本死循环压缩大图减少同时加载的AB包使用AssetBundle.Unload分享后奖励不发放onShareAppMessage回调不代表用户真正分享成功改造为“分享成功回调”要结合onShareComplete逻辑奖励小额化控制风控这里特别提醒微信小游戏的基础库版本迭代很快某些API在老版本里不可用。开发时在game.json中配置一个合适的最低基础库版本别为了兼容过老机型影响新API的使用。6.3 上线审核和版本发布节奏微信小游戏上线审核最容易被拒的几种情况诱导分享文案、测试广告未关闭、缺少隐私政策说明、包体里存在违规内容。我的经验是提交审核前花十分钟走查一遍所有UI文案把“分享得奖励”改成“邀请好友助力得奖励”这类合规表达避免出现“必须分享才能继续”的强诱导。审核通过不代表结束游戏上线后的版本迭代反而更频繁。我按周更节奏走每周修bug、调参数每两周上一个小版本每月尝试一个新玩法模块。这样做的好处是能让老玩家持续有新鲜感算法也会因为活跃度提升而给你更多自然流量。版本更新时资源版本号一定要同步更新否则老玩家会加载到旧的缓存资源出现UI错乱。最后一个经验是关于配置后台的广告位、分享文案、域名配置、数据存储这些后台配置一定要做成一键可查的文档尤其是多个游戏并行开发时没有文档很容易搞混。微信后台的配置项很分散我把每个游戏常用的配置截图存到同一个目录里每次要改动第一时间找到地方省下很多搜索时间。写在最后的个人体会这一年多下来我最深的感受是一人工作室做微信小游戏真正的竞争力不在代码写得多好而在你能不能把一个很小的玩法做到完整、顺畅、让人愿意多玩两局。技术坑再多都是可以查文档解决的但玩法和变现节奏的设计只能靠自己对玩家心理的理解。如果你现在正准备开始我建议你按这个顺序推进先做一个30秒就能玩明白的原型上传测试号让朋友试玩确认玩法有趣再开始美术留白和广告接入。别嫌流程慢小游戏的生命周期可能很短但准备得越充分上线后的机会越大。最后再分享一个小技巧任何新功能上线前先小范围灰度几天用数据对比再做决定。一个人做产品时容易拍脑袋数据才是你最好的合伙人。 
长河君 · 2026/9/19 23:37:53 · 阅读 1.2k Unity微信小游戏实战：从打包到广告变现的完整踩坑指南
一个人做微信小游戏这件事听起来很美好但实际上绝大多数时间都是在跟工具链和平台规则搏斗。我自己从零搭了一个一人工作室白天上班晚上和周末写代码用Unity做了三款微信小游戏前两款的评价是“能玩但不能火”第三款总算跑通了留存和广告变现。这一路踩过的坑尤其是Unity微信小游戏打包、视频播放、广告接入、排行榜这些环节几乎每个都能单独写一篇复盘。如果你也准备走这条路或者正在做类似的东西这篇实战笔记应该能帮你少走不少弯路。我先说结论微信小游戏依然是小团队和个人开发者最值得尝试的方向之一原因不是技术门槛低而是分发链路短、社交裂变强、变现闭环完整。但它的难点也恰恰藏在这些“看起来很简单”的外壳之下——包体限制、运行环境差异、广告组件接入、数据回流每个环节都有一堆反直觉的细节。这篇文章我会按我实际开发的顺序把从选型到打包从视频方案到广告设计再到排行榜、分享和常见坑一次性讲透。1. 一人工作室做微信小游戏先把这些事想清楚1.1 为什么是微信小游戏而不是App或者Steam做独立游戏的人都有过平台选择的纠结。我的判断逻辑其实很朴素一个人开发最缺的是流量和分发能力。Steam和App Store的上架门槛不高但发现机制对新手极不友好上架之后没人下载才是常态。微信小游戏则完全不同它天生长在微信的社交关系链里用户玩完一关随手分享到群里被朋友点开就是一次新增这种传播效率是其他平台给不了的。另一个关键点是变现。微信小游戏对个人开发者开了一个口子——只要满足一定用户规模条件就能开通流量主接入广告系统无需版号针对一些轻度休闲品类在特定政策下相对更宽松实际操作仍需遵守最新规定但确实比独立App买量变现的门槛低很多。你不需要做内购、不需要对接支付系统流量主的激励视频、插屏、Banner广告把变现链路完全标准化了。我当时给自己定了一个目标先用一个周末做出可玩原型一个月内上线三个月内验证广告变现模型。这个节奏在App或Steam上根本跑不动但在微信小游戏里是真实可行的。1.2 技术选型Unity、Cocos还是纯微信原生微信小游戏本质上是一个运行在浏览器环境里的JavaScript应用所以Cocos和Laya这类以JS/TS为母语的引擎天然更契合社区里也有大量现成模板。但我最终还是选了Unity原因很个人化我的主力语言是C#Asset Store里有大量现成的美术资源和插件3D能力也是三选一里最强的。微信公众号官方提供了“微信小游戏Unity转换插件”可以把Unity工程转换成能在小游戏环境运行的包体这条路是官方长期维护的。这个选择有一个必须提前接受的代价Unity转微信小游戏不是“导出一次就完事”而是把Unity WebGL内容包在微信小游戏容器里跑。听起来绕但官方插件把大部分工作都自动化了你要做的是理解它的边界——哪些API能用、哪些不能用、性能损耗在哪里、包体如何压缩。选Unity意味着你拥有了3D和复杂2D表现的上限代价是调优成本更高。还有一点如果你完全不会Unity纯做2D休闲游戏Cocos Creator其实上手更快。一个人工作室的关键是“以最低成本做出能上线的产品”引擎只是工具别在这个环节纠结太久。2. Unity微信小游戏打包全流程从安装插件到真机预览2.1 环境准备Unity版本、微信开发者工具、转换插件我用的Unity长期支持版本是2021.3 LTS转换插件在Package Manager里直接搜索“wechat”就能出来安装“WeChat Mini Game”这个官方包。这里有个坑插件版本和Unity版本有兼容性要求装不上或者Build报错先看官方文档的兼容表别急着升级Unity。微信开发者工具必须装稳定版它会负责加载你Build生成的小游戏包提供模拟器和真机调试。我建议首次接触的人先在微信公众平台注册一个小游戏AppID测试阶段可以用测试号因为后面所有能力——广告、开放数据域、分享——都需要一个真实的AppID才能调通。插件的第一个作用是自动生成game.js、game.json等小游戏必需文件第二个作用是把Unity的WebGL产物转译成微信小游戏能加载的模块。安装好插件之后Unity菜单栏会出现一个“微信小游戏”菜单这就是打包入口。2.2 打包配置里的几个关键开关打包前必须改几项配置否则后面全是泪Player Settings - Other Settings里把Scripting Backend切到IL2CPP。Unity转微信小游戏走的是WebGL分支只能用IL2CPP。Api Compatibility Level选.NET Standard 2.0选了.NET Framework的话编译会报一堆API不兼容。主动设置一个你拥有的Bundle Identifier格式不要带下划线微信对包名的校验比较严格。勾选“Strip Engine Code”能明显减小包体但配合后文的link.xml使用。配置好后点“微信小游戏”菜单下的“Build”弹窗里填写AppID选好导出目录。第一次Build会拉取微信小游戏的基础模板之后等待编译顺利的话会生成一个包含game.js、unity-namespace.js和一堆Unity WebGL文件的目录。Build完成后打开微信开发者工具导入这个目录模拟器里就能跑起来。如果画面正常再点“真机预览”扫码手机上测一遍。这是每人必做的第一道关卡很多人第一版就卡在这里——不是白屏就是黑屏我后面会讲排查方法。2.3 包体4MB限制和远程资源方案微信小游戏的主包限制是4MB总包也有上限这一点是所有Unity转小游戏开发者的头号敌人。Unity一个空项目Build出来就接近20MB如果不做资源拆分连预览都过不去。我的做法是主包只放核心代码和启动场景所有美术、音频、视频全部打成AssetBundle放到CDN或者自己的服务器上。启动时先展示一张加载图同时用UnityWebRequest下载所需AB包下载完成后再进入游戏。这里有一个关键策略AB包要按功能拆不要一个包塞到底。我拆成“公共UI”“角色动画”“关卡美术”“音频”四类每个关卡的资源单独打包玩家到第5关才下载第5关的资源首启下载量控制在3MB以内加载时间控制在2到3秒。微信对远程资源有域名白名单要求下载用的资源地址必须填到微信公众平台后台的“downloadFile合法域名”里而且必须是HTTPS。缓存方面我用了微信小游戏提供的文件系统接口把AB包存到本地带版本号命名每次启动先请求一个版本配置文件发现新版本再增量下载。自己写这套逻辑不复杂但一定要处理断网、下载失败和缓存损坏三种异常否则玩家会在加载页卡死。2.4 代码裁剪和AOT那个绕不开的坑Unity转微信小游戏后C#代码会被编译成WebAssemblyIL2CPP自带的代码裁剪会把没被直接引用的类和成员全部删掉。如果代码里用了反射、动态加载或者某个库的特性运行时会报“MissingMethodException”或“FileNotFoundException”。我在第一个项目里用Newtonsoft.Json做解析发布后频繁报错查了很久才发现是代码裁剪把JsonConvert的相关方法裁掉了。解决办法是在Assets目录下建一个link.xml文件把需要的程序集和类型显式保留。另一个更隐蔽的坑是AOT泛型类在某些路径下无法生成代码表现是本地编译没问题真机上特定操作直接崩。预防方法是在开发阶段多用真机测试并且避免在热更新路径里写过于复杂的泛型嵌套。打包文档里有一个“剥离类型”的开关默认是开的如果你的游戏逻辑大量依赖反射先关掉试试。3. 微信小游戏里的视频播放我踩了一遍坑终于跑通3.1 为什么Unity自带的VideoPlayer不能直接用做游戏剧情、过场动画、新手引导时视频是最直观的表现手段。但Unity的VideoPlayer在微信小游戏环境里并不可靠。原因有三一是视频文件不能塞进包体放远程的话VideoPlayer的跨域请求在浏览器环境里经常被拦截二是即使能播放视频画面渲染在多线程环境里会被卡顿声音也不同步三是视频无法稳定显示在Unity UI之上特别是当你需要视频和游戏UI叠加时。我的结论是不要试图用Unity方案解决视频播放直接调用微信小游戏提供的原生视频组件。3.2 正确方案用jslib调用wx.createVideo微信小游戏本身有视频组件可以实现原生播放器支持全屏、进度控制、封面等功能。要在Unity里调用它需要通过插件提供的“jslib互调机制”让C#代码调用JavaScript函数。我在Unity工程里建了一个Plugins/WebGL目录写了一个minigame-video.jslib文件里面把wx.createVideo封装成了一个C#可以调用的方法。核心逻辑是这样C#端传入视频URL和播放位置JS端创建或复用微信视频组件设置src、poster、objectFit等属性然后播放。同时把onEnded、onError等事件函数注册好回调到Unity侧。对应的C#封装可以放在一个MonoBehaviour里暴露出Init(url)、Play()、Pause()、Stop()方法。这套机制的要点是理解C#与JS是异步交互C#不能同步等待视频状态所有状态都要通过事件回调。我在回调里使用UnityMainThreadDispatcher把事件派发回主线程再更新游戏逻辑避免跨线程操作Unity对象导致的崩溃。3.3 视频层级、生命周期和协议那些细节微信小游戏的原生视频组件是一个UI组件永远显示在Unity渲染画面之上。这意味着你不能指望视频上面再盖Unity UI否则层级会乱。我的处理方式是视频播放时把Unity UI整体隐藏或置灰不播放时把视频组件彻底销毁而不是暂停隐藏。销毁是必须的否则它会一直悬浮在界面上。生命周期方面小游戏切后台、微信窗口最小化、锁屏这些场景都会让视频组件状态异常。我监听wx.onHide事件自动暂停视频回到前台时根据业务需求决定是继续播放还是重播。还有协议问题视频地址必须是HTTPS同时要加到“downloadFile合法域名”或业务域名里。编码建议用H.264AAC的MP4iOS和Android兼容性最好尽量用低码率版本可以减少加载缓冲时间。3.4 内容和广告视频要分开处理内容视频比如剧情过场和广告视频是两套逻辑。内容视频用上面的自定义方案。广告视频则直接走微信广告组件你在代码里调用wx.createRewardedVideoAd传入广告位ID即可不需要自己处理播放器UI。广告视频和内容视频混用播放器会互相干扰尤其是激励视频的播放优先级很高我建议二者彻底解耦分别管理状态。4. 广告接入与激励视频设计一个人也要把变现想明白4.1 微信小游戏广告类型和开通条件微信小游戏流量主支持多种广告形态我实际用下来最核心的是激励视频、插屏和Banner。激励视频用户主动点击观看完整观看后获得奖励。单价最高是休闲游戏的主要收入来源。插屏在游戏自然切换时弹出按展示计费用户反感度较高要控制频率。Banner常驻或自动展示单价低但稳定适合挂在结算页面。开通流量主有用户规模门槛一般是累计注册用户数达到一定标准后后台会开放申请入口。个人开发者和企业开发者在广告单价、类目权限上有一些差异但个人主体完全够用。想要在开发阶段测试广告流程可以用微信广告后台提供的“测试广告位ID”请求到的是测试广告不会产生真实收入。4.2 激励视频点位怎么设计才不惹人烦激励视频的收益模型其实是单位时长收益所以设计的核心不是“把广告塞满”而是“让用户心甘情愿看完”。我失败过一次第一款游戏在关卡失败时强制弹出激励视频用户点击“再来一次”就自动拉取广告结果次留特别低。后来看数据才发现用户不是反感广告而是反感被绑架的感觉。第二款游戏我改成这样设计点位复活看广告玩家失败后提供一个“看广告复活保留当前进度”的按钮玩家主动点击才触发。双倍奖励每日签到、关卡结算时看广告领双倍金币。额外抽卡抽角色或道具时看广告增加一次抽卡机会。免费体力体力耗尽时看广告立即恢复。这样每个广告都对应一个明确的用户目标看广告是达成目标的“捷径”而不是“惩罚”。另外必须做频率控制同一个激励视频广告位在短时间内不能重复触发。微信后端也有频控但自己还是要在代码里加一层避免广告组件在onClose回调里再次show时返回错误码这是很多人会踩的bug。4.3 用数据优化广告收入渗透率比ECPM重要做过流量主的人都会盯一个指标ECPM千次展示收入。但ECPM是平台侧决定的你能干预的空间很小。真正能优化的是渗透率和人均展示次数。渗透率观看激励视频的人数/活跃人数。我给自己的及格线是25%优秀线是40%。人均展示次数则取决于游戏深度和奖励点位数量。我第三款游戏的活跃用户人均激励视频展示在5到7次之间广告填充率能到95%以上。如果某个点位人均展示能达到2次以上说明这个位点设计得合理如果低于0.5次就该换位置或换奖励。广告代码里也要处理onError回调填充失败时不要让用户等待直接关闭广告并发放一个安慰奖励这样至少不会流失玩家。5. 排行榜、分享裂变和数据分析让小游戏活起来5.1 开放数据域好友排行榜的实现细节微信小游戏里“好友排行榜”是很多玩家愿意反复刷的核心驱动力但它的实现和普通游戏完全不同。出于隐私保护主域不能直接获取好友的微信信息所有“好友关系数据”只能在开放数据域里读取和绘制。开放数据域和主域是两个隔离环境。主域通过wx.setUserCloudStorage把当前玩家的得分写到微信的云端存储里开放数据域通过wx.getFriendCloudStorage拿到好友的分数列表。由于开放数据域里不能运行Unity排行榜界面只能用canvas或WebGL自行绘制再用OpenDataContext.postMessage把玩家自己的分数传进去决定是否刷新。我第一次实现时遇到一个奇怪现象排行榜只要一显示Unity界面就变模糊。后来才知道开放数据域的canvas是永久的2D画板显示排行榜时需要把它当做一个普通UI元素用并且要控制它的渲染帧率别每帧重绘。具体节奏是收到主域postMessage后OpenDataDataContext重新拉取一次好友数据绘制一帧之后不再持续重绘这样可以大幅降低性能消耗。5.2 分享裂变让玩家主动帮你拉新分享是微信小游戏最核心的传播机制。我用过最有效的套路是“互惠型分享”玩家在关卡里碰到一个限时奖励分享到群后奖励翻倍。这里的细节在于分享动作本身不一定真的成功onShareAppMessage只是发起分享用户可能分享到任意会话或取消。为了防刷可以请求分享场景但个人开发者能做的校验有限我的思路是让分享的奖励“小额多次”即便被刷损失也可控。还有一个容易忽略的点分享出去的卡片文案和图片要精心设计。微信会截取当前游戏画面作为分享图但这张图切在UI卡住的瞬间很容易变成一张黑屏。我特意做了一个“分享专用截屏”在分享时隐藏敏感UI展示角色和分数文案里带上“你能超过我吗”这类挑战信息点击率能提升一倍。5.3 数据埋点和留存分析微信公众平台自带的基础数据能看访问来源、用户画像但这远远不够。我在游戏里埋了十几个自定义事件全部上报到自己的日志接口启动、完成新手引导、通过第几关、观看广告、分享成功、领取奖励。每天花十分钟看一眼这些数据就能知道玩家卡在哪一关、广告点在哪些位置被触发。最关键的是留存曲线。次日留存低于20%说明新手引导或核心玩法有问题七日留存低于8%说明内容深度不够。我会用关卡漏斗来定位问题玩家从第1关到第2关的流失率超过50%那一定是难度曲线太陡如果活跃用户人均在线时长小于5分钟就要考虑增加可玩点或增加让人想“再玩一把”的机制。数据能给你一个客观的调整方向而不是自我感觉良好。6. 电脑上查看小游戏资源包以及那些必须进速查表的坑6.1 电脑微信里的小游戏资源到底能不能看很多人玩微信小游戏后想找安装包里的美术、音频资源学习或者检查自己发布的版本有没有丢资源。电脑版微信在聊天和浏览小游戏后会在本地留下该小游戏的资源缓存目录通常在微信数据目录下的一个以小游戏AppID命名的文件夹里内部是打包好的文件资源。这个资源目录对个人开发者最大的用处是调试当你怀疑线上包和本地包不一致时可以在这里核对版本号和资源哈希确认是否上传了正确版本。作为学习参考也能看到其他开发者是怎么组织资源结构和压缩素材的。但必须说清楚游戏资源和代码是别人的智力成果拿来做逆向和抄袭是违规的我建议仅仅把它当作自查工具不要动歪心思。查看方式也很简单打开电脑微信的设置找到文件管理里的“打开文件夹”按钮按AppID定位目录只在需要的场景下使用。6.2 高频报错排查速查表我自己整理了一份高频问题表几乎每次有新成员加入开发流程都会发一遍问题现象排查方向解决办法真机白屏模拟器正常看真机Console日志多半是资源下载跨域或API版本过低升级基础库版本检查HTTPS和合法域名加资源下载容错视频播放黑屏但有声音视频格式或编码不支持或objectFit不对统一H.264AAC的MP4检查poster是否设置正确广告拉取失败error code 1004广告位ID错误、测试广告位失效、网络问题检查广告位ID确认测试广告位没有过期onError里友好降级包体超限无法预览未开启资源远程化或场景里引用了大资源主包只留启动场景AB资源全部远程化开启Strip Engine Code微信开发者工具内存溢出场景纹理过大或脚本死循环压缩大图减少同时加载的AB包使用AssetBundle.Unload分享后奖励不发放onShareAppMessage回调不代表用户真正分享成功改造为“分享成功回调”要结合onShareComplete逻辑奖励小额化控制风控这里特别提醒微信小游戏的基础库版本迭代很快某些API在老版本里不可用。开发时在game.json中配置一个合适的最低基础库版本别为了兼容过老机型影响新API的使用。6.3 上线审核和版本发布节奏微信小游戏上线审核最容易被拒的几种情况诱导分享文案、测试广告未关闭、缺少隐私政策说明、包体里存在违规内容。我的经验是提交审核前花十分钟走查一遍所有UI文案把“分享得奖励”改成“邀请好友助力得奖励”这类合规表达避免出现“必须分享才能继续”的强诱导。审核通过不代表结束游戏上线后的版本迭代反而更频繁。我按周更节奏走每周修bug、调参数每两周上一个小版本每月尝试一个新玩法模块。这样做的好处是能让老玩家持续有新鲜感算法也会因为活跃度提升而给你更多自然流量。版本更新时资源版本号一定要同步更新否则老玩家会加载到旧的缓存资源出现UI错乱。最后一个经验是关于配置后台的广告位、分享文案、域名配置、数据存储这些后台配置一定要做成一键可查的文档尤其是多个游戏并行开发时没有文档很容易搞混。微信后台的配置项很分散我把每个游戏常用的配置截图存到同一个目录里每次要改动第一时间找到地方省下很多搜索时间。写在最后的个人体会这一年多下来我最深的感受是一人工作室做微信小游戏真正的竞争力不在代码写得多好而在你能不能把一个很小的玩法做到完整、顺畅、让人愿意多玩两局。技术坑再多都是可以查文档解决的但玩法和变现节奏的设计只能靠自己对玩家心理的理解。如果你现在正准备开始我建议你按这个顺序推进先做一个30秒就能玩明白的原型上传测试号让朋友试玩确认玩法有趣再开始美术留白和广告接入。别嫌流程慢小游戏的生命周期可能很短但准备得越充分上线后的机会越大。最后再分享一个小技巧任何新功能上线前先小范围灰度几天用数据对比再做决定。一个人做产品时容易拍脑袋数据才是你最好的合伙人。