Unity转微信小游戏：水果扛狼广告接入与变现调优实战

做微信小游戏这几年，我经手过好几个 Unity 转小游戏的休闲项目，最典型的一类就是“水果扛狼”这种玩法：场上摆一排水果，同级的合成为更高级，狼群一波波从右边冲过来，玩家的水果就是防线，撑过关卡拿金币。玩法轻、单局短、上手门槛低，天然就是靠广告吃饭的产品。真到了“Unity-微信小游戏-水果扛狼-接入广告”这一步，问题往往不在“API 怎么写”，而在于点位怎么埋、频次怎么控、包体怎么压、真机上为什么不展示。这篇就把我踩过的坑按顺序摊开讲，从整体结构到三种广告形态的落地代码，再到排查手记，尽量让你少走两遍弯路。

1. 广告变现的整体设计：先定结构，再写代码

1.1 这个玩法为什么天生适合广告变现

“水果扛狼”这类合成塔防的骨架很固定：一局三到五分钟，失败点密集，复活需求强烈，金币永远不够用。这三个特征决定了它的广告位不需要硬塞，玩家自己会去找。合成类玩法的爽点在于“再合一级就能过”，而失败往往只差一点点，这个“差一点点”就是激励视频最好的入口。

我一般会先看三个数：单局时长、关卡失败率、金币缺口。单局三分钟左右，说明玩家在一局内可以接受一次主动看广告；失败率在 40% 到 60% 之间的关卡，复活广告的点击率最高；金币缺口指的是通关奖励和下一次升级消耗之间的差额，缺口越大，双倍奖励的吸引力越强。这三个数不需要很精确，跑两天埋点就能摸出来，但它们决定了你后面所有广告点位的密度上限。

反过来说，如果一局只有四十秒，或者失败率只有 10%，那说明玩法本身还没调好，这时候急着上广告，只会把留存拉垮。我见过一个早期版本，新手前三关就塞了插屏，结果次留直接掉了十几个点，后来把插屏挪到第五关之后，数据才回来。广告是放大器，不是救命药，玩法不成立的时候，加广告只会加速死亡。

1.2 三种广告形态的定位与点位规划

微信小游戏这边能用的主流形态就三种：激励视频、插屏、Banner。它们的角色完全不同，混着用就会互相打架。我的定位是这样的——

激励视频是绝对主力，这一点在休闲品类里几乎没有例外。它好在玩家有心理预期：我主动点的，看完拿奖励，不觉得被打扰。所以“水果扛狼”里我会埋三个激励点位：失败复活、结算双倍、金币补给。三个点位不要同时出现，同一屏最多给一个主动入口，否则玩家会觉得你在逼他看广告。

插屏的作用是承接“自然断点”。合成类游戏的自然断点很明确：一局结束、进入下一关、从关卡返回主界面。这三个时机玩家注意力本来就在切换，弹一个全屏广告的心理抵触最小。但插屏的频次必须硬控，我一般做成全局冷却，最短 180 秒一次，而且新手前若干关直接屏蔽。

Banner 是最容易被滥用的。它常驻在屏幕底部，看起来“反正不占操作区”，实际上在竖屏游戏里会直接压住最下面一排水果，误触率极高。我的做法是只在主界面、商店、关卡选择页展示 Banner，进入战斗立即隐藏。收益少了点，但留存保住了，长期算下来更划算。

1.3 Unity 转微信小游戏的技术栈与包体约束

技术栈这块，Unity 版本我一般锁在 2021 LTS 或更新的 LTS 分支，转换用平台官方提供的 Unity WebGL 转换插件。版本不要追新，转换插件对小版本是敏感的，我吃过一次亏：升级到一个刚发的补丁版本，构建出来的包在部分机型上直接黑屏，回退就正常了。所以工程一旦跑通，版本号就别乱动，写进项目文档里。

包体是第一道硬门槛。平台对代码包有体积上限，主包和整包都有约束，具体数字会调整，以你后台和官方文档的最新口径为准。但无论数字怎么变，思路是一样的：主包只放首屏必须的资源，其余全部走 AssetBundle 分包或远程加载。

“水果扛狼”的资源构成其实很轻：水果图标、狼的序列帧、几套 UI 图集、音效。真正占体积的是图集和音频。我的处理方式是：UI 图集开 ASTC 或 ETC2 压缩，按平台分套；狼的动画帧数从 24 帧砍到 12 帧，靠补间补足观感；背景音乐从 WAV 转成压缩格式，采样率降到 44.1kHz 以下。这一套下来，主包体积通常能砍掉一半以上。

还有个容易被忽略的点：首屏加载时间。小游戏的用户耐心极低，加载超过五秒流失非常明显。我会做一个极简的加载页，先加载主包内的 UI 和一张背景图，让玩家看到进度条在动，同时后台拉取第一关的资源包。玩家点“开始”的时候，第一关已经加载完了，体验上是无缝的。

2. 接入前的准备：账号门槛、广告位与工程改造

2.1 流量主门槛与广告位 ID 的管理方式

广告不是代码写完就能出量的。小游戏要开通流量主，需要达到平台规定的累计独立访客门槛，这个门槛目前是千级 UV 的量级，具体数字以后台显示为准。也就是说，你得先有真实的自然量，才能开始接广告。很多人在这一步卡住，以为是代码问题，其实是账号还没开通权限，createRewardedVideoAd直接返回 undefined 或者报错。

开通之后，后台会给你创建广告位，每个广告位有一个独立的 adUnitId。我的管理原则很简单：一个点位一个 ID，绝不复用。复活一个 ID、双倍一个 ID、金币补给一个 ID、插屏一个 ID、Banner 一个 ID。分开的好处是后台能看到每个点位的曝光、点击和收益，你才能判断哪个点位值得加权，哪个点位该砍掉。混用一个 ID，数据全糊在一起，调优就无从下手。

这些 ID 千万别硬编码在业务脚本里。我一般建一个 ScriptableObject 或者一个静态配置类，把 ID 按环境（开发/正式）分开存，打包的时候按构建目标切换。原因很实际：测试期用的是测试广告位，上线要换成正式位，硬编码的话每次都要全局搜索替换，漏一个就白干。

注意：广告位 ID 属于敏感配置，不要提交到公开的代码仓库，也不要写进前端可见的配置文件里被玩家扒出来，走构建时注入更稳妥。

2.2 Unity 工程的转换与体积瘦身

转换插件装好之后，第一件事不是急着构建，而是改 Player Settings。几个必改项：颜色空间用 Gamma 而不是 Linear，WebGL 1.0 的兼容性更好；关闭不必要的图形 API，只留 WebGL 2.0（如果目标机型支持）；Strip Engine Code 打开，把用不到的引擎模块剔掉，光这一项就能省下几百 KB 到 1MB。

音频设置是重灾区。Unity 默认的 WebGL 音频解码在移动端表现一般，我一般把加载方式改成“流式”或“按需”，背景音乐用流式，音效用“加载时解压”。另外，移动端浏览器有自动播放限制，音频必须等玩家第一次触摸屏幕之后才能播，这个后面会单独说。

纹理压缩要按平台分套。安卓侧 ETC2 兼容性最好，iOS 侧 ASTC 压缩比更高。转换插件里可以配置按平台输出不同的资源包，虽然构建时间翻倍，但包体收益明显。如果实在赶时间，至少把 UI 图集和角色图集分开压，UI 用高质量压缩，角色用中等质量，玩家肉眼几乎看不出差别。

最后是分包策略。我的习惯是按关卡组分包，每十关一个资源包，主包只留前三关。玩家玩到第四关才触发下载，这时候他已经投入了，等待容忍度高得多。分包加载要有进度提示和失败重试，弱网环境下第一次加载失败很常见，直接给个“重试”按钮比静默失败强。

2.3 广告 SDK 初始化时机与生命周期对齐

广告实例的创建时机很讲究。太早创建，玩家可能还没进游戏，白白消耗一次拉取机会；太晚创建，玩家点按钮的时候广告还没准备好，只能干等或者直接给奖励（那就亏了）。我的做法是：进入主界面后延迟一小段时间，在后台静默预加载激励视频，玩家真正点击时大概率已经 ready。

初始化必须和 Unity 的生命周期对齐。小游戏切后台再回来，页面会触发 onShow，这时候广告实例可能已经失效，需要重新检查状态。我在广告管理器里挂了一个“可见性检查”，每次应用获得焦点时判断当前广告实例是否可用，不可用就重新 load。这个细节不做，玩家切出去回个消息再回来，点复活按钮没反应，差评就来了。

还有并发保护。玩家手快，连点两下复活按钮，会触发两次 show，第二次必然报“广告正在展示中”。所以按钮点击的第一时间就要置灰，并且广告管理器内部加一个布尔锁，show 期间拒绝任何新的请求。这个锁不需要很复杂，一个状态枚举就够，但一定要有。

3. 核心实现：三种广告的代码落地

3.1 用 jslib 桥接打通 C# 与平台 API

Unity 转小游戏之后，C# 没法直接调平台的原生 API，中间必须过一层 JavaScript。有三种走法：一是用转换插件自带的封装类，二是自己写 .jslib 插件，三是直接在打包模板里注入 JS。我推荐第二种，因为可控、可调试、出问题好定位。

.jslib 的本质是一个 JS 文件，通过mergeInto把函数挂到 Unity 的调用表上。C# 端用DllImport("__Internal")声明同名函数，构建时链接器会自动匹配。先看 JS 这一侧——

// AdsBridge.jslib mergeInto(LibraryManager.library, { WXAd_CreateRewarded: function (adUnitIdPtr) { var adUnitId = UTF8ToString(adUnitIdPtr); if (!wx.createRewardedVideoAd) { SendMessage('AdBridge', 'OnAdError', 'api_not_supported'); return; } var ad = wx.createRewardedVideoAd({ adUnitId: adUnitId }); // 关键：把实例挂在全局，后续 show/load 复用同一个对象 window.__rewardedAd = ad; ad.onLoad(function () { SendMessage('AdBridge', 'OnRewardedLoaded', ''); }); ad.onError(function (err) { SendMessage('AdBridge', 'OnAdError', JSON.stringify({ code: err.errCode, msg: err.errMsg })); }); ad.onClose(function (res) { // isEnded 为 true 才算完整观看 var ended = res && res.isEnded ? '1' : '0'; SendMessage('AdBridge', 'OnRewardedClosed', ended); }); ad.load(); }, WXAd_ShowRewarded: function () { var ad = window.__rewardedAd; if (!ad) { SendMessage('AdBridge', 'OnAdError', 'ad_not_created'); return; } ad.show().catch(function () { // show 失败先 load 再重试一次，这是最常见的坑 ad.load() .then(function () { return ad.show(); }) .catch(function (e) { SendMessage('AdBridge', 'OnAdError', JSON.stringify({ code: e.errCode || -1, msg: e.errMsg || 'show_failed' })); }); }); } });

这里有两个细节值得单独说。第一，SendMessage的目标是一个挂在场景里的 GameObject，名字必须和 JS 里写的一致，我通常做一个常驻的AdBridge单例，DontDestroyOnLoad。第二，show()失败后必须重新load()再show()，直接连着调show()是不会成功的，这一点在官方文档里写得不显眼，但实际项目里几乎百分百会遇到。

C# 这一侧就是一层薄封装，负责把字符串回调转成事件：

using System; using UnityEngine; using System.Runtime.InteropServices; public class AdBridge : MonoBehaviour { public static event Action OnRewardedLoadedEvent; public static event Action<bool> OnRewardedClosedEvent; public static event Action<string> OnAdErrorEvent; void Awake() { DontDestroyOnLoad(gameObject); } #if UNITY_WEBGL && WEIXINMINIGAME [DllImport("__Internal")] private static extern void WXAd_CreateRewarded(string adUnitId); [DllImport("__Internal")] private static extern void WXAd_ShowRewarded(); #else private static void WXAd_CreateRewarded(string adUnitId) { } private static void WXAd_ShowRewarded() { } #endif public static void CreateRewarded(string adUnitId) { WXAd_CreateRewarded(adUnitId); } public static void ShowRewarded() { WXAd_ShowRewarded(); } // 以下三个方法由 JS 侧调用，名字必须完全一致 public void OnRewardedLoaded(string _) { OnRewardedLoadedEvent?.Invoke(); } public void OnRewardedClosed(string ended) { OnRewardedClosedEvent?.Invoke(ended == "1"); } public void OnAdError(string msg) { OnAdErrorEvent?.Invoke(msg); } }

编辑器里跑的时候，#else分支是空实现，这样你可以在 PC 上正常调试业务逻辑，不用每次都真机跑。这个技巧看着不起眼，但能省下大量构建时间。

3.2 激励视频：状态机 + 预加载 + isEnded 判定

激励视频最容易写错的地方，是把“展示成功”当成“观看完成”。show()返回成功只代表广告弹出去了，玩家看两秒就关掉，isEnded是 false，这时候绝对不能发奖励。我见过不止一个项目在这里翻车，上线当天就被刷爆了。

所以我用一个明确的状态机来管：

public enum AdState { None, Loading, Ready, Showing, Cooldown } public class RewardedVideoController : MonoBehaviour { [SerializeField] private string adUnitId; [SerializeField] private float cooldownSeconds = 5f; private AdState state = AdState.None; private float lastCloseTime = -999f; private Action onSuccess; private Action onFail; void OnEnable() { AdBridge.OnRewardedLoadedEvent += HandleLoaded; AdBridge.OnRewardedClosedEvent += HandleClosed; AdBridge.OnAdErrorEvent += HandleError; } void OnDisable() { AdBridge.OnRewardedLoadedEvent -= HandleLoaded; AdBridge.OnRewardedClosedEvent -= HandleClosed; AdBridge.OnAdErrorEvent -= HandleError; } public void Preload() { if (state == AdState.Loading || state == AdState.Ready) return; state = AdState.Loading; AdBridge.CreateRewarded(adUnitId); } public void Play(Action success, Action fail) { if (Time.time - lastCloseTime < cooldownSeconds) { fail?.Invoke(); return; } if (state != AdState.Ready) { // 没准备好就现拉，但要让 UI 显示 loading onSuccess = success; onFail = fail; Preload(); return; } onSuccess = success; onFail = fail; state = AdState.Showing; AdBridge.ShowRewarded(); } private void HandleLoaded() { if (state == AdState.Loading) { state = AdState.Ready; // 如果是"点了按钮才现拉"的场景，加载完立刻展示 if (onSuccess != null) { state = AdState.Showing; AdBridge.ShowRewarded(); } } } private void HandleClosed(bool ended) { state = AdState.Cooldown; lastCloseTime = Time.time; if (ended) { onSuccess?.Invoke(); } else { // 用户中途关闭，给出明确提示，不要静默失败 onFail?.Invoke(); } onSuccess = null; onFail = null; Preload(); // 立刻为下一次做准备 } private void HandleError(string msg) { Debug.LogWarning($"[Ad] rewarded error: {msg}"); state = AdState.None; onFail?.Invoke(); onSuccess = null; onFail = null; } }

几个实战经验。第一，HandleClosed里立刻调用Preload()，这样下一次点击大概率是秒开。第二，用户中途关闭要给明确反馈，比如弹一个“看完整视频才能复活哦”，而不是什么都不发生，后者会被玩家理解成“按钮坏了”。第三，冷却时间是防连点的，也防止玩家在一局里反复刷同一个广告，五秒是个比较稳妥的值。

“水果扛狼”里的复活点，我一般做成“本局仅一次”。第二次失败就不给复活入口了，改成“再来一局”。这样既保证了广告的稀缺性，也避免了无限复活导致的关卡难度失真。

3.3 插屏广告：冷却与重建实例

插屏的 API 比激励视频简单，但坑一点不少。最大的一个是：插屏实例在展示之后，很多基础库版本下需要重新创建才能再次展示，直接复用会报错。所以我的做法是每次展示前重建实例，虽然多了一点开销，但稳定。

// AdsBridge.jslib 追加 mergeInto(LibraryManager.library, { WXAd_ShowInterstitial: function (adUnitIdPtr) { var adUnitId = UTF8ToString(adUnitIdPtr); if (!wx.createInterstitialAd) { SendMessage('AdBridge', 'OnAdError', 'interstitial_not_supported'); return; } // 每次重建，规避复用失效问题 if (window.__interstitialAd) { window.__interstitialAd.destroy && window.__interstitialAd.destroy(); window.__interstitialAd = null; } var ad = wx.createInterstitialAd({ adUnitId: adUnitId }); window.__interstitialAd = ad; ad.onError(function (err) { SendMessage('AdBridge', 'OnAdError', JSON.stringify({ code: err.errCode, msg: err.errMsg })); }); ad.show().catch(function (e) { SendMessage('AdBridge', 'OnAdError', JSON.stringify({ code: e.errCode || -1, msg: e.errMsg || 'interstitial_show_failed' })); }); } });

C# 侧再包一层全局冷却：

public class InterstitialController : MonoBehaviour { [SerializeField] private string adUnitId; [SerializeField] private float globalCooldown = 180f; [SerializeField] private int unlockLevel = 5; private float lastShowTime = -9999f; private int currentLevel = 1; public void SetLevel(int level) { currentLevel = level; } public bool TryShow() { if (currentLevel < unlockLevel) return false; if (Time.time - lastShowTime < globalCooldown) return false; lastShowTime = Time.time; AdBridge.ShowInterstitial(adUnitId); return true; } }

unlockLevel这个参数很关键。新手前几关是留存的关键窗口，这时候弹全屏广告，等于把新用户往外推。我一般设到第五关之后，等玩家已经建立了“这游戏我能玩下去”的判断，再开始收割。冷却时长按 180 秒起步，如果你的关卡节奏更慢，可以拉到 240 秒。

还有一个必须做的动作：插屏触发前要判断当前场景是否适合。比如玩家正在合成动画播放中、正在看结算数字跳动，这时候弹出来会打断节奏。我的做法是在切关的加载页里弹，加载页本来就有一两秒的等待，广告正好填满，玩家感知上是“加载久了点”，而不是“被广告打断了”。

3.4 Banner 广告：尺寸适配与界面切换联动

Banner 的核心难点不在调用，在适配。小游戏的屏幕比例五花八门，Banner 的宽度有最小值限制，你设的宽度小于最小值会被自动拉大，位置就偏了。正确做法是先设一个初始样式，然后监听 onResize 拿到真实宽高，再根据真实尺寸算位置。

mergeInto(LibraryManager.library, { WXAd_ShowBanner: function (adUnitIdPtr, topPtr, bottomPtr) { var adUnitId = UTF8ToString(adUnitIdPtr); var top = Number(UTF8ToString(topPtr)); var bottom = Number(UTF8ToString(bottomPtr)); if (!wx.createBannerAd) { SendMessage('AdBridge', 'OnAdError', 'banner_not_supported'); return; } var sysInfo = wx.getSystemInfoSync(); var screenW = sysInfo.windowWidth; var screenH = sysInfo.windowHeight; if (window.__bannerAd) { window.__bannerAd.destroy(); window.__bannerAd = null; } var ad = wx.createBannerAd({ adUnitId: adUnitId, style: { left: 0, top: screenH - 120, width: screenW } }); window.__bannerAd = ad; ad.onResize(function (size) { // 拿到真实尺寸后重新定位，底部对齐，避开安全区 ad.style.left = (screenW - size.width) / 2; ad.style.top = screenH - size.height - bottom; }); ad.onError(function (err) { SendMessage('AdBridge', 'OnAdError', JSON.stringify({ code: err.errCode, msg: err.errMsg })); }); ad.show().catch(function () {}); }, WXAd_HideBanner: function () { if (window.__bannerAd) { window.__bannerAd.hide(); } }, WXAd_DestroyBanner: function () { if (window.__bannerAd) { window.__bannerAd.destroy(); window.__bannerAd = null; } } });

这里bottom参数是给安全区留的余量。全面屏底部有手势条，Banner 贴死底边会被挡住一部分，点击率反而下降。留出一点距离，视觉上也更舒服。

更要命的是层级问题。Banner 是原生组件，永远浮在 Unity 的渲染画布之上，你的 Unity UI 遮不住它。这意味着进入战斗界面的时候，如果只是“用 UI 盖住它”，玩家还是能看到、能点到，误触率飙升。唯一的正解是切换界面时直接hide()，回到主界面再show()。

我在项目里做了一个界面栈监听：

public class BannerController : MonoBehaviour { [SerializeField] private string adUnitId; public void OnScreenChanged(string screenName) { bool shouldShow = screenName == "Main" || screenName == "Shop" || screenName == "LevelSelect"; if (shouldShow) AdBridge.ShowBanner(adUnitId, 0, 24); else AdBridge.HideBanner(); } }

screenName由 UI 管理器统一派发，这样 Banner 的显示逻辑只有一处，不会出现“某个界面忘了隐藏”的情况。

4. 变现调优：频次、埋点与合规红线

4.1 埋点体系与关键指标

广告接进去只是开始，真正决定收入的是数据。我会埋四类事件：广告请求、加载成功、展示、关闭（带 isEnded）、错误（带错误码）。每个事件都带上点位标识、关卡号、用户首次进入的天数。这些字段看着多，但排查问题时缺一个都难受。

核心指标我盯这几个：请求成功率、展示率、完播率、人均展示次数、ARPU。请求成功率反映的是网络和配置问题，低于 90% 就要查；展示率等于展示数除以加载成功数，太低说明你的入口玩家不愿意点；完播率低于 80%，要么是奖励吸引力不够，要么是广告太长；人均展示次数是最直接的变现强度指标，但超过某个阈值就会开始伤留存。

我一般的判断逻辑是：先看次留，次留稳定再看 ARPU。如果加了某个点位之后 ARPU 涨了但次留掉了三个点以上，这个点位就得砍或者降频。短期收入换长期留存，这笔账在休闲品类里从来不划算，因为这类游戏的 LTV 主要靠长线留存撑。

埋点上报用平台自带的分析能力就够，不需要额外接三方。上报要异步、要合并，别在关键帧里同步调用，我见过因为上报卡顿导致合成动画掉帧的案例。做个队列，每五秒批量发一次，稳得多。

4.2 激励视频的价值锚点设计

同样的广告位，文案和奖励设计不同，点击率能差一倍。核心是“价值锚点”——让玩家清晰地感知到“看完这个广告，我能得到什么，而且这个回报是划算的”。

“水果扛狼”里我常用的三个锚点。复活：“看视频，原地复活并保留全部水果”。双倍：“本局金币翻倍，直接够升两级”。补给：“免费领取一个高级水果”。这三句话都有明确的量化结果，玩家不用猜。

反面教材是“看广告获得奖励”这种模糊表述，点击率会低很多。还有一个细节：按钮上要标出广告时长预期，比如“看 15 秒视频复活”，让玩家有心理准备。不标的话，点进去发现要看半分钟，中途关闭率会很高，而中途关闭你一分钱拿不到，还白白消耗了玩家的耐心。

奖励发放的时机也有讲究。必须在isEnded == true之后再发，这个前面说过。但发完之后要给一个明确的视觉反馈，金币飞入、水果升级动画，让玩家确认“我确实拿到了”。缺了这一步，玩家会怀疑奖励没到账，下次就不点了。

4.3 审核与合规的硬性要求

这块是红线，踩了直接下架或者封广告权限，没有商量余地。我按顺序列几条必须遵守的。

广告不能伪装成游戏内容。按钮样式、颜色、文案不能刻意模仿游戏内的操作按钮，让玩家误以为是游戏功能。诱导点击是审核重点，比如“点击广告继续游戏”这种，绝对不行。

广告不能遮挡核心操作区。Banner 压住水果合成区、插屏在关键操作瞬间弹出，都属于体验违规，用户举报多了会被处理。这也是我前面强调 Banner 只在非战斗界面展示的原因。

未成年人和隐私合规。小游戏需要配置隐私协议，涉及用户信息收集的要明示。广告内容本身由平台侧审核，但你自己的展示场景要合理，不能出现在明显面向低龄用户的界面里。

注意：广告频次不要为了短期收益无限拉高。平台对恶意诱导、强制观看有明确的处罚口径，轻则限流，重则关闭流量主权限，恢复起来非常麻烦。

还有一条容易被忽略：广告内容与游戏调性不符时的处理。比如你的游戏是卡通水果风格，突然弹出一个画风完全不同的广告，玩家的体验是割裂的。这个你控制不了广告素材，但可以控制展示时机，尽量放在自然断点上。

5. 常见问题与排查实录

5.1 拉取失败与不展示

真机上点了没反应，是最常见的问题。按我的排查顺序，先看后台权限有没有开通，再看 adUnitId 是不是正式位，再看基础库版本够不够。

如果报错里带no advertisement或者类似字样，通常是当前没有匹配到合适的广告，属于正常现象，不是代码问题。这种情况要做兜底：加载失败重试两次，还不行就直接给奖励或者给出友好提示，别让玩家卡在那里。

如果是adUnitId is invalid，八成是复制的时候多了空格，或者用了另一个环境的 ID。我吃过这个亏，测试环境配了正式 ID，正式环境配了测试 ID，来回折腾了半天。

还有一种情况是开发者工具里能出，真机不出。这通常是开发者工具的广告模拟和真机行为不一致，真机才是准的。所以广告这块一定要真机验证，两种机型以上，安卓和 iOS 各一台。

5.2 音频、内存与闪退

广告播放会抢占音频焦点。激励视频播完回到游戏，背景音乐经常就没了。解决方法是监听广告关闭回调，在里面重新初始化音频系统，或者干脆在广告展示前主动静音，关闭后恢复。后者更稳，因为不同机型对音频焦点的处理差异很大。

内存是另一个大坑。Unity WebGL 在小游戏环境下的内存本来就紧张，加上广告组件本身也占内存，低端机上很容易崩。我的做法是：广告展示前主动释放一些非必要资源，比如上一关的临时图集、缓存的动画帧，展示完再按需加载回来。

闪退如果发生在广告关闭的瞬间，大概率是回调里做了重操作，比如立刻加载一个大资源包。回调里只做状态更新和轻量逻辑，重活丢到下一帧或者用协程延迟执行，能规避大部分问题。

5.3 问题速查表

这张表我一般直接贴在项目文档里，新人接手的时候照着查，能省掉大量重复沟通。

最后分享一个我在实际项目里用到的小技巧：给广告管理器加一个“模拟模式”开关，在编辑器里用假的延迟和假回调走完整流程。这样策划调 UI、程序调逻辑都不用等真机，效率提升非常明显。上线前把开关关掉，走真实链路再验一遍就行。踩过几次坑之后我越来越觉得，广告接入这件事，代码本身只占三成，剩下七成都在时机、频次和兜底上。