APP未安装时从通用链接启动：deferred deeplink处理及方法调用咨询

1. 首次安装启动时，application(_:continue:restorationHandler:)会被调用吗？ #

不会。这个方法仅在APP已处于前台/后台活跃状态时，处理通过Universal Links或自定义URL Scheme唤起APP的场景。用户从App Store首次安装并启动APP时，APP是全新初始化的，没有可恢复的会话状态，因此该方法不会触发。

2. 处理Deferred Deeplink的最佳方式 #

Deferred Deeplink（延迟深度链接）的核心是在用户首次启动APP时，获取之前点击链接携带的上下文信息，以下是几种可靠的实现方案：

• Universal Links + 后端验证方案
  这是最主流的实现方式：

  • 用户点击邮件中的Universal Link时，若APP未安装，系统会跳转至App Store。此时后端服务器记录该请求的设备关联信息（如IP、哈希化的IDFA，或通过网页Cookie关联用户），并绑定链接携带的上下文参数。
  • 用户首次启动APP后，APP向后端发起请求，携带当前设备的标识信息（需遵守隐私政策，比如IDFA需用户授权），后端匹配之前的记录，返回对应的上下文参数供APP处理。

• 中转网页+剪贴板（备选方案）
  适合快速实现的场景：

  • 点击链接后先打开中转网页，网页将上下文信息写入剪贴板，再跳转至App Store。
  • 用户首次启动APP时，读取剪贴板内容并解析上下文。
  • 缺点：依赖用户不清除剪贴板，体验不够稳定，仅作为临时方案使用。

• 结合系统框架的归因方案

  • iOS 14+可使用AppTrackingTransparency框架获取用户授权后的IDFA，结合后端的点击记录进行设备匹配，获取上下文。
  • Apple的SKAdNetwork主要用于广告归因，但也可在转化参数中携带有限长度的上下文信息，满足简单场景的需求。

• 唯一标识绑定方案

  • 点击链接后跳转至中转网页，生成唯一标识并与上下文绑定存储到后端；网页引导用户跳转至App Store时，将该标识通过某种方式关联到设备（如网页Cookie或IP）。
  • 首次启动APP时，APP请求后端，携带设备信息，后端匹配唯一标识对应的上下文返回。

内容的提问来源于stack exchange，提问作者Nilesh Tupe