iOS设备上YouTube IFrame API为何使用youtubeplayer://协议发送消息？

问题背景 #

我正在为项目尝试使用YouTubePlayerKit的部分功能，该库的工作流程大致如下：

• 通过videoId创建播放器实例
• 创建用于加载视频的webview
• 执行JS代码以加载视频

在研究第三步的源码时，我发现了如下函数：

// Send YouTubePlayer Event with optional data
function sendYouTubePlayerEvent(event, data) {
    var locationHref = 'youtubeplayer://' + event;
    if (data) {
        locationHref = locationHref + '?data=' + data;
    }
    window.location.href = locationHref
}

我的疑问是：该库为何使用youtubeplayer://协议？是否是根据播放器类名推断事件接收方？另外我参考了youtube-ios-player-helper库，它使用的是ytplayer://协议，这背后的逻辑是什么？

解答 #

1. 自定义协议的本质作用 #

youtubeplayer://这类不是标准HTTP协议，而是自定义URL Scheme，是WebView和原生代码之间的通信手段：

• 原生端会提前注册这个Scheme（比如iOS里在Info.plist配置相关项，或通过WebView代理拦截请求）
• 当JS里修改window.location.href触发这个Scheme时，原生的WebView代理会捕获到该请求，解析出事件名和附带的data，再将事件分发到对应的播放器实例处理。
• 它和播放器类名没有直接关联，核心是原生端提前约定好要拦截处理这个Scheme的请求。

2. 不同库使用不同Scheme的逻辑 #

不同库用不同的自定义Scheme，核心是为了避免冲突：

• YouTubePlayerKit用youtubeplayer://是开发者基于库名做的命名，直观好识别，能和其他库的通信请求区分开。
• youtube-ios-player-helper是官方维护的辅助库，用ytplayer://是因为yt是YouTube的通用缩写，更简洁，也是官方团队的命名习惯，同样是为了和其他自定义Scheme划清界限，防止不同库的通信请求被误处理。

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