关于前端:融云-IM-在-Electron-平台上的设计实践

6次阅读

共计 3914 个字符,预计需要花费 10 分钟才能阅读完成。

Electron 凭借其绝对更低的研发老本投入、弱小的跨平台反对、领有基数宏大的 Javascript 开发者受众等劣势,在 PC 端桌面应用软件研发畛域异军突起。

本文旨在分享融云 IM 在 Electron 平台上的桌面端 SDK 产品开发实践经验。关注【 融云寰球互联网通信云 】理解更多

融云 IM 的 Electron 桌面解决方案指标

1. 提供与传统桌面通信软件相匹配的能力反对

相较于 B/S 架构的 Web 页面利用,融云冀望可能在 Electron 环境下向开发者提供更为丰盛的本地化能力,以及比 Websocket(or Comet)更高效的双工通信通道。

借助这些在浏览器环境下不便实现的技术能力,来整体进步用户对于桌面端产品的应用体验,将 Electron 作为一个 C/S 架构软件运行平台的后劲施展到最大。

2. Browser 与 Electron 不同运行时代码高度复用

因为 Electron 与规范 Web 利用领有简直雷同的技术生态,因而少数产品会要求前端代码工程兼顾 Browser 与 Electron,也就是说,一套代码既要打包为传统桌面端利用,又可公布为浏览器中运行的 Web 利用。

基于此,作为 PaaS 能力提供的融云 IM SDK 须要在两种不同的 Runtime 下做到差别最小化,防止开发者编写冗余的平台兼容代码。

3. 便于开发者构建多窗口、多过程简单桌面端利用

Electron 通过对 IPC 能力的封装为桌面端利用开发提供了较欠缺的跨过程通信计划,借助此能力,开发者构建的桌面端利用也逐步趋于简单。

比拟典型的如桌面端通信产品,通常用一个独立窗口做根底的 IM 聊天业务,一个窗口做历史聊天记录查问业务;当有音视频会议业务场景时,还须要再开一个窗口做会议业务;甚至有开发者提出了与每个聊天对象都放弃一个独立聊天窗口的需要(产品状态如 QQ)。

在这种场景下,长连贯状态维持、音讯同步变得异样简单,起因在于:

若每个过程窗口都维持独立长连贯,难免会呈现某一过程连贯与其余过程连贯状态不同步;且开发者需在各过程同时保护连贯状态,复杂度较高;同时还会造成服务的并发能力降落。

若仅有繁多主窗口进行连贯维持,其余窗口通过 IPC 能力将主窗口作为连贯代理,则须要在主过程、各渲染过程中保护简单的跨过程通信业务代码,从而推高我的项目整体的复杂度。

目前的 Electron 开发者绝大多数来自于 Web 开发者,既有编程思维是建设在浏览器页面内单过程单线程的利用模型下构建起来的,对于解决此类多过程模型的产品开发不足相干的教训积攒。

为升高相似场景的业务实现复杂度,融云须要在 PaaS 能力层面上解决多过程连贯共享、多过程音讯同步问题,让开发者在既有编程思维模式下将每个业务实现的更为顺畅。

4. 需同步适配融云 IM SDK 多个版本

融云的既有 Web IM SDK 存在多个不同版本,各版本都有不同数量的客户积攒,且各版本 API 接口设计迥异,跨版本升级老本较高。

思考到应用不同版本的客户将来将业务向 Electron 迁徙的可能性,咱们冀望通过架构设计的改良来防止既有客户做过多的集成代码批改,在确保既有客户不因版本升级而散失的前提下升高 Web 研发团队本身的多版本 SDK 保护老本。

指标落地推动计划

1. 剥离各版本的独特业务与对外差异性 API 定义

融云的 IM SDK 各版本别离为不同的代码仓库独立保护,互无干系,这导致所有的性能(包含行将开发的 Electron 桌面解决方案)都可能要在各个版本仓库上独自实现,不仅开发成本高,还会导致实现品质无奈保障、或代码实现不对立,同时也推高了产研后续流程的测试、上线等环节的老本。


(IM SDK 不同版本独立保护)

基于指标 4 的要求,在既有现状下持续开发,意味着须要在两个版本的根底上做不同实现,既不合乎程序员的代码审美,也影响团队整体的研发效率。

为更好地达成指标 4,团队决定优先通过重构将既有业务分层,各个版本所必须的业务代码形象下沉为 IM Engine 包,并为各个版本 IM SDK 别离实现不同的 APILayer 以便与既有线上版本接口对齐,这样既能够升高团队的研发老本,也能够满足既有线上客户后续的降级需要。


(重构代码,业务分层)

实现分层后,对于 IM SDK 有依赖的其余产品如 RTC SDK,也都能够解脱对 IM SDK 接口的依赖而间接调用 Engine 层接口,业务层在拓展 RTC 业务时,也就无需再思考 IM SDK 的版本问题。


(保障拓展性)

做分层的另一个思考还为了达成指标 2,将与业务层的交互限度在 API 层,在 Engine 中解决 Electron 与 Browser 两种运行时下的代码差别,业务层只需关怀 IM SDK 的接口调用而无需关怀底层差别,确保业务层在两种运行时下只须要保护极少甚至无需保护兼容代码,便于业务层更专一于业务开发。

2. Electron 与 Browser 平台下 IM SDK 的辨别

在将 Engine 与业务层隔离后,须要思考 Engine 在不同的运行时下的要害能力差异,并根据能力差异落实 Engine 的底层设计。

在 Browser 与 Electron 平台下,从连贯治理、到音讯收发等实现形式迥异,团队须要对 Engine 包持续分层,通过 AEngine 抽象类来定义 IM Engine 的能力接口,并形象 APIContext 类用来治理 AEngine 的能力调用。

思考到纯 Web 利用构建尺寸问题,Electron 的能力实现代码不应被打包到规范 Web 页面内,因而还须要将 Electron 平台下的实现代码独自抽离进去作为一个独立包(ElectronSolution),作为可选模块由开发者抉择装置应用。


(代码抽离为可选模块)

如上图所示,CppEngine 在 ElectronSolution 包中定义,其须要由开发者在 Electron 利用创立 BrowserWindow 实例时通过 webPreferences.preload 配置属性向渲染过程窗口预挂载。

APIContext 在初始化 AEngine 实例时,优先检测 CppEngine 是否已定义。当发现有 CppEngine 定义时,则初始化 CppEngine 提供更丰盛的本地化能力,否则初始化 JSEngine。

const engine: AEngine = typeof CppEngine !== 'undefined'
  ? new CppEngine()
  : new JSEngine()

3. 解决多过程音讯同步、多过程连贯共享问题

ElectronSolution 包截止目前的设计中,所有代码都运行在渲染过程内,这意味着每个过程彼此独立,都在保护独立的过程状态,无奈满足指标 3 中多过程状态同步、连贯共享的需要。

为了解决该问题,须要将 CppProto.node 模块放到主过程,在主过程中实现连贯治理、音讯收发等能力,多个渲染过程通过 IPC 通信共享主过程状态。


(多个渲染过程通过 IPC 通信共享主过程状态)

为了达成指标 3 的要求,ElectronSolution 须要拆分为两个子包:Main 与 Renderer

Main 包运行在主过程内,负责维持 CppProto.node 模块的调用,实现底层连贯治理、音讯治理等性能,同时通过 Electron 提供的 ipcMain 与各渲染过程维持通信

Renderer 包中定义 CppEngine 类,继承自 Engine 包内的 AEngine 抽象类,仍然通过 webPreferences.preload 用来作为主过程的代理,通过 ipcRenderer 与主过程维持通信


(Main 与 Renderer 两个子包)

批改实现后,ElectronSolution 包的整体构造根本确定,以下列出 ElectronSolution 包要害目录构造供参考。

node_modules/@rongcloud/electron-solution
├── index.js
├── main
│   ├── addon
│   │   ├── binding
│   │   │   └── electron-v{electron-version}-{platform}-{arch}.node
│   │   └── index.js
│   ├── dist
│   │   └── index.js
│   ├── index.js
│   └── package.json
└── renderer
│   ├── dist
│   │   └── index.js
│   ├── index.js
│   └── package.json
└── package.json

基于上述架构变动,当业务层须要在多个渲染过程中实现 IM 能力时,仅须要关注在各个过程中的 IM SDK 接口调用,由 ElectronSolution 解决多过程之间的状态同步问题。

当开发者冀望由既有 Web 业务向 Electron 平台迁徙时,开发者也无需批改既有的 Web 业务代码,仅须要增量编写主过程代码相干性能实现,将 ElectronSolution 装置并集成到 Electron 桌面端利用中即可。

整体构造展现

融云 Electron 平台的将来布局

融云作为平安、牢靠的寰球互联网通信云服务商,除了在 IM 相干业务的继续深耕,后续还会在该平台下发力 RTC 场景能力。

目前 Electron 平台下由 Chromium 原始提供的 WebRTC 能力对于开发桌面级音视频应用软件来说绝对单薄,融云将摸索如何借助 node.js 的拓展能力,提供更为底层的 WebRTC 能力拓展如音效、音质、视频特效等。

除了更深刻的能力拓展,融云还将提供一个全方面的桌面级利用开发框架,为开发者提供更为全面的 Electron 能力封装,规范化开发者的代码组织、脚本构建过程,以便于开发者在解决简单的大型桌面利用时,更专一于业务自身。

同时,融云始终保持对技术的持续性投入,一直夯实底层技术,强化基石力量。对于 Electron 之外的前端技术一直摸索,同时保持自我迭代,保持技术卓越,以期为宽广开发者带来更多实用且易用的产品。

正文完
 0