接入实战指南)
iOS 平台 Google Mobile Ads 插页式广告Interstitial Ads接入实战指南【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills插页式广告Interstitial Ads是全屏覆盖型广告适合在应用的天然过渡节点如关卡切换、页面跳转、任务完成时展示。本文以本仓库 google-mobile-ads-interstitial 技能中的 iOS 平台指南为骨架完整梳理在 iOS 应用中接入 Google Mobile AdsGMASDK 插页式广告的四步工作流加载广告、注册事件回调、展示广告、验证实现并结合仓库中 SDK 安装、验证等配套技能文档补充前置配置与发布前检查细节。读完后你将掌握 iOS 插页式广告从 SDK 配置到编译验证的完整落地路径。插页式广告与 iOS 接入定位按照 技能描述插页式广告Interstitial Ads为移动应用中的用户展示全页广告设计目的是穿插在内容之间最佳放置位置是应用的自然过渡点。该技能同时覆盖 Android、iOS、Unity 三个平台其中 iOS 平台的具体实现指南正是本文所讲解的 ios-interstitial.md。需要特别注意的是该技能明确约定不适用于激励式插页广告rewarded interstitial接入前应先在技能层面确认需求与广告类型的匹配关系。整个插页式广告接入遵循固定顺序的工作流Load the ad加载广告Register for ad event callbacks注册广告事件回调Show the ad展示广告Verify the implementation验证实现iOS 接入前置条件SDK 安装与应用配置在进入插页式广告四步工作流之前iOS 项目必须先完成 GMA SDK 的基础集成。仓库中的 ios-get-started.md 详细记录了前置流程核心要点如下1. 添加 SDK 依赖Swift Package ManageriOS 端推荐使用 Swift Package Manager 安装 Google Mobile Ads SDK。指南中的做法是先查询最新版本号再以Up to Next Major Version的依赖规则把GoogleMobileAdsSwift Package 作为 target 依赖添加。若 Ruby 与xcodeprojgem 可用可编写临时 Ruby 脚本程序化添加依赖若不可用或脚本执行失败则直接输出指引让用户在 Xcode 中手动添加该 Swift Package。2. 设置应用标识符GADApplicationIdentifier若项目的Info.plist中尚不存在GADApplicationIdentifier需要添加该 key并写入测试用 AdMob App IDkeyGADApplicationIdentifier/key stringca-app-pub-3940256099942544~1458002511/string发布前必须替换为真实的 AdMob App ID。同时Info.plist中还应补齐 Google 要求的SKAdNetworkItems标识符列表用于 iOS 归因相关校验规则见 google-skadnetwork-ids.md。3. 初始化 SDK在应用合适的入口点初始化 SDKSwift 下必须使用以下代码MobileAds.shared.start { status in print(SDK initialized.) }完成上述前置配置后即可开始插页式广告的四步接入。第一步加载插页式广告Load the adiOS 平台指南首先强调一个贯穿始终的Gotcha易错点Google Mobile Ads SDK 使用NS_SWIFT_NAME宏为 Objective-C API 提供符合 Swift 习惯的命名。这意味着你在 Swift 中调用 SDK 接口时看到的方法名与底层 Objective-C 名可能存在差异应以 Swift 惯例命名为准。在加载广告时指南给出明确的 Swift 专项建议对于 Swift 代码使用async/await替代 completion handler完成回调。即加载插页式广告的推荐方式是异步等待式调用而不是传统的回调闭包写法。加载动作本身对应的是InterstitialAd对象的装载操作后续所有环节都建立在这一步成功的基础上。第二步注册广告事件回调Register for ad event callbacks加载完成后需要在InterstitialAd对象上设置fullScreenContentDelegate以接收插页式广告的全屏内容事件。这一步的检查项如下在InterstitialAd对象上设置fullScreenContentDelegate当广告被关闭dismissed或展示失败fails to show时释放drop对插页式广告对象的引用。释放引用的原因在于插页式广告本质上是一次性资源展示结束或失败后该对象即不可复用。如果不及时释放引用并重新加载新广告既会造成内存滞留也无法保证下一个过渡点有可用的新广告。这也是 Unity 平台指南中展示关闭后销毁对象并重新 Load 一个新广告的同一原则的体现详见 unity-interstitial.md。第三步展示插页式广告Show the ad展示环节的关键参数说明ViewController Parameter控制器参数present(from:)方法中的rootViewController参数是可选参数可以设置为nil。这意味着在 Swift 中调用展示方法时不必强制传入当前视图控制器SDK 会自行处理呈现所需的最上层控制器。这一设计简化了从任意上下文如回调闭包、异步任务中展示广告的代码路径避免了手动传递ViewController带来的生命周期管理负担。第四步验证实现Verify the implementation实现完成后必须验证构建无编译错误。指南给出了两条分支路径若xcodebuild可用运行xcodebuild以编程方式验证 iOS 项目能否与 GMA SDK 正确编译并解决所有与 GMA SDK 相关的编译错误若xcodebuild不可用输出指引让用户在 Xcode 中构建项目并手动确认没有编译错误。xcodebuild是 Xcode 附带的命令行构建工具可在 CI 或本地终端完成自动化编译验证这也是本技能强调的程序化验证手段。使用测试广告单元 ID 进行调试在开发调试阶段应使用 Google 官方测试广告单元 ID 而非真实 ID以避免无效流量并保证广告稳定填充。仓库 unity-interstitial.md 中记录了测试广告单元 ID 的对应关系其中 iOS 平台UNITY_IPHONE的插页式广告测试 ID 为ca-app-pub-3940256099942544/4411468910Android 平台对应ca-app-pub-3940256099942544/1033173712作为对比可一并参考 android-interstitial.md。发布前的校验清单集成完成后可借助仓库中的 google-mobile-ads-validate 技能对项目做发布前审计。与本文 iOS 接入直接相关的校验项包括应用 ID 校验见 application-id.mdiOS 平台检查Info.plist中的GADApplicationIdentifierkey应用 ID 必须匹配格式正则^(ca-app-pub-[a-zA-Z0-9\-])~(.*)$同一平台或构建目标下不应配置多个应用 ID除非有 flavor 或环境分离若发现仍在使用官方测试应用 IDca-app-pub-3940256099942544~1458002511应给出 Warning 提示。广告单元 ID 校验见 ad-units.mdAdMob 广告单元 ID 必须匹配^(ca-app-pub-[a-zA-Z0-9\-])/([a-zA-Z0-9_\-])(/.*)?$若源码中存在测试广告单元 ID以ca-app-pub-3940256099942544/开头即使被DEBUG标志门控应给出 Warning。跨平台对照iOS 与 Android、Unity 的差异要点仓库的 SKILL.md 将三平台流程统一抽象为加载 → 注册回调 → 展示 → 验证但各平台实现细节存在关键差异iOS 特有的注意点如下环节iOS本文Androidandroid-interstitial.mdUnityunity-interstitial.md加载方式Swift 使用async/await而非 completion handlerInterstitialAd.load(adRequest, adLoadCallback)回调在后台线程执行UI 操作必须包裹runOnUiThread {}静态InterstitialAd.Load()携带ActionInterstitialAd, LoadAdError回调回调注册设置fullScreenContentDelegate设置adEventCallback订阅OnAdPaid、OnAdImpressionRecorded、OnAdClicked、OnAdFullScreenContentOpened/Closed/Failed等事件展示present(from:)的rootViewController可为nil—先检查CanShowAd()再调用Show()线程要求关注NS_SWIFT_NAME宏带来的命名差异回调在后台线程UI 操作必须切回主线程否则崩溃Unity 对象非线程安全需用MobileAdsEventExecutor.ExecuteInUpdate()调度到主线程验证方式xcodebuild或 Xcode 手动构建gradle build -x test检查 Unity Console 无 C# 编译错误从这一对照可以看出虽然四步工作流在各平台保持一致但线程模型Android 强制 UI 主线程、Unity 强制调度到主线程与回调风格iOS 推荐 async/await是接入时最容易踩坑的差异点。小结本文围绕仓库中 ios-interstitial.md 的完整内容展开说明了 iOS 插页式广告接入的全过程以 SDK 安装与GADApplicationIdentifier配置为前置条件严格按加载async/await→ 注册fullScreenContentDelegate并在关闭/失败时释放引用→ 展示rootViewController可传nil→xcodebuild编译验证四步落地最后以测试广告单元 ID 和 google-mobile-ads-validate 校验清单完成发布前自检。开发者只需按此顺序执行即可在 iOS 应用中稳定接入插页式广告并安全过渡到生产环境。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考