CDN Presentation API是一组让网页能够将内容展示到第二屏幕并维持远程控制的浏览器接口。它主要解决的是本地会议、在线教育和产品发布等场景中，主讲人希望用一台设备操控另一台设备显示内容的需求。借助这套机制，演示文稿不必依赖特定的硬件连线，也不必将主控设备的全部界面暴露给观众。
Presentation API的核心概念与连接模型
在Presentation API中，最核心的对象是PresentationRequest。它由网页脚本在主文档中创建，并传入一个演示文稿的URL，这个URL通常指向承载幻灯片内容的HTML页面。当调用start()方法时，浏览器会尝试寻找可用的演示设备，例如通过Miracast、Google Cast或系统级的无线显示能力，进而在第二屏幕上加载指定页面。
一旦连接建立，主页面会拿到一个PresentationConnection对象。这个对象代表一条逻辑通道，主控端和接收端都可以通过它收发消息。需要特别注意的是，演示文稿页面本身运行在接收端，而主控页面运行在发送端，两者通过postMessage交换数据，而不是共享同一个DOM。这样的隔离设计避免了敏感操作被投射出去，也降低了渲染冲突。
可用性检测是实际开发中容易忽略的一步。通过监听PresentationRequest的onavailablechange事件，脚本能够得知当前是否有可投屏设备。若直接调用start()而没有任何可用设备，浏览器会抛出异常或让用户从空列表中选择，体验较差。下面代码展示了基本的请求与可用性监听：
const presUrl = 'https://ipipp.com/slides/index.html';
const req = new PresentationRequest(presUrl);
req.onavailablechange = function(event) {
if (event.value) {
console.log('发现可用演示设备');
} else {
console.log('当前无可用设备');
}
};
req.start().then(function(conn) {
console.log('连接已建立，连接ID：' + conn.id);
}).catch(function(err) {
console.error('启动演示失败：' + err.message);
});
基于CDN的演示资源分发与延迟优化
当演示文稿包含大量图片、字体与脚本时，如果接收端直接从源站拉取，位于不同网络环境的分会场可能加载缓慢。将幻灯片静态资源托管在CDN上，可以让接收端从边缘节点就近获取。由于Presentation API的演示页本质是一个独立网页，它和普通Web页面一样受益于一整套缓存与分发策略。
在具体实践中，建议把幻灯片拆分为瘦HTML加异步数据。主控端只发送当前页码和批注坐标，接收端根据页码从CDN拉取对应分片。这样即便网络抖动，也只影响单页而非整体连接。对比传统的整包屏幕共享，这种方式带宽占用通常能下降到原来的三分之一以下，同时主控端的CPU不用持续编码画面。
另一个要点是缓存失效控制。演示者经常临时修改文稿，如果CDN缓存时间过长，接收端会显示旧版本。可以通过在资源URL后追加版本号或哈希来破缓存，例如slide-2.3.1.js。下面给出一个简单的接收端拉取逻辑，展示如何结合页码与CDN地址：
let currentPage = 1;
function loadSlide(page) {
const base = 'https://ipipp.com/cdn/slides/';
const url = base + 'page-' + page + '.html?v=2.3.1';
fetch(url).then(function(r) {
return r.text();
}).then(function(html) {
document.getElementById('stage').innerHTML = html;
});
}
window.addEventListener('message', function(e) {
const data = JSON.parse(e.data);
if (data.type === 'goto') {
currentPage = data.page;
loadSlide(currentPage);
}
});
远程控制指令通道与错误处理实践
主控端对演示文稿的远程控制，实际上是一组结构化消息的往返。常见的指令包括翻页、高亮、激光笔坐标和退出演示。为了保证可靠，发送端应在PresentationConnection的onmessage中确认回执，接收端则在onstatechange中感知连接断开。很多初级实现只发不收，结果大屏卡死而主讲人并不知情。
在错误分类上，主要有设备层错误、通道层错误和语义层错误。设备层例如无可用屏幕，应在start()的catch中提示用户检查无线显示；通道层如连接被系统回收，需要重新start；语义层如接收端解析指令失败，应通过消息返回错误码。下表列出常见错误与建议处理：
| 错误类型 | 触发场景 | 处理建议 |
|---|---|---|
| 设备不可用 | 无投屏目标或权限被拒 | 引导开启系统无线显示 |
| 连接中断 | 网络切换或设备休眠 | 自动重连并恢复页码 |
| 消息超时 | 接收端脚本异常 | 发送端弹窗提醒并检查接收页日志 |
下面示例展示了一个带确认机制的翻页指令发送，以及接收端的简单应答。注意消息体使用纯字符串或JSON，避免传递函数或DOM对象：
// 发送端
conn.postMessage(JSON.stringify({type: 'goto', page: 5, ts: Date.now()}));
conn.onmessage = function(e) {
const ack = JSON.parse(e.data);
if (ack.type === 'ack' && ack.page === 5) {
console.log('接收端已切换到第5页');
}
};
// 接收端
conn.onmessage = function(e) {
const cmd = JSON.parse(e.data);
if (cmd.type === 'goto') {
showPage(cmd.page);
conn.postMessage(JSON.stringify({type: 'ack', page: cmd.page}));
}
};
综合来看，CDN Presentation API把演示文稿的远程控制抽象为请求、连接与消息三层结构。配合CDN的边缘分发，能够显著降低大屏加载时延并提升弱网稳定性。开发时应重视可用性监听、缓存版本管理与双向确认，才能让遥控翻页真正可用而不是演示翻车。
CDN_Presentation_APIremote_controlslideshow修改时间：2026-08-17 23:38:39