CN116301807A

CN116301807A - Electron-based application program implementation method and device

Info

Publication number: CN116301807A
Application number: CN202310274330.9A
Authority: CN
Inventors: 沈涛
Original assignee: Shanghai Bilibili Technology Co Ltd
Current assignee: Shanghai Bilibili Technology Co Ltd
Priority date: 2023-03-20
Filing date: 2023-03-20
Publication date: 2023-06-23

Abstract

The application provides an implementation method of an application program based on an Electron, which comprises the following steps: configuring a main service layer; the main service layer runs in the main process and is used for providing the bottom layer service of the application program; configuring a rendering layer; the rendering layer is operated in a rendering process and is used for providing page interaction of an application program; configuring a JSB unified interface; wherein the JSB unified interface is to provide communication between the host process and the rendering process; wherein, the JSB unified interface is used for: injecting the JSB object into the window object of each page of the rendering process by the main process in a preloading mode so that the plurality of pages can access the JSB object. According to the technical scheme, the communication complexity of the main process and the rendering process is simplified, and the development and maintenance cost is reduced.

Description

Electron-based application program implementation method and device

Technical Field

The embodiments of the present application relate to the field of computer technologies, and in particular, to a method, an apparatus, a computer device, and a computer readable storage medium for implementing an application program based on an Electron.

Background

With the development of computer technology, applications based on various operating system environments are produced in large numbers. To this end, electronics provide an open source software framework for cross-platform desktop applications. The electronics mainly comprise a main process and a rendering process, and Web technologies such as HTML, CSS, javaScript and the like can be used for constructing the application program, so that development of the cross-platform desktop GUI application program is completed. That is, developers can build cross-platform desktop applications using Web development techniques for use on multiple operating systems, such as Windows, macOS and Linux.

Currently, the communication complexity between the main process and the rendering process is high, and the maintenance is not easy, especially in large-scale application programs.

It should be noted that the foregoing is not necessarily prior art, and is not intended to limit the scope of the patent protection of the present application.

Disclosure of Invention

An object of an embodiment of the present application is to provide a method, an apparatus, a computer device, and a computer-readable storage medium for implementing an Electron-based application program, which are used for solving or alleviating the above-mentioned problems.

An aspect of an embodiment of the present application provides a method for implementing an Electron-based application, where the method includes:

configuring a main service layer; the main service layer runs in the main process and is used for providing the bottom layer service of the application program;

Configuring a rendering layer; the rendering layer is operated in a rendering process and is used for providing page interaction of an application program;

configuring a JSB unified interface; wherein the JSB unified interface is to provide communication between the host process and the rendering process;

wherein, the JSB unified interface is used for: injecting the JSB object into the window object of each page of the rendering process by the main process in a preloading mode so that the plurality of pages can access the JSB object.

Optionally, the underlying service includes:

a first class of services, the first class of services being services that introduce dependencies;

and the second class of services are mutually called in an injection mode or a theme subscription mode.

Optionally, the rendering layer includes a local page and an embedded page;

the JSB unified interface is further to: injecting the JSB object into the local page and the embedded page.

Optionally, the development architecture of the application program includes a root directory, and a first package json file and an installation package packaging configuration file located under the root directory; the method further comprises the steps of:

creating an APP catalog under a root catalog, and configuring the second package. Json file under the APP catalog; synchronizing partial information in the first package json file to the second package json file; wherein the partial information includes dependency information required for the production phase, the dependency information including dependency declarations;

Placing a generated code under the APP catalog through the installation package packaging configuration file, and packaging the generated code and a second package json file into a construction package; the installation package configuration file is further configured with a dependency deletion hook, and the dependency deletion hook is used for deleting the dependency declaration from the construction package to obtain an installation package.

Optionally, the installation package comprises a full installation package and an incremental installation package; the method further comprises the steps of:

and uploading the full installation package, the incremental installation package and the incremental update configuration file to a server to provide a downloading service.

Optionally, the target installation comprises a delta installation package; the method further comprises the steps of:

setting the incremental installation package under a user data directory under the condition that the incremental installation package is obtained;

and setting a module path variable in the environment variable to change a path for importing the incremental installation package.

Another aspect of an embodiment of the present application provides an implementation apparatus of an Electron-based application program, where the apparatus includes:

the first configuration module is used for configuring the main service layer; the main service layer runs in the main process and is used for providing the bottom layer service of the application program;

The second configuration module is used for configuring the rendering layer; the rendering layer is operated in a rendering process and is used for providing page interaction of an application program;

the third configuration module is used for configuring the JSB unified interface; wherein the JSB unified interface is to provide communication between the host process and the rendering process;

Another aspect of an embodiment of the present application provides a computer device, comprising:

at least one processor; and

A memory communicatively coupled to the at least one processor;

wherein: the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method as described above.

Another aspect of the embodiments provides a computer-readable storage medium having stored therein computer instructions which, when executed by a processor, implement a method as described above.

Another aspect of an embodiment of the present application provides a system for implementing an Electron-based application, the system including:

the main service layer is used for running in the main process and providing the bottom layer service of the application program;

the rendering layer is used for running in a rendering process and providing display and interaction of pages in the application program;

a JSB unified interface for providing communication between the host process and the rendering process;

wherein, the JSB unified interface is: injecting the JSB object into the window object of each page of the rendering process by the main process in a preloading mode so that the plurality of pages can access the JSB object.

Optionally, the implementation system includes:

a root directory;

an APP catalog located under the root catalog;

the first package json file is positioned under the root directory;

the installation package packages the configuration file, locates under the said root directory;

an APP catalog is configured under the root catalog, and the second package. Json file is configured under the APP catalog; the partial information in the first package json file is synchronized to the second package json file; the partial information comprises dependency information required by a production stage, and the dependency information comprises dependency declarations;

The installation package packaging configuration file is used for designating to place a generated code under the APP catalog and designating to package the generated code and a second package. The installation package configuration file is also configured with a dependency deletion hook for deleting the dependency declaration from the construction package to obtain an installation package.

Optionally, in the case of incremental updating, the implementation system includes:

the incremental installation package is positioned under the user data directory;

wherein a module PATH (process. Env. Node_path) variable in the environment variable is set to: a path of the delta installation package is specified.

The technical scheme provided by the embodiment of the application comprises the following technical advantages: and replacing the IPC with a JSB unified interface, and carrying out communication between the main process and the rendering process through the JSB unified interface. Specifically, the JSB object of the main process is injected into each page in the rendering process through the preload mechanism, so that the page in the rendering process can directly access the API of the main process. Thus, the page can realize communication between the main process and the rendering process through the JSB object, so that the complexity of communication between the main process and the rendering process is simplified, and the development and maintenance cost is reduced.

Drawings

FIG. 1 schematically illustrates a diagram of an operating environment for a method of implementing an Electron-based application in accordance with one embodiment of the present application;

FIG. 2 (A) schematically illustrates a build framework of an Electron-based application according to embodiment one of the present application;

FIG. 2 (B) schematically shows a process timing diagram of an optimization flow of an application;

FIG. 2 (C) schematically illustrates interface changes based on an optimization procedure;

fig. 2 (D) schematically shows a schematic view in a small window mode;

fig. 2 (E) schematically shows an installation flow of an installation package of an application program;

FIG. 3 schematically illustrates a flow chart of a method of implementing an Electron-based application according to one embodiment of the present application;

fig. 4 schematically shows a block diagram of an implementation apparatus of an Electron-based application according to a third embodiment of the present application; and

Fig. 5 schematically shows a hardware architecture diagram of a computer device according to a fourth embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

It should be noted that the descriptions of "first," "second," etc. in the embodiments of the present application are for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In addition, the technical solutions of the embodiments may be combined with each other, but it is necessary to base that the technical solutions can be realized by those skilled in the art, and when the technical solutions are contradictory or cannot be realized, the combination of the technical solutions should be regarded as not exist and not within the protection scope of the present application.

In the description of the present application, it should be understood that the numerical references before the steps do not identify the order of performing the steps, but are only used for convenience in describing the present application and distinguishing each step, and thus should not be construed as limiting the present application.

First, a term explanation is provided in relation to the present application:

electron: is the open source software framework developed by GitHub for building cross-platform desktop applications. The electronics can construct application programs based on node. Js (corresponding to a main process) and a colorium rendering engine (corresponding to a rendering process) by using Web technologies such as HTML, CSS, javaScript (client script) and the like, and the development of cross-platform desktop GUI application programs is completed. That is, developers can build cross-platform desktop applications using Web development techniques for use on multiple operating systems, such as Windows, macOS and Linux.

Github, an online software source code hosting service platform.

HTML (HyperText Markup Language ) is a markup language used to create Web pages. HTML is used to describe the structure and content of elements in Web pages, such as text, pictures, links, forms, videos, and the like, and to provide tags and attributes for these elements so that the browser can properly display.

CSS (Cascading Style Sheet ), is a style sheet language used to define element styles and layouts in HTML (or XML) documents. By using CSS, web page designers can better control the appearance and layout of documents, thereby realizing richer, more aesthetically pleasing, and easier to manage Web pages.

JavaScript, a scripting language, is used to develop front-end and back-end applications.

The GUI (Graphical User Interface ) is an interface that graphically presents a program or system to a user, allowing the user to interact with the program or system through an intuitive graphical interface. GUIs typically use graphical controls such as windows, menus, buttons, text boxes, etc. to enable interaction between a user and a program.

IPC (Inter-Process Communication ) is a mechanism that enables communication between a host process and a rendering process.

JSB (JavaScript Bindings) is a technique to bind c++ objects to JavaScript objects.

A window object, representing an open window. If the document contains frames (< frame > or < iframe > tags), a window object is created for the HTML document and an additional window object is created for each frame.

The electronic-builder is an electronic-based cross-platform software packaging and distribution tool and is used for helping developers to package electronic application programs into executable files, installation packages, compression packages and other various forms, supporting cross-platform packaging and packaging application programs of Windows, mac and Linux platforms. The Electron-builder can automatically process the differences of different platforms, including file systems, operating systems, third party libraries and the like. Electron-builder may also provide a number of configuration options for helping developers customize the packaging process. In the Electron-builder, the package and configuration information for the item are stored in a file named package. The package. Json file is a node. Js project configuration file, and may include various metadata, dependencies, and construction scripts of an application program, which are used to determine how to construct the application program.

Electron-updater is an automatic update tool for an Electron application to help developers to implement automatic updates of the application, including incremental and full updates. Using Electron-updater, an application can detect updates, download updates, and automatically install updates, thereby enabling seamless upgrades of the application.

RxJS (Reactive Extensions for JavaScript), a responsive programming library, for handling asynchronous and event driven.

NPM (Node Package Manager), tools for managing dependencies, building and packaging applications.

postnstall/postuninstall are NPM script commands.

The afterallArtifactbuilding is a task or script that runs after all the application programs are built.

A hook, referring to a predefined function or method, may be triggered at certain specific points in the life cycle of the program.

Vue, a progressive framework for building user interfaces, focuses on the view layer.

SPA (Single Page Application), which is a Web application development mode, can put all contents in a single HTML page, and dynamically update the contents by using JavaScript and AJAX technologies, so that the problem of refreshing pages multiple times by the conventional Web application can be avoided. SPA is implemented using a front-end framework such as Angular, react, vue, etc., with the back-end providing RESTful API interfaces to provide data services.

An open Page (Splash Page), also known as a start Page, welcome Page, refers to the first Page displayed when the App starts.

Main Page (Main Page), also called Main interface, main interface Page, refers to the initial Page of the function set in the mobile application program, and is usually the Main entry, presentation interface and interaction interface of the App function. The home page is created according to specific needs and designs and typically contains page elements such as various functional menus, buttons, search bars, etc. of the application.

Hierarchical relationships may also exist between different pages, with pages of a higher hierarchy overlaying pages of a lower hierarchy.

A shell refers to a process of embedding an application into another application.

Implantation refers to the process of adding new code, libraries, or components in an application.

Tampering, which refers to the process of modifying an application, may be for illegal purposes, such as the production of malware or pirate software.

v8 bytecode, which is a bytecode used by v8 engines developed by Google, is a low-level, interpreted binary code that can be directly executed in v8 engines. After the JavaScript code is compiled in the v8 engine, v8 bytecode is generated and operation instructions and data of the JavaScript code are included.

Eval, a function in JavaScript language, can execute dynamically generated code strings and execute dynamically generated codes.

WebAsssembly is a low-level bytecode that can run on different types of devices, with security and portability.

Js is a cross-platform running environment capable of writing JavaScript code at the server side.

Nest. Js, a node. Js-based framework that provides a set of tools and modules to help developers build scalable, modular, and easy-to-maintain Web applications and services

Esbuild, is a fast, extensible build tool for building JavaScript and TypeScript applications.

Vue3, a JavaScript framework, is used to create a user interface.

Vite2 is a fast build tool for the development of modern Web applications.

TypeScript, an open source programming language, is a superset of JavaScript.

Next, in order to facilitate a person skilled in the art to understand the technical solutions provided in the embodiments of the present application, the following related art is described:

the electronics act as an open source software framework for the cross-platform desktop application, including a main process and a rendering process. For communication between the main process and the rendering process, the Electron provides an IPC interaction layer. Without a good IPC interaction layer encapsulation, large projects can be very difficult to maintain. In addition, the package. Json file constructed by using the Electron-builder contains dependency and script information, and technical information is leaked. The full-volume update realized by using only an Electron-updater needs to download a complete installation package, and has slow download and slow installation, thereby affecting the updating experience of a user.

Therefore, the embodiment of the application provides a new scheme for solving the problem of complex communication between the main process and the rendering process of the large-scale Electron program, and reducing the development cost; the method solves the problems of configuration of Electron-builder packing environment variables and optimization of products; the method solves the problem that the electronic increment is updated and bypasses the window UAC (user account control) authority limit.

Fig. 1 schematically shows an environmental operation diagram of an implementation method of an Electron-based application according to an embodiment of the present application. As shown in fig. 1, the environment schematic includes a development platform 2, a server 4, and a client 6, where:

the development platform 2 may be a workstation, a personal computer, a virtual instance in a cloud platform, etc., and provides a development environment and a development interface for a user. The development platform 2 may run a Windows system, an IOS system, or a Unix system, etc. After the development platform 2 develops the application (installation package), it can distribute through the server 4.

The server 4, which is a service platform, may be constituted by a plurality of computing devices. The plurality of computing devices may include virtualized computing instances. Virtualized computing instances may include virtual machines such as emulation of computer systems, operating systems, servers, and the like. The computing device may load the virtual machine based on a virtual image and/or other data defining particular software (e.g., operating system, dedicated application, server) for emulation. As the demand for different types of processing services changes, different virtual machines may be loaded and/or terminated on one or more computing devices. A hypervisor may be implemented to manage the use of different virtual machines on the same computing device.

The server 4 may provide services such as storage, distribution of application programs, etc.

The server 4 may be configured to communicate with the development platform 2, clients 6, etc. over a network.

The client 6 may be provided with a user access page, or may automatically download an installation package from the server 4 to perform software update, or the like.

Wherein an optimized application may be provided at the development platform 2 or the client 6, the application processing may be based on an Electron framework.

The application is described below in terms of its overall architecture and construction, playback experience optimization, and code security.

And (one) the whole architecture, construction and upgrading of the application program.

As shown in fig. 2 (a), the overall architecture may include a main service layer 100, a rendering layer 200, and a JSB unified interface 300.

The application programs are mainly divided into a Main Process (Main Process) and a rendering Process (Render Process), the Main Process (corresponding to the Main service layer 100) may be a node js and a native API, the rendering Process (Render layer 200) is mainly a front-end technology, and the Main Process and the rendering Process are communicated through the JSB unified interface 300. For the purposes of easy maintenance, good expansion, reusability and the like, a scheme of NodeJs+NestJs+Esbuild can be selected to develop a main process, and Vue3+Vite2+TypeScript is selected to develop a rendering process. Of course, other techniques may be used.

The application program can have the conventional functions of recommendation, live broadcast, popular, OGV (Occupationally Generated Video, professional production content), dynamic, space, search and the like, and needs other capabilities of local software of a computer end, such as installation and upgrading, tray hiding, local storage, proprietary windows, offline cache, custom configuration and call end pull-out.

For specific architecture and construction, upgrades reference is made to the following examples one to five.

And (II) optimizing the playing experience of the application program.

When an application program (such as an Electron application) opens a window, if the window opens a relatively large SPA page, because resource loading is relatively time-consuming, a white screen can be generated if loading optimization is not performed. In addition, the rendering process occupies larger resources, and if the user does not use the rendering process for a long time and does not exit the program, the rendering process can cause the conditions of resource waste, power consumption and the like. Under a Windows system, the inability of a window movable region to affect a mouse event can result in the front end being unable to determine whether the mouse hovers over a window.

Therefore, the problems that an application program such as an Electron is slow to open and a white screen is opened, the resource consumption of the application program is optimized, and the problem that a window movable area of the application program cannot influence a mouse event under a Windows system is solved.

Referring to fig. 2 (B), 2 (C) and 2 (D), the specific optimization operation of the application program is as follows:

first: starting and window optimization, wherein the steps are as follows:

1. at start-up (first opening the main window), a hidden main window is created first, and a relatively simple open page is loaded.

2. And after the rendering of the open screen page is completed, calling the open screen page processing interface of the main process, and controlling and displaying the main window to prevent the open screen page from being white.

3. After the main window and the open page are displayed, the main page is loaded and rendered below the open page of the main window.

4. And when the main page rendering is completed, calling a main process main page processing interface, and closing an open screen page covered on the main page.

5. After receiving the notification of the completion of the main page rendering, the main process creates a hidden playing window.

6. When the user clicks the play video, the rendered play window is displayed, and the video is loaded and played.

7. When the main window and the play window are closed, only the main window and the play window are hidden. The window instance is hidden and not really destroyed, and when the video is opened or played again, the window can be opened quickly, so that the user experience is improved.

In the main window, there may be different levels of pages that are presented on the display. For example, there are page a and page B in the main window, and if the level of page a is greater than that of page B, page a is overlaid on page B when displayed.

In the scheme, the application program is started, and the main page is not loaded, but the open page is loaded and displayed first. And under the condition that the main window and the open page are displayed, loading and rendering of the main page can be carried out, so that the problems of resource occupation and abnormal display caused by loading and rendering of the open page and the main page can be avoided.

And loading and rendering the main page after the main window and the open screen page are displayed. The main page is lower in level than the open page, and therefore, the open page is overlaid thereon when the main page is loaded and rendered. In this way, the main page under loading and rendering corresponds to being in a hidden state and is not seen by the user.

In an exemplary application, a domsetloadevent in JavaScript or $ (document) · ready () method in jQuery, etc. may be used to detect whether the main page has completed rendering. In other embodiments, the home page may also be considered to be rendered when the user implements the main content of the setting to complete the loading and rendering.

And after the main page is rendered, setting the main page as the content of the main window, and closing the open screen page. In an exemplary application, the open page may be hidden by controlling the CSS attribute, or removed directly.

The scheme can improve the user experience, and is specifically as follows:

and responding to the starting of the application program, creating a main window in a hidden state, loading and rendering an open screen page, and loading and rendering the main page below the level of the open screen page under the condition that the main window and the open screen page are both displayed, so that a user can see one open screen page instead of a possible home page white screen in the process of waiting for loading the home page. And displaying the main page on the main window and closing the open page under the condition that the main page is completely rendered, so that a user can normally use an application program.

According to the scheme, the starting process of the application program is optimized, the white screen caused by directly loading the main page is avoided or relieved, and the experience is improved. The optimization is particularly applicable to programs with large main pages, such as Electron applications.

In this scenario, the main page may be various types of pages, such as an HTML web page, a multimedia web page, a dynamic web page, a single page application, and so on. The home page may have various controls, such as a home page for video playback having a play control, etc.

Taking an application program based on Eletron as an example, after the main page is rendered, a main window processing interface in a main process is called, and an open page is closed. And after the main process receives the completion of the main page rendering, creating the playing window.

In an exemplary application, a video element in a main window is acquired, the element binding a click event listener. When the user clicks the element, a play window is displayed, and video is acquired according to a video source specified by the video element and added into the play window.

In an exemplary application, a video file or video playback component is played in a playback window using the video tag of HTML 5; the playing window may have video control components, such as a progress bar, display mode switching, etc., as needed.

In an exemplary application, some video processing functions may be added in the play window, such as video clips, adding special effects, etc.; interactive functions such as comments, praise and the like can be added in the play window; other functions may also be provided.

In an exemplary application, elements of a primary window are acquired and an event listener is added to the primary window. When the main window is closed, the event listener sets the display attribute of the main window to none (attribute value), thereby hiding it. It should be noted that, the hiding operation of the playing window may also refer to the main window.

In the scheme, when the main window and the playing window are closed, only the window is hidden and the window instance is not really destroyed, and when the video is opened or played again, the window can be opened rapidly, so that the user experience is improved.

Second, a power saving mode of the application is provided:

because the rendering process occupies larger resources, if the user does not use for a long time and does not close, the resource waste is caused, so that an energy-saving mode can be set for the application program, the application program can enter the mode after being hidden in the tray for a period of time, and the rendering process corresponding to the main window and the playing window can be destroyed at the moment, so that the resource occupation is released. After entering the energy saving mode, if the user reopens the application program, the screen opening process is entered again.

The application entering a minimized state may refer to the application being hidden to a tray or in the background.

In an exemplary application, in the power saving mode, when the application enters the minimized state, a timer is started, recording the duration of time that the minimized state was entered. And when the duration time of entering the minimized state exceeds a preset threshold value, destroying the rendering processes of the main window and the playing window, thereby releasing the occupation of resources and relieving the waste of resources. The above-described resource release is not performed in the non-power saving mode. The user may autonomously select whether to enter the power saving mode.

In some schemes, different preset thresholds can be set according to different application scenes and user requirements; the minimum state duration time can be dynamically determined according to the current state of the client so as not to influence the normal use of the equipment; the method can also remind the user that the process is to be destroyed when the duration approaches to the preset threshold value, and the user decides whether to destroy or not.

Third, provide for optimization of the application in a compact mode (widget mode):

the widget mode is entered when the widget mode button in the upper right corner of the play window is clicked or when the play window is dragged to change to a small size.

In the small window mode: the window can adapt to the video locking aspect ratio to realize black-edge-free play. The function of the fixed window at the forefront is matched, so that a user can learn a course while actually operating the course. Compared with the picture-in-picture of the webpage, the small window of the computer client can display the barrage, and the limitation of the original picture page is avoided. A small window in essence refers to a succinct pattern because it can also drag edges to resize, becoming larger than a "large window".

In the small window mode, the default window size and scale are not fixed, and the user can drag the window edge to change size to achieve the desired effect (shape, size). The user can click the 'lock aspect ratio' button to realize window proportion adaptation video size to realize black-edge-free play, and the scaling can be maintained when the window size is changed by dragging.

In the small window mode, hovering of the mouse is simulated by taking an intersection according to the positions of the window and the mouse in the physical screen. For example, after the designated target play window is acquired, the mouse event listener is executed by setting a preset time interval. When the target playing window is in a visible state, a target area of the target playing window in the physical screen is acquired, and the position of the mouse in the physical screen is acquired. It is checked whether the mouse position exceeds the target area. And under the condition that the position of the mouse is not in the target area or the target playing window is in an invisible state, automatically removing the mouse event monitor so as to achieve the aim of simulating a mouse event, and further efficiently and accurately determining the display and the hiding of the window title bar. It should be noted that the mouse event may be simulated in other manners.

And (III) code security of the application program.

Electron acts as an open source software framework for cross-platform desktop applications, which can be used in a variety of devices. An installation package for an application generally includes: application code files (e.g., JS code, CSS code, etc.), package. Json files, etc. The application code file is easily removed from the case, implanted, or tampered with by a person.

The code protection scheme is also provided, so that the problems that the application program code is easy to be sleeved, implanted or tampered and the like can be solved.

The scheme is as follows:

1. obfuscating program code of an application program to obtain a first obfuscated file;

2. encrypting the first confusion file to obtain an encrypted file;

3. acquiring a decryption entry code for the encrypted file;

4. obfuscating the decryption entry code to obtain a second obfuscated file;

5. converting the second obfuscated file into a bytecode entry file; and

6. And obtaining an installation package according to the encrypted file and the byte code entry file, wherein the installation package is used for providing the client.

The application program may be various programs. Taking an Electron-based application as an example, its main process code includes, for example, javaScript code. The JavaScript language is easy to be sleeved, implanted and tampered with because the environment on which the JavaScript language depends is open, readable and editable. For example, an attacker may tamper with JavaScript code during network transmission.

Therefore, it is necessary to perform a secure process after the program code of the application program is constructed.

The protection scheme of the application program provided by the scheme is used for increasing the difficulty of being sleeved, implanted and tampered, and improving the safety of the application program. Program code may be prevented from reverse engineering decryption by confusion and encryption operations. The encrypted file may be decrypted by decrypting the entry code, which in turn increases the difficulty of the attacker to analyze the code by confusion and bytecode conversion. And then, generating an installation package according to the encrypted file and the byte code entry file for the client to use. In the client, the client machine itself may decrypt the encrypted file according to the bytecode entry file, thereby enabling installation and running of the application. However, because the installation package combines the processing modes of code confusion, encryption, byte codes and the like, an attacker (person) is difficult to reversely engineer to obtain the original code, thereby avoiding the application program from being sheathed, implanted and tampered as much as possible and realizing the effective protection of the application program.

In an alternative scheme, the byte code entry files have a plurality of byte code entry files; the above process further comprises:

generating an execution entry file according to an operating system and/or a system architecture; wherein:

the execution entry file is used for: and selecting a target byte code entry file from a plurality of byte code entry files according to the system environment of the client.

The execution portal file provides an installation portal for the client, which may be in JavaScript or the like.

For example, the steps of the plurality of bytecode entry files and the execution entry file may be as follows:

step one: and acquiring a path of the decryption-entry file, and reading the content in the decryption-entry file.

Step two: confusion is made with respect to the decryption entry file.

Step three: and acquiring the confused codes, and covering the original decryption entry file by the confused codes.

Step four: different bytecode entry files are generated based on the obfuscated code, depending on the operating system and system architecture.

If the system is Windows, the suffix is 'win', otherwise, the suffix is generated according to the system architecture.

The suffix is 'arm' if the system architecture is arm, otherwise it is 'x86'.

Step five: a complete path for each bytecode entry file is generated.

Step six: and constructing an execution entry file according to the complete path of each byte code entry file to provide path guidance.

Taking an Electron application as an example, which has cross-platform capability, the installation package is often adapted to different hardware or software environments to improve compatibility and stability. In the scheme, an installation inlet of the application program is provided for the client by executing the inlet file, an operating system and/or a system architecture of the client are judged, and then the corresponding byte code inlet file is effectively determined according to the operating system and/or the system architecture of the client, so that the installation is correctly guided.

In some aspects, the method may further include:

after the application program is constructed, generating a hash value of the application program according to the file in the application program.

The hash value of the application may be used to verify the integrity and security of the application. When the installation package of the application program is installed, whether the installation package passes through the shell, is implanted or tampered can be confirmed by calculating the hash value of the application program and comparing the hash value of the application program with an expected hash value, so that the safety is improved.

In some aspects, the method may further include:

generating an application key for the application program; wherein the application key is used to identify and verify the identity of the application.

The application key (AppKey) of the application may be used to identify and verify the identity of the application. The application key may be an encrypted string that may be used to authenticate the publisher and license of the application. The application key may ensure that the application is only published by authorized publishers and may prevent unauthorized tampering or distribution.

The installation package based on the code protection scheme can be installed as follows:

1. and under the condition that an installation package of the application program is obtained, acquiring a target byte code entry file in the installation package.

2. According to the target byte code entry file, decrypting the encrypted file in the installation package to obtain the program code of the application program; wherein the target bytecode entry file is transcoded based on a decryption entry.

The encrypted file in the installation package is obfuscated and encrypted program code. In the client, the client machine itself may decrypt the encrypted file according to the bytecode entry file and ultimately enable the installation and running of the application. Because the encrypted file in the installation package combines the processing modes of code confusion, encryption, byte codes and the like, and the byte code entry file combines the confusion and byte code processing, an attacker is difficult to obtain the original code in the encrypted file by reverse engineering, and the application program is prevented from being sheathed, implanted and tampered as much as possible while the client can correctly install the program.

By way of example, the installation procedure may be as follows:

step one: decompiling the target byte code entry file to obtain a second obfuscated file.

Step two: and performing anti-obfuscation operation on the second obfuscated file, and restoring the decryption entry code.

Step three: and carrying out decryption operation on the encrypted file through the decryption entry code to obtain a first confusion file.

Step four: and performing anti-confusion operation on the first confusion file to obtain the program code.

Step five: and running the program code.

In some aspects, the decrypting the encrypted file in the installation package according to the target bytecode entry file to obtain the program code of the application program includes: loading the target byte code entry file through WebAsssembly to obtain a WebAsssembly decryption instance; and carrying out decryption operation on the encrypted file through the WebAsssembly decryption instance to obtain the program code.

In some schemes, a combination mode of code confusion, encryption, byte code and WebAssemblem decryption is combined, so that the difficulty of cracking the original program code can be further increased, and the difficulty of cracking the installation package is improved.

In some aspects, the program code includes an application key and/or a hash value of the application program. Correspondingly, it may further include:

Verifying the application program according to the application key and/or the hash value;

if the application program does not pass the verification, the application program is exited; and

And starting and running the application program under the condition that the application program passes the verification.

The hash value of the application may be used to verify the integrity and security of the application. When the installation package of the application program is installed, whether the installation package passes through the shell, is implanted or tampered can be confirmed by calculating the hash value of the application program and comparing the hash value of the application program with an expected hash value, so that the safety is improved. The application key of the application may be used to identify and verify the identity of the application. The application key may be an encrypted string that may be used to authenticate the publisher and license of the application. The application key can ensure that the application program is only issued by an authorized issuer, and the installation and operation of unauthorized risk application programs are avoided.

In some aspects, the installation package includes an execution entry file and a plurality of bytecode entry files; correspondingly, the obtaining the target byte code entry file in the installation package includes: executing the execution entry file, and determining an operating system and/or a system frame of the client through the execution entry file; and selecting the target byte code entry file from the plurality of byte code entry files according to an operating system and/or a system framework of the client.

Taking an Electron application as an example, which has cross-platform capability, the installation package is often adapted to different hardware or software environments to improve compatibility and stability. In this embodiment, the client may obtain the installation portal of the application program by executing the portal file, and determine the corresponding bytecode portal file, so as to install correctly and efficiently.

To make the present code protection scheme easier to understand, an example of an installation procedure is provided below in connection with fig. 2 (E).

a. And running the execution entry file, judging the system architecture, and finding out the corresponding target byte code file for execution.

b. The encrypted file (obfuscated and encrypted program code) is decrypted in the bytecode and executed by Eval.

c. Judging whether the application key and the hash value are correct, if the verification is not passed, throwing out an error, and exiting the program.

d. And if the safe running environment is checked, the application program is started normally.

The architecture, construction and upgrade schemes of the application program provided in the present application are described in the following through a plurality of embodiments with the development platform 2 as an execution subject.

Example 1

Fig. 2 (a) schematically shows a functional architecture of an implementation system of an Electron-based application according to the first embodiment of the present application. The functional architecture includes a main service layer 100, a rendering layer 200, and a JSB unified interface 300.

(1) The main service layer 100 is configured to run in a main process and provide an underlying service of an application program.

In an Electron environment, the main process runs in the background of the Electron framework. The main process is responsible for executing the underlying services. As an example, as shown in fig. 2 (a), the underlying service may include: window management service, configuration service, event service, API request service, general public service, account service, reporting service, upgrading and updating service, video downloading service, local storage service, local file service, gray experiment service and other various bottom layer services. The host process may also access underlying resources such as file systems, networks, operating systems, etc. through APIs. In practical application, the adjustment of the service may be performed according to actual needs.

In an alternative embodiment, the underlying service may include:

In practical applications, new services may be added as needed, and the services may be classified into different categories.

For example, services such as local logging, local storage, and SDK download may introduce dependencies. By introducing dependencies, various external libraries and SDKs can be used to accomplish specified functions, thereby achieving more functionality and better performance.

For another example, various services such as the window management service and the configuration service can be mutually invoked in a manner of injection or RxJS topic subscription. Where injection refers to injecting an instance of one service into another service in order to invoke the former in the latter. The RxJS topic subscription refers to the use of subjects or Observable objects provided in the RxJS library to enable messaging and subscription between individual services. A Subject or an Observable object may be subscribed to by multiple services. If a Subject or an Observable object changes, all services subscribed to it are notified. This approach is typically used to achieve loose coupling between multiple services.

As above, by introducing dependency, injection, topic subscription and the like, different services can be realized, and the service efficiency and flexibility are improved.

(2) And the rendering layer 200 is used for running in a rendering process and providing display and interaction of pages in the application program.

In an Electron environment, the rendering process corresponds to a window page, responsible for rendering and presenting user interfaces, such as windows, menus, dialog boxes, and the like. The rendering process uses the browser kernel to interpret and execute HTML, CSS, javaScript, etc.

The window page is a main window in the Electron application for displaying a user interface of the application. The window page may call a native API provided by the Electron, such as creating a new window, displaying a system notification, controlling a menu bar, and so forth.

It should be noted that, the application program is developed based on Electron and WEB technologies, and the window page and the HTML page are essentially realized by WEB technologies such as HTML, CSS and JavaScript, and one window page is essentially an HTML page. In addition, the HTML page can be a local page pulled from a local server, and even if the network is disconnected, the application program can respond and display corresponding prompt information. The page (home page) with strong correlation to the network can display failure prompt when the network is disconnected, but the functions of offline caching, setting and the like can be used.

In an optional embodiment, the rendering layer includes various pages such as a local page and an embedded page, so as to promote the richness of the page.

As shown in fig. 2 (a), the rendering layer may include: local pages such as recommendation, live broadcast, popular sitcoms, movies, dynamic, my, spatial messages, settings, search, play list, player, etc. The method can also comprise account login, recharging, live details, and embedded pages such as open broadcasting. The embedded page may be implemented by < iframe >, < webview >, etc. In practical application, the page may be adjusted according to actual needs.

(3) A JSB unified interface 300 for providing communication between the host process and the rendering process.

The JSB unified interface is as follows: injecting JSB objects into window objects of pages of the rendering process by the main process in a preloading (preloading) mode so that the plurality of pages can access the JSB objects.

In an Electron environment, a main process and a rendering process realize data transmission and function call through IPC communication. It is currently known that the current IPC interaction layer is very difficult to maintain, especially in large programs. In this embodiment, IPC is replaced by a JSB unified interface, and communication between the two is performed through the JSB unified interface.

In this embodiment, in order to enable a page in the rendering process to directly access an API of a main process, a JSB object is created in the main process, and then the JSB object of the main process is injected into each page in the rendering process through a preload mechanism. Thus, the page can realize communication between the main process and the rendering process through the JSB object, so that the complexity of communication between the main process and the rendering process is simplified, and further, the development and maintenance cost is reduced.

In an alternative embodiment, the rendering layer includes a local page and an embedded page. Correspondingly, the JSB unified interface is further configured to: injecting the JSB object into the local page and the embedded page. In this alternative embodiment, direct communication of various parent, child pages and host processes, including embedded pages, may be implemented.

Based on the functional partitioning above, the main service layer 100 (corresponding to the main process), the rendering layer 200 (corresponding to the rendering process), and the JSB unified interface 300 are introduced. UI and interaction are realized by a rendering process, functions of local log, storage, downloading, reporting and the like are realized by a main process, the rendering process and the main process communicate through a packed JSB unified interface, the problem of complex communication between the main process and the rendering process of a large-scale Electron program is solved, and development and maintenance cost is reduced.

The present system will be described below from the point of view of file division.

List one

As shown in table one, from the perspective of file partitioning, the system may include:

(1) Root directory (Electron/, as in table one);

(2) An APP catalog located under the root catalog (Electron /);

(3) A first package. Json file located under the root directory (Electron /);

(4) An installation package packaging configuration file (Electron-builder. Config. Js) located under the root directory (Electron /); and

build resource directory (build /), install package generation directory (dist /), render process build configuration file (vite. Config. Ts), etc.

In this embodiment, the APP directory is configured under the root directory, and the second package. The partial information in the first package json file is synchronized to the second package json file; the partial information includes dependency information required for the production phase, the dependency information including dependency declarations.

The reason for setting the file structure is as follows:

the first package json file is a package json in the development environment, and includes a large amount of configuration information, for example: name (name of application), version (description of application), author (author information), license (open source license type), dependencies (including Electron and other npm packages), devDependencies (developing dependencies including build tools and test frameworks, etc.), build (build configuration information including package format, target platform, application icons, etc.).

If the first package is driven into a package when the package is constructed, the package is issued to a user to cause leakage of technical information. For example, dependencies, devDependencies and other information-dependent leaks may result.

For this purpose, the present embodiment creates an APP directory under the root directory by Electron-bush. The addition of a second package. Json file under the APP directory may of course also add other files like program profiles (e.g. read em. Next, when the package is built, the required files under the APP directory can be designated to be driven in to get the build package. Wherein, the build package may refer to the code built, the compatible package without installation, or the final installation package. Specifically:

first: the dependency information in the first package json file is partially synchronized into the second package json file so that the program can reference the required dependencies. It should be noted that, not all the dependency information in the first package json file is synchronized into the second package json file, but essential dependency information required by the synchronization application in the production environment (not the development environment). Therefore, even if the second package. Json file is packaged into the construction package, information-dependent leakage is reduced, and potential safety hazards are reduced to a certain extent.

In the specific engineering implementation, a synchronization script under execution/script may be triggered by the NPM executing predefined hooks (such as a postall hook and a postuninstallation hook), so that the necessary dependency information in the first package json file may be synchronized into the second package json file by the synchronization script.

Second,: the generated code is also placed under the./app directory. The generated code is the code compiled at program construction. In a specific engineering implementation, the generated code may be placed under the "/app directory by an electron-builder.config.js designation.

Thus, both the generated code and the second package. Json file in the production environment are under the./app directory. At the time of packaging, it is possible to specify which files under the app directory need to be driven into the package by the electronics-builder.

After packaging is completed and a "build package" is obtained, dependency information in the production environment still exists in the build package. If the build package is provided directly to the user, this part of the dependency information may be compromised. Therefore, after obtaining the build package, the dependency declaration of the second package json file in the build package also needs to be deleted, so as to obtain the final installation package. The final installation package is provided for the user again, so that the problem of information leakage dependence does not occur. In an exemplary operation, a dependency delete hook may be added to the electron-builder. Config. Js, through which the dependency declaration is deleted, thereby obtaining an installation package that may be provided to the user.

The above describes that the problem of technical information leakage is avoided or alleviated by setting the file structure so as to improve the information security.

After an installation package is obtained, our final goal is to provide the user with the installation or update to the client.

In an alternative embodiment, the installation packages include a full volume installation package and a delta installation package.

After the full installation package, the delta installation package is obtained, then a download service may be provided. Specific: uploading the full installation package, the incremental installation package and the incremental update configuration file to a server to provide a download update.

The full install package is a software package that replaces the entire software package with the latest version. The client needs to download the installation package of the whole new version and cover the original software package. The updating mode enables the updated software package to be brand new, and stability and integrity of the software can be guaranteed. But downloading the entire installation package requires a long time and bandwidth resources.

The incremental installation package is to update the code package. The benefit of this update approach is that download time and bandwidth resources can be saved. The incremental installation package is obtained on the basis of the construction package, and the construction package is an installation package compatible with a plurality of hardware platforms and has large volume. When the incremental installation package is constructed, an afterallArtifactbuild hook can be added in the electron-builder.config.js, and the incremental installation package is generated through the afterallArtifactbuild hook based on the construction package. The delta installation package may be provided to the client after compression.

The full mount package corresponds to a full update, and the incremental mount package corresponds to an incremental update. That is, the full-volume update is to download the full-volume installation package to the local at one time for updating. The incremental update is performed by downloading only the change part, so that the size and the downloading time of the update package can be reduced, for example, only the incremental update package (code package) is downloaded.

The download update may be a full version download update or a gray level download update in the test phase.

When the incremental gray level update is started, only the version supporting the increment can be updated in increments, and the version not supporting the increment needs to be updated to the latest version through the whole amount. If the latest version of the delta update configuration file (update. Yml) is issued, even the version supporting the delta will detect an update. Therefore, a new update. Yml needs to be generated according to the version number of the client, the configuration of the configuration center, and the resources uploaded by the server.

In an alternative embodiment, in the case of incremental updates, the implementation system includes:

wherein the module path variable of the environment variables is set to: a path of the delta installation package is specified.

In a Windows system, due to UAC limitations, modifying files under an installation package requires requesting user rights, and in a system disk requires requesting administrator rights. The request rights can also affect the upgrade experience if the incremental installation package is downloaded under the installation directory. Therefore, this embodiment bypasses the UAC limitation problem described above and places the incremental installation package under the user data directory. At the same time, the module path variable is set to specify the path of the incremental installation package, ensuring that code running under the user data directory (incremental installation package) can be imported.

Example two

It should be noted that technical details, technical effects, and the like of the present embodiment may be referred to above.

Fig. 3 schematically shows a flowchart of an implementation method of an Electron-based application according to an embodiment of the present application. As shown in fig. 3, the implementation method of the Electron-based application program may include steps S300 to S304, in which:

s300, configuring a main service layer; the main service layer runs in the main process and is used for providing the bottom layer service of the application program;

s302, configuring a rendering layer; the rendering layer is operated in a rendering process and is used for providing page interaction of an application program;

S304, configuring a JSB unified interface; wherein the JSB unified interface is to provide communication between the host process and the rendering process;

In an alternative embodiment, the underlying service includes:

In an alternative embodiment, the rendering layer includes a local page and an embedded page;

In an alternative embodiment, the development architecture of the application program includes a root directory, and a first package json file and an installation package packaging configuration file located under the root directory; the method further comprises the steps of:

In an alternative embodiment, the installation packages include a full installation package and a delta installation package; the method further comprises the steps of:

In an alternative embodiment, the target installation includes a delta installation package; the method further comprises the steps of:

Example III

Fig. 4 schematically shows a block diagram of an implementation apparatus of an Electron-based application according to the third embodiment of the present application, which may be divided into one or more program modules, which are stored in a storage medium and executed by one or more processors to complete the embodiments of the present application. Program modules in the embodiments of the present application refer to a series of computer program instruction segments capable of implementing specific functions, and the following description specifically describes the functions of each program module in the embodiments. As shown in fig. 4, the implementation apparatus 400 of the Electron-based application program may include a first configuration module 410, a second configuration module 420, and a third configuration module 430, wherein:

A first configuration module 410, configured to configure a main service layer; the main service layer runs in the main process and is used for providing the bottom layer service of the application program;

a second configuration module 420 for configuring the rendering layer; the rendering layer is operated in a rendering process and is used for providing page interaction of an application program;

a third configuration module 430, configured to configure the JSB unified interface; wherein the JSB unified interface is to provide communication between the host process and the rendering process;

In an alternative embodiment, the underlying service includes:

In an alternative embodiment, the development architecture of the application program includes a root directory, and a first package json file and an installation package packaging configuration file located under the root directory; the apparatus further comprises a packaging module (not identified) for:

In an alternative embodiment, the installation packages include a full installation package and a delta installation package; the apparatus further comprises an upload module (not identified) for:

In an alternative embodiment, the target installation includes a delta installation package; the apparatus further comprises a setting module (not identified) for:

Example IV

Fig. 5 schematically shows a hardware architecture diagram of a computer device 10000 suitable for implementing an implementation method of an Electron-based application according to a fourth embodiment of the present application. The computer device 10000 may be part of the server 4. In this embodiment, the computer device 10000 may be a workstation, a personal computer, a cloud server, or the like. As shown in fig. 5, the computer device 10000 includes at least, but is not limited to: the memory 10010, processor 10020, network interface 10030 may be communicatively linked to each other via a system bus. Wherein:

memory 10010 includes at least one type of computer-readable storage medium including flash memory, hard disk, multimedia card, card memory (e.g., SD or DX memory, etc.), random Access Memory (RAM), static Random Access Memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, memory 10010 may be an internal storage module of computer device 10000, such as a hard disk or memory of computer device 10000. In other embodiments, the memory 10010 may also be an external storage device of the computer device 10000, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash Card (Flash Card) or the like. Of course, the memory 10010 may also include both an internal memory module of the computer device 10000 and an external memory device thereof. In the present embodiment, the memory 10010 is typically used for storing an operating system installed on the computer device 10000 and various types of application software, such as program codes of implementation methods of Electron-based application programs. In addition, the memory 10010 may be used to temporarily store various types of data that have been output or are to be output.

The processor 10020 may be a central processing unit (Central Processing Unit, simply CPU), controller, microcontroller, microprocessor, or other object processing chip in some embodiments. The processor 10020 is typically configured to control overall operation of the computer device 10000, such as performing control and processing related to data interaction or communication with the computer device 10000. In this embodiment, the processor 10020 is configured to execute program codes or process data stored in the memory 10010.

The network interface 10030 may comprise a wireless network interface or a wired network interface, which network interface 10030 is typically used to establish a communication link between the computer device 10000 and other computer devices. For example, the network interface 10030 is used to connect the computer device 10000 to an external terminal through a network, establish a data transmission channel and a communication link between the computer device 10000 and the external terminal, and the like. The network may be a wireless or wired network such as an Intranet (Intranet), the Internet (Internet), a global system for mobile communications (Global System of Mobile communication, abbreviated as GSM), wideband code division multiple access (Wideband Code Division Multiple Access, abbreviated as WCDMA), a 4G network, a 5G network, bluetooth (Bluetooth), wi-Fi, etc.

It should be noted that fig. 5 only shows a computer device having components 10010-10030, but it should be understood that not all of the illustrated components are required to be implemented, and more or fewer components may be implemented instead.

In this embodiment, the implementation method of the Electron-based application program stored in the memory 10010 may also be divided into one or more program modules and executed by one or more processors (the processor 10020 in this embodiment) to complete the embodiments of the present application.

Example five

The present application also provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the implementation method of the Electron-based application in the embodiments.

In this embodiment, the computer-readable storage medium includes a flash memory, a hard disk, a multimedia card, a card memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, and the like. In some embodiments, the computer readable storage medium may be an internal storage unit of a computer device, such as a hard disk or a memory of the computer device. In other embodiments, the computer readable storage medium may also be an external storage device of a computer device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash Card (Flash Card), etc. that are provided on the computer device. Of course, the computer-readable storage medium may also include both internal storage units of a computer device and external storage devices. In this embodiment, the computer readable storage medium is typically used to store an operating system installed on a computer device and various types of application software, such as program codes of implementation methods of the Electron-based application program in the embodiment. Furthermore, the computer-readable storage medium may also be used to temporarily store various types of data that have been output or are to be output.

It will be apparent to those skilled in the art that the modules or steps of the embodiments of the application described above may be implemented in a general purpose computing device, they may be concentrated on a single computing device, or distributed across a network of computing devices, they may alternatively be implemented in program code executable by computing devices, so that they may be stored in a storage device for execution by computing devices, and in some cases, the steps shown or described may be performed in a different order than what is shown or described, or they may be separately fabricated into individual integrated circuit modules, or multiple modules or steps of them may be fabricated into a single integrated circuit module. Thus, embodiments of the present application are not limited to any specific combination of hardware and software.

It should be noted that the foregoing is only a preferred embodiment of the present application, and is not intended to limit the scope of the patent protection of the present application, and all equivalent structures or equivalent processes using the descriptions and the contents of the present application or direct or indirect application to other related technical fields are included in the scope of the patent protection of the present application.

Claims

1. A method for implementing an Electron-based application program, the method comprising:

2. The method of claim 1, wherein the underlying service comprises:

3. The system of claim 1, wherein the rendering layer comprises a local page and an embedded page;

4. A method according to any one of claims 1 to 3, wherein the development framework of the application program comprises a root directory, and a first package. Json file and an installation package configuration file located under the root directory; the method further comprises the steps of:

5. The method of claim 4, wherein the installation packages comprise a full installation package and a delta installation package; the method further comprises the steps of:

6. The method of claim 4, wherein the target installation comprises a delta installation package; the method further comprises the steps of:

7. An apparatus for implementing an Electron-based application program, the apparatus comprising:

8. A computer device, comprising:

at least one processor; and

A memory communicatively coupled to the at least one processor; wherein:

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.

9. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein computer instructions which, when executed by a processor, implement the method of any of claims 1-6.

10. An Electron-based application implementation system, the system comprising:

11. The system of claim 10, wherein the implementation system comprises:

a root directory;

an APP catalog located under the root catalog;

the first package json file is positioned under the root directory;

12. The system of claim 10, wherein in the case of incremental updates, the implementation system comprises: