Zoom Video SDK 跨平台交付实战Android / iOS / macOS / Unity 的统一 Token、会话状态与升级策略【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins本指南围绕 knowledge-work-plugins 仓库中 Zoom Video SDK 的 Native 多平台交付用例展开目标是在同一产品愿景下同时交付 Android、iOS、macOS 与 Unity 四个平台的视频会话应用并确保 Token 鉴权、会话行为与 SDK 升级策略在各端保持一致。读完本文你将掌握一套可落地的跨平台交付模型统一后端 Token 服务契约、跨平台一致的会话生命周期状态机、版本锁定与兼容性检查流程以及针对各平台故障模式的回退预案与输出清单。用例背景与目标本用例对应的原文见 Native Video SDK Multi-Platform Delivery其核心目标可以浓缩为一句话Ship one product experience across Android, iOS, macOS, and Unity while keeping token auth, session behavior, and upgrade policies aligned.翻译成工程语言就是不要让每个平台各自为政地实现一遍登录—开会—退出而是由一套共享的设计约束Token 契约、会话状态机、升级策略、回退预案把所有平台绑定在同一条产品线上。该用例位于 Zoom 插件技能树的 use-cases 目录下属于 zoom-video-sdk 母技能下的应用层编排文档适合在确定走 Video SDK 而非 Meeting SDK之后作为多端交付的执行蓝图。在进入交付模型之前需要先明确技术选型边界。母技能 SKILL.md 中有一条硬性路由护栏Hard Routing Guardrail自定义实时视频 App 行为topic/session 加入、自定义渲染、attach/detach必须路由到 Video SDKVideo SDK不使用Meeting ID、join_url也不接受 Meeting SDK 的meetingNumber、passWord字段。同时Video SDK 与 Meeting SDK 在产品形态上有本质区别特性Meeting SDKVideo SDKUI默认 Zoom UI 或自定义 UI完全自定义 UI由你构建体验Zoom 会议Meeting视频会话Session品牌定制空间有限完全品牌可控功能Zoom 全量功能核心视频功能跨平台交付的前提是四端都基于 Video SDK 的能力模型因此下文所有会话、Token、事件概念均以 Video SDK 为准。需要串联的技能链路原文明确给出了完成该用例需要按序调用的技能Skills to chain在仓库中的完整路径为zoom-video-sdkVideo SDK 总体参考负责路由判定与通用生命周期zoom-video-sdk-androidAndroid 原生端自定义 UI、会话 Token、事件驱动参与者状态zoom-video-sdk-iosiOS 原生端delegate 驱动的生命周期zoom-video-sdk-macosmacOS 桌面端自定义会话窗口、桌面设备工作流zoom-video-sdk-unityUnity 包装器端游戏引擎集成、场景驱动的 UXzoom-oauth鉴权与 Token 生命周期支撑。这六份技能各有侧重四份平台技能负责本端如何入会、渲染、退会zoom-oauth负责后端如何签发/刷新访问令牌而母技能负责把两端串起来。跨平台交付时正确的调用顺序应当是先用母技能完成路由判定与通用设计 → 用zoom-oauth确定后端鉴权方案 → 再逐个平台落地。注意各平台技能文件本身都内置了Start Here入口例如 Android 端从 android.md 开始依次阅读 lifecycle-workflow、architecture、session-join-pattern 等阅读时可按各自入口顺序深入。推荐交付模型四步法原文将交付模型归纳为 4 个步骤。下面逐条展开并补充仓库中的源码级证据。第 1 步标准化后端 Token 服务契约四端共用一套后端签名服务契约字段必须事先冻结。仓库中的 token-contract-test-spec.md 给出了完整契约定义这正是原文sessionName、userName、role/claims 的具体化契约输入请求侧字段必填说明sessionName是会话/主题标识符用于 joinuserName是会话内显示名roleType可选写入 Token claims 的角色/权限塑造expirationSeconds可选Token TTL 覆盖值须在策略窗口内契约输出响应侧字段必填说明token是短时效 Video SDK JWTexpiresAt是绝对过期时间戳sessionName是回显的 join 会话标识后端必须满足的断言Assertions签名使用ZOOM_VIDEO_SDK_KEYZOOM_VIDEO_SDK_SECRET来自服务端配置绝不下发到客户端Token TTL 为短时效且符合策略响应不暴露任何密钥材料非法输入返回结构化的 4xx 错误载荷。从架构证据看四端文档一致强调Token 创建必须严格放在后端。例如 Android 的 architecture.md 中的架构图明确画出UI → ViewModel/Controller → 同时指向 Video SDK 与 Token API → Token API 再连到服务端 JWT Signer → Signer 依赖 Marketplace 的 App Credentials。Unity 的 architecture.md 则明确要求 Avoid direct credential logic in Unity clientUnity 客户端内不得出现凭据逻辑。iOS 的 architecture.md 同样将 Server JWT Signer 独立于客户端之外。为什么要统一契约因为四端拿到的是同一个sessionName 各自唯一的userName才能在同一个 session 中互见。若某一端私自改字段语义例如把sessionName拼上前缀会导致该端用户被分到另一个会话——这就是原文Token claim 变更只打破一个平台这类故障模式的根源。关于后端鉴权本身可进一步参考 zoom-oauthVideo SDK 场景通常采用 Server-to-Serveraccount_credentials无用户参与的机器对机器鉴权签发访问令牌若涉及以用户身份授权例如移动端则应走授权码流程并为公开客户端启用 PKCE因为移动 App 无法安全保存 Client Secret。该技能还包含完整的错误码对照表4700–4741 区间如 4709 Redirect URI mismatch、4733 Code 过期等是排查后端鉴权问题时的速查入口。第 2 步保持各平台会话状态机一致原文要求四端的状态机保持一致init - join - media - leave。各平台的生命周期文档给出了几乎同构的操作序列这正是跨平台一致性的实现基础阶段Androidlifecycle-workflowiOSlifecycle-workflowmacOSlifecycle-workflowUnitylifecycle-workflow1从后端请求 Token请求 Token获取 Token从后端获取 Token2初始化 SDK 并注册核心监听器初始化并挂接 delegate初始化 SDK 与 delegate/event 桥初始化 wrapper 与事件处理器3用 sessionName/topic、显示名、Token 入会用 session 名/topic 与显示名入会以用户身份入会以 topic/session 名与显示身份入会4入会成功后才启动本地摄像头/麦克风在 join 成功回调后启动本地媒体join 确认后启动媒体通过 wrapper API 启停本地媒体5依据事件渲染远端用户以回调为唯一事实来源处理参与者与媒体处理参与者/媒体更新与视图生命周期将参与者/媒体更新应用到场景对象6退会/断开时取消监听并释放资源退出时清理 delegate 与会话资源停止媒体并释放资源退会或切场景时干净地释放资源跨端对齐的关键点有二入会成功后才能启媒体是所有平台的共同硬约束。母技能 SKILL.md 中有一条权威警告在 Web 端client.getMediaStream()只有在join()之后才有效提前调用会静默返回undefined各原生端也一致要求Start local media only after successful join。这条规则在四端必须一视同仁。渲染必须是事件驱动的。Android 文档明确要求Drive UI from SDK event streams to avoid stale participant state用 SDK 事件流驱动 UI避免参与者状态过期iOS 要求Render participant tiles from delegate-driven state onlymacOS 要求Separate render state from transport/session stateUnity 要求Convert SDK callbacks into explicit Unity state updates。也就是说UI 上谁在线、谁在讲话的显示一律来自事件/回调而不是本地缓存。可进一步参考 session-lifecycle.md该文档标题即 Join, Stream, Render, Leave它把规范顺序总结为Create client →init→join→ 获取媒体流 → 基于事件启动音视频并渲染 → 退会清理。这套顺序对所有平台通用。第 3 步版本锁定与发布前兼容性检查原文要求Version-lock each platform release and run compatibility checks before rollout。仓库中各平台的版本兼容文档提供了具体证据Androidversioning-and-compatibility.mdSDK 包zoom-video-sdk-android-2.5.0.zip内部版本v2.5.0 (37500)包含mobilertc.aar与示例模块兼容性要求App 与后端 Token 逻辑必须与同一 Video SDK 发布族对齐跨版本会有方法新增/重命名因此每个发布列车都要固定 SDK 版本升级时必须重新校验 ProGuard/R8 规则与权限。Unityversioning-and-compatibility.md包装器包unity-zoom-video-sdk-0.0.2-beta.zip内含ZoomVideoSDK.unitypackageUnity wrapper 的版本号与原生 Android/iOS/macOS 的 SDK 流相互独立实现前必须逐一核对 wrapper 参考文档中的每个 API/事件是否可用明确把 wrapper 视为可能只是原生 SDK 功能子集。这两份文档共同揭示了跨平台版本管理的核心矛盾四端并不天然处于同一版本平面。Unity wrapper0.0.2-beta与原生包族2.5.0之间存在明显版本落差wrapper 文档中的功能名可能与原生平台参考不一致。因此版本锁定不能只锁Zoom SDK 版本而是要建立一张平台 × SDK 版本 × 后端 Token 契约版本的对照矩阵每次发布前逐端跑兼容性检查。兼容性检查的落地方式可复用 token-contract-test-spec.md 中定义的全平台客户端冒烟测试用相同的sessionName模式和唯一的userName请求 Token用返回的 Token 入会确认 join 成功回调/事件启动本地媒体并验证参与者状态事件退会并验证清理回调/事件。同一套冒烟脚本跑满四端任何一端在步骤 25 中行为不一致即视为发布阻断问题。第 4 步为被重命名/废弃的 API 准备各平台回退计划原文要求 Maintain per-platform fallback plans for renamed/deprecated APIs。结合版本证据这一条的现实基础非常充分Android 文档明示Expect method additions/renames across releases各版本间会出现方法新增/重命名Unity 文档明示 wrapper 与原生之间Some docs and feature names may differ部分文档与功能名可能不一致。因此回退计划至少应包含API 别名层在客户端封装一个薄抽象层Android 的 ViewModel/Session Controller、iOS 的 Coordinator/Session Store、macOS 的 Session Coordinator、Unity 的 Session Manager把底层 SDK 调用收敛到单一边界内。四个平台的 architecture.md、ios architecture、macos architecture、unity architecture 全部强调了这个边界一旦 SDK 方法改名只需改这一层而不是全项目替换版本对照表升级前先做 API diff标记哪些方法被 rename、哪些事件被 rename、哪些能力被移除回滚策略每个发布列车保留上一个可用 SDK 版本作为回滚目标并在升级 runbook 中写明回滚触发条件例如冒烟测试步骤 3/4 失败即回滚降级预案对 Unity 这类 wrapper 滞后于原生的情况若某功能 wrapper 不支持明确是等待 wrapper 升级还是回退到原生桥接实现避免临场决策。需要提前规划的故障模式原文列出了四类必须 pre-plan 的失败模式结合仓库证据逐一展开1. Wrapper / 原生功能错位尤其是 UnityUnity 的 wrapper 包为0.0.2-beta远落后于原生2.5.0包族wrapper 可能只是原生功能子集。这意味着原生能跑的通Unity 可能跑不通。token-contract-test-spec 中的诊断项也专门给出works native, fails Unity→ 验证该版本 wrapper 是否支持相同的 join/token 预期。建议Unity 端开发前先对照 wrapper 参考文档盘一遍要用到的 API 是否存在不要直接照搬原生示例代码。2. 跨 SDK 版本的事件命名漂移各平台文档都提示事件/方法会随版本演进改名。事件名漂移的直接后果是 UI 收不到某人上/下麦某人进出会等关键回调表现为参与者面板不动或画面不渲染。建议把事件名视为契约的一部分纳入升级 runbook 的 diff 检查事件处理逻辑集中封装避免散落各处难以统一替换。3. Token claim 变更只影响单个平台同一后端契约同时服务四端但各端 SDK 对 claim 的解析细节可能不同。若某次改动调整了 claim 结构例如角色字段从roleType改为role可能出现三个平台正常、一个平台 join 失败的现象。token-contract-test-spec 的诊断条目指出join failed/auth仅出现在单平台时应对比 claim 载荷的处理方式与 SDK 版本差异。建议Token 契约变更必须四端同时回归尤其是冒烟测试第 2 步join。4. 各 OS 版本的权限/回归差异Android、iOS、macOS 每次系统大版本发布都可能改变权限模型摄像头/麦克风授权弹窗行为、后台权限策略等Unity 场景还叠加了宿主平台权限。Android 兼容文档特别要求升级时重新校验 ProGuard/R8 规则与权限。建议维护一张OS 版本 × 权限行为 × 已知回归的矩阵在 OS 新版本发布窗口期提前跑全平台权限回归。输出清单交付物定义原文给出了跨平台交付必须产出的四类工件它们应当与交付流程绑定输出物内容要点对应仓库依据共享鉴权/Token 契约规格sessionName、userName、roleType、expirationSeconds输入token、expiresAt、sessionName输出后端断言清单token-contract-test-spec.md各平台会话生命周期文档每端一份init → join → media → leave状态机文档注明事件驱动渲染规则各平台 lifecycle-workflow 文档族带回滚计划的升级 runbook版本锁定策略、API diff 检查、冒烟测试步骤、回滚触发条件versioning-and-compatibility.mdAndroid、versioning-and-compatibility.mdUnity已知不兼容矩阵平台 × SDK 版本 × 功能能力对照wrapper 子集问题OS 权限回归记录上述兼容性文档的 Contradictions or drift to watch 小节这份清单同时构成了跨平台交付的验收标准四件工件齐备、冒烟测试全端通过才算一次完成的发布。落地路径与进一步阅读在实际执行时建议按以下顺序推进用 zoom-oauth 确定后端鉴权方案S2S 或授权码 PKCE冻结 Token 契约按 token-contract-test-spec.md 实现并验证后端签名服务逐平台实现会话生命周期统一遵循 session-lifecycle.md 的规范顺序锁定各端 SDK 版本维护不兼容矩阵发布前在四端各跑一遍冒烟测试并准备好回滚方案。如需进一步深入可继续阅读平台入门Android SKILL.md、iOS SKILL.md、macOS SKILL.md、Unity SKILL.md各含 Start Here 阅读顺序与 RUNBOOK架构细节Android architecture.md、iOS architecture.md、macOS architecture.md、Unity architecture.md会话加入模式examples/session-join-pattern.md各平台技能目录下均有同构文件母技能总览与路由规则video-sdk/SKILL.md。需要提醒的是本仓库为只读参考资源所有技能文档用于指导开发与排查不涉及对仓库本身的修改。实际构建时请以 Zoom 官方最新文档为准核对版本与 API 细节因为如兼容性文档所注仓库内的版本与功能信息可能滞后于官方动态页面。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Zoom Video SDK 跨平台交付实战：Android / iOS / macOS / Unity 的统一 Token、会话状态与升级策略
Zoom Video SDK 跨平台交付实战Android / iOS / macOS / Unity 的统一 Token、会话状态与升级策略【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins本指南围绕 knowledge-work-plugins 仓库中 Zoom Video SDK 的 Native 多平台交付用例展开目标是在同一产品愿景下同时交付 Android、iOS、macOS 与 Unity 四个平台的视频会话应用并确保 Token 鉴权、会话行为与 SDK 升级策略在各端保持一致。读完本文你将掌握一套可落地的跨平台交付模型统一后端 Token 服务契约、跨平台一致的会话生命周期状态机、版本锁定与兼容性检查流程以及针对各平台故障模式的回退预案与输出清单。用例背景与目标本用例对应的原文见 Native Video SDK Multi-Platform Delivery其核心目标可以浓缩为一句话Ship one product experience across Android, iOS, macOS, and Unity while keeping token auth, session behavior, and upgrade policies aligned.翻译成工程语言就是不要让每个平台各自为政地实现一遍登录—开会—退出而是由一套共享的设计约束Token 契约、会话状态机、升级策略、回退预案把所有平台绑定在同一条产品线上。该用例位于 Zoom 插件技能树的 use-cases 目录下属于 zoom-video-sdk 母技能下的应用层编排文档适合在确定走 Video SDK 而非 Meeting SDK之后作为多端交付的执行蓝图。在进入交付模型之前需要先明确技术选型边界。母技能 SKILL.md 中有一条硬性路由护栏Hard Routing Guardrail自定义实时视频 App 行为topic/session 加入、自定义渲染、attach/detach必须路由到 Video SDKVideo SDK不使用Meeting ID、join_url也不接受 Meeting SDK 的meetingNumber、passWord字段。同时Video SDK 与 Meeting SDK 在产品形态上有本质区别特性Meeting SDKVideo SDKUI默认 Zoom UI 或自定义 UI完全自定义 UI由你构建体验Zoom 会议Meeting视频会话Session品牌定制空间有限完全品牌可控功能Zoom 全量功能核心视频功能跨平台交付的前提是四端都基于 Video SDK 的能力模型因此下文所有会话、Token、事件概念均以 Video SDK 为准。需要串联的技能链路原文明确给出了完成该用例需要按序调用的技能Skills to chain在仓库中的完整路径为zoom-video-sdkVideo SDK 总体参考负责路由判定与通用生命周期zoom-video-sdk-androidAndroid 原生端自定义 UI、会话 Token、事件驱动参与者状态zoom-video-sdk-iosiOS 原生端delegate 驱动的生命周期zoom-video-sdk-macosmacOS 桌面端自定义会话窗口、桌面设备工作流zoom-video-sdk-unityUnity 包装器端游戏引擎集成、场景驱动的 UXzoom-oauth鉴权与 Token 生命周期支撑。这六份技能各有侧重四份平台技能负责本端如何入会、渲染、退会zoom-oauth负责后端如何签发/刷新访问令牌而母技能负责把两端串起来。跨平台交付时正确的调用顺序应当是先用母技能完成路由判定与通用设计 → 用zoom-oauth确定后端鉴权方案 → 再逐个平台落地。注意各平台技能文件本身都内置了Start Here入口例如 Android 端从 android.md 开始依次阅读 lifecycle-workflow、architecture、session-join-pattern 等阅读时可按各自入口顺序深入。推荐交付模型四步法原文将交付模型归纳为 4 个步骤。下面逐条展开并补充仓库中的源码级证据。第 1 步标准化后端 Token 服务契约四端共用一套后端签名服务契约字段必须事先冻结。仓库中的 token-contract-test-spec.md 给出了完整契约定义这正是原文sessionName、userName、role/claims 的具体化契约输入请求侧字段必填说明sessionName是会话/主题标识符用于 joinuserName是会话内显示名roleType可选写入 Token claims 的角色/权限塑造expirationSeconds可选Token TTL 覆盖值须在策略窗口内契约输出响应侧字段必填说明token是短时效 Video SDK JWTexpiresAt是绝对过期时间戳sessionName是回显的 join 会话标识后端必须满足的断言Assertions签名使用ZOOM_VIDEO_SDK_KEYZOOM_VIDEO_SDK_SECRET来自服务端配置绝不下发到客户端Token TTL 为短时效且符合策略响应不暴露任何密钥材料非法输入返回结构化的 4xx 错误载荷。从架构证据看四端文档一致强调Token 创建必须严格放在后端。例如 Android 的 architecture.md 中的架构图明确画出UI → ViewModel/Controller → 同时指向 Video SDK 与 Token API → Token API 再连到服务端 JWT Signer → Signer 依赖 Marketplace 的 App Credentials。Unity 的 architecture.md 则明确要求 Avoid direct credential logic in Unity clientUnity 客户端内不得出现凭据逻辑。iOS 的 architecture.md 同样将 Server JWT Signer 独立于客户端之外。为什么要统一契约因为四端拿到的是同一个sessionName 各自唯一的userName才能在同一个 session 中互见。若某一端私自改字段语义例如把sessionName拼上前缀会导致该端用户被分到另一个会话——这就是原文Token claim 变更只打破一个平台这类故障模式的根源。关于后端鉴权本身可进一步参考 zoom-oauthVideo SDK 场景通常采用 Server-to-Serveraccount_credentials无用户参与的机器对机器鉴权签发访问令牌若涉及以用户身份授权例如移动端则应走授权码流程并为公开客户端启用 PKCE因为移动 App 无法安全保存 Client Secret。该技能还包含完整的错误码对照表4700–4741 区间如 4709 Redirect URI mismatch、4733 Code 过期等是排查后端鉴权问题时的速查入口。第 2 步保持各平台会话状态机一致原文要求四端的状态机保持一致init - join - media - leave。各平台的生命周期文档给出了几乎同构的操作序列这正是跨平台一致性的实现基础阶段Androidlifecycle-workflowiOSlifecycle-workflowmacOSlifecycle-workflowUnitylifecycle-workflow1从后端请求 Token请求 Token获取 Token从后端获取 Token2初始化 SDK 并注册核心监听器初始化并挂接 delegate初始化 SDK 与 delegate/event 桥初始化 wrapper 与事件处理器3用 sessionName/topic、显示名、Token 入会用 session 名/topic 与显示名入会以用户身份入会以 topic/session 名与显示身份入会4入会成功后才启动本地摄像头/麦克风在 join 成功回调后启动本地媒体join 确认后启动媒体通过 wrapper API 启停本地媒体5依据事件渲染远端用户以回调为唯一事实来源处理参与者与媒体处理参与者/媒体更新与视图生命周期将参与者/媒体更新应用到场景对象6退会/断开时取消监听并释放资源退出时清理 delegate 与会话资源停止媒体并释放资源退会或切场景时干净地释放资源跨端对齐的关键点有二入会成功后才能启媒体是所有平台的共同硬约束。母技能 SKILL.md 中有一条权威警告在 Web 端client.getMediaStream()只有在join()之后才有效提前调用会静默返回undefined各原生端也一致要求Start local media only after successful join。这条规则在四端必须一视同仁。渲染必须是事件驱动的。Android 文档明确要求Drive UI from SDK event streams to avoid stale participant state用 SDK 事件流驱动 UI避免参与者状态过期iOS 要求Render participant tiles from delegate-driven state onlymacOS 要求Separate render state from transport/session stateUnity 要求Convert SDK callbacks into explicit Unity state updates。也就是说UI 上谁在线、谁在讲话的显示一律来自事件/回调而不是本地缓存。可进一步参考 session-lifecycle.md该文档标题即 Join, Stream, Render, Leave它把规范顺序总结为Create client →init→join→ 获取媒体流 → 基于事件启动音视频并渲染 → 退会清理。这套顺序对所有平台通用。第 3 步版本锁定与发布前兼容性检查原文要求Version-lock each platform release and run compatibility checks before rollout。仓库中各平台的版本兼容文档提供了具体证据Androidversioning-and-compatibility.mdSDK 包zoom-video-sdk-android-2.5.0.zip内部版本v2.5.0 (37500)包含mobilertc.aar与示例模块兼容性要求App 与后端 Token 逻辑必须与同一 Video SDK 发布族对齐跨版本会有方法新增/重命名因此每个发布列车都要固定 SDK 版本升级时必须重新校验 ProGuard/R8 规则与权限。Unityversioning-and-compatibility.md包装器包unity-zoom-video-sdk-0.0.2-beta.zip内含ZoomVideoSDK.unitypackageUnity wrapper 的版本号与原生 Android/iOS/macOS 的 SDK 流相互独立实现前必须逐一核对 wrapper 参考文档中的每个 API/事件是否可用明确把 wrapper 视为可能只是原生 SDK 功能子集。这两份文档共同揭示了跨平台版本管理的核心矛盾四端并不天然处于同一版本平面。Unity wrapper0.0.2-beta与原生包族2.5.0之间存在明显版本落差wrapper 文档中的功能名可能与原生平台参考不一致。因此版本锁定不能只锁Zoom SDK 版本而是要建立一张平台 × SDK 版本 × 后端 Token 契约版本的对照矩阵每次发布前逐端跑兼容性检查。兼容性检查的落地方式可复用 token-contract-test-spec.md 中定义的全平台客户端冒烟测试用相同的sessionName模式和唯一的userName请求 Token用返回的 Token 入会确认 join 成功回调/事件启动本地媒体并验证参与者状态事件退会并验证清理回调/事件。同一套冒烟脚本跑满四端任何一端在步骤 25 中行为不一致即视为发布阻断问题。第 4 步为被重命名/废弃的 API 准备各平台回退计划原文要求 Maintain per-platform fallback plans for renamed/deprecated APIs。结合版本证据这一条的现实基础非常充分Android 文档明示Expect method additions/renames across releases各版本间会出现方法新增/重命名Unity 文档明示 wrapper 与原生之间Some docs and feature names may differ部分文档与功能名可能不一致。因此回退计划至少应包含API 别名层在客户端封装一个薄抽象层Android 的 ViewModel/Session Controller、iOS 的 Coordinator/Session Store、macOS 的 Session Coordinator、Unity 的 Session Manager把底层 SDK 调用收敛到单一边界内。四个平台的 architecture.md、ios architecture、macos architecture、unity architecture 全部强调了这个边界一旦 SDK 方法改名只需改这一层而不是全项目替换版本对照表升级前先做 API diff标记哪些方法被 rename、哪些事件被 rename、哪些能力被移除回滚策略每个发布列车保留上一个可用 SDK 版本作为回滚目标并在升级 runbook 中写明回滚触发条件例如冒烟测试步骤 3/4 失败即回滚降级预案对 Unity 这类 wrapper 滞后于原生的情况若某功能 wrapper 不支持明确是等待 wrapper 升级还是回退到原生桥接实现避免临场决策。需要提前规划的故障模式原文列出了四类必须 pre-plan 的失败模式结合仓库证据逐一展开1. Wrapper / 原生功能错位尤其是 UnityUnity 的 wrapper 包为0.0.2-beta远落后于原生2.5.0包族wrapper 可能只是原生功能子集。这意味着原生能跑的通Unity 可能跑不通。token-contract-test-spec 中的诊断项也专门给出works native, fails Unity→ 验证该版本 wrapper 是否支持相同的 join/token 预期。建议Unity 端开发前先对照 wrapper 参考文档盘一遍要用到的 API 是否存在不要直接照搬原生示例代码。2. 跨 SDK 版本的事件命名漂移各平台文档都提示事件/方法会随版本演进改名。事件名漂移的直接后果是 UI 收不到某人上/下麦某人进出会等关键回调表现为参与者面板不动或画面不渲染。建议把事件名视为契约的一部分纳入升级 runbook 的 diff 检查事件处理逻辑集中封装避免散落各处难以统一替换。3. Token claim 变更只影响单个平台同一后端契约同时服务四端但各端 SDK 对 claim 的解析细节可能不同。若某次改动调整了 claim 结构例如角色字段从roleType改为role可能出现三个平台正常、一个平台 join 失败的现象。token-contract-test-spec 的诊断条目指出join failed/auth仅出现在单平台时应对比 claim 载荷的处理方式与 SDK 版本差异。建议Token 契约变更必须四端同时回归尤其是冒烟测试第 2 步join。4. 各 OS 版本的权限/回归差异Android、iOS、macOS 每次系统大版本发布都可能改变权限模型摄像头/麦克风授权弹窗行为、后台权限策略等Unity 场景还叠加了宿主平台权限。Android 兼容文档特别要求升级时重新校验 ProGuard/R8 规则与权限。建议维护一张OS 版本 × 权限行为 × 已知回归的矩阵在 OS 新版本发布窗口期提前跑全平台权限回归。输出清单交付物定义原文给出了跨平台交付必须产出的四类工件它们应当与交付流程绑定输出物内容要点对应仓库依据共享鉴权/Token 契约规格sessionName、userName、roleType、expirationSeconds输入token、expiresAt、sessionName输出后端断言清单token-contract-test-spec.md各平台会话生命周期文档每端一份init → join → media → leave状态机文档注明事件驱动渲染规则各平台 lifecycle-workflow 文档族带回滚计划的升级 runbook版本锁定策略、API diff 检查、冒烟测试步骤、回滚触发条件versioning-and-compatibility.mdAndroid、versioning-and-compatibility.mdUnity已知不兼容矩阵平台 × SDK 版本 × 功能能力对照wrapper 子集问题OS 权限回归记录上述兼容性文档的 Contradictions or drift to watch 小节这份清单同时构成了跨平台交付的验收标准四件工件齐备、冒烟测试全端通过才算一次完成的发布。落地路径与进一步阅读在实际执行时建议按以下顺序推进用 zoom-oauth 确定后端鉴权方案S2S 或授权码 PKCE冻结 Token 契约按 token-contract-test-spec.md 实现并验证后端签名服务逐平台实现会话生命周期统一遵循 session-lifecycle.md 的规范顺序锁定各端 SDK 版本维护不兼容矩阵发布前在四端各跑一遍冒烟测试并准备好回滚方案。如需进一步深入可继续阅读平台入门Android SKILL.md、iOS SKILL.md、macOS SKILL.md、Unity SKILL.md各含 Start Here 阅读顺序与 RUNBOOK架构细节Android architecture.md、iOS architecture.md、macOS architecture.md、Unity architecture.md会话加入模式examples/session-join-pattern.md各平台技能目录下均有同构文件母技能总览与路由规则video-sdk/SKILL.md。需要提醒的是本仓库为只读参考资源所有技能文档用于指导开发与排查不涉及对仓库本身的修改。实际构建时请以 Zoom 官方最新文档为准核对版本与 API 细节因为如兼容性文档所注仓库内的版本与功能信息可能滞后于官方动态页面。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
