WO2022120640A1 - 基于electron的更新方法及系统 - Google Patents

基于electron的更新方法及系统 Download PDF

Info

Publication number
WO2022120640A1
WO2022120640A1 PCT/CN2020/134926 CN2020134926W WO2022120640A1 WO 2022120640 A1 WO2022120640 A1 WO 2022120640A1 CN 2020134926 W CN2020134926 W CN 2020134926W WO 2022120640 A1 WO2022120640 A1 WO 2022120640A1
Authority
WO
WIPO (PCT)
Prior art keywords
program
patch
update
rendering process
patch file
Prior art date
Application number
PCT/CN2020/134926
Other languages
English (en)
French (fr)
Inventor
韩非
马健
温书豪
赖力鹏
Original Assignee
深圳智药科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳智药科技有限公司 filed Critical 深圳智药科技有限公司
Priority to PCT/CN2020/134926 priority Critical patent/WO2022120640A1/zh
Publication of WO2022120640A1 publication Critical patent/WO2022120640A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/656—Updates while running

Definitions

  • the invention relates to the field of computers, in particular to an update method and system based on Electron.
  • the user manually downloads the new installation package, which corresponds to the .exe file under the Windows platform and the .dmg file under the MacOS platform. After the new installation program is executed, the new program will replace the existing old version.
  • Electron-based update system that can improve update convenience is provided.
  • An Electron-based update method that includes:
  • Program startup receive the startup command and call the program in the main process
  • Patch detection Check whether a patch file exists or is imported in the directory of the current program
  • Version detection If a patch file is detected, call the version management of the main process to check the current version number;
  • Container update judgment According to the version number of the patch file, if it is detected that there is an update patch file, it is judged whether the container needs to be updated;
  • Test If there is no need to update the container, load the latest patch file, call the patch test of the rendering process, and execute the test script of the patch file;
  • the built-in program of the rendering process is called to start it; in the version detection, if no patch file is detected If there is an update patch file, start it normally or call the built-in program of the rendering process to start it.
  • the testing step if the patch test fails, delete the patch, call the latest available patch in the current directory, and start the current version program; if it is detected that no normal patch file can be run, execute the The built-in program of the rendering process is started.
  • the patch file is packaged into the input data, and the patch file is added to the program along with the input data.
  • a patch file in the patch detection, if a patch file is detected, it will be cached in a local directory; the patch file includes: a separate patch file, or a patch file and a report data package file; on the input client, If the patch file is attached to the target file, after the program starts, if the patch detection step detects that the target file is attached with a patch, the version detection is performed, and the patch cache is stored in the folder designated by the client. If the folder does not exist, When the client starts, it will be created by itself.
  • a script in the patch file needs to call the program interface in the main process, or when the rendering process needs to call the API interface of the Electron framework, the operating environment of Electron is detected, and the program of the current rendering process runs in In the container of the client, call the rendering process communication in the main process, inject the script, after the main process receives the script input, execute the script, and return the execution result to the rendering process through the rendering process communication of the main process, and the data of the execution result is passed in Callback function, the rendering process executes the callback function.
  • the container update determination if it is determined that the container needs to be updated, a new installation package installation program is executed, the program is restarted, and the program starts.
  • An Electron-based update system that includes:
  • Program startup module Receive startup instructions and call programs in the main process
  • Patch detection module Check whether a patch file exists or is imported in the directory of the current program
  • Version detection module If a patch file is detected, call the version management of the main process to check the current version number;
  • Container update judgment module According to the version number of the patch file, if it is detected that there is an update patch file, it is judged whether the container needs to be updated;
  • Test module If there is no need to update the container, load the latest patch file, call the patch test of the rendering process, and execute the test script of the patch file;
  • Update module If the test is passed, start loading, upgrade the current program version number, call the program update of the main process to backup and replace the built-in program, execute the built-in program of the rendering process, start the rendering process client, and update the program.
  • the patch detection module if it is detected that the directory of the current program does not exist or that a patch file is not imported, the built-in program of the rendering process is called to start;
  • the version detection module if it is detected that there is no update patch file, it is normally started or the built-in program of the rendering process is called to start it;
  • test module if the patch test fails, the patch is deleted, the latest available patch in the current directory is called, the current version program is started, and version detection is performed; if it is detected that no normal patch file can be run, the rendering process is performed. to start the built-in program;
  • the update module if the test is passed, the patch file is packaged into the input data, and the patch file is added to the program along with the input data.
  • a script in the patch file needs to call the program interface in the main process, or when the rendering process needs to call the API interface of the Electron framework, the operating environment of Electron is detected, and the program of the current rendering process Running in the container of the client, calling the rendering process communication in the main process, injecting the script, after the main process receives the script input, executes the script, and returns the execution result to the rendering process through the rendering process communication of the main process, the data of the execution result
  • the callback function is passed in, and the rendering process executes the callback function.
  • the above-mentioned update method and system based on Electron when performing patch update and version detection, find the patch file of the latest version, pass the test, verify the functional integrity of the patch, update after the verification is passed, start loading, and upgrade the current program Version number, call the program update of the main process to backup and replace the built-in program, execute the built-in program of the rendering process, start the rendering process client, and update the program. Updated question. Since 90% of the changes occur in the rendering process, by using the Electron-based update method of the present invention, in the input data type client, the program of the rendering process and the input data can be packaged together to perform a network-free environment. The update can also solve the trouble of repeatedly updating the underlying framework in 90% of the update cases.
  • the Electron-based update method and system of the present invention provides a client design idea in which the front-end code is separated from the underlying framework, and can meet the requirements of frequent client update and customized display data in actual use.
  • FIG. 1 is a partial flowchart of an Electron-based update method according to an embodiment of the present invention
  • Figure 2 is a schematic diagram of a customized chart.
  • an Electron-based update method includes:
  • Step S101 program startup: receiving a startup instruction, calling the program in the main process;
  • Step S103 patch detection: check whether a patch file exists or is imported in the directory of the current program
  • Step S105 version detection: if a patch file is detected, call the version management of the main process to check the current version number;
  • Step S107 container update judgment: according to the version number of the patch file, if it is detected that there is an update patch file, it is judged whether the container needs to be updated;
  • Step S109 test: if the container does not need to be updated, load the latest patch file, call the patch test of the rendering process, and execute the test script of the patch file;
  • Step S111 update: if the test is passed, update the current program version number, call the program update of the main process to backup and replace the built-in program, execute the built-in program of the rendering process, start the rendering process client, and update the program.
  • the client program developed based on Electron is divided into the main process part and the rendering process part.
  • the main process part is responsible for the communication work related to the Electron framework and the operating system; the rendering process is mainly .html, .js , .css files, etc. and the business logic layer of the response.
  • Electron is equivalent to a browser shell. It can embed a web page program into the shell, a program that can run on the desktop, and a web page can be packaged into a program that runs on the desktop. Generally speaking, it is software, such as ByteDance. Feishu, Atom, Skype, WhatsApp, etc. You can build cross-platform desktop programs, natively support node.js, and use some modules of node.js.
  • the main process includes: version management, program update, startup, and rendering process communication.
  • Version management in the main process includes:
  • Verification version function Compare the version number and verify whether to perform an overall client upgrade or a patch upgrade
  • Patch switching function record patch update records. When there is a problem with some versions of the patch, you can switch between different versions to avoid the program being stuck and unable to be used.
  • Program updates in the main process include:
  • Network update When an overall update of the client is required, that is, a full update, it is still necessary to rely on the installation package to perform a full update.
  • This module needs to have network and file loading functions, which can be downloaded remotely or loaded locally. The installation package is fully updated;
  • Patch update This is the main problem to be solved by the present invention, namely the frequently changed front-end interface and business logic.
  • the purpose of this update module is to replace the built-in program with the latest patch package, so as to realize the update operation without reinstallation.
  • Rendering process communication in the main process It mainly solves the call of the program in the rendering process to Electron or the underlying interface.
  • This module does not encapsulate the specific interface, but provides a script injection interface for the rendering process, which will be required in the rendering process.
  • the script that calls the underlying interface is injected into this module, and it can be called when the program is actually executed.
  • the main function of this module is to separate the front-end and the underlying business, avoid the coupling between the framework and the front-end interaction, so as to realize the partial update of the front-end part.
  • the part that is actually displayed and interacted in the interface is the content in the rendering process, including the client interface and data management functions, and it is also the part that the client actually needs to be developed by developers and used by users.
  • the rendering process includes: built-in programs, patch tests, patches.
  • the built-in program is called when the program is initially installed. After the program is installed, since there is no patch file, a certain version of the front-end program will be solidified into the client, and the built-in program will be executed when there is no normal patch file to run.
  • the patch is the same code package as the built-in program, which can completely replace the functions of the built-in program.
  • Each patch is equivalent to an independent front-end version. Switching between the patches can realize the version switching of the client content.
  • the invocation of the patch needs to cooperate with a set of patch testing modules.
  • the patch Since the patch is the content of the actual program, if there is a problem with the patch, the program content will be stuck. Therefore, the function of the patch needs to be verified.
  • a test script will be carried in the patch package. Every time there is a new patch Updates will supplement and upgrade the test scripts in the patch test module. Only after the test scripts pass, the patch is considered to be available and can be upgraded.
  • the built-in program of the rendering process is invoked to start.
  • the information of the version number needs to be verified. For example, if the current version number is 1.7.1, the existing patch version number is 1.7.2 and the last digit of the (.) symbol indicates the upgrade of the patch, and the version number must be greater than The current version, and when the patch version number is 1.8.1, there is an 8 in the middle, indicating that the client needs to be upgraded, and the number must also be greater than the corresponding number of the current version.
  • the version number can be divided into three sections, divided by ".”, such as 1.2.3, the last digit of 3 indicates the repair of each minor problem, the middle 2 indicates that there are more content updates, and the first 1 indicates major renew.
  • the startup program needs to first detect the program version number in package.Json or the version record file defined by the developer. For example, the version number of the current client is read as 1.1.1, and the corresponding client is detected. There is a patch of 1.1.13 in the folder, and there is no externally imported patch file, then use the folder under 1.1.13 as the content of the program to start. If the program is started, it is detected that there is an externally imported patch. If the file is 1.2.0 or 2.0.0 (the behavior can be agreed by the developer), if the agreed intermediate position is changed and the client is updated as a whole, the startup program will no longer detect the version of the patch package, and directly upgrade the client as a whole.
  • the name of each folder corresponding to the folder under the current client is the content of a certain version of the program.
  • the old and new version numbers of the patches in this embodiment for example, 1.1.12 is newer than 1.1.11, and 1.2.0 is newer than 1.1.12. And so on, the priority of the version number decreases from left to right.
  • the built-in program in this embodiment is a default patch package, which is created by default when the program is started and the program directory is created, and is called when there is no new patch package.
  • the client When used as a patch update, the client does not need to be restarted or install a new client installation package.
  • the program update of the main process will retrieve the patch file, find the latest version of the patch file, and then execute the built-in patch test to verify the correctness of the patch. Functional integrity, after the verification is passed, modify the current version number of the upgrade program, back up and replace the built-in program, and execute the content of the built-in program, and the program is updated.
  • the patch test fails, the patch is deleted, the latest available patch in the current directory is called, the current version program is started, and version detection is performed.
  • the patch file is packaged into the input data, and the patch file is added to the program along with the input data.
  • Patch files include: individual patch files, or patch files and report data package files.
  • Patch file The cross-platform client program developed based on Electron is actually like opening different web pages in a browser.
  • the patch program can be understood as different web pages.
  • Browser content By switching different web pages Browser content can be switched.
  • the patch of this application is similar to the page in the browser. It is a packaged and compressed zip package, which contains all the code required for a webapp to run, including pictures, fonts and other resource files, js scripts, css style sheets, html page.
  • the patch package can be imported into the program along with the input data, the imported data is read when the program starts, and after the patch package is detected, it can be cached in the local file directory for Subsequent update operations.
  • the patch file is attached to the target file, after the program starts, if the patch detection step detects that the target file is attached with a patch, the version detection is performed, and the patch is cached in the folder specified by the client. If the folder does not exist, it will be created by itself when the client starts.
  • a script in the patch file needs to call the program interface in the main process, or when the rendering process needs to call the API (Application Programming Interface, application program interface) interface of the Electron framework
  • the operating environment of Electron is detected.
  • the program of the current rendering process runs in the container of the client, calls the rendering process communication in the main process, injects the script, after the main process receives the script input, executes the script, and returns the execution result through the rendering process communication of the main process to The rendering process, the data of the execution result is passed into the callback function, and the rendering process executes the callback function.
  • the container update determination in this embodiment if it is determined that the container needs to be updated, a new installation package installation program is executed, the program is restarted, and the program starts.
  • the client developer needs to check whether a target folder exists when the client starts up.
  • the file path can be defined by the developer, such as C: ⁇ Users ⁇ UserName ⁇ .testclient under the Windows platform.
  • the client program needs to create the folder at startup.
  • the startup program In the input client, the user needs to open a file, and the patch can be attached to the target file.
  • the startup program detects that there is a patch attached to the file, it will verify the patch and cache the patch into the folder specified by the client. If this folder does not exist, you need to create it when the client starts.
  • the developer In order to prevent the program from being stuck, for each version of the program, the developer needs to run and complete the corresponding test script. After the function test is passed or the function verification script test in the client is passed, the startup and loading can be started, otherwise it will be Continue to use the current version of the program content.
  • all the programs in the patch package run in the rendering process, and the startup sequence of the programs starts from the main process and is executed until the client of the rendering process is started.
  • a script in a patch file needs to call the main process.
  • rendering process development that is, actual program development
  • an if statement judgment is executed.
  • the operating environment of electron it means that the program of the current rendering process is running in the client container, so the rendering process in the main process can be called.
  • Communication inject script, after the main process receives the script input, execute the script, and return the execution result to the rendering process through the rendering process.
  • the call will be executed when the user interacts or the actual business logic starts.
  • the index.html file is loaded in the window
  • the corresponding style and script files are index.css and index.js.
  • the specific file names can be freely defined according to the actual development situation. These files correspond to The program code in the rendering process, and the underlying code in the main process is located in the electron framework. Therefore, when the code of the rendering process is packaged separately, if the corresponding interface in the electron framework cannot be found, an error will be reported, but the communication module of the rendering process is added.
  • the method of script injection and callback can cleverly avoid this error when packaging, but sometimes it is necessary to call the api interface of the electron framework in the rendering process. process, it indirectly implements the rendering process calling the main process interface.
  • index.html file, index.css file, and index.js file of this embodiment the size of each folder ranges from 2 to 3M, and the volume is very small. The volume is much smaller.
  • the actual rendering process corresponds to the front-end part, and the electron corresponds to the underlying framework. Most of the changes only involve the modification of the front-end rendering process without frequent updating of the electron framework.
  • the decoupling of the main process and the rendering process is achieved through the rendering process communication of the main process.
  • the rendering process communication does not carry out specific business logic, but only exposes the calling interface to the rendering process, such as a simple run(func, callback) function, which The first parameter of the function accepts an executable function as a parameter, which corresponds to the business logic of the rendering process.
  • the callback is also the callback function of the rendering process.
  • the rendering process will only pass the result data to the callback function after the main process executes the script and execute it. , which perfectly separates the invocation of the api interface in the main process from the actual business logic implementation, that is, the main process is only responsible for providing a running environment, executing input and output scripts, and not developing specific business logic.
  • the patch file can be compressed into the input data through file compression, and the patch file can be separated from the input data through decompression. For example: use zip (or some other compression method) to compress a certain folder, and get the XXX.zip file after compression. When the file contains patch files, the corresponding patch folder will be obtained after decompression. In order to prevent the data from being maliciously modified, you can confuse by modifying the file suffix, encrypting data for the compressed package, etc., and performing a non-perceptual hot update in actual use.
  • the container described in this embodiment is the client program, that is, the underlying framework of electron.
  • the input file contains a patch version, and the first and second paragraphs separated by the version number ".” are updated, you can Think that an upgrade is required for the framework or client or container.
  • the code of the actual interactive part is in index.html and index.js.
  • the rendering process communication module will be used to solve the call of the underlying interface. , all other logic can be implemented in the code of the rendering process.
  • the patch in this embodiment is a specific folder, which contains html pages, js scripts, css styles, and resource files such as pictures, sounds, and fonts; when the framework does not need to be changed, it is only necessary to use the updated html at startup , js, css and resource files to update the program.
  • a certain report reading tool needs to draw a chart customized according to different data, so part of the drawn logic code cannot be solidified into the program, and the data content of the report is only a few MB, the full amount Updating the client program is not conducive to the storage and transmission of data. Therefore, through the patch scheme, adding a patch to the report that requires customized charts can be performed in the existing client without upgrading the overall client program. Bug fixes and updates to interactive and visual data.
  • a patch file can be packaged together with the report data.
  • the client opens the report, the corresponding patches are detected, and these patches have some customizations to the current data.
  • the chart display so there is no need to upgrade the client to realize the customized update of the data.
  • the client cannot be updated due to the internal firewall of some companies, and the use of the network is disconnected, or the update cannot be updated in time due to batch deployment. At this time, through the report The way of carrying the patch can timely stage the current problem, and fundamentally solve the problem in the subsequent major version of the client's overall update.
  • the program of the rendering process and the input data can be packaged together to update without a network environment, and at the same time, it can also solve the trouble of repeatedly updating the underlying framework in 90% of the update cases.
  • this solution can package the program patch into the input data, and can also realize the update of the client program in the offline situation, and the whole process does not need to be restarted. There is no need to download the installation package, which is more agile than the electron-builder method.
  • Program startup module Receive startup instructions and call programs in the main process
  • Patch detection module Check whether a patch file exists or is imported in the directory of the current program
  • Version detection module If a patch file is detected, call the version management of the main process to check the current version number;
  • Container update judgment module According to the version number of the patch file, if it is detected that there is an update patch file, it is judged whether the container needs to be updated;
  • Test module If there is no need to update the container, load the latest patch file, call the patch test of the rendering process, and execute the test script of the patch file;
  • Update module If the test is passed, start loading, upgrade the current program version number, call the program update of the main process to backup and replace the built-in program, execute the built-in program of the rendering process, start the rendering process client, and update the program.
  • the patch detection module of this embodiment if it is detected that the directory of the current program does not exist or that no patch file has been imported, the built-in program of the rendering process is invoked to start.
  • version detection module of this embodiment if it is detected that there is no update patch file, it is normally started or the built-in program of the rendering process is called to start it;
  • the patch test fails, the patch is deleted, the latest available patch in the current directory is called, the current version program is started, and version detection is performed; if it is detected that no normal patch file can be run, Then execute the built-in program of the rendering process to start;
  • the update module of this embodiment if the test is passed, the patch file is packaged into the input data, and the patch file is added to the program along with the input data.
  • a patch file if a patch file is detected, it will be cached in a local directory.
  • the patch file in this embodiment includes: a separate patch file, or a package file of the patch file and the report data.
  • the patch file is attached to the target file, after the program is started, if it is detected in the patch detection step that the target file is attached with a patch, the version detection is performed, and the patch is cached into the folder designated by the client. , if the folder does not exist, it will be created when the client starts.
  • the container update determination module of this embodiment if it is determined that the container needs to be updated, a new installation package installation program is executed, the program is restarted, and the program starts.
  • a script in the patch file needs to call the program interface in the main process, or when the rendering process needs to call the API (Application Programming Interface) interface of the Electron framework
  • the operating environment of Electron is detected, and the current rendering
  • the program of the process runs in the container of the client, calls the rendering process communication in the main process, injects the script, after the main process receives the script input, executes the script, and returns the execution result to the rendering process through the rendering process communication of the main process, and executes
  • the resulting data is passed into the callback function, and the rendering process executes the callback function.
  • Electron-based update method and system of the present invention can be updated offline, and its program architecture provides a client design idea that separates the front-end code from the underlying framework, which can solve the problem of frequent client update and customized display in actual use data needs.
  • the embodiments of the present application may be provided as a method, a system, or a computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
  • computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, etc.
  • These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory result in an article of manufacture comprising instruction means, the instructions
  • the apparatus implements the functions specified in the flow or flow of the flowcharts and/or the block or blocks of the block diagrams.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Between Computers (AREA)

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 (10)

  1. 一种基于Electron的更新方法，其特征在于，包括：
    程序启动：接收启动指令，调用主进程中的程序；
    补丁检测：检查当前程序的目录下是否存在或被导入有补丁文件；
    版本检测：若检测到有补丁文件，调用主进程的版本管理进行检查当前版本号；
    容器更新判断：根据补丁文件的版本号，若检测到存在更新补丁文件，则判断是否需要更新容器；
    测试：若无需更新容器，加载最新的补丁文件，调用渲染进程的补丁测试，执行补丁文件的测试脚本；
    更新：若测试通过，启动加载，升级当前程序版本号，调用主进程的程序更新进行备份并替换内置程序，执行渲染进程的内置程序，渲染进程客户端启动，程序更新。
  2. 根据权利要求1所述的基于Electron的更新方法，其特征在于，所述补丁检测中，若检测到当前程序的目录下不存在或没有被导入有补丁文件，则调用渲染进程的内置程序进行启动；所述版本检测中，若检测到不存在更新补丁文件，则正常启动或调用渲染进程的内置程序进行启动。
  3. 根据权利要求1所述的基于Electron的更新方法，其特征在于，所述测试步骤中，若补丁测试未通过，则删除该补丁，调用当前目录下最新的可用补丁，启动当前版本程序；若检测到没有正常的补丁文件可以运行，则执行渲染进程的内置程序进行启动。
  4. 根据权利要求1所述的基于Electron的更新方法，其特征在于，所述更新中，若测试通过，则将补丁文件打包进入输入数据，补丁文件跟随输入数据一起到程序中。
  5. 根据权利要求1至4任意一项所述的基于Electron的更新方法，其特征在于，所述补丁检测中，若检测到补丁文件，则缓存到本地目录下；所述补丁文件包括：单独补丁文件、或补丁文件与报告数据打包文件；在输入型客户端，若补丁文件附着在目标文件中，程序启动后，若补丁检测步骤中检测到该目标文件附着有补丁，进行版本检测，并将补丁缓存进入客户端指定的文件夹，若该文件夹不存在，则在客户端启动时，自行创建。
  6. 根据权利要求1至4任意一项所述的基于Electron的更新方法，其特征在于，若补丁文件中的一段脚本需要调用主进程中的程序接口、或当渲染进程中需要调用Electron框架的API接口，检测到Electron的运行环境，当前的渲染进程的程序运行在客户端的容器内，调用主进程中的渲染进程通信，注入脚本，主进程接收到脚本输入后，执行脚本，并将执行结果通过主进程的渲染进程通信返回到渲染进程，执行结果的数据传入回调函数，渲染进程执行回调函数。
  7. 根据权利要求1至4任意一项所述的基于Electron的更新方法，其特征在于，所述容器更新判断中，若判断为需要更新容器，则执行新的安装包安装程序，程序重启，进入程序启动。
  8. 一种基于Electron的更新系统，其特征在于，包括：
    程序启动模块：接收启动指令，调用主进程中的程序；
    补丁检测模块：检查当前程序的目录下是否存在或被导入有补丁文件；
    版本检测模块：若检测到有补丁文件，调用主进程的版本管理进行检查当前版本号；
    容器更新判断模块：根据补丁文件的版本号，若检测到存在更新补丁文件，则判断是否需要更新容器；
    测试模块：若无需更新容器，加载最新的补丁文件，调用渲染进程的补丁测试，执行补丁文件的测试脚本；
    更新模块：若测试通过，启动加载，升级当前程序版本号，调用主进程的程序更新进行备份并替换内置程序，执行渲染进程的内置程序，渲染进程客户端启动，程序更新。
  9. 根据权利要求8所述的基于Electron的更新系统，其特征在于，所述补丁检测模块中，若检测到当前程序的目录下不存在或没有被导入有补丁文件，则调用渲染进程的内置程序进行启动；
    所述版本检测模块中，若检测到不存在更新补丁文件，则正常启动或调用渲染进程的内置程序进行启动；
    所述测试模块中，若补丁测试未通过，则删除该补丁，调用当前目录下最新的可用补丁，启动当前版本程序，执行版本检测；若检测到没有正常的补丁 文件可以运行，则执行渲染进程的内置程序进行启动；
    所述更新模块中，若测试通过，则将补丁文件打包进入输入数据，补丁文件跟随输入数据一起到程序中。
  10. 根据权利要求8或9所述的基于Electron的更新系统，其特征在于，若所述补丁文件中的一段脚本需要调用主进程中的程序接口、或当渲染进程中需要调用Electron框架的API接口，检测到Electron的运行环境，当前的渲染进程的程序运行在客户端的容器内，调用主进程中的渲染进程通信，注入脚本，主进程接收到脚本输入后，执行脚本，并将执行结果通过主进程的渲染进程通信返回到渲染进程，执行结果的数据传入回调函数，渲染进程执行回调函数。
PCT/CN2020/134926 2020-12-09 2020-12-09 基于electron的更新方法及系统 WO2022120640A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/134926 WO2022120640A1 (zh) 2020-12-09 2020-12-09 基于electron的更新方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/134926 WO2022120640A1 (zh) 2020-12-09 2020-12-09 基于electron的更新方法及系统

Publications (1)

Publication Number Publication Date
WO2022120640A1 true WO2022120640A1 (zh) 2022-06-16

Family

ID=81972870

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/134926 WO2022120640A1 (zh) 2020-12-09 2020-12-09 基于electron的更新方法及系统

Country Status (1)

Country Link
WO (1) WO2022120640A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117519691A (zh) * 2024-01-04 2024-02-06 腾讯科技（深圳）有限公司 应用程序处理方法、装置、计算机设备和存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060047942A1 (en) * 2004-08-27 2006-03-02 Rothman Michael A Method, program and system to update files in a computer system
CN107256161A (zh) * 2017-06-13 2017-10-17 广发证券股份有限公司 基于electron技术的客户端升级方法
CN111857765A (zh) * 2020-06-16 2020-10-30 深圳晶泰科技有限公司 用于药物设计系统的插件系统及其生成方法和更新方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060047942A1 (en) * 2004-08-27 2006-03-02 Rothman Michael A Method, program and system to update files in a computer system
CN107256161A (zh) * 2017-06-13 2017-10-17 广发证券股份有限公司 基于electron技术的客户端升级方法
CN111857765A (zh) * 2020-06-16 2020-10-30 深圳晶泰科技有限公司 用于药物设计系统的插件系统及其生成方法和更新方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117519691A (zh) * 2024-01-04 2024-02-06 腾讯科技（深圳）有限公司 应用程序处理方法、装置、计算机设备和存储介质
CN117519691B (zh) * 2024-01-04 2024-04-16 腾讯科技（深圳）有限公司 应用程序处理方法、装置、计算机设备和存储介质

Similar Documents

Publication Publication Date Title
CN108027722B (zh) 在编译和部署中动态更新应用
US9280554B2 (en) Using confidence values for synchronizing file systems
US6948164B2 (en) Method and system for modifying executable code to add additional functionality
US8607208B1 (en) System and methods for object code hot updates
US8489925B1 (en) System and method for processing of system errors
CN112463198B (zh) 基于Electron的更新方法及系统
TWI649694B (zh) 一種安卓動態框架及其方法
US10331425B2 (en) Automated source code adaption to inject features between platform versions
US20130104115A1 (en) Systems and methods for upgrading a version of software
US9329985B1 (en) Using emulation to disassociate verification from stimulus in functional test
US20190114165A1 (en) Using semantic annotations to control compatibility behaviors
US9690564B2 (en) Runtime detection of software configurations and upgrades
WO2017087801A1 (en) Dynamic update of an application in compilation and deployment
US11841731B2 (en) Cloud plugin for legacy on-premise application
WO2022120640A1 (zh) 基于electron的更新方法及系统
US11573787B1 (en) Hot reloading a running application with an unsaved source code change
CN109960522B (zh) 一种软件升级方法及装置
CN110874226B (zh) 一种android系统功能升级的方法
CN115454394A (zh) 具有增强的状态切换和共享的开发环境管理器
US12013866B2 (en) Plugin version management for legacy on-premise application
CN117130987B (zh) 一种大规模无人机集群的飞控管理方法
US20230102514A1 (en) Container plugin for legacy on-premise application
CN113672269B (zh) 数据处理方法、系统、电子设备及程序产品
JP6011712B2 (ja) 修正管理装置、修正管理方法、及び修正管理プログラム
CN107632934B (zh) 一种C-sharp中函数复制方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20964582

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 22.09.2023)

122 Ep: pct application non-entry in european phase

Ref document number: 20964582

Country of ref document: EP

Kind code of ref document: A1