# 苹果版Facebook应用自定义URL方案完整解析

## 吉祥法师

## 核心概念

苹果版Facebook应用（iOS版Facebook App）曾经提供了一套基于“自定义URL方案”（Custom URL Scheme）的深度链接功能。这些URL方案允许开发者或用户通过特定格式的链接，从其他应用程序或浏览器直接跳转到Facebook应用内的特定页面、功能或用户界面。此类链接格式通常以“fb://”开头，后跟指向特定模块或操作的路径和参数。

由于Facebook应用更新频繁，这些URL方案多数未经过官方文档正式说明（Undocumented），属于内部开发或逆向工程所发现的“非官方接口”。因此，这些URL方案在用户升级应用后可能会失效或行为发生变化，存在极大的不稳定性。严格来说，使用这些未公开的URL方案进行应用开发或日常操作，属于依赖未公开API（Undocumented APIs）的风险行为。

## 逻辑结构

本文将通过分析来自Stack Overflow等多个来源的汇总信息，梳理Facebook iOS版自定义URL方案的发展历程、功能分类与演变。逻辑结构分为以下部分：

1. **基础知识**：解释自定义URL方案的含义及其在Facebook应用中的作用。
2. **历史脉络**：整理不同版本（如v3.4、v12等）Facebook应用支持的各种URL方案，展现其功能演化与失效趋势。
3. **功能分类**：按照功能模块（如用户资料、动态消息、消息、照片、事件、群组、广告、市场等）分类整理URL方案，帮助读者理解其用途和使用方式。
4. **风险与注意事项**：强调这些URL方案未经官方支持，随时可能失效，并提及安全风险。
5. **总结与建议**：给出使用此类方案的最佳实践，以及官方推荐替代方案。

## 主要论点和论据

### 论点一：Facebook iOS应用自定义URL方案种类繁多，覆盖广泛功能

**论据**：根据逆向工程（通过分析Facebook二进制文件并提取字符串获得）的结果，Facebook应用的自定义URL方案数量非常庞大，功能覆盖了几乎所有主要的应用模块。例如，从较早的v3.4版本，到较新的v12版本，再到Android版本更新（通常与iOS版本功能保持一致），URL方案的数量和复杂性都在增长，甚至在某些列表中出现超过数百条方案记录（如“October 2017 Update”中的列表）。

**详细分类与举例**：

#### 用户资料和关系

-   **个人主页**：`fb://profile` 打开当前登录用户的个人主页；`fb://profile/` 或 `fb://profile?id=` 可打开指定用户的主页。
-   **好友列表**：`fb://friends` 打开好友列表页面。
-   **添加好友**：`fb://profile//addfriend` 向指定用户发送好友请求。
-   **好友动态**：`fb://friendsnearby` 打开“附近的朋友”功能。
-   **通知**：`fb://notifications` 打开通知列表。

#### 动态内容

-   **动态消息**：`fb://feed` 打开动态消息（News Feed）主页；`fb://feed/` 可打开特定过滤的动态（如“动态”、“最近”等）。
-   **发布状态**：`fb://publish/profile/?text=` 可以打开发布状态窗口并预先填充内容。然而，这个功能可能不够完美，发布后页面可能不会自动关闭，需要用户手动点击取消。

#### 消息与聊天

-   **消息列表**：`fb://messaging` 打开消息收件箱；`fb://messaging/` 可打开特定文件夹（如收件箱、垃圾箱）。
-   **新建会话**：`fb://messaging/new` 或 `fb://messaging/compose` 打开新建消息界面；`fb://messaging/compose/` 可指定收件人。
-   **查看会话**：`fb://messaging?id=` 打开与指定用户的对话。
-   **聊天功能（旧版）**：`fb://chat/` 打开与指定用户的聊天窗口。

#### 照片与视频

-   **相册列表**：`fb://albums` 打开照片相册列表。
-   **查看相册**：`fb://album/` 打开指定相册；`fb://album//cover` 查看相册封面。
-   **查看照片**：`fb://photo?id=` 打开指定照片；`fb://photo///` 可以查看特定用户特定相册中的特定照片。
-   **上传照片**：`fb://upload/photo///` 触发上传照片操作。
-   **播放视频**：`fb://video/` 播放指定视频。

#### 事件

-   **事件列表**：`fb://events` 或 `fb://events/` 打开事件列表页面。
-   **查看事件**：`fb://event/` 打开指定事件详情页面。
-   **事件创建**：`fb://event_creation` 打开创建事件页面；`fb://event_creation/` 预填特定事件信息。
-   **事件邀请**：`fb://event//invite` 邀请好友参加事件；`fb://event//extendedinvite` 邀请更多好友。

#### 群组

-   **群组列表**：`fb://groups` 或 `fb://groups/discover` 打开群组页面或发现群组。
-   **查看群组**：`fb://group/` 打开指定群组页面；`fb://group//members` 查看群组成员列表。
-   **创建群组**：`fb://groups/create` 打开创建群组页面。

#### 广告与商业功能

-   **广告管理**：`fb://adsmanager//insights/` 打开广告管理器查看广告效果；`fb://adsmanager//billing/settle` 进入广告结算页面。
-   **广告创建**：`fb://boost_post/?page_id=` 启动推广帖子流程；`fb://boost_event/?page_id=` 推广活动。
-   **支付相关**：`fb://ads_payments_checkout?account=&page=` 启动广告支付结账流程。
-   **商品**：`fb://commerce/products/` 打开特定商品页面；`fb://commerce/shop/` 查看店铺。

#### 其他功能

-   **账户设置**：`fb://account/recovery` 账户恢复；`fb://account_settings` 打开账户设置；`fb://privacy` 打开隐私设置。
-   **捐赠**：`fb://donate/?fundraiser_campaign_id=` 打开捐赠页面。
-   **市场**：`fb://marketplace` 打开Facebook Marketplace。
-   **获取应用**：`fb://appcenter` 打开应用中心；`fb://appcenter/detail?app_id=` 查看应用详情。
-   **通用链接**：`fb://faceweb/f?href=` 通过FaceWeb（Facebook内嵌浏览器）打开一个网页链接，常用于无法直接通过App内导航实现的页面访问。

### 论点二：这些自定义URL方案未经官方支持，存在严重的稳定性和安全性风险

**论据**：答案中明确提到“Note: These URL’s are likely not available. Facebook has been updated a number of times and did not officially support any of these.”（注意：这些URL可能已经不可用了。Facebook已经被更新了很多次，并且从未官方支持其中的任何一个。） 此外，多位用户报告称，随着应用的升级，许多URL方案在后续版本中失效或被移除。**甚至在某些时候，应用只接受没有任何参数的 `fb://` 基本链接**。

**风险分析**：

1.  **版本依赖**：URL方案的行为和可用性完全依赖于应用内部实现，一旦Facebook更新应用，链接可能立即失效或者重定向到意想不到的页面。
2.  **逆向工程来源**：这些信息是通过逆向工程（反编译应用二进制文件）获得的，这意味着它们不属于公开的稳定API。开发者使用此类方案将面临应用商店审核风险（Apple App Store通常不鼓励使用未公开的私有API）。
3.  **安全隐私问题**：部分URL方案允许跳过用户选择而直接打开特定功能，这可能被恶意应用利用来发起钓鱼攻击或窥探用户隐私（例如，通过预先填充表单诱骗用户发布内容）。
4.  **开发成本高**：为了维护与Facebook应用的兼容性，开发者需要不断追踪这些URL方案的变化，增加了开发和维护成本。

### 论点三：官方推荐的最佳实践是使用Facebook官方提供的SDK和深度链接方案，而非依赖自定义URL方案

**论据**：虽然问答未直接提及官方方案，但根据Facebook开发者文档的官方指导，开发者应使用Facebook SDK提供的“App Links”或“Facebook Universal Links”来实现深度链接。这些方案是官方支持、稳定且安全的。

**官方替代方案**：

-   **App Links**：一种开放标准，允许从一个应用链到另一个应用的特定内容。Facebook应用支持App Links规范。
-   **Facebook Universal Links（iOS 9+）**：现代iOS上实现无缝深度链接的标准方式，允许应用直接通过标准的 `https://` 链接跳转到应用内内容，如果应用未安装则回退到网站。
-   **Facebook SDK**：通过 `FBSDKAppLinkUtility` 类可以获取和解析传入应用的深度链接。
-   **分享到Facebook**：通过Facebook SDK的 `Share Dialog` 或 `Share API`，用户可以直接发布内容到其时间线，无需依赖非官方URL的发布命令。

## 深度解析与内容扩充

### 自定义URL方案的背景与意义

在Facebook官方还未提供完善的深度链接API和通用链接（Universal Links）之前，开发者若想实现“当用户点击某个链接时，自动唤起Facebook应用并跳转到指定的页面或功能”，只能依赖自定义URL方案。这些方案实质上是应用向系统注册的“自定义协议”（如 `fb://`），系统收到此类协议的请求后，会尝试唤起Facebook应用中对应的处理程序。

这种机制为应用间互操作（Inter-app Communication）提供了可能性。例如，第三方应用可以通过 `fb://publish/profile/me?text=Hello` 这样的链接，让用户无需手动输入内容就能直接在Facebook应用中发表状态。但与此同时，这种“非官方”的接口也给开发者带来了巨大的不确定性，因为Facebook随时可以修改其内部架构，导致链接失效。

### 列表的演化历程

从问答中可以看出，URL方案列表在多个版本中有显著的差异：

-   **早期版本（v3.4左右）**：列表相对简洁，功能主要是导航到应用的各个主要界面（如资料、朋友、动态、照片、相册、事件、群组等）。部分方案支持简单的参数（如通过ID导航到指定对象）。
-   **中期版本（v12左右）**：功能更加丰富，出现了与位置服务、商品、捐赠、广告管理、市场、游戏、应用中心等模块相关的链接。方案的形式也变得更加复杂，引入了更多的查询参数（query parameters）以实现更精确的定位和操作。
-   **后期版本（Android版2017年）**：列表达到惊人的长度，功能几乎覆盖了Facebook应用的所有模块，包括支付、广告管理、店铺、捐赠、市场、商品、事件、群组、位置、账户、应用中心等。这反映了Facebook应用功能的不断扩张，但对私有API的依赖风险也随之加大。

**重要转折点**：用户反馈中提到“Looks like none of below works anymore with latest versions, facebook app navigation probably has been rewrited.”（看起来下面的所有方案在最新版本中都不再工作，Facebook应用导航可能已被重写。） 这证实了自定义URL方案的脆弱性。迭代时，Facebook可能会从根本上重写应用的导航架构（例如，从传统的UIViewController导航切换到更深度的基于路由的架构），导致所有基于旧架构的URL方案全部失效。

### 使用实例与潜在陷阱

-   **发布状态**：`fb://publish/profile/#ID#?text=#BODY#`。原提问者发现，使用此方案发布后，对话框不会自动关闭，用户必须手动点击“取消”按钮。这种不完善的行为会破坏用户体验。
-   **通知页面**：`fb://notifications`。用户报告称，该URL虽然能打开通知页面，但会导致用户无法再导航到应用的其他地方，这显然是一个Bug。
-   **“feed”方案**：`fb://feed` 被普遍使用，因为它是直接跳转至动态消息的便捷路径。但在后续版本中，此链接可能无法稳定工作，可能直接回到主页或打开错误的页面。
-   **“faceweb”方案**：`fb://faceweb/f?href=` 是处理无法直接通过App导航实现的复杂页面的通用方法。它本质上是将请求委托给Facebook内置的浏览器（FaceWeb）来加载标准网页。这虽然是兼容性方案，但加载速度较慢，用户体验不如原生界面。

### 安全与风险的进一步讨论

除了前文已提到的稳定性问题外，依赖自定义URL方案还可能导致应用在审核时被拒。Apple App Store严格禁止应用使用未公开的私有API，因为这类API可能随时被操作系统或系统应用（如Facebook）更改，导致应用崩溃或行为异常。使用 `fb://` 这样的方案来与其他应用进行深度交互，虽然不被视为直接违反私有API规则，但一旦Facebook决定停用这些方案，依赖它们的应用功能会突然失效，用户在启动应用后无法跳转到目标页面，体验大受折扣。

此外，开发者还应警惕安全漏洞。例如，如果一个恶意应用能够伪造一个链接来调用 `fb://publish/profile/me?text=恶意内容`，它就可能诱骗用户在其不知情的情况下发布有害内容（尽管实际操作需要用户再次确认，但风险依然存在）。

## 结论与建议

虽然苹果版Facebook的自定义URL方案曾为开发者提供了一种与Facebook应用进行深度交互的便捷方法，但这种方法因其不稳定性、缺乏官方支持和潜在安全风险，已不再推荐使用。

**给当前开发者的建议**：

1.  **立即弃用**：所有依赖于上述任意URL方案的功能应当被移除或重写。
2.  **转向官方方案**：
    -   **深度链接**：使用Facebook SDK提供的“App Links”或“Universal Links”。这些是面向未来的、官方的标准，能够保证稳定性和可靠性。
    -   **分享内容**：使用Facebook SDK的`Share API`来让用户从你的应用直接共享内容到其时间线，而不是模拟在Facebook应用内部发布。
    -   **打开特定页面**：如果需要在你的应用中链接到Facebook应用的特定页面（例如一个公共主页），你可以使用iOS 9+的`SFSafariViewController`在应用内嵌浏览器中打开该页面的URL（例如`https://www.facebook.com/YourPage`），这总比一个可能会崩溃的深度链接要好。
3.  **关注官方文档**：始终参考Facebook开发者官方文档（developers.facebook.com），以了解最新的、被支持的API和功能。
4.  **预防性措施**：即使在短期内继续使用某些经过测试且有效的自定义URL方案，也应在代码中加入容错机制（例如，当无法唤起Facebook应用时，优雅地降级为在Safari中打开网页），并且定期测试以确保方案尚未失效。

总而言之，自定义URL方案已成为Facebook应用开发历史的一部分，对于新项目而言，使用官方SDK和现代深度链接标准是不二之选。对于遗留系统，迁移到官方支持的方案应被列为优先任务，以确保应用长期的兼容性与用户体验。