爱奇艺多桌面端统一：Mac客户端架构升级实践
原创 PC客户端团队 2025-11-13 09:01 北京
基于LWA方案对Mac客户端进行架构升级，降本增效的实践成果
01#
背景
爱奇艺一直致力于提供卓越的桌面视频客户端使用体验。爱奇艺的桌面端主要包括：
电脑网页端
Windows客户端
UWP客户端
Mac客户端
爱奇艺的桌面客户端矩阵演进历程
2022年之前
这4个端由不同的产品和研发团队设计开发，用户界面和使用体验各不相同，开发、维护、运营成本很高。
电脑网页端↓
Windows客户端↓
UWP客户端↓
UWP（Universal Windows Platform）是微软公司创建并在Windows10中首次引入的一个同性质应用程序架构平台，是创建适用于Windows的客户端应用程序的众多方法之一。此软件平台的目的是帮助发展Metro样式的应用程序，便于软件可以在Windows10和Windows10 Mobile上执行且无需重新编写。
Mac客户端↓
2022年-2023年
PC客户端团队和微软合作，提出基于微软Edge Webview 2和Web技术栈的全新桌面应用开发框架——LWA（Local Web App），并用其重构了Windows客户端，逐步完成功能全覆盖上线。
Windows客户端↓
2024年
得益于LWA框架基于标准Web技术栈开发用户界面和业务逻辑的特点，其前端业务代码用较低的成本复用到了电脑网页端，提供了一致的用户体验的同时，也实现了降本增效。
电脑网页端↓
2025年
PC客户端团队再接再厉，将LWA方案继续复用到了MacOS操作系统。
本文下面重点分享基于LWA方案对Mac客户端进行架构升级的实践。
LWA桌面应用开发框架介绍
背景
在2022年以前，爱奇艺Windows客户端使用自研的RND（React Native for Desktop）框架来开发界面和交互。RND框架的技术原理和Facebook当年的RN（React Native）框架很像。RND和RN一样使用JS和React框架来开发前端界面和业务逻辑，支持热更新，开发快捷。但是，RND没有RN框架那么完善的开源社区资源，例如各种UI组件库和原生模块等，需要RND框架团队自己实现，成本较高。不幸的是，后来组织架构调整，RND框架团队解散，由业务团队继续维护。但是，在后续迭代中遇到一些底层问题，如通信效率等，难以推进优化和解决，大大限制了产品需求落地。
因此，PC客户端团队积极寻求替代方案。
方案对比
PC客户端团队基于和微软公司良好的合作关系，提出基于Microsoft Edge WebView2的桌面前端应用开发框架LWA（Local Web App）。该方案得到了微软公司的大力支持，由微软与爱奇艺团队合作开发。
在Windows操作系统平台上，LWA方案使用WebView2作为运行时容器和渲染引擎，相较于当时其他桌面前端开发方案具有一定优势：
WebView2技术优势：
官方支持：微软出品，Win10(部分)/ Win11自带，持续更新，文档齐全。
社区支持：因其主体部分采用Web标准而受行业支持。
稳定可靠：微软的专业团队会持续迭代升级webview2，提升其性能和稳定性。
复用技术：标准Web开发。
LWA方案原理
LWA方案通过内嵌网页的方式，以标准Web的形式支持业务逻辑实现和界面展现，并通过宿主来进行能力扩展。
宿主程序负责应用程序生命周期和内嵌网页的管理，其可以是现行模式，或是基于WPF或Windows App SDK。
内嵌网页通过WebView容器（Windows平台采用微软的Edge WebView2，其他系统平台可以更换）加载，并通过JS Bridge 和 Post Message的方式进行通信。
内嵌页面资源可通过离线包管理，以实现加速，因此支持热更新。
LWA框架架构图↓
LWA方案优势
Web前端技术栈：采用了标准的web技术栈，享有业界最新主流的界面与交互能力，更为完善的特效支持，某些产品和交互需求的实现更为便捷
可扩展：业务代码和原生的能力交互层隔离，可扩展为多个平台运行，易于迁移（比如迁移到Mac端）
自打包和升级体系：可以享有基于微软框架的LWA技术能力的加持，如热更新
LWA方案上线效果
LWA方案落地上线时，我们做了几个典型场景的性能评估，优化效果明显。
重构随刻热点页面（RND → LWA）
冷启动至主界面呈现耗时减少38.8%。
重构收银台页面（内嵌 Web 页 → LWA）
点击至主界面呈现耗时减少74.7%，流失率降低至少 1.69pp。
重构登录页（C++ → LWA）
点击至主界面呈现耗时各有千秋，快捷登录1.10s → 0.70s，扫码0.34s → 0.80s。
重构主窗口（RND → LWA）
页面滚动、页面切换、过渡效果，实现性能体验效果提升。
Mac客户端概况
在架构升级之前，Mac客户端采用苹果公司的Mac Catalyst方案，将iPad端的代码复用适配到Mac端。因此，之前的Mac客户端的用户界面跟老版iPad客户端很像，而跟Windows客户端有着显著差异。然而，后来iPad客户端界面大改版，考虑到大屏响应式设计成本，采用了iPad端和Mac端界面分道扬镳的策略，代码差异越来越大，复用性越来越低，Mac端更新频率下降。
痛点：
在各种尺寸显示器上的使用体验不够理想
新功能需要兼顾iPadOS和MacOS两个系统上的体验导致产品、设计和研发成本较高
大屏体验不佳↓
iPad端界面大改版后跟Mac端分道扬镳↓
02#
目标
03#
方案选择
针对MacOS，出于稳定性和实现成本的考量，Web容器优先选择使用系统自带的WKWebView。而关于LWA原生支持能力，我们最终决定采用基于AppKit框架重写原生层，并移植Windows播放器业务逻辑的方案。尽管原生层复用MacCatalyst方案代码成本最低，但因经过MacCatalyst技术转换的WKWebView不支持MSE特性而被迫放弃；而直接移植iOS播放器又面临基础库适配工作量大、后续维护门槛高的难题。相比之下，将Windows端由C++开发的播放器核心逻辑移植到MacOS，不仅能复用已有的JS Bridge接口、节省开发投入，更有利于由PC团队统一维护和未来跨平台的业务逻辑共享，同时推动了播放器底层架构的优化与解耦，为多端协同奠定了长远基础。
04#
开发实践
LWA原生容器开发
MacOS上的LWA原生容器基于WKWebView构建，作为连接原生层与JS层的核心框架，主要负责通信桥梁与基础功能，主要界面与交互逻辑则由Web端的JS代码处理。其核心功能包括：
虚拟域名与资源加载：支持虚拟域名、本地资源匹配加载及跨域访问。
请求处理：通过Runtime Hook拦截HTTPS请求，并分别转发至本地文件系统或原生网络库。
JS Bridge通信：实现Command接收与Event应答的双向通信机制。
导航栏交互：将自定义系统按钮、窗口拖拽及点击事件传递至JS层处理。
窗口状态管理：同步全屏/小窗状态，管理多窗口，并更新原生播放器位置。
JS业务代码适配
JS代码由于运行在Web容器中，跟操作系统隔离，天然具备跨平台运行能力，很容易复用和移植到不同的操作系统平台。不过，由于MacOS的WKWebView使用的浏览器内核是webkit，而Windows上我们使用的WebView2的浏览器内核是Chromium，仍然存在一些差异。在实践的过程中，我们确实发现了一些MacOS上的兼容性问题，需要对代码做少量修改和适配。我们将遇到的问题和解决办法进行了整理，以便持续迭代桌面客户端JS业务代码时，能避免引入兼容性问题，从而减少多平台重复的测试验证成本。
C++代码移植和适配
Windows客户端的C++代码中大部分业务逻辑其实是平台无关的，可以移植到MacOS端，主要是将跟平台耦合的那部分代码进行适配。另外，由于Windows和MacOS在操作系统特性和应用开发生态上存在较大差异，需要针对这些差异点做针对性的开发和适配。
播放器移植适配
播放器是客户端的核心功能，内部业务逻辑非常复杂，依赖库众多，迁移适配的工作量也很大。我们认真梳理了不同平台播放器的层次结构，找出相同点和差异点，设计合理的架构，最大化代码复用，节省开发成本。
基础库和核心库：复用iOS代码，适配MacOS
播放器功能：复用Windows平台C++代码，适配MacOS
JS Bridge：针对MacOS，使用Objective-C语言对标Windows平台重新实现
播放器组件和播放窗口功能：复用Windows客户端上的LWA JS代码，适配MacOS的工作量极少
形态差异
老Mac客户端采用Mac Catalyst技术将iPad App适配到MacOS，因此其播放器使用iOS标准原生技术栈进行开发。
新Mac客户端由于复用Windows客户端的LWA方案，因此也和Windows客户端一样，通过在原生播放器上叠加一个背景透明的Web容器来实现，原生播放器只负责渲染播放画面，播放器的各种UI控件和业务逻辑均在Web容器内用JS语言来实现。不同之处在于原生播放器和Web容器：
原生播放器：视频播放能力依托于操作系统的底层能力，在MacOS上无法直接复用Windows上的播放内核，需要独立封装，不过可以基于爱奇艺iOS播放内核对MacOS进行适配，复用大部分iOS播放内核的能力。
Web容器：不同的操作系统各自有其自带的Web容器能力，虽然理论上也可以使用跨平台浏览器内核，实现复用，比如Chromium，但是相比于使用系统自带的Web容器，实现成本高，并且显著增加安装包大小。因此，目前我们针对Windows平台使用微软的Edge WebView2，针对MacOS平台使用系统自带的WKWebView。
可复用的部分
Windows客户端播放器中可复用的代码主要涵盖：
通信层：JS Bridge原生部分（大部分）
核心层：基础播放功能（协议解析、播控、状态机、容错等）与本地播放
辅助层：设备云控、播放特性、码流播控、设置与配置
AI辅助编程提效
将C++代码适配到MacOS平台
在复用C++代码到MacOS平台的过程中，需要将大量之前依赖Windows平台API的C++业务代码适配MacOS平台。比如，在Windows平台，一般使用.ini配置文件，读写逻辑用的是Windows系统API：GetPrivateProfileInt、WritePrivateProfileString这种形式的API，在MacOS上没法用，于是，我们直接用Curosr IDE重写了一个ini配置文件工具类。AI非常擅长开发这类工具类，效果非常好，提效明显。
将C++代码转成Objective-C代码
在复用C++代码到MacOS平台的过程中，还需要将很多C++代码转换成MacOS主流的Objective-C代码，以便和其他复用自iOS端的基础库配合使用。AI也非常擅长这个场景，效果也非常好，提效明显。
C++代码→ObjC代码
AI辅助开发JS版MacOS收银台
由于在LWA架构下，用户界面主要由JS实现，而MacOS上的收银台和Windows上的很不一样，因为必须使用苹果应用商店要求的苹果内付费机制，因此需要全新开发。
我们借助Cursor IDE，使用提示词+MCP（自研的设计稿转前端代码的MCP）的方式，实现React组件开发提效，时间节省30%。
05#
成果和收益
正式上线
9月10日，全新升级的爱奇艺Mac客户端16.9.0上线App Store。
桌面端体验统一
全新Mac客户端上线，解决了之前Mac端在大屏上体验不佳的问题，并能跟随Windows客户端一起快速迭代，不断带给用户新的功能和更优的体验。
降本增效
为了控制测试范围，全新Mac客户端16.9.0版本复用的JS业务代码的版本对齐的是Windows客户端13.7.5版本，而9月10日上线时，Windows客户端的最新版本是13.9.0，相差了3个大版本。后来，Mac客户端16.9.5版本需要对齐到Windows客户端13.9.0版本，也就是在Mac客户端的一个版本迭代周期中带入Windows客户端3个版本的内容。看似任务很艰巨，但是得益于LWA方案的优势，经过对3个版本共91个需求的梳理，仅5个需求需要迁移适配，且适配工作量很小，而其余86个需求的代码可以完全复用。需求复用度达到95%，极大节省了开发成本。
06#
未来规划
持续优化新Mac客户端的使用体验
MacOS有很多独特的系统特性是Windows系统没有的，比如MacOS上的Handoff接力功能，需要持续迭代支持。另外，性能也和Windows客户端一样需要持续监控和优化。
推动桌面客户端架构升级以适应多平台
LWA方案中的JS代码天然适应多操作系统平台，因为有W3C标准作为保障，每个操作系统平台都有支持W3C标准的Web容器。在将LWA方案复用到MacOS平台时，我们发现C++代码其实也是天然适应多操作系统平台的，因为这些操作系统本身基本上都是基于C和C++语言开发的。但是，C++代码一开始并未考虑到适应多操作系统的需求，因此直接耦合依赖了很多Windows系统的API和能力，要更容易地复用尽可能多的C++代码，需要升级代码架构，对代码进行合理的拆分和解耦，最终实现理想的最大化代码复用的效果。
将LWA方案复用到UWP客户端
从文章开头的截图可以看出，爱奇艺UWP客户端与Windows客户端在UI设计风格上显著不同。由于在同一操作系统平台上维护两个产品的设计、开发和运营需要较高的成本，这使得更新迭代的速度有所放缓。基于将LWA方案成功移植到Mac客户端的经验，爱奇艺PC客户端团队计划继续推进多桌面端的统一之旅，尝试将LWA方案应用于UWP客户端，为用户提供一致且优秀的使用体验。
也许你还想看