关于桌面应用:语雀桌面端技术架构实践

作者：易芝林 (维骏)

语雀桌面端作为语雀为用户提供的生产力工具，上线两年多来始终放弃高频的迭代和衰弱的业务增长。本次次要介绍咱们在做桌面端时的一些技术架构思考和实际，同时也将分享咱们积淀的一些通用桌面利用解决方案和教训。

文章会分为四局部，首先会简略介绍语雀桌面端，而后介绍以后语雀桌面端的利用架构以及关键点，之后介绍架构中的几个架构重点项，最初在进行总结。

语雀桌面端介绍

语雀是孵化自蚂蚁体验技术部的一款笔记与文档知识库工具。咱们在两年前，针对语雀用户特点，以及后续倒退策略，旨在为创作者提供更好的创作体验，推出语雀桌面客户端。

相较于现有浏览器提供的产品服务而言，咱们提供的桌面端产品次要思考以下几点：

• 无烦扰 ：给用户一个沉迷式的创作体验，而不像浏览器有其余窗口、tab 进行烦扰，以及用完即走的用户心智。
• 零碎级常驻 ：关上速度更快，能够一键启动或者利用各类快捷工具唤起。
• 集成更多操作系统能力 ：晋升创作效率的多窗口、零碎菜单和快捷键、对文件读写、与系统软件集成等。
• 离线 ：冀望能在离线或弱网的状况下，无障碍的进行创作。

桌面端架构概览

研发测次要分为右边三层，最底层是语雀的基础设施，依赖了语雀后盾提供或封装的大量云服务，以及底层依赖的平安能力和存储模块。

两头一层是比拟偏利用架构的一些能力封装，下面是代码层面用的的辅助能力，还有主过程的模块，而后有给利用提供的一些治理能力和一些跟 UI 相干的功能模块，最上层就是基于底层架构搭建的业务利用。包含桌面端利用比拟外围的几个模块，以及一些由子利用形式承接的业务模块（前面也会具体介绍子利用这个概念）

同时最右侧也有很多辅助研发的依赖能力，来实现语雀桌面端的公布、品质和稳定性治理。

架构概览 – 关键点

相比拟一般 web 利用来说，咱们感觉桌面端有以下几个能力比拟重要：包含平安、软件降级、以及桌面端通用的的根底能力：

架构概览 – 平安

平安是一个生产力工具软件的生命线，特地是语雀作为一款常识管理工具，对于平安是十分看重。

根底平安

• 下载安装包时，须要有平安管理机制，防止下载过程中被歹意替换；
• 降级到最新的 Electron 版本（语雀目前紧跟官网大版本，同时也会参考微软的头部利用 (vscode)，防止有没思考到的场景；
• 同时用户离线下载到本地的文件，包含图片，附件等，也须要通过加密。

启动平安

• 杀毒软件 ：启动平安次要是在启动软件时的一些平安问题，例如二进制模块是否有加签名，防止被杀毒软件查杀导致无奈启动，也能够分割平安厂商加白名单，同时还能晋升启动速度。
• 禁止调试 ：因为软件代码都会下载到客户端，能够禁止软件在客户端浏览器进行调试。
• 数据库秘钥治理 ：本地数据库文件须要保障即便被歹意拿到，也要保障无奈查看到外面的内容。咱们通过生成内存安全级别的计划，确保其余非以后电脑的语雀软件即便拿到数据库文件后也无奈关上。

利用平安

• 渲染容器设置白名单来管制不被引入歹意页面；
• 渲染过程敞开 Node 性能以及开启隔离模式，防止渲染过程权限过高；
• Electron 自身是 web 开发模式，所以 web 中遇到的平安问题，在 Electron 同样会遇到，能够对立解决。

架构概览 – 软件降级

客户端软件相比拟于 web 来说，还有一个十分大的区别就是有性能更新时，有一个降级过程，不像 web 间接刷新页面即可。语雀桌面端作为迭代迅速的产品，对于降级这块也是踩了不少坑。

语雀桌面端由两大部分组成：包含 Electron 和 Node.js 等根底模块的软件包 + 以及本人的业务代码。

Mac OS：Mac 下的降级流程比较简单，软件下载实现后，利用 hdiutil 来模仿用户手动装置流程，用户重启即可实现装置。

Windows：Windows 下因为环境特殊性，须要下载安装包后，通过主过程主动关上装置界面，疏导用户进行手动一步一步装置。

其实这种计划很好的满足的咱们晚期的性能迭代，然而随着用户量上涨，也遇到了很多问题。

比方：

• 每次降级带宽耗费微小：对于每次装置每个 UV 都有近 100M 的下载，每次推送版本时，都会遇到 OSS 流量告警，这背地都对应着老本；
• 装置体验差：Windows 下因为每次降级简直都是一次新的装置流程，所以体验也是比拟差的，常常收到用户吐槽。

所以咱们就调研了一种增量更新的计划，一个 Electron 程序包含 Electron 外围包以及业务代码，其实每次变更的仅仅是业务代码，所以实践上每次更新只须要增量更新业务代码即可。

Mac 下增量间接下载到增量代码后，替换掉即可。

Windows 下比较复杂，咱们次要遇到两个问题：

1. 文件占用问题 ：因为 Windows 零碎个性，如果某个文件在应用，会无奈删除。所以说如果要替换，必定关闭程序，而后进行删除操作后再启动。所以咱们写了一个 .exe 可执行文件来做关闭程序、更新文件、启动语雀。
2. UAB 权限管制 ：文件写入另一个问题是 C 盘文件个别是须要受权才能够操作的。咱们软件启动没方法拿到这么高权限。不过还在 Windows 7 及当前新增了一个 PowerShell 性能，通过这个性能执行，能疏导用户受权，拿到更高级的权限。

当然过程中还碰到不少细节问题，比方替换过程中门路中英文问题、用户自定义过环境变量地位问题等等

架构概览 – 根底能力积淀

另外咱们在做软件的过程中，也积淀了一些与业务无耦合的组件：

• 多窗口治理：当给用户提供提供更不便的多窗口编辑能力时，如何去治理这些窗口关上，敞开，性能监控等；
• Webview：不同编辑器以及子利用都是通过 Webview 来承载的，须要有一个通用的模块来保护零碎中用到的各个 webview 的生命周期等；
• 离线在线：电脑离线和在线状态获取，尽管浏览器有提供这个状态的获取和事件监听，然而 Windows 下不太精确。咱们封装了一个比拟通用的模块。

桌面端架构重点

从架构上来说，相较于用了多酷炫的技术，更重要的是研发交付效率高不高，性能怎么样，稳定性高不高。咱们认为以下三点是架构好坏评判的重要规范。

架构重点 – 交付效率

从桌面端性能上来说，包含编辑器在内，有超过 60% 的功能模块都是与 web 统一的，所以开始是用到了同构的计划。

同构过程中的一些教训：

• 通用代码移动到 Common 目录：语雀代码仓库是 monorepo 模式，如果没有很清晰的目录划分，很容易造成跨端兼容问题。有了这个约定当前，业务研发同学就会留神到这个会用在挪动端或者桌面端
• 通过 webpack alias 适配多端：这个形式比拟常见，比方各端有不同的网络申请库，在组件层面应用 adapter/request。webpack 在构建时，adapter 映射到不同的端实现。
• 定义多端代码研发标准：梳理出不同端的一些差别点，在研发时防止采坑。

交付效率 (同构问题)

尽管同构模式能够解决咱们过后遇到的一些问题，然而随着业务规模和性能减少，陆续有些问题裸露进去：

• 迁徙到 Common 目录，各种依赖问题 ：很多性能在桌面端之前曾经上线，有些简单组件迁徙到 Common 下自身也须要消耗不少工夫。
• 短少动态化能力，迭代滞后（web 与桌面端性能不统一）：组件在 web 公布上线后，桌面端须要公布才反对，所以常常会碰到 web 和桌面端不统一的吐槽。
• 容易呈现多端兼容问题（环境依赖等）：尽管咱们定义了一些标准，但很难彻底避免出现环境依赖问题。
• 短少独立沙箱，容易影响主利用 (内存泄露、款式)：web 可能用完即走，能够刷新等，不太容易遇到问题，然而桌面端因为是常驻的，如果有些内存泄露或者款式净化问题，就间接影响到整体可用性。

交付效率（子利用）

思考到上述起因，咱们将代码复用架构升级成子利用模式，利用桌面端容器，嵌套一个 html 在线或者离线页面。

简略来说，子利用模式能够了解为支付宝九宫格进去的各个小程序模块。

• 疾速迭代 ：提供独立的公布迭代能力，所以无需追随桌面端整体公布。而且间接由业务同学跟进整个交付流程，无需桌面端同学参加，晋升交付效率。
• 具备端相干能力 ：每个子利用默认就能应用桌面端提供的 JSBridge 能力，人造能做到跟桌面端模块一样的能力。
• 独立沙箱 ：独立于桌面端主窗口，利用桌面端的容器来实现渲染，所以能齐全做到过程级别隔离，相互之间的内存开销高深莫测，更好的做到管控，保障整体利用稳定性。
• 加载初始化 ：除了上述的一些劣势，也会到来一些问题，比方加载速度慢等，咱们通过 webview 预热、缓存等形式，肯定水平上解决了这个问题。

架构重点 – 性能

性能是一个桌面端软件必须要面对的问题，是须要继续在不同角度进行优化的

次要包含这几个方面：

• 启动速度优化 ：启动速度是用户第一映像，咱们次要是将主过程代码进行缓存，尽早展现 loading 防止白屏，主窗口和渲染过程的局部工作同时执行，达到并发成果；
• 主过程优化 ：主过程和渲染过程执行是同步的，如果主过程做了太多任务，会导致用户应用起来卡顿，甚至闪退。所以尽量减少主过程所做的事件；
• Web 优化 ：同时，之前很多在 web 上做的优化，一样能够拿过去应用。例如懒加载，合并模块等（组合多个模块自身也有开销）；
• Webview 优化 ：例如预热 webview、并进行一些性能管控措施，防止失控。

性能（持续性工作）

性能优化其实不是说做完哪些事件就能够彻底解决，而是一个长期过程。可能咱们后续新增性能时，代码里有某一个内存泄露问题，就很容易导致性能拉胯下来。所以咱们也建设了一些持续性的机制：

次要包含：

• 日常观测 ：在开发模式下，建设观测性能指标能力，做到成竹在胸；
• 自动化工作 ：日常也会有自动化工作，模仿实在用户长时间应用，及时发现内存泄露等问题；
• 性能大盘 ：对于线上性能水位，能有一个全盘的感知能力，灰度公布过程中可重点关注。

架构重点 – 稳定性

相比拟于 web 而言，桌面端的稳定性也是要求更高的。

从研发流程上看，咱们次要有两块事件：

1. 单测、集成测试 ：利用代码测试来辅助整体稳定性
2. UIA：通过模仿用户行为的 UIA 自动化测试回归来晋升稳定性，及时发现异常。

注：UIA 是语雀工程师自研的自动化计划，详见：Macaca MacOS

另外建设了稳定性大盘和实时告警，来感知到线上性能状况。

为了保障每次公布的稳定性，缩小回归老本，咱们利用每周一次预览版公布的麻利研发模式，来合成大版本公布带来的集成危险。

总结

• 针对以后的业务体量和团队教训，抉择适合的技术架构；

  • 当初必定有比 Electron 更新的桌面端架构，比方 flutter、tauri 等，要综合看比方团队积攒以及稳定性，是否有成熟的商业化产品等；
• 性能和稳定性优化是持续性的过程，先建设度量和感知；

• 交付效率和交付品质最容易被忽视，但却是架构计划的重要考量；

  • 架构好坏的评判规范肯定是由业务成果决定的，交付效率和交付品质是掂量业务成果的伎俩之一。