书接上文
之前在 跨平台渲染引擎之路：类 Figma 的无限画布 中提到了想落地无限画布场景的渲染 SDK，最近业余时间基本都在折腾类似的事情，不过在形式和顺序上有些调整，首先先看下目前还比较粗糙的项目预览。 ps：习惯玩知乎的同学可以访问 本文链接 ，平常在知乎平台上更新得多一些～
预览
项目地址：Blitz
体验地址：Blitz - A collaborative whiteboard with chat functionality
目前前端项目直接运行后，协同编辑与音视频部分连接的是我个人的服务器，配置比较低，可能会出现不稳定的情况，后续会再做一些服务自动重启之类的保障措施，也会在 server 模块提供本地运行的机制，感兴趣的可以先 Star 关注一下～
项目目标
产品向
技术向
- 覆盖前端客户端与后端服务器完整链路
- 矢量绘制、文字排版与渲染、特效、音视频等实现原理
- 集成一些流行或前沿的技术尝鲜，比如 AIGC、抠图、超分等
- 调研子技术点目前常见的技术选型，研究第三方库与自主实现/优化的方案
落地思路
最开始提到的落地思路上的调整主要是在以下几个方面上：
第一是在项目形式上，原计划只想搞几个按钮来进行操作，结果发现这太过简陋了，要做更复杂的功能和性能测试就很不方便，同时自己后续想进一步落地像文字、路径等引擎之上的元素级别的能力，因此考虑直接搭建一个类似 Canva 或 Figma 的白板应用，并逐渐迭代到可真正供用户使用的状态。
第二是在引擎开发的节奏上，上次调研后发现，在前端 Pixi.js 的性能其实已经算是 Top 级别的了，像 WASM 方向的 CanvasKit 也只能是不相上下（当然 CanvasKit 的定位其实是不太一样的），如果按照 Pixi 的设计重新用 C++ 或 Rust 实现一遍，那亲测性能是有 30% 左右的提升的，所以考虑先直接用 Pixi.js 作为第一步的引擎，后续逐步替换成 C++ 版本。
第三是会在画布之上从编辑器的角度将整个生态搭建起来，比如更多的元素、特效，以及实时协作、通信等，并且集成一些自己感兴趣的或者看到的有意思的第三方能力，跟市面上已有的产品形成差异化，比如在白板协作的同时能够进行视频聊天、视角跟随等。
因此，在落地顺序上会先搭建一个可以满足最小主流程的编辑器，并在其上逐渐补充能力和优化架构，这过程中会使用到许多优秀的第三方项目来先快速满足需求，最后再将第三方的内容逐渐替代成原生能力（如果第三方存在问题或自己的确有这个能力的话～）。
这项目不仅涉及渲染等多媒体技术，也是一个自己用来学习从前端到后端完整技术栈的项目，欢迎大家一起交流讨论，有想要的功能或者新奇的想法更可以提出来，一起共建或者我来尝试集成到项目中看看～。
编辑器
介绍一下目前编辑器已支持的能力所涉及的技术选型，以及落地过程相关知识点的整理。
无限画布
目前我是直接使用 Pixi 作为渲染引擎，因此只需要将视图中的 传递给 Pixi 的 Application 即可。不过现实情况下我们不可能创建一个无限大的 canvas，因此一般需要自定义一个 Viewport 的概念，用于模拟出无限缩放倍数以及无边界移动的效果。
社区中已经有一个 pixi-viewport 的项目支持类似效果了，但是实际使用过程中，发现其所使用的 Pixi 是之前的版本，与最新版本结合使用时会报错，另外我预先考虑考虑是将用户操作事件进行统一的拦截、分发和处理，该项目会把视口上的事件都接管过去，与我的设计思路相悖，不过 Viewport 的复杂度也不高，因此这部分目前是直接自主实现的。
代码文件：Viewport.ts
画笔
线条的绘制最开始使用的是 Paper.js ，效果和性能方式都很优异，而且也能完全满足后面形状、路径元素的实现，在交互上 Paper 也完整支持了基于锚点调整路径等操作。不过在引入 Pixi 后就需要考虑二者如何交互，目前为了先跑通最小流程先使用的 Pixi 的 Graphics ，后面在完成二者的兼容设计后大概率还是会换回来的。
代码文件：Brush.ts
交互
编辑器用户界面框架是基于 Vue3 落地的，在 UI 组件和风格上采用的是 Element-Plus 为主，这部分前端同学应该属于驾轻就熟的，目前只实现了简单的包围盒展示以及移动元素的操作。
用户认证
用户认证目前直接使用的是第三方的 Authing 身份云 ，不仅能够支持用户名、邮箱、手机等注册方式，微信、Github等第三方身份绑定也是齐全的，并且提供了配套的 UI 组件，拆箱即用，在眼下阶段可以节省很大的成本，帮助聚焦在其他核心能力的开发上。
协同编辑
协同算法目前主流的就是 OT 和 CRDT ，二者都有许多的论文和应用实践，我目前的方案是直接使用 Y.js 项目，目前还只是简单接入，后续这个模块的设计将参考 liveblocks 进行。
CRDT 在多人编辑场景的适用性方面，首先最终一致性保障上肯定是没问题的，同时 Figma、Room.sh、Pingcode WIKI 等成熟项目也都正在使用，Y.js 的作者在 Are CRDTs suitable for shared editing? 文章中也做了很多说明。从个人的使用体验来说，在工程应用方面，Y.js 相比自己基于 OT 的原理进行实现而言成本大大降低了，只需要进行数据层的 Binding 即可，至于内存方面的问题，其实远没有想象中那么严重，也有许多优化手段，综合评估来看，对于个人或小团队，以及新项目来说，Y.js 是一个相对更好的选择。
协同编辑是很大的一个课题，@doodlewind 的 探秘前端 CRDT 实时协作库 Yjs 工程实现 ， @pubuzhixing 的 多人协同编辑技术的演进 都是很好的学习文章，后面自己有更多心得收获的话再进行分享。
代码文件：WhiteBoard.ts
音视频会议
音视频会议的技术实现方案是多样的，你可以选择直接基于 WebRTC 甚至更底下的协议层完全自主实现，也可以采用成熟的流媒体服务器和配套客户端 SDK 进行接入，前者更适合系统学习，但是我觉得后者会更平滑一些，不仅能够先快速满足项目需求，也能够从成熟的解决方案中学习成功经验，避免自己重复走弯路。
媒体服务器的架构目前主要有 Mesh、MCU、SFU 三种。纯 Mesh 方案无法适应多人视频通话，也无法实现服务端的各种视频处理需求，SFU 相比于 MCU，服务器的压力更小（纯转发，无转码合流），灵活性更好，综合看比较适合目前我的诉求。
在 SFU 的架构方向下，被 Miro 收购的 MediaSoup 是综合社区活跃性、团队稳定性、配套完善度等方面较好的选择。在编辑器侧 MediaSoup 提供了 mediasoup-client ，基于该 SDK 可以实现房间连接、音视频流获取与传输、消息通信等能力。
代码文件：VideoChat.ts
服务器
HTTPS 证书
MediaSoup 的服务端访问需要通过 HTTPS 协议，另外处于安全考虑，也建议前端与后端通信统一走 HTTPS ，证书的申请我是用的 Certbot ，按官方教程走就行，非常简单，如果遇到静态页面 HTTPS 访问异常的话，可以参考 该文章 调整下 Nginx 配置看看。
协同编辑
协同编辑我采用的是 Hocuspocus 的解决方案，其除了提供客户端的 Provider 外，也提供了对应服务端的 SDK，按照官网教程直接使用即可，也比较简单。
不过因为项目使用的是 HTTS 协议，因此 WebScoket 也需要使用 WSS 协议才行，Hocuspocus 没有提供这部分的封装，需要自己通过 Express 中转一层，这部分参考 express-ws 的 https 实现即可。
代码文件：server 目录下的 whiteboard.ts
音视频会议
MediaSoup 官方提供了一套基本可以拆箱即用的 demo ，目前我是直接将其 server 模块的代码改了改直接部署在了后端上。主要的修改点就是在端口、证书等配置上，另外项目编译的时候可能会有一些 TS 的 Lint 错误，视情况修改或跳过即可。可以直接参考这两篇文章：mediasoup部署 、 mediasoup错误解决 。
代码文件：后面熟悉了该模块代码后再整理到项目里面，目前与官方无太大差异
CI/CD
这部分会等到项目的架构相对稳定，功能相对完整后再落地，特别是 CI 属于项目质量保障的重要一环，为了项目达成用户可用的目标是一定要做的。
下一步
从上述内容看其实目前我们也还不算完成了最小流程的编辑体验，比如作图记录的保存就没有做，而且已实现的能力都比较简陋，问题较多，因此下一个项目计划节点中会做的是：
- 保存/读取作图记录
- 元素缩放/旋转/删除
- 导出作图结果
- 音视频聊天的一些能力补充
- 支持图片/文字元素
- 快捷键
同时会将项目的代码框架再做一些完善，修复一些问题，届时会再结合过程中的技术点或浅或深地做一些分享。
最后
目前项目还处于最最开始的起步阶段，架构设计、代码规范等都存在暴力实现的情况，不过我基本会保持每天抽时间更新的状态（通过 Github记录也能看出来），计划今年内能够实现定好的项目目标。
在过程中会阶段性分享自己做的技术选型还有一些技术原理、优化细节等，目前我的路径大体是从第三方到自主实现，因此分享上也会是从浅到深，从大框架到具体技术这么一个节奏。之前我对前端/后端开发其实接触很少，所以许多知识都需要现学现用，比如这次的 Vue、Nginx 等等，欢迎看到的朋友有任何问题或者建议可以一起交流，甚至一起共建项目～
最后对 Blitz 感兴趣的可以点个 Star ，万分感谢～
