得物后台 --- （得物商家 --- 桌面端Electron技术实践）

电子框架，一个值得关注的前端生态，在nodejs的铬基础上得以实现。由于其快速交付的能力和高效的业务层代码复用机制，成为前端开发者的首选。该框架允许开发者直接使用前端生态，无需考虑Flutter desktop的复杂性。更重要的是，电子框架允许开发者专注于主流程和系统级功能的实现，满足业务所需。

在技术实现方面，电子框架包含两个核心组件：主进程和渲染进程。主进程主要负责管理BrowserWindow实例和应用事件，包括注册全局快捷方式、创建系统菜单和对话框以及响应自动更新事件。渲染进程则负责运行应用的用户界面，提供DOM API、Node.js API和Electron API的所有子集。这种架构使得开发者能够充分利用Electron的特性，同时保持代码的清晰和易于管理。

那么为什么电子框架会有多个渲染进程呢？这源于Chromium的多进程架构。每个标签页都单独运行在一个进程中，保证了一个标签页的崩溃不会影响到其他标签页的运行。每个进程在自己的空间中运行，由操作系统调度和管理。这种设计确保了应用的稳定性和可靠性。在开发桌面应用时，我们主要关注主进程的代码实现，而渲染进程的大部分代码可以迁移自web端项目。

电子框架的主进程包含多个功能模块，如通信模块、菜单模块、托盘模块和异常处理模块。通信模块主要负责调用Electron框架的API进行进程间的通信。菜单模块利用Electron框架的API实现快速扩展菜单功能和自定义菜单功能。托盘模块在系统级操作中被设置，用于实现系统托盘的相关功能。异常处理模块则通过结合Electron框架和Node.js的API来检测系统的异常情况并自动刷新上报。这些模块共同构成了电子框架强大的功能体系。

渲染进程的代码大部分与web端一致，只需要进行部分迁移即可。例如登录改造部分，通过将登录信息本地化，实现在登录成功后保存账号信息，下次打开应用时无需重新输入。静态资源的处理方式也有所不同，传统Web应用通过服务器访问静态资源，而现在则通过或直接获取的方式发布版本流程。这些改进使得桌面应用的开发更加便捷和高效。

电子框架以其快速交付能力、高效的代码复用机制以及强大的功能体系成为了前端开发者的优选方案。无论是主进程还是渲染进程的开发，电子框架都提供了丰富的API和工具支持，帮助开发者快速构建出稳定、可靠的桌面应用。Electron以其强大的能力，将静态资源打包到安装程序中，使得用户在安装时，项目文件同步安装到电脑中。这样的设计不仅使访问本地文件更为便捷，而且减少了请求占用资源，有效地解决了因网速问题导致的静态资源无法实时获取、页面白屏等问题。

在数据存储方面，Electron应用通过Electron-store这一第三方库轻松实现数据存储。这一实现过程相对简单直接。当web项目转变为应用渲染进程时，打包过程需要调整API请求代码，确保API前缀适应本地调试和应用环境。使用Electron将项目打包成离线应用后，通过file协议在本地读取静态资源。对于ajax请求，需要提供完整的url路径以确保打包过程的顺利进行。

在构建商家桌面端应用的过程中，我们遇到了一系列技术挑战。尽管Electron社区非常活跃，但在不同场景中遇到的问题往往难以找到对应的解决方案。这里主要围绕发布构建流程和安全性两大方面展开。

关于安全性问题，我们遇到了渲染进程XSS、用户认证信息泄漏以及本地缓存明文读取等风险。Electron实现的桌面端软件渲染层是通过chrome内核渲染的，同样存在XSS注入的风险。我们通过接入了公司统一的XSS治理方案来解决这一问题。对于用户认证信息泄漏和本地缓存明文读取问题，我们采用加密和解密算法对本地缓存信息进行处理，并积极与安全部门沟通，排查桌面端发布后的安全漏洞，确保满足安全标准。

在发布构建流程方面，应用发布涉及渲染进程和主进程。渲染进程负责给主进程提供渲染包，主进程则使用Electron-builder库来打包部署所发布的包。Electron的好处在于可以无缝集成web端的业务逻辑代码。我们将web端的构建产物同步到主进程的渲染进程目录下，这样在打包应用包时就能集成渲染进程的业务逻辑。此方案存在一些缺陷，如生产构建环境需要window环境，暂不支持远程打包。我们目前在本地window机器上打出完整包后上传到，商家通过加载的更新包来替换本地安装文件。

在应用更新方面，商家桌面应用面临更大的挑战。除了全量更新和增量更新两种常见的更新模式外，我们还面临着如何将业务需求更好地同步给商家使用的难题。在业务快速发展的背景下，我们需要在打开app时访问远程的json文件，根据版本号比较来决定是否进行更新。在网速慢的情况下，增量更新更能提供较好的用户体验。我们致力于提供稳定、高效、安全的更新方式，以满足商家的需求并提升用户的使用体验。电子应用更新之旅：从electron-updater到文件替换的

随着网络技术的发展，软件的更新已成为常态。对于商家应用而言，如何在Windows平台上实现增量更新功能尤为关键。将带您深入了解electron-updater和文件替换这两种更新方式，以及在实际应用中面临的挑战与解决方案。

一、更新概述

更新主要分为全量更新和增量更新两大类。其中，全量更新涉及整个应用的替换，而增量更新则只更新应用的部分内容。根据业务需要，还可分为强更新和弱更新。强更新要求用户必须更新才能使用系统功能，而弱更新则允许用户自主选择是否进行更新。

二、electron-updater介绍

electron-updater是Electron应用中的一种常用更新工具。它通过对比新旧版本的blockmap文件来实现增量更新。blockmap文件记录了应用中的文件变化，通过对比新旧版本的blockmap文件，可以确定哪些文件需要更新，从而实现增量更新。

三、使用blockmap文件的更新流程

1. 使用7z压缩安装包。

2. 读取安装包的header。

3. 计算每个文件的offset和end，生成相应的hash以生成blockmap。

在实际应用中，通过下载云上的blockmap文件与本地文件进行对比，确定哪些文件需要更新。然后，使用range和request发起范围请求，下载更新内容。这种方式下载量小，对应用性能影响较小。

四、文件替换方式

除了使用blockmap文件外，还有一种增量更新方式是文件替换。这种方式只更新需要更新的模块，通常只更新渲染进程的资源。由于主进程资源通常不需要更改，因此下载的资源较小，更新速度较快。这种方式在实际应用中遇到了权限问题和文件被占用的问题。为了解决这个问题，需要在更新前判断用户的安装路径是否有管理员权限，并在覆盖原文件时确保应用处于非占用状态。

五、遇到的问题及解决方案

1. 在win7或Linux系统上，Electron的硬件加速功能容易出现问题。解决方案是禁用硬件加速功能。

2. 在渲染进程使用node时可能出现“Uncaught ReferenceError: require is not defined”报错。解决方案是开启主进程的nodeIntegration。但出于安全考虑，不建议这样做。

3. 在打包过程中可能出现临时文件问题。解决方案是清理磁盘空间，删除不必要的临时文件和缓存。

4. 下载npm包时可能出现下载慢的问题。解决方案是使用yarn安装、使用镜像安装或公司镜像安装公司内部包。

作为公司的首个Electron应用，我们在开发、打包和部署过程中遇到了一系列挑战。尽管遇到了诸多困难，但Electron仍是我们业务目标和开发资源的最佳框架选择。未来，我们将继续完善开发流程，克服技术难点，努力打造更完善的商家工作台应用。

作者：Uni