uni-app App端开屏广告无需写代码，由DCloud原生层自动接管，仅需在uni-ad后台实名认证、开通并完成渠道SDK审核，在manifest.json中不配置任何广告字段；小程序端则需手动调用uni.createAd实现伪开屏。
uni-app App端开屏广告根本不用写代码
uni-app 的 app 端开屏广告（即 android/ios 启动时全屏展示的广告）是平台级能力，manifest.json 配置好、后台开通后，dcloud 原生层自动接管，不走 vue 页面生命周期，也不依赖 app.vue 的 onlaunch 或任何 js 逻辑。
你手动在 App.vue 里调用 uni.createFullScreenVideoAd 或 uni.addad，反而会失效或报错——因为那类 API 是给「插屏」「激励视频」等手动触发广告用的，不是开屏广告的正确入口。
- 开屏广告只在应用冷启动（从桌面图标首次打开）时生效；热启动（切到后台再切回）、进程保活状态下不会重复展示
- 必须先在 uni-ad 后台 用创建应用的 DCloud 账号实名认证并开通「App 开屏广告」，审核通过后才可配置
-
manifest.json中无需添加adSplash或splashscreen相关字段——这些是旧版或自定义启动页方案，与 uni-ad 开屏广告无关，混用会导致行为不可控
广告位 ID 和审核卡在哪？
很多人卡在“开了但没展示”，90% 是因为广告位没真正生效：uni-ad 后台显示“已开通”≠ 广告能展示，它分两步：
- 第一步：开通「App 开屏广告」开关（在「广告设置 → 应用详情 → App开屏广告管理」点开启）
- 第二步：必须完成「渠道 SDK 广告」审核（如腾讯优量汇、穿山甲），这需要软著 + 应用商店上架证明（快手/Sigmob 除外），1–3 个工作日，节假日顺延
- 审核未过时，即使后台显示开通，实际请求返回的是空广告或 fallback 图片（甚至白屏），控制台也几乎不报错，极难排查
验证方式：真机调试时打开日志（HBuilderX 控制台 → 运行日志），搜索 adSplash 或 fullScreenAd，有类似 [ad] splash ad loaded: true 才算成功加载；否则就是卡在审核或配置环节。
为什么微信小程序开屏广告不能照搬 App 写法？
微信小程序压根没有原生开屏广告能力，所谓“小程序开屏广告”其实是伪开屏：在首页 onLoad 时用 uni.createAd 创建一个覆盖全屏的广告组件，靠视觉模拟。这和 App 端的系统级开屏是两套机制。
- 小程序端必须手动调用
uni.loadad+uni.createad，且需处理show()失败降级（比如跳过广告直接进首页） - App 端完全不需要写这些 JS，写了也没用；小程序端不写就根本没广告
- 参数差异明显：
uni.createad的mode: 'b'（背景模式）、type: 'pre'（预加载）仅小程序有效；App 端这些字段会被忽略 - 小程序广告受微信审核约束，图片尺寸、跳转链接、倒计时逻辑都要符合《微信小程序广告规范》，否则上线后被下线
倒计时、跳过按钮、点击跳转谁来控制？
App 端开屏广告的倒计时、跳过按钮、点击行为全部由 DCloud 原生层实现，开发者无法干预样式或逻辑——你不能改“跳过”文字颜色，也不能把 5 秒改成 3 秒，更不能监听“用户点了跳过”这个事件。
唯一可控的是广告跳转目标：在 uni-ad 后台编辑开屏广告素材时，上传图片的同时填写「落地页 URL」或「小程序 appid + path」，这部分生效后，用户点击即跳转，无需前端代码参与。
如果你需要自定义倒计时或跳过逻辑（比如用户看满 3 秒才允许跳过），那就不能用平台开屏，得退回到「自定义启动页 + 手动广告组件」的老路，但代价是失去原生性能、首屏延迟增加、iOS 上可能被系统判定为“启动卡顿”而影响审核。
真正的难点从来不在怎么写，而在什么时候不该写——App 开屏广告最常被踩的坑，就是试图用 JS 去“增强”一个本就不该被增强的能力。
