企业官网建设流程全解析

1. 为什么手游团队绕不开 Deep Link 这件事

做过 Unity 手游投放的同学大概都有过这种体验：买量素材里放了一个“点击直接打开游戏领奖励”的按钮，用户点完之后要么跳到了 App Store 下载页，要么打开了游戏却停在登录界面，奖励没领到，客服工单先来了一堆。这个链路里最容易出问题的环节，就是Deep Link——也就是从游戏外部（浏览器、短信、社交 App、广告落地页）把用户精准送进游戏内某个具体页面的能力。

在 iOS 生态里，Deep Link 主要有两条技术路线：URL Scheme和Universal Links。前者是老牌方案，兼容性好但体验粗糙；后者是苹果主推的方案，体验顺滑但配置门槛高。而 Unity 作为跨平台引擎，C# 层拿到的往往只是原生层透传过来的一串字符串，怎么把这串字符串安全、准确地投递到游戏逻辑层，才是真正考验工程能力的地方。

这篇文章面向的是正在做 Unity iOS 手游、需要打通买量归因、活动唤醒、分享回流等场景的开发者。我会把从原生配置到 C# 参数投递的完整链路拆开讲，包括 URL Scheme 和 Universal Links 的取舍、UnityAppController 的改造、冷启动与热启动的区分、参数解析的坑，以及我在实际项目里踩过的那些雷。看完之后，你应该能独立把这套流程跑通，而不是对着苹果文档和 Unity 论坛的碎片信息拼凑。

2. 两条技术路线的选型逻辑与底层差异

2.1 URL Scheme 的机制与适用边界

URL Scheme 的本质是给 App 注册一个自定义协议头，比如mygame://。当系统收到这个协议的 URL 时，会查找哪个 App 注册了它，然后拉起对应 App 并把完整 URL 传进去。它的实现依赖Info.plist里的CFBundleURLTypes配置，原理简单直接。

它的优势在于兼容性极好，从很老的 iOS 版本就支持，而且不依赖域名和服务器配置，测试阶段改起来快。但问题也很明显：任何 App 都可以注册同名 Scheme，存在被劫持的风险；在 Safari 里如果目标 App 没安装，会弹出一个丑陋的“打不开”提示；从微信、QQ 这类内置浏览器里，Scheme 经常被拦截，根本跳不过去。

所以我的经验是：URL Scheme 适合作为兜底方案和内部测试通道，不适合作为买量投放的主链路。买量场景下用户大概率没装 App，Scheme 的失败体验会直接劝退。

2.2 Universal Links 为什么是投放首选

Universal Links 走的是标准 HTTP/HTTPS 链接，比如https://game.example.com/open?scene=activity。它的核心机制是：App 在Associated Domains里声明自己信任某个域名，同时该域名下放置一个apple-app-site-association（简称 AASA）文件，声明哪些路径归这个 App 处理。系统在打开链接时会先校验这个信任关系，通过则直接拉起 App，不通过则用 Safari 打开网页。

这套机制的好处是：链接是标准 HTTPS，任何浏览器、任何 App 里都能点；没装 App 时自动降级到网页，网页可以引导去 App Store；域名归属明确，基本杜绝劫持。代价是配置链路长，AASA 文件、域名、Team ID、签名、CDN 缓存任何一个环节出问题，链接都会静默失效，而且排查起来很痛苦。

2.3 双通道并行的实际策略

实际项目里我一般两条都配，但分工明确：Universal Links 作为主链路负责投放和分享，URL Scheme 作为兜底负责站内跳转和测试。判断逻辑放在原生层，优先尝试 Universal Links 的回调，如果一段时间内没收到就降级。下面这张表是我总结的选型对照，可以直接拿去和团队对齐。

3. 原生层配置：从 Info.plist 到 AASA 文件

3.1 URL Scheme 的最小配置

在 Unity 导出的 Xcode 工程里，找到Info.plist，添加CFBundleURLTypes数组。每一项包含CFBundleURLName（建议用反域名格式，如com.example.mygame）和CFBundleURLSchemes（实际的协议头数组）。配置完之后，系统就能识别mygame://开头的链接了。

这里有个细节很多人忽略：CFBundleURLName最好全局唯一，虽然它不直接参与匹配，但在某些系统日志和冲突排查时能帮你快速定位是哪个 App 注册的。另外 Scheme 命名不要用太通用的词，比如game、app这种，被其他 App 抢注的概率很高。

3.2 Universal Links 的完整配置链路

Universal Links 的配置分三块，缺一不可。第一块是苹果开发者后台，在 App ID 的 Capabilities 里勾选 Associated Domains。第二块是 Xcode 工程，在 Signing & Capabilities 里添加 Associated Domains，填入applinks:game.example.com。第三块是服务器，在https://game.example.com/.well-known/apple-app-site-association放置 AASA 文件。

AASA 文件是个纯 JSON，不需要.json后缀，Content-Type必须是application/json。内容大致长这样：

{ "applinks": { "apps": [], "details": [ { "appID": "TEAMID.com.example.mygame", "paths": ["/open/*", "/share/*"] } ] } }

appID是 Team ID 加 Bundle ID，中间用点连接。paths声明哪些路径归这个 App 处理，*是通配符。这里我强烈建议不要用"*"匹配所有路径，只声明你真正需要的路径前缀，否则用户点你官网的任何链接都会被拉进 App，体验很怪。

3.3 AASA 文件那些让人抓狂的坑

AASA 文件最坑的地方在于苹果的 CDN 会缓存它。你更新了文件，可能几小时甚至一天都不生效。调试阶段可以用苹果的 AASA 验证工具查当前缓存状态，但正式环境一定要提前部署，别等到发版当天才配。

另一个坑是重定向。AASA 文件所在的 URL 不能有任何 301、302 跳转，必须是直接返回 200。如果你的域名有强制 HTTPS 跳转或者 CDN 做了路径重写，很可能导致苹果抓取失败。我遇到过一次，排查了半天才发现是 CDN 把.well-known目录给屏蔽了。

还有一点，AASA 文件里paths的匹配是大小写敏感的，而且不支持查询参数匹配。也就是说https://game.example.com/open?scene=activity里的?scene=activity不参与路径匹配，只匹配/open部分。参数怎么传，是后面 C# 层要处理的事。

4. Unity 原生层改造：UnityAppController 的接管

4.1 找到正确的回调入口

Unity 导出的 iOS 工程里，UnityAppController.mm是 App 生命周期的核心类。Deep Link 的回调有两个入口：URL Scheme 走application:openURL:options:，Universal Links 走application:continueUserActivity:restorationHandler:。这两个方法默认在 UnityAppController 里可能没有实现，或者只是简单转发，你需要自己接管。

我的做法是新建一个分类或者直接在 UnityAppController 里重写这两个方法，把拿到的 URL 或NSUserActivity里的webpageURL统一转成字符串，然后通过UnitySendMessage发给场景里的一个常驻 GameObject。这样原生层只负责“拿到链接”，解析和业务逻辑全部交给 C#，职责清晰。

4.2 冷启动与热启动的分叉处理

这里有个关键区别必须处理清楚：冷启动时 App 还没起来，Deep Link 的回调可能在 Unity 引擎初始化之前就触发了，此时UnitySendMessage发出去没人接收，消息就丢了。热启动时 App 在后台，引擎还活着，直接发消息没问题。

我的解决方案是在原生层维护一个pendingURL字符串。冷启动时先把 URL 存起来，等 Unity 引擎初始化完成（可以监听UnityReady通知，或者在UnityAppController的startUnity之后）再统一发送。热启动时直接发送。C# 层收到消息后，如果游戏还没进入主流程，就把参数缓存起来，等主流程就绪再消费。

4.3 一个容易忽略的时机问题

application:continueUserActivity:在冷启动场景下的调用时机，可能早于application:didFinishLaunchingWithOptions:里的某些初始化。如果你在回调里直接访问了还没初始化的单例，就会崩溃。稳妥的做法是回调里只做最轻量的字符串提取和存储，不做任何业务判断。

另外，Universal Links 的回调在 App 已经在前台时，如果用户点击的是同一个域名的链接，系统可能不会重新触发continueUserActivity，而是走scene:continueUserActivity:（如果你用了 SceneDelegate）。Unity 默认工程一般没有 SceneDelegate，但如果你手动加了，就要注意这个分叉。

5. C# 层参数投递：从字符串到业务数据

5.1 消息接收与线程安全

原生层通过UnitySendMessage("DeepLinkManager", "OnDeepLink", url)发过来的消息，是在主线程执行的，这点可以放心。但要注意UnitySendMessage的参数只能是字符串，而且有长度限制（大约 64KB），正常 Deep Link 不会超，但如果你把整个网页内容塞进去就会出问题。

C# 侧我一般建一个DeepLinkManager单例，挂在一个 DontDestroyOnLoad 的 GameObject 上。OnDeepLink方法收到字符串后，先做一层缓存，然后触发一个事件，让关心 Deep Link 的模块去订阅。这样解耦之后，登录模块、活动模块、归因模块可以各自处理自己关心的参数。

5.2 URL 解析的完整实现

拿到 URL 字符串后，第一步是判断它是 Scheme 还是 Universal Links。Scheme 形如mygame://open?scene=activity&id=123，Universal Links 形如https://game.example.com/open?scene=activity&id=123。两者的路径和参数结构类似，但解析方式不同。

我一般用System.Uri来解析，它能同时处理两种格式。uri.Scheme拿到协议，uri.Host拿到域名或 Scheme 后的第一段，uri.AbsolutePath拿到路径，uri.Query拿到查询字符串。查询字符串的解析 Unity 没有内置工具，我通常自己写一个简单的ParseQueryString，按&和=拆分，注意做 URL 解码。

public static Dictionary<string, string> ParseQuery(string query) { var result = new Dictionary<string, string>(); if (string.IsNullOrEmpty(query)) return result; query = query.TrimStart('?'); foreach (var pair in query.Split('&')) { var kv = pair.Split('='); if (kv.Length == 2) { result[Uri.UnescapeDataString(kv[0])] = Uri.UnescapeDataString(kv[1]); } } return result; }

5.3 参数投递到业务层的设计

解析出来的参数字典，怎么投递给业务层是个设计问题。我见过两种做法：一种是直接在 DeepLinkManager 里写一堆 if-else，根据scene参数跳转不同界面；另一种是发一个通用事件，让各模块自己判断。前者写起来快，但后期加场景会越来越乱；后者初期麻烦，但扩展性好。

我推荐后者，但加一层路由表。定义一个DeepLinkRoute结构，包含scene名称和对应的处理委托，注册到一个字典里。收到 Deep Link 时，根据scene查表调用。这样新增场景只需要注册一行，不用改核心逻辑。

6. 冷热启动与延迟消费的实战处理

6.1 冷启动参数缓存机制

冷启动时，Deep Link 参数可能在登录流程之前就到达了。如果此时直接触发跳转，用户还没登录，跳过去也是白跳。我的做法是：DeepLinkManager 收到参数后，先检查游戏是否已经进入主流程（比如登录完成、资源加载完成），如果没有，就把参数存到pendingDeepLink里，等主流程就绪的事件触发时再消费。

这个“主流程就绪”的信号，我一般用一个全局的GameFlowManager来发。登录完成、热更完成、进入大厅，这几个节点都可以作为消费时机，具体看你的业务需求。关键是只消费一次，消费完就把pendingDeepLink清空，避免重复跳转。

6.2 热启动的即时响应

热启动时游戏已经在大厅或者某个界面，Deep Link 参数到达后应该立即响应。但这里有个体验细节：如果用户正在战斗中，你直接把他拉去活动页面，他会很恼火。所以热启动的消费逻辑要加一层判断，比如战斗中先弹个提示，让用户选择是否现在前往。

另外，热启动时如果 App 是从后台恢复，OnApplicationPause(false)和 Deep Link 回调的先后顺序在不同 iOS 版本上可能不一样。我遇到过参数先到、OnApplicationPause后到的情况，导致界面状态判断错误。稳妥的做法是消费参数时不要依赖OnApplicationPause的状态，而是用自己维护的界面栈来判断。

6.3 重复唤醒的去重

用户可能连续点同一个链接多次，或者从不同渠道点进来。如果不做去重，可能会重复弹窗、重复发奖励。我的做法是给每个 Deep Link 生成一个唯一标识（比如 URL 的哈希），在一定时间窗口内（比如 5 秒）相同标识只处理一次。这个窗口不要太长，否则用户真的想再点一次会被误拦。

7. 常见问题排查与避坑清单

7.1 Universal Links 静默失效的排查顺序

Universal Links 最让人头疼的是它失败时没有任何提示，链接就是打不开 App。我总结了一套排查顺序，按这个顺序走基本能定位到问题：

我踩过最深的一个坑是：AASA 文件里appID的 Team ID 用了开发团队的，但打包用的是企业证书，两者 Team ID 不一致，导致链接一直不生效。排查了两天才发现。

7.2 URL Scheme 被拦截的应对

从微信、QQ 里点 Scheme 链接，大概率没反应。这不是你的配置问题，是这些 App 的内置浏览器主动拦截了非 HTTP 协议。应对方式有两种：一是引导用户点右上角“在浏览器中打开”，二是直接改用 Universal Links。买量场景下我强烈建议直接用 Universal Links，别跟内置浏览器较劲。

7.3 参数乱码与特殊字符

Deep Link 参数里如果包含中文、空格、&、=这些字符，必须做 URL 编码，否则解析会出错。原生层拿到的 URL 可能已经被系统解码过一次，C# 层再解码一次就乱了。我的经验是：在生成链接时就做好编码，解析时只解码一次，并且用Uri.UnescapeDataString而不是WWW.UnEscapeURL，前者对+的处理更符合标准。

7.4 测试阶段的实用技巧

测试 Universal Links 时，直接在 Safari 地址栏输入链接是不行的，Safari 会当成搜索。正确做法是把链接放在备忘录里，长按点击，或者用xcrun simctl openurl命令在模拟器里打开。真机测试时，从短信或者邮件里点链接最接近真实场景。

另外，每次改完 AASA 文件，最好把 App 卸载重装一次，因为系统会缓存 App 和域名的绑定关系。不重装的话，可能你改了配置但系统还在用旧的缓存。

8. 我在实际项目里的一些体会

这套链路我前后在三个项目里落地过，最大的感受是：原生层的代码越薄越好，C# 层的容错越厚越好。原生层只做“拿到字符串、存起来、发出去”三件事，任何业务判断都不要放进去，因为原生层调试成本太高，改一行要重新打包。C# 层则要把各种异常情况都考虑到，参数缺失、格式错误、重复唤醒、时机不对，都要有兜底。

还有一个体会是关于归因的。Deep Link 参数里通常会带渠道号、广告计划 ID 这些归因信息，这些信息在冷启动时可能比登录还早到达。我的做法是在 DeepLinkManager 初始化时就先把归因参数提取出来存到本地，等归因 SDK 初始化完成后直接读取，而不是等主流程。这样能避免归因丢失。

最后分享一个小技巧：在 Debug 包里加一个隐藏的 Deep Link 测试入口，可以手动输入 URL 模拟唤醒。这样测试同学不用真的去点链接，效率高很多。正式包记得把这个入口关掉，或者用宏定义隔离。

这套流程跑通之后，买量回流、活动唤醒、分享拉新这些场景都能复用同一套基础设施，后续加新场景只需要在路由表里注册一行。前期配置麻烦一点，但长期看非常值得。