CN112463198B - 基于Electron的更新方法及系统 - Google Patents

Abstract

一种基于Electron的更新方法及系统包括：接收启动指令，调用主进程中的程序；检查当前程序的目录下是否存在或被导入有补丁文件；若检测到有补丁文件，调用主进程的版本管理检查当前版本号；根据补丁文件的版本号，若检测到存在更新补丁文件，判断是否需要更新容器；若无需更新容器，加载最新的补丁文件，调用渲染进程的补丁测试，执行补丁文件测试脚本；若测试通过，升级当前程序版本号，备份并替换内置程序，执行内置程序，程序更新；上述方法及系统通过版本检测找到最新版本补丁文件，通过测试校验补丁的功能完整性，校验通过后更新，执行渲染进程的内置程序，客户端无需重启，无需安装新的客户端安装包，解决用户频繁更新的问题。

Description

基于Electron的更新方法及系统

技术领域

本发明涉及计算机领域，特别涉及一种基于Electron的更新方法及系统。

背景技术

目前基于Electron开发的客户端程序，在需要更新时，常用的方式有两种：

用户手动下载新的安装包，Windows平台下对应的是 .exe 文件，MacOS平台下对应的 .dmg文件，在新的安装程序执行完成之后，新的程序会替换已有的旧版本。

或通过electron-builder构建应用程序安装包，并使用electron-builder的热更新方案，在程序启动时校验服务器端是否有新版本更新，在存在更新时，通过内部的网络模块下载服务器上新版本的安装包，在下载完成之后自动执行安装和重启，实现程序的热更新。

目前已有的基于electron开发的客户端程序热更新的方案，存在以下问题：

在无网络情况下，无法进行程序更新，这在一些较高安全等级的工作环境中无法实现程序的快速更新；

在网络延迟较高的情况下，程序更新缓慢，可能出现迟迟无法更新的问题，在跨国企业的跨国部门之间可能会出现该问题；

electron很多的更新，是更新基于前端技术开发的界面、内部数据处理逻辑等，需要更新的内容可能仅仅是几十几百kb，且不涉及框架的修改，但是目前的更新方案是对整个客户端的程序进行全量的更新，最小的安装包也有50至60Mb，在大量下载请求存在时，浪费带宽，且框架的内容会将一样的内容又重新安装一次。

发明内容

基于此，有必要提供一种可提高更新便利性的基于Electron的更新方法。

同时，提供一种可提高更新便利性的基于Electron的更新系统。

一种基于Electron的更新方法，包括：

程序启动：接收启动指令，调用主进程中的程序；

补丁检测：检查当前程序的目录下是否存在或被导入有补丁文件；

版本检测：若检测到有补丁文件，调用主进程的版本管理进行检查当前版本号；

容器更新判断：根据补丁文件的版本号，若检测到存在更新补丁文件，则判断是否需要更新容器；

测试：若无需更新容器，加载最新的补丁文件，调用渲染进程的补丁测试，执行补丁文件的测试脚本；

更新：若测试通过，启动加载，升级当前程序版本号，调用主进程的程序更新进行备份并替换内置程序，执行渲染进程的内置程序，渲染进程客户端启动，程序更新。

在优选实施例中，所述补丁检测中，若检测到当前程序的目录下不存在或没有被导入有补丁文件，则调用渲染进程的内置程序进行启动；所述版本检测中，若检测到不存在更新补丁文件，则正常启动或调用渲染进程的内置程序进行启动。

在优选实施例中，所述测试步骤中，若补丁测试未通过，则删除该补丁，调用当前目录下最新的可用补丁，启动当前版本程序；若检测到没有正常的补丁文件可以运行，则执行渲染进程的内置程序进行启动。

在优选实施例中，所述更新中，若测试通过，则将补丁文件打包进入输入数据，补丁文件跟随输入数据一起到程序中。

在优选实施例中，所述补丁检测中，若检测到补丁文件，则缓存到本地目录下；所述补丁文件包括：单独补丁文件、或补丁文件与报告数据打包文件；在输入型客户端，若补丁文件附着在目标文件中，程序启动后，若补丁检测步骤中检测到该目标文件附着有补丁，进行版本检测，并将补丁缓存进入客户端指定的文件夹，若该文件夹不存在，则在客户端启动时，自行创建。

在优选实施例中，若补丁文件中的一段脚本需要调用主进程中的程序接口、或当渲染进程中需要调用Electron框架的API接口，检测到Electron的运行环境，当前的渲染进程的程序运行在客户端的容器内，调用主进程中的渲染进程通信，注入脚本，主进程接收到脚本输入后，执行脚本，并将执行结果通过主进程的渲染进程通信返回到渲染进程，执行结果的数据传入回调函数，渲染进程执行回调函数。

在优选实施例中，所述容器更新判断中，若判断为需要更新容器，则执行新的安装包安装程序，程序重启，进入程序启动。

一种基于Electron的更新系统，包括：

程序启动模块：接收启动指令，调用主进程中的程序；

补丁检测模块：检查当前程序的目录下是否存在或被导入有补丁文件；

版本检测模块：若检测到有补丁文件，调用主进程的版本管理进行检查当前版本号；

容器更新判断模块：根据补丁文件的版本号，若检测到存在更新补丁文件，则判断是否需要更新容器；

测试模块：若无需更新容器，加载最新的补丁文件，调用渲染进程的补丁测试，执行补丁文件的测试脚本；

更新模块：若测试通过，启动加载，升级当前程序版本号，调用主进程的程序更新进行备份并替换内置程序，执行渲染进程的内置程序，渲染进程客户端启动，程序更新。

在优选实施例中，所述补丁检测模块中，若检测到当前程序的目录下不存在或没有被导入有补丁文件，则调用渲染进程的内置程序进行启动；

所述版本检测模块中，若检测到不存在更新补丁文件，则正常启动或调用渲染进程的内置程序进行启动；

所述测试模块中，若补丁测试未通过，则删除该补丁，调用当前目录下最新的可用补丁，启动当前版本程序，执行版本检测；若检测到没有正常的补丁文件可以运行，则执行渲染进程的内置程序进行启动；

所述更新模块中，若测试通过，则将补丁文件打包进入输入数据，补丁文件跟随输入数据一起到程序中。

在优选实施例中，若所述补丁文件中的一段脚本需要调用主进程中的程序接口、或当渲染进程中需要调用Electron框架的API接口，检测到Electron的运行环境，当前的渲染进程的程序运行在客户端的容器内，调用主进程中的渲染进程通信，注入脚本，主进程接收到脚本输入后，执行脚本，并将执行结果通过主进程的渲染进程通信返回到渲染进程，执行结果的数据传入回调函数，渲染进程执行回调函数。

上述基于Electron的更新方法及系统，进行补丁更新时，版本检测时，找到最新版本的补丁文件，通过测试，校验补丁的功能完整性，在校验通过后进行更新，启动加载，升级当前程序版本号，调用主进程的程序更新进行备份并替换内置程序，执行渲染进程的内置程序，渲染进程客户端启动，程序更新，客户端无需重启，也无需安装新的客户端安装包，解决用户频繁更新的问题。由于90%的改动情况都发生在渲染进程，因而通过使用本发明的基于Electron的更新方法，在输入数据型的客户端中，可以将渲染进程的程序和输入数据一起打包，进行无网络环境的更新，同时也可以解决90%的更新情况下，重复更新底层框架的苦恼。本发明的基于Electron的更新方法及系统，提供了一种前端代码与底层框架分离的客户端设计思路，可以解决在实际使用中频繁更新客户端及定制化的展示数据的需求。

附图说明

图1为本发明一实施例的基于Electron的更新方法的部分流程图；

图2为定制化图表的示意图。

具体实施方式

如图1所示，本发明一实施例的基于Electron的更新方法，包括：

步骤S101，程序启动：接收启动指令，调用主进程中的程序；

步骤S103，补丁检测：检查当前程序的目录下是否存在或被导入有补丁文件；

步骤S105，版本检测：若检测到有补丁文件，调用主进程的版本管理进行检查当前版本号；

步骤S107，容器更新判断：根据补丁文件的版本号，若检测到存在更新补丁文件，则判断是否需要更新容器；

步骤S109，测试：若无需更新容器，加载最新的补丁文件，调用渲染进程的补丁测试，执行补丁文件的测试脚本；

步骤S111，更新：若测试通过，则升级当前程序版本号，调用主进程的程序更新进行备份并替换内置程序，执行渲染进程的内置程序，渲染进程客户端启动，程序更新。

为实现离线更新及局部更新，基于Electron开发的客户端程序分为与主进程部分和渲染进程部分，主进程部分负责与Electron框架及操作系统相关的通信工作；渲染进程主要是 .html、.js、.css文件等构成的界面及响应的业务逻辑层。

Electron相当于一个浏览器的外壳，可以把网页程序嵌入到壳里面，可以运行在桌面上的一个程序，可以把网页打包成一个在桌面运行的程序，通俗来说就是软件，比如字节跳动的飞书、Atom、Skype、WhatsApp等等。可以构建跨平台桌面程序，本身支持node.js，可以使用node.js的一些模块。

主进程包括：版本管理、程序更新、启动、渲染进程通信。

在主进程中的版本管理包括：

1、校验版本功能：比对版本号，校验是否进行客户端整体升级还是进行补丁升级；

2、补丁切换功能：记录补丁更新记录，在某些版本的补丁存在问题时，可以进行不同版本的切换，避免程序卡死无法使用。

主进程中的程序更新包括：

1、网络更新：在需要进行客户端整体更新时，也即全量更新时，依然需要依赖安装包来进行全量更新，在该模块中需要具备网络和文件加载功能，可以远程下载也可以加载本地的安装包进行全量更新；

2、补丁更新：为本发明主要要解决的问题，也即频繁改动的前端界面及业务逻辑，该更新模块目的在于使用最近的补丁包来替换内置的程序，实现无需重新安装的更新操作。

主进程中的启动：在程序启动时，优先执行，为客户端程序的入口文件，该模块调用版本管理及程序更新，在程序版本校验及更新完成之后，加载对应的渲染进程的文件，使程序启动。

主进程中的渲染进程通信：主要解决的是渲染进程中的程序对Electron或底层接口的调用，该模块不做具体接口的封装，为渲染进程提供一个脚本注入的接口，在渲染进程中将需要调用底层接口的脚本注入进入该模块，即可在程序实际执行时得到调用，该模块的主要作用在于分离前端和底层业务，避免框架和前端交互的耦合，从而实现前端部分的局部更新。

在主进程启动之后，实际在界面中展示及交互的部分是渲染进程中的内容，包括客户端的界面及数据的管理等功能，也是客户端实际需要开发人员开发、用户使用的部分。

渲染进程包括：内置程序、补丁测试、补丁。

在渲染进程中的内置程序：

内置程序在程序初始安装时调用，在程序安装之后，由于不存在补丁文件，因而会将某一版本的前端程序固化进客户端之中，在没有正常的补丁文件可以运行时，执行内置程序。

渲染进程中的补丁：

补丁是和内置程序一样的代码包，可以完全的替换内置程序的功能，每一个补丁都相当于一份独立的前端版本，在各个补丁之间进行切换即可实现客户端内容的版本切换，针对补丁的调用需要配合一套补丁测试模块。

渲染进程中的补丁测试：

由于补丁是实际的程序的内容，因而在如果补丁出现问题将会导致程序内容卡死，因而对于补丁的功能需要进行校验，在补丁包中会携带一份测试脚本，每次有新的补丁更新，均会对补丁测试模块内的测试脚本进行补充升级，只有在测试脚本通过之后，才认为该补丁是可用的可以升级的。

进一步，本实施例的补丁检测中，若检测到当前程序的目录下不存在或没有被导入有补丁文件，则调用渲染进程的内置程序进行启动。

进一步，本实施例的版本检测中，若检测到不存在更新补丁文件，则正常启动或调用渲染进程的内置程序进行启动。

当存在补丁时，需要校验版本号的信息，例如当前版本号为1.7.1 存在的补丁版本号为1.7.2及（.）符号的最后一位表示补丁的升级更新，且版本号必须大于当前版本，而当补丁版本号为1.8.1时则中间一位8，表示需要进行客户端的升级，且该数字也必须大于当前版本的对应数字。当需要进行客户端的升级时，可以手动加载新的安装包或者链接网络进行全量的更新，新的程序内部的架构仍需与当前程序保持一致。

可将版本号分三段，由“.”进行分割，例如1.2.3，器最后一位3表示每一次的小问题的修复，中间位2表示有较多内容更新，第一位1表示重大更新。

在客户端启动的时候，启动程序需要先行检测 package.Json 或开发人员自行定义的版本记录文件中的程序版本号，例如读取到当前客户端的版本号为1.1.1，同时检测到客户端对应文件夹下存在1.1.13的补丁，且不存在外部输入的补丁文件，则此时使用1.1.13下的文件夹作为程序的内容进行启动，如果在程序启动时，检测到有外部导入的补丁文件如1.2.0或2.0.0（该行为可开发人员自行约定），如约定中间位置更改及进行客户端整体更新，则启动程序不再检测补丁包的版本，直接进行客户端的整体升级。当前客户端下文件夹下对应的每一个文件夹的名字即某一版本程序内容。

本实施例的补丁的新旧有版本号，例如1.1.12 比 1.1.11新， 1.2.0 比 1.1.12新。依次类推，版本号的优先级从左到右依次递减。本实施例的内置程序是一份默认的补丁包，在程序启动，创建程序目录时会默认创建，在没有新的补丁包时调用。

当作为补丁更新时，客户端无需重启，也无需安装新的客户端安装包，主进程的程序更新会检索补丁文件，找到最新版本的补丁文件，之后执行内置的补丁测试，校验补丁程序的功能完整性，在校验通过后，修改升级程序的当前版本号，备份并替换内置程序，并执行内置程序的内容，程序获得更新。

进一步，若补丁测试未通过，则删除该补丁，调用当前目录下最新的可用补丁，启动当前版本程序，执行版本检测。

若检测到没有正常的补丁文件可以运行，则执行渲染进程的内置程序进行启动。

若测试通过，则将补丁文件打包进入输入数据，补丁文件跟随输入数据一起到程序中。

进一步，本实施例的补丁检测中，若检测到补丁文件，则缓存到本地目录下。

补丁文件包括：单独补丁文件、或补丁文件与报告数据打包文件。

补丁文件：基于Electron开发的跨平台客户端程序实际如同浏览器打开不同的网页一样，可以将补丁程序理解成不同的网页，在客户端没有重大更新时，无需切换浏览器，通过切换不同的网页即可实现浏览器内容的切换。

本申请的补丁和浏览器中的页面类似，是一个打包并压缩后的zip包，其中包含了一个webapp运行所需要的全部代码，包括图片、字体等资源文件、js脚本、css样式表、html页面。在输入输出型的客户端程序中，补丁包可以跟随输入数据一起导入到程序中，在程序启动时读取导入的数据，检测到其中的补丁包之后，便可缓存到本地文件目录下，进行后续的更新操作。

在输入型客户端，若补丁文件附着在目标文件中，程序启动后，若补丁检测步骤中检测到该目标文件附着有补丁，进行版本检测，并将补丁缓存进入客户端指定的文件夹，若该文件夹不存在，则在客户端启动时，自行创建。

在优选实施例中，若补丁文件中的一段脚本需要调用主进程中的程序接口、或当渲染进程中需要调用Electron框架的API（Application Programming Interface，应用程序接口）接口，检测到Electron的运行环境，当前的渲染进程的程序运行在客户端的容器内，调用主进程中的渲染进程通信，注入脚本，主进程接收到脚本输入后，执行脚本，并将执行结果通过主进程的渲染进程通信返回到渲染进程，执行结果的数据传入回调函数，渲染进程执行回调函数。

进一步，本实施例的容器更新判断中，若判断为需要更新容器，则执行新的安装包安装程序，程序重启，进入程序启动。

客户端开发人员在开发客户端时需要在客户端启动时检查某一目标文件夹是否存在，该文件路径可由开发人员自行定义，如在Windows平台下 C:\Users\UserName\.testclient ，当该文件夹不存在时，客户端程序需在启动时创建该文件夹。

在输入型客户端中，用户需要打开某一文件，补丁可附着在该目标文件中，当启动程序检测到该文件附着有补丁时，校验补丁，并把补丁缓存进入客户端指定的文件夹下；若不存在此文件夹，在客户端启动时，需要自行创建。为避免程序卡死，针对每一个版本的程序，均需开发人员运行并完善对应的测试脚本，待功能测试通过或客户端内的功能校验脚本测试通过之后，方可进行启动加载，否则会继续使用当前版本的程序内容。

本实施例中，所有的补丁包内的程序均运行在渲染进程内，程序的启动顺序从主进程开始，执行到渲染进程客户端启动完毕，例如某一补丁文件中的一段脚本需要调用主进程中的某些程序接口，但是直接调用在打包渲染进程的文件时会产生错误，打包无法正常进行，因为渲染进程缺少主进程的执行环境，主进程的渲染进程通信起到了主进程和渲染进程通信的桥梁。

在渲染进程开发也就是实际的程序开发中，会执行一次if语句判断，当检测到electron的运行环境，则表示当前渲染进程的程序运行在客户端容器内，因而可以调用主进程中的渲染进程通信，注入脚本，主进程接收到脚本输入后，执行脚本，并将执行结果通过渲染进程返回到渲染进程，在无需调用主进程的接口时，就无需使用渲染进程通信，渲染进程通信的调用在实际渲染进程中，当用户的交互或实际业务逻辑出发后会执行调用。

比如在程序启动时，会打开一个窗口，窗口加载的是index.html文件，对应的样式及脚本文件为index.css和index.js ，具体文件名按实际开发情况可自由定义，这些文件对应于渲染进程中的程序代码，而主进程中的底层代码位于electron框架之中，因而在单独打包渲染进程的代码时，无法找到electron框架中对应的接口就会报错，但是增加渲染进程通信模块后通过脚本注入加回调的方式可以巧妙的避开这个打包时的报错，但是在渲染进程中有时需要调用electron框架的api接口，此时，通过检测electron运行环境，将脚本通过渲染进程的通信模块注入主进程，就间接的实现了渲染进程调用主进程接口。

本实施例的补丁文件、index.html文件、index.css文件、index.js文件，每个文件夹的大小在2~3M不等，体积很小，相比于整体的electron 50~60M，文件体积要小很多，实际的渲染进程对应于前端的部分，electron则对应底层框架，大部分的改动仅仅涉及前端渲染进程的修改，而无需频繁的更新electron框架。

主进程和渲染进程的解耦通过主进程的渲染进程通信来实现的，渲染进程通信不开展具体的业务逻辑，只对渲染进程暴露调用接口，例如一个简单的run（func，callback）函数，该函数第一个参数接受一个可执行函数作为参数，该函数对应于渲染进程的业务逻辑，回调也是渲染进程的回调函数，渲染进程会在主进程执行完脚本只有将结果数据传入回调函数并执行，完美地将主进程中的api接口的调用和实际的业务逻辑实现分离，也就是，主进程只负责提供运行环境，执行输入、输出脚本，不做具体业务逻辑的开发。

渲染进程中的补丁，渲染进程如果在功能测试中无法通过，则该补丁会被删除，程序启动会调用当前目录下最新的可用补丁。

当客户端输入数据为压缩的格式时，通过文件压缩，可以将补丁文件压缩到输入数据之中，通过解压缩，将补丁文件与输入数据实现分离。例如：使用zip（或其他某种压缩方式）压缩某一文件夹，压缩后得到了XXX.zip文件，当该文件下包含补丁文件时，就会在解压缩后获取到对应的补丁文件夹。为了防止数据被恶意修改，可以通过修改文件后缀，针对压缩包进行数据加密等方式进行混淆，在实际使用时，进行无感知热更新。

本实施例所述的容器即客户端程序，也就是electron的底层框架，当输入的文件中带有补丁版本，且版本号“.”分割的第一段和第二段有更新时，则可以认为需要针对框架或客户端或容器进行升级。

利用electron开发的游戏客户端中，实际的交互部分的代码都在index.html、index.js之中，其中有需要调用框架层接口进行性能运算的场景会使用渲染进程通信模块解决底层接口的调用，其他的所有逻辑均可在渲染进程的代码中实现。

本实施例的补丁是一个具体的文件夹，里面包含有html页面、js脚本、css样式，及图片、声音、字体等资源文件；在无需改动框架时，只需要在启动时使用更新后的html、js、css及资源文件，即可实现程序的更新。

当需要改动底层框架，例如新增第三方依赖库等操作时，会进程整体的更新。

如图2所示，本实施例中，某一报告阅读工具，需要根据不同的数据定制化的绘制图表，因而绘制的部分逻辑代码无法固化进入程序内部，而报告的数据内容仅仅数MB，全量的更新客户端程序不利于数据的存储于传递，因而通过该补丁的方案，在需要定制化图表的报告内部，增加补丁，无需升级整体客户端程序，即可在已有的客户端中，进行问题的修复及交互及可视化数据的更新。

在一个报告阅读的客户端程序之中，当用户打开一份报告进行阅览，当其需要某些部分的图表展示成散点图，另外一些展示成柱状图，但是目前客户端内的程序又无法满足这种定制化的需求时，可以将一份补丁文件和报告数据一起进行打包，在客户端打开这份报告时，检测到了对应的补丁程序，这些补丁程序中有对当前数据的一些定制化的图表展示，因而就无需通过客户端升级的方式，实现了数据的自定义化的更新。

同样，当用户使报告阅读程序阅读报告出现错误时，由于某些公司内部防火墙、及断网使用的情况，无法进行客户端的更新，或由于批量部署导致的无法及时更新的情况，此时通过报告携带补丁的方式可以及时的阶段当前出现的问题，在后续的大版本的客户端整体更新中，从根本上解决该问题。

使用基础的electron更新的方式，需要连接网络，下载最新的electron程序包，大小在 50~60mb左右，其中底层框架的改动较小，90%的改动情况都发生在渲染进程，因而通过使用该方案，在输入数据型的客户端中，可以将渲染进程的程序和输入数据一起打包，进行无网络环境的更新，同时也可以解决90%的更新情况下，重复更新底层框架的苦恼。

本实施例中，针对基于Electron开发的输入输出型的跨平台客户端程序，该方案可以将程序补丁打包进入输入数据，在离线情况下也可以实现客户端程序的更新，且全过程无需重启，无需下载安装包，较electron-builder的方式更为敏捷。

在基于Electron开发的游戏客户端中，由于底层依赖过多会导致安装包过大，每次更新耗时，因而不利于游戏得bug修复及更新、使用改补丁的方案可以将游戏部分逻辑代码分离，通过更新该部分逻辑代码，在一定程度上解决频繁用户频繁更新的问题。

本发明一实施例的基于Electron的更新系统，包括：

程序启动模块：接收启动指令，调用主进程中的程序；

补丁检测模块：检查当前程序的目录下是否存在或被导入有补丁文件；

版本检测模块：若检测到有补丁文件，调用主进程的版本管理进行检查当前版本号；

容器更新判断模块：根据补丁文件的版本号，若检测到存在更新补丁文件，则判断是否需要更新容器；

测试模块：若无需更新容器，加载最新的补丁文件，调用渲染进程的补丁测试，执行补丁文件的测试脚本；

更新模块：若测试通过，启动加载，升级当前程序版本号，调用主进程的程序更新进行备份并替换内置程序，执行渲染进程的内置程序，渲染进程客户端启动，程序更新。

进一步，本实施例的补丁检测模块中，若检测到当前程序的目录下不存在或没有被导入有补丁文件，则调用渲染进程的内置程序进行启动。

进一步，本实施例的版本检测模块中，若检测到不存在更新补丁文件，则正常启动或调用渲染进程的内置程序进行启动；

进一步，本实施例的测试模块中，若补丁测试未通过，则删除该补丁，调用当前目录下最新的可用补丁，启动当前版本程序，执行版本检测；若检测到没有正常的补丁文件可以运行，则执行渲染进程的内置程序进行启动；

进一步，本实施例的更新模块中，若测试通过，则将补丁文件打包进入输入数据，补丁文件跟随输入数据一起到程序中。

进一步，本实施例的补丁检测模块中，若检测到补丁文件，则缓存到本地目录下。

进一步，本实施例的补丁文件包括：单独补丁文件、或补丁文件与报告数据打包文件。

进一步，在输入型客户端，若补丁文件附着在目标文件中，程序启动后，若补丁检测步骤中检测到该目标文件附着有补丁，进行版本检测，并将补丁缓存进入客户端指定的文件夹，若该文件夹不存在，则在客户端启动时，自行创建。

进一步，本实施例的容器更新判断模块中，若判断为需要更新容器，则执行新的安装包安装程序，程序重启，进入程序启动。

进一步，若补丁文件中的一段脚本需要调用主进程中的程序接口、或当渲染进程中需要调用Electron框架的API（Application Programming Interface，应用程序接口）接口，检测到Electron的运行环境，当前的渲染进程的程序运行在客户端的容器内，调用主进程中的渲染进程通信，注入脚本，主进程接收到脚本输入后，执行脚本，并将执行结果通过主进程的渲染进程通信返回到渲染进程，执行结果的数据传入回调函数，渲染进程执行回调函数。

本发明的基于Electron的更新方法及系统，可进行离线更新，其程序架构提供了一种前端代码与底层框架分离的客户端设计思路，可以解决在实际使用中频繁更新客户端及定制化的展示数据的需求。

以上述依据本申请的理想实施例为启示，通过上述的说明内容，相关工作人员完全可以在不偏离本项申请技术思想的范围内，进行多样的变更以及修改。本项申请的技术性范围并不局限于说明书上的内容，必须要根据权利要求范围来确定其技术性范围。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

Claims (9)

1.一种基于Electron的更新方法，其特征在于，包括：

程序启动：接收启动指令，调用主进程中的程序；

补丁检测：检查当前程序的目录下是否存在或被导入有补丁文件；

版本检测：若检测到有补丁文件，调用主进程的版本管理进行检查当前版本号；

容器更新判断：根据补丁文件的版本号，若检测到存在更新补丁文件，则判断是否需要更新容器；

测试：若无需更新容器，加载最新的补丁文件，调用渲染进程的补丁测试，执行补丁文件的测试脚本；

更新：若测试通过，启动加载，升级当前程序版本号，调用主进程的程序更新进行备份并替换内置程序，执行渲染进程的内置程序，渲染进程客户端启动，程序更新；

若补丁文件中的一段脚本需要调用主进程中的程序接口、或当渲染进程中需要调用Electron框架的API接口，检测到Electron的运行环境，当前的渲染进程的程序运行在客户端的容器内，调用主进程中的渲染进程通信，注入脚本，主进程接收到脚本输入后，执行脚本，并将执行结果通过主进程的渲染进程通信返回到渲染进程，执行结果的数据传入回调函数，渲染进程执行回调函数。

2.根据权利要求1所述的基于Electron的更新方法，其特征在于，所述补丁检测中，若检测到当前程序的目录下不存在或没有被导入有补丁文件，则调用渲染进程的内置程序进行启动；所述版本检测中，若检测到不存在更新补丁文件，则正常启动或调用渲染进程的内置程序进行启动。

3.根据权利要求1所述的基于Electron的更新方法，其特征在于，所述测试步骤中，若补丁测试未通过，则删除该补丁，调用当前目录下最新的可用补丁，启动当前版本程序；若检测到没有正常的补丁文件可以运行，则执行渲染进程的内置程序进行启动。

4.根据权利要求1所述的基于Electron的更新方法，其特征在于， 所述更新中，若测试通过，则将补丁文件打包进入输入数据，补丁文件跟随输入数据一起到程序中。

5.根据权利要求1至4任意一项所述的基于Electron的更新方法，其特征在于，所述补丁检测中，若检测到补丁文件，则缓存到本地目录下；所述补丁文件包括：单独补丁文件、或补丁文件与报告数据打包文件；在输入型客户端，若补丁文件附着在目标文件中，程序启动后，若补丁检测步骤中检测到该目标文件附着有补丁，进行版本检测，并将补丁缓存进入客户端指定的文件夹，若该文件夹不存在，则在客户端启动时，自行创建。

6.根据权利要求1至4任意一项所述的基于Electron的更新方法，其特征在于，所述容器更新判断中，若判断为需要更新容器，则执行新的安装包安装程序，程序重启，进入程序启动。

7.一种基于Electron的更新系统，其特征在于，包括：

程序启动模块：接收启动指令，调用主进程中的程序；

补丁检测模块：检查当前程序的目录下是否存在或被导入有补丁文件；

版本检测模块：若检测到有补丁文件，调用主进程的版本管理进行检查当前版本号；

容器更新判断模块：根据补丁文件的版本号，若检测到存在更新补丁文件，则判断是否需要更新容器；

测试模块：若无需更新容器，加载最新的补丁文件，调用渲染进程的补丁测试，执行补丁文件的测试脚本；

更新模块：若测试通过，启动加载，升级当前程序版本号，调用主进程的程序更新进行备份并替换内置程序，执行渲染进程的内置程序，渲染进程客户端启动，程序更新；

若补丁文件中的一段脚本需要调用主进程中的程序接口、或当渲染进程中需要调用Electron框架的API接口，检测到Electron的运行环境，当前的渲染进程的程序运行在客户端的容器内，调用主进程中的渲染进程通信，注入脚本，主进程接收到脚本输入后，执行脚本，并将执行结果通过主进程的渲染进程通信返回到渲染进程，执行结果的数据传入回调函数，渲染进程执行回调函数。

8.根据权利要求7所述的基于Electron的更新系统，其特征在于， 所述补丁检测模块中，若检测到当前程序的目录下不存在或没有被导入有补丁文件，则调用渲染进程的内置程序进行启动；

所述版本检测模块中，若检测到不存在更新补丁文件，则正常启动或调用渲染进程的内置程序进行启动；

所述测试模块中，若补丁测试未通过，则删除该补丁，调用当前目录下最新的可用补丁，启动当前版本程序，执行版本检测；若检测到没有正常的补丁文件可以运行，则执行渲染进程的内置程序进行启动；

所述更新模块中，若测试通过，则将补丁文件打包进入输入数据，补丁文件跟随输入数据一起到程序中。

9.根据权利要求7或8所述的基于Electron的更新系统，其特征在于，若所述补丁文件中的一段脚本需要调用主进程中的程序接口、或当渲染进程中需要调用Electron框架的API接口，检测到Electron的运行环境，当前的渲染进程的程序运行在客户端的容器内，调用主进程中的渲染进程通信，注入脚本，主进程接收到脚本输入后，执行脚本，并将执行结果通过主进程的渲染进程通信返回到渲染进程，执行结果的数据传入回调函数，渲染进程执行回调函数。

Images