企业官网建设流程全解析

1. 项目概述：为什么iOS 14.5+的ATT弹窗是Unity开发者的“必答题”

如果你正在用Unity开发iOS游戏，并且计划接入广告变现，那么“ATT弹窗”这四个字，绝对是你绕不开的一道坎。这不仅仅是多写几行代码那么简单，它直接关系到你的应用能否在App Store上架，以及后续广告收入的“天花板”有多高。从iOS 14.5开始，苹果强制推行了应用追踪透明度（App Tracking Transparency，简称ATT）框架，要求应用在追踪用户数据（主要是为了跨应用投放个性化广告）前，必须通过系统弹窗明确获得用户的许可。这个弹窗，就是大家常说的ATT弹窗。

很多开发者，尤其是从Android平台转过来或者初次接触iOS发布的同学，很容易在这里踩坑。你以为在Unity里调个API就完事了？结果打包到Xcode后，要么弹窗不出现，要么应用被拒，要么明明用户点了“允许”，后台却收不到IDFA（广告标识符），广告填充率和eCPM（千次展示收益）直接“腰斩”。我自己在接入第一个ATT项目时，就曾因为一个Info.plist的配置项漏了，导致整个提审流程卡了一周。所以，今天我就把从Unity工程配置，到Xcode项目设置，再到真机测试的完整流程，以及那些官方文档里不会写的“坑点”，给你彻底捋清楚。

这篇文章适合所有使用Unity开发并计划在iOS平台发布带广告功能应用的开发者。无论你是独立开发者还是团队中的技术负责人，理解并正确实现ATT流程，都是确保项目合规、顺利变现的基础。我们会从ATT的核心概念讲起，一步步拆解在Unity编辑器中的配置、代码编写、Xcode的避坑设置，最后分享一些提升用户授权率的实战技巧。

2. ATT框架核心解析与Unity集成方案选型

在动手写代码之前，我们必须先搞明白ATT到底是什么，以及苹果为什么要搞这么一出。简单来说，IDFA是苹果设备上一个用于广告归因和追踪的唯一标识符。在ATT政策之前，应用可以相对自由地获取并使用这个ID。但ATT之后，获取IDFA的权限被收紧了，变成了一个需要用户明确授权的“隐私权限”，就像访问相册、地理位置一样。

2.1 ATT授权状态与你的收入直接挂钩

ATT弹窗的结果，会返回四种授权状态，这四种状态直接决定了你后续的广告变现能力：

1. ATTrackingManagerAuthorizationStatusAuthorized(用户允许追踪)：这是最理想的状态。应用可以获取到IDFA，广告平台（如Unity Ads, AdMob, ironSource等）可以利用这个标识符进行精准的用户画像分析、广告归因和重定向投放。这意味着你的广告填充会更精准，eCPM（每千次展示收入）通常会更高。
2. ATTrackingManagerAuthorizationStatusDenied(用户拒绝追踪)：用户明确点击了“要求App不追踪”。此时应用无法获取到IDFA。广告平台将无法进行跨应用的用户行为追踪，广告投放会退回基于上下文（如应用内容、粗略地理位置）的模式，其精准度和价值通常会下降，直接影响你的广告收益。
3. ATTrackingManagerAuthorizationStatusRestricted(限制追踪)：这个状态通常由设备的管理策略（如家长控制、企业设备管理）决定，与应用本身无关。同样无法获取IDFA。
4. ATTrackingManagerAuthorizationStatusNotDetermined(未决定)：这是应用首次安装启动后的默认状态。只有在这个状态下，你弹出的ATT请求窗才是有效的，用户的选择才会改变这个状态。一旦用户做出选择（允许或拒绝），这个状态就会改变，并且在同一设备上，除非用户卸载后重装应用，否则你将无法再次弹出系统ATT请求窗。用户后续可以在系统的“设置”->“隐私与安全性”->“追踪”里，单独为每个应用修改这个权限。

理解这四种状态至关重要。你的代码逻辑核心就是：检查当前状态是否为NotDetermined，如果是，则准备并弹出请求；如果不是，则根据当前状态（允许或拒绝）来初始化你的广告SDK，可能采用不同的策略。

2.2 Unity项目集成ATT的三种方案对比

在Unity项目中，我们有几种方式来实现ATT弹窗，每种都有其适用场景和优缺点。

方案一：使用Unity官方提供的iOS 14 Support包（推荐给大多数项目）这是最省心、与Unity Ads集成度最高的方案。Unity提供了一个名为com.unity.ads.ios-support的Package。它不仅仅封装了ATT的API，还提供了一个可自定义的“上下文说明屏幕”的预制体。这个说明屏幕非常重要，我们后面会详细讲。它的优点是开箱即用，与Unity引擎和Unity Ads SDK兼容性好，减少了原生代码交互的复杂度。

方案二：通过Unity的iOS.Call或第三方插件调用原生API如果你不想引入额外的Package，或者你的项目主要使用非Unity Ads的其他广告联盟，你可以选择自己编写C#脚本，通过[DllImport(“__Internal”)]的方式调用iOS原生的ATT API。这种方式更轻量，但需要你自行处理iOS原生代码的桥接和编译条件，对开发者的要求稍高。

方案三：完全在Xcode工程中处理有些团队习惯于在Unity导出Xcode工程后，在Xcode中编写Objective-C或Swift代码来处理ATT弹窗。这种方式将iOS相关的逻辑完全剥离到原生侧，适合那些拥有强大iOS原生开发团队，或者项目本身就有大量自定义原生代码的情况。但对于纯Unity开发者来说，调试和迭代会稍微麻烦一些。

对于绝大多数以Unity开发为主的中小团队和个人开发者，我强烈推荐方案一。它平衡了易用性、功能性和官方支持度。接下来，我们的实操也将围绕这个方案展开。

注意：无论选择哪种方案，都必须确保在初始化任何广告SDK（包括Unity Ads、AdMob、AppLovin等）之前，先处理ATT授权状态。因为一旦广告SDK被初始化，它可能就会尝试去获取IDFA，如果此时用户尚未授权，SDK可能就无法正常工作，或者导致合规风险。

3. 核心细节解析：上下文说明屏幕与Info.plist配置

这是ATT接入中最容易出错的两个地方，一个是逻辑上的，一个是配置上的。

3.1 为什么需要“上下文说明屏幕”？

苹果的系统ATT弹窗非常“高冷”，只有两个按钮：“要求App不追踪”和“允许”。没有任何解释空间。根据苹果的统计和业内的普遍经验，用户面对一个突如其来的、关于“追踪”的请求，第一反应往往是警惕和拒绝。直接弹出系统弹窗的授权率可能低至20%-30%。

为了提高授权率，苹果推荐（几乎是强制要求）开发者在弹出系统弹窗前，先展示一个自定义的“上下文说明屏幕”。在这个屏幕上，你可以用友好的语言向用户解释：

• 为什么你需要请求这个权限？（例如：“为了给您推荐更感兴趣的游戏，减少无关广告的打扰”）
• 用户允许追踪能获得什么好处？（例如：“获得更个性化的游戏内容推荐”、“支持我们免费提供这款游戏”）
• 他们的数据将如何被使用和保护？（例如：“数据仅用于优化游戏内的广告体验，不会出售给第三方”）

这个屏幕是你与用户沟通的唯一机会，设计得好，授权率提升到40%-50%甚至更高都是有可能的。Unity的iOS 14 Support包里的示例场景，就是为你提供了一个快速搭建这个屏幕的模板。

3.2NSUserTrackingUsageDescription：必须配置的隐私描述

即使你做了上下文说明屏幕，系统ATT弹窗上仍然需要显示一段描述文字。这段文字不是由你的上下文屏幕提供的，而是必须配置在iOS应用的Info.plist文件中的一个特定键——NSUserTrackingUsageDescription。

这个配置项极其重要，如果缺失，ATT系统弹窗将不会弹出，并且应用在提交App Store审核时会被直接拒绝。它的内容需要清晰、诚实地告知用户追踪数据的使用目的。你不能写“此功能用于改善用户体验”这样模糊的话，必须具体。

正确示例：

• “我们将使用您的数据，为您展示更相关、更感兴趣的广告，这有助于我们为您免费提供此游戏。”
• “通过允许追踪，我们可以了解哪些广告让您发现了我们，从而与合作伙伴结算，并优化未来的广告内容。”

这个描述会在系统弹窗中，应用名称下方以小字显示。你需要在Unity打包时，确保这个键值对被自动或手动地添加到最终的Xcode工程的Info.plist中。

4. 实操过程：从Unity到Xcode的全链路配置

理论讲完，我们进入实战环节。假设我们使用Unity 2022.3 LTS版本和Unity Ads进行变现。

4.1 步骤一：在Unity中安装与配置iOS 14 Support包

1. 打开Package Manager：在Unity编辑器中，点击顶部菜单栏的Window->Package Manager。
2. 切换资源来源：在Package Manager窗口左上角，默认是Unity Registry。你需要点击旁边的“+”号，选择Add package by name...。
3. 输入包名：在弹出的窗口中，输入完整的包名：com.unity.ads.ios-support，然后点击Add。Unity会从资源库中下载并安装这个包。
   • 实操心得：有时网络原因会导致添加失败。如果遇到问题，可以尝试在Packages/manifest.json文件中直接添加依赖"com.unity.ads.ios-support": "x.x.x"，然后回到Unity，它会自动解析。版本号可以去Unity官方Package注册表查看最新版。
4. 导入示例资源（可选但推荐）：安装完成后，在Package Manager中找到已安装的iOS 14 Support包。在详情底部，你会看到一个Samples区域，里面有一个Context Screen Sample。点击Import按钮，将这个示例场景和脚本导入到你的项目Assets文件夹下。
5. 查看与修改示例：导入后，你可以在Assets/Samples/iOS 14 Advertising Support/<version>/01 Context Screen/路径下找到示例场景和预制体。打开ContextScreenSample场景，运行一下，你会看到那个上下文说明屏幕的UI。你可以直接修改这个预制体（ContextScreen.prefab）上的文字、图片和按钮样式，来匹配你游戏的UI风格。

4.2 步骤二：编写ATT权限请求管理器

我们不需要完全照搬示例，可以创建一个更简洁、易于集成的管理器脚本。在你的项目脚本目录下（例如Assets/Scripts/Ad/），创建一个C#脚本，命名为ATTManager.cs。

using UnityEngine; #if UNITY_IOS using Unity.Advertisement.IosSupport; // 引入iOS Support包的命名空间 #endif public class ATTManager : MonoBehaviour { // 使用单例模式方便全局访问 private static ATTManager _instance; public static ATTManager Instance { get { if (_instance == null) { GameObject go = new GameObject("ATTManager"); _instance = go.AddComponent<ATTManager>(); DontDestroyOnLoad(go); // 常驻，避免场景切换时被销毁 } return _instance; } } // 定义一个委托和事件，用于通知ATT授权结果 public delegate void OnATTComplete(ATTrackingStatusBinding.AuthorizationTrackingStatus status); public static event OnATTComplete onATTComplete; [SerializeField] private GameObject contextScreenPrefab; // 在Inspector中拖入你的上下文屏幕预制体 private GameObject currentContextScreen; void Awake() { if (_instance != null && _instance != this) { Destroy(this.gameObject); return; } _instance = this; RequestATT(); } public void RequestATT() { #if UNITY_IOS && !UNITY_EDITOR // 1. 检查当前ATT授权状态 var currentStatus = ATTrackingStatusBinding.GetAuthorizationTrackingStatus(); Debug.Log($"[ATT] Current Status: {currentStatus}"); // 2. 如果状态是“未决定”，则准备弹出请求 if (currentStatus == ATTrackingStatusBinding.AuthorizationTrackingStatus.NOT_DETERMINED) { ShowContextScreen(); } else { // 3. 如果已决定（允许或拒绝），直接通知并初始化广告SDK OnATTStatusReceived(currentStatus); } #else // 在编辑器或非iOS平台，模拟一个授权状态，方便调试 Debug.Log("[ATT] Non-iOS platform, skipping ATT request."); // 这里可以模拟一个状态，例如直接调用 OnATTStatusReceived(ATTrackingStatusBinding.AuthorizationTrackingStatus.AUTHORIZED); #endif } private void ShowContextScreen() { if (contextScreenPrefab != null) { // 实例化上下文屏幕，通常是一个全屏UI currentContextScreen = Instantiate(contextScreenPrefab); // 假设你的上下文屏幕预制体上有一个脚本，上面有“同意”按钮，并调用了下面的`OnContextScreenAccepted`方法 } else { Debug.LogWarning("[ATT] Context screen prefab is not assigned. Showing system ATT dialog directly."); // 如果没有上下文屏幕，直接弹出系统请求（不推荐） ShowSystemATTRequest(); } } // 这个方法由上下文屏幕的“同意”按钮调用 public void OnContextScreenAccepted() { if (currentContextScreen != null) { Destroy(currentContextScreen); } ShowSystemATTRequest(); } // 这个方法由上下文屏幕的“拒绝”或“稍后”按钮调用 public void OnContextScreenDeclined() { if (currentContextScreen != null) { Destroy(currentContextScreen); } // 用户在不看系统弹窗的情况下就拒绝了，我们将其视为拒绝追踪 OnATTStatusReceived(ATTrackingStatusBinding.AuthorizationTrackingStatus.DENIED); } private void ShowSystemATTRequest() { #if UNITY_IOS && !UNITY_EDITOR // 调用iOS Support包提供的API，弹出系统ATT请求窗 ATTrackingStatusBinding.RequestAuthorizationTracking(OnATTStatusReceived); #else Debug.Log("[ATT] System ATT request would show here on real iOS device."); #endif } // 这是ATT请求的回调，无论用户如何选择都会被调用 private void OnATTStatusReceived(ATTrackingStatusBinding.AuthorizationTrackingStatus status) { Debug.Log($"[ATT] User's choice: {status}"); // 保存状态，例如存到PlayerPrefs，避免每次启动都检查（虽然检查很快） PlayerPrefs.SetInt("ATT_Status", (int)status); // 触发事件，通知其他模块（如广告初始化管理器） onATTComplete?.Invoke(status); // 根据状态初始化广告SDK InitializeAdsSDK(status); } private void InitializeAdsSDK(ATTrackingStatusBinding.AuthorizationTrackingStatus status) { // 这里是初始化你的广告SDK的地方，例如Unity Ads, AdMob等 // 关键点：将ATT状态传递给SDK的初始化配置 bool canTrack = (status == ATTrackingStatusBinding.AuthorizationTrackingStatus.AUTHORIZED); // 示例：初始化Unity Ads // Advertisement.Initialize(gameId, testMode, canTrack); Debug.Log($"[ATT] Initializing Ads SDK with tracking allowed: {canTrack}"); // 如果使用的是其他SDK，如Google Mobile Ads，可能需要设置对应的请求配置 // var request = new AdRequest(); // request.Extras.Add("npa", canTrack ? "0" : "1"); // 非个性化广告参数 } }

这个脚本提供了一个完整的管理流程：检查状态 -> 显示自定义说明屏 -> 弹出系统请求 -> 根据结果初始化广告。你需要将这个脚本挂载到一个游戏启动时就存在的GameObject上（例如一个启动场景的空物体），并将制作好的上下文屏幕预制体拖拽到contextScreenPrefab字段。

4.3 步骤三：自动配置Info.plist的构建后处理脚本

手动去Xcode里修改Info.plist容易忘记，我们可以写一个编辑器脚本，让Unity在构建iOS项目后自动添加NSUserTrackingUsageDescription。

在项目Assets文件夹下创建一个Editor文件夹（如果没有的话），然后在里面创建一个C#脚本，命名为PostBuildProcessor.cs。

#if UNITY_IOS using UnityEditor; using UnityEditor.Callbacks; using UnityEditor.iOS.Xcode; using System.IO; public class PostBuildProcessor { // 在这里定义你的ATT请求描述 private const string TrackingDescription = “我们将使用您的数据来为您提供更相关、更感兴趣的广告内容，这有助于我们持续免费运营和改进这款游戏。”; [PostProcessBuild(1)] // 数字代表执行顺序，可以调整 public static void OnPostprocessBuild(BuildTarget buildTarget, string pathToBuiltProject) { if (buildTarget != BuildTarget.iOS) return; string plistPath = Path.Combine(pathToBuiltProject, “Info.plist”); PlistDocument plist = new PlistDocument(); plist.ReadFromString(File.ReadAllText(plistPath)); PlistElementDict rootDict = plist.root; // 设置NSUserTrackingUsageDescription rootDict.SetString(“NSUserTrackingUsageDescription”, TrackingDescription); // 可选：同时设置其他相关的隐私描述，例如地理位置（如果需要） // if (!rootDict.values.ContainsKey(“NSLocationWhenInUseUsageDescription”)) // { // rootDict.SetString(“NSLocationWhenInUseUsageDescription”, “我们需要您的位置来提供基于地区的广告和内容。”); // } File.WriteAllText(plistPath, plist.WriteToString()); Debug.Log($“[PostBuild] NSUserTrackingUsageDescription added to Info.plist: {TrackingDescription}”); } } #endif

这个脚本会在每次成功构建iOS项目后自动执行，将定义好的描述文字写入Xcode工程的Info.plist文件中，万无一失。

4.4 步骤四：Xcode工程配置与避坑指南

Unity导出Xcode工程后，用Xcode打开.xcodeproj文件。即使有自动脚本，我们仍需检查几个关键点，这些都是我踩过的坑。

1. 检查Info.plist：在Xcode项目导航器中，点击Info.plist文件，确认Privacy - Tracking Usage Description（即NSUserTrackingUsageDescription）键值对已经存在，并且描述文字正确无误。
2. 添加AppTrackingTransparency框架（关键！）：光有描述和代码调用还不够，必须链接系统的ATT框架。
   • 在Xcode中，点击你的项目根节点（蓝色图标），进入TARGETS->你的项目名称->General选项卡。
   • 找到Frameworks, Libraries, and Embedded Content区域。
   • 点击+号，搜索AppTrackingTransparency，然后点击Add。确保它的Embed状态是Do Not Embed（对于系统框架，通常选择不嵌入）。
   • 避坑点：如果忘记添加这个框架，编译不会报错，但运行时调用ATTrackingManager的API会静默失败，弹窗永远不会出现。这是最常见的错误之一。
3. 设置iOS部署目标：确保Deployment Target设置为14.5或更高。因为ATT框架是从iOS 14.5开始强制要求的。如果你的项目支持更老的iOS版本，代码中需要用#if __IPHONE_14_5之类的条件编译来包裹ATT相关代码，或者使用运行时API可用性检查。Unity的iOS Support包内部已经做了这些处理，但自己写原生代码时需要注意。
4. 检查签名与能力：在Signing & Capabilities选项卡中，确保你的开发者账号和Bundle Identifier正确。ATT功能不需要额外的Capability（能力）开关，它属于隐私权限的一部分。

5. 常见问题与排查技巧实录

即使按照流程一步步走，在实际测试和上线过程中，还是会遇到各种问题。下面是我总结的“排坑手册”。

5.1 问题一：ATT弹窗在真机上不出现

这是最高频的问题。请按以下顺序排查：

1. 检查Info.plist：确认NSUserTrackingUsageDescription键值对存在且内容不为空。这是审核和功能生效的硬性要求。
2. 检查AppTrackingTransparency框架：在Xcode中确认框架已正确添加。可以尝试删除后重新添加一次。
3. 检查代码调用时机：确保你的RequestATT方法在应用启动后尽早调用，并且一定是在任何广告SDK初始化之前。一个常见的错误是把ATT请求放在了一个延迟加载的场景里，而广告SDK在更早的Awake或Start中就被初始化了。
4. 检查授权状态：在RequestATT方法里，先打印当前的ATTrackingStatusBinding.GetAuthorizationTrackingStatus()。如果打印出来不是NOT_DETERMINED，那说明用户已经做过选择（可能是之前安装过），或者设备策略限制，系统就不会再弹窗了。在测试时，每次测试弹窗都需要卸载App重装。
5. 检查Xcode控制台日志：运行应用时，打开Xcode的Console，搜索ATT或tracking关键词，看是否有相关错误或警告信息。

5.2 问题二：用户点击“允许”后，广告收益没有提升

这通常不是ATT弹窗本身的问题，而是后续流程没对接好。

1. 确认IDFA是否成功传递：在ATT回调OnATTStatusReceived中，当状态是AUTHORIZED时，你需要将这个信息传递给广告SDK的初始化方法。例如，Unity Ads的Advertisement.Initialize方法有一个可选的enablePerPlacementLoad参数，但更重要的是确保SDK在初始化时能获取到IDFA。通常，只要你在初始化前请求了ATT，并且用户允许，SDK会自动处理。但最好查阅你所使用广告SDK的最新文档，确认初始化配置。
2. 检查广告平台的配置：在Unity Ads Dashboard、AdMob后台等平台，确认你的iOS应用Bundle ID已正确关联，并且相关设置（如SKAdNetwork配置，这是苹果的另一套归因方案，与ATT并行）已按指南完成。
3. 测试广告请求：在真机上，授权后，尝试请求一个测试广告。查看Xcode日志或广告平台的调试模式，确认广告请求中是否包含了有效的IDFA字段。有时需要等待一段时间（几分钟到几小时）数据才会同步到广告平台的后台。

5.3 问题三：App Store审核被拒，理由与ATT相关

审核被拒的邮件通常会引用《App Store审核指南》的5.1.2(i)条款。常见原因和解决方法：

1. 描述不准确或过于模糊：NSUserTrackingUsageDescription的描述必须清晰、具体地说明数据用途。避免使用“改善服务”、“优化体验”等泛泛之词。参考前面给出的示例，明确说出是为了“展示相关广告”。
2. 在未获授权前收集设备信息：确保你的应用（或集成的第三方SDK）在用户点击“允许”前，没有使用任何可以用于追踪的API（如访问IDFV、收集精确的设备指纹信息等）。即使ATT状态是DENIED，也要确保应用行为合规。
3. 上下文屏幕设计不当：你的自定义说明屏幕不能误导用户，不能将“允许”按钮设计得特别突出而将“拒绝”选项隐藏（例如，只做一个“下一步”按钮，点击后直接弹出系统允许弹窗）。必须给用户平等、清晰的选择权。苹果的示例中，“同意”和“不同意”按钮在视觉权重上应该是接近的。

5.4 问题四：如何在Unity编辑器和Android平台调试？

ATT是iOS特有的，在Unity Editor和Android平台编译时，UNITY_IOS宏是未定义的，相关代码不会执行。这可能导致你的广告初始化逻辑在测试时走不通。

解决方案是创建平台无关的接口：

public interface IATTService { void CheckAndRequestPermission(System.Action<AuthorizationStatus> callback); } // iOS实现 #if UNITY_IOS public class iOSATTService : IATTService { public void CheckAndRequestPermission(System.Action<AuthorizationStatus> callback){ /* 调用上面写的ATTManager逻辑 */ } } #endif // 非iOS平台（Editor, Android）的模拟实现 public class DefaultATTService : IATTService { public void CheckAndRequestPermission(System.Action<AuthorizationStatus> callback) { // 模拟一个授权成功的状态，或者根据PlayerPrefs读取一个模拟状态 callback?.Invoke(AuthorizationStatus.Authorized); } } // 在你的游戏启动管理器里 IATTService attService; #if UNITY_IOS && !UNITY_EDITOR attService = new iOSATTService(); #else attService = new DefaultATTService(); #endif attService.CheckAndRequestPermission(OnATTComplete);

这样，无论在哪個平台，你的广告初始化流程都能以统一的方式被触发，便于开发和调试。

最后，关于提升授权率的小技巧：除了设计一个真诚、友好的上下文说明屏幕外，选择合适的弹窗时机也很重要。不要在游戏刚启动、加载资源卡顿的时候弹，也不要在用户正在紧张操作（如Boss战）时弹。可以尝试在用户完成一个新手引导、获得一次胜利奖励后，在一个相对轻松、正面的时刻弹出请求，并强调“这将帮助您获得更好的奖励”之类的关联利益，效果可能会更好。