淘宝直播PC客户端的hybrid探索

▐通俗易懂的翻译

▐客户端世界里的“hybrid”

▐移动端的hybrid方案

• 基于开源框架，如：weex、flutter、RN

• 原生+小程序，如支付宝小程序

• 使用WebView容器渲染+NA的方式，前端页面在webview的容器内渲染绝大部分业务交互。其开发效率高，被很多app所使用，但webview也有其缺点，web应用的体验无法达到原生应用的体验，适合做一些非核心业务。

▐  PC端如何去做？

▐面对的问题

• 技术上

1. 沿用纯Qt Native客户端开发，所有功能实现都需要使用Qt+&C++进行开发，开发周期长人力资源紧张；
2. 客户端的迭代升级依赖发布，客户端的迭代周期前期在一个月左右，目前的迭代周期保持在两周，升级对于用户的干扰性比较大；
3. 三方业务接入困难，没有C++ PC平台开发经验的同学很难介入继续开发；

• 业务上

主播的分类

1. 有专业直播团队和运营团队的主播
2. MCN机构的主播
3. 为自己店铺直播的普通直播

1. 对于普通用户（主播+运营合二为一）需要同时打开主播端（负责推流）、中控台（负责运营）进行直播，用户在直播的过程中需要来回切换不同的端完成直播过程。
2. 中控台是一个前端页面，用户可以在Mac、windows上无缝运行，但是在Chrome中各种插件也造成了很多的问题，用户舆情关于在中控台中的使用问题很大一部分都是源自于插件对于页面的干扰。

▐相关产品的架构分析

▐我们怎么做

• 为什么要选择 QT+CEF过渡？

1. CEF是基于Google Chromium项目的开源组件，有非常活跃的社区支持；
2. 保持与Chrome一样的速度的迭代更新，对于H5、CSS的兼容性很高，同版本下与Chrome的特性保持一致；
3. 有丰富的API可供定制化开发；
   离屏渲染，这个能力在后续的开发中起到了很大的作用；
   重定向请求回调处理；
   下载方法回调处理；
   资源请求拦截启用本地缓存以及可以实现HTTPS；
   JS 桥接C++方法处理；
   加载开始、完成、错误等回调处理；
   cookie植入；
   Chrome开关命令处理（Chrome预制开关参数，如是否开启OpenGL渲染、进程数量限制等）
4. 考虑到当前的人力情况，改造当前的部分功能为容器化页面，并提供通用底层能力，给后续的功能迭代提供底层支持

1. 中控台页面整合进入PC客户端、直播间内整合直播中常用工具进入工具箱，便于普通直播对于直播中的运营把控；
2. 直播间内区域1、2、3均为web容器承载的前端页面，尤其是区域1整合了工具箱，提供基础底层能力，对于目前线上新增需求与底层推流无关的完全可以不跟随主播端发版随时配置页面上线达到迭代效率提升同时没有依赖于升级过程。
3. 直播中可以返回中控台同时不断流进行其他数据的运营操作；

• Electron+node框架的迭代

• 期间碰到的问题

1. 层级1：为可以理解为我们经常看到的Chrome浏览器的主窗口、Electron应用的主窗口，HTML/CSS页面再渲染的过程中都是交付给浏览器的主窗口进行渲染展示的，所渲染的frame内部层级都是局限在此窗口页面渲染内的。
2. 层级2：为底层新创建的windows窗口，此时根据系统的窗口层级设置层级1为层级2的主窗口，同时C++底层渲染绘制再层级2的窗口上。
3. 页面mock对应层级2窗口的布局、位置，底层提供位置、宽高、隐藏、展示、销毁的接口，可以提供前端业务布局使用。
4. 弹框类提示创建新的election自窗口并按照父子关系设置为层级1的自窗口，本身窗口内部也自带order顺序，新创建的弹框也就在当前进程内部了。

1. 如上图所示，整体新框架下安装路径最外层主要为Electron框架的相关资源依赖；
2. 底层是以node包为基础提供的底层依赖，SDK基础依赖就全部被放进resources中的node依赖包中，有一些依赖的底层库是通过获取当前执行进程的路径动态加载的方式载入的，这里就无法正确获取加载路径。此时我们通过修改加载路径的方案进行了规避；
3. 通过切换当前进程工作目录兼容底层对于相对目录寻址的依赖；

▐总结

1. 完善底层能力建设，提供更多的元能力作为业务发开发支持，如纯净流录制、贴片元素移动限制等；
2. 对于渲染模块优化的探索，C++提供渲染好的画面交付前端使用canvas进行渲染；
3. 对于当前框架下业务插件的实现及扩展；
4. 开发、测试基础设置建设完善；