Electron two-way communication method and electronic equipment

Abstract

The invention provides an Electron two-way communication method and electronic equipment, relates to the technical field of computers, and is used for solving the problems of large code writing amount, low development efficiency, difficulty in subsequent development and maintenance and the like. The method is applied to the electronic equipment, a desktop application program of the electronic equipment is constructed by an Electron framework, and the Electron framework comprises a host process and a rendering process; the method comprises the steps that a rendering process calls a target application programming interface API provided by an Electron framework and sends a call request to a host process, and the call request comprises a target method index; wherein a plurality of first method indexes are packaged in the target API, different first method indexes are used for matching and calling methods registered in the host process, and the plurality of first method indexes comprise a target method index; and the host process calls a target method corresponding to the target method index in response to the call request.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and electronic device for bidirectional Electron communication. Background Technology

[0002] Electron, as an optional technology stack for front-end development of cross-platform desktop applications, is currently used in building cross-platform applications. Electron has extensive community support and a large number of plugins, such as... Figure 1 As shown, Electron consists of Chromium, Node.js, and a native API. Chromium and Node.js use inter-process communication (IPC) to build feature-rich desktop applications. Within the Electron framework, there can be a main process and one or more renderer processes. The main process can be created by starting a local web server (HTTP server) using Node.js; that is, an HTTP server started using Node.js can serve as the main process. When creating the main process using Node.js, the native API can be used to obtain the configuration information needed for its creation. The renderer processes can be implemented using Chromium.

[0003] The main process and the rendering process are different processes with isolated contexts, meaning they exist in two independent contexts and can communicate via IPC. For example, user interactions such as dragging and dropping native files through a graphical user interface (GUI) and accessing devices (e.g., serial devices like Bluetooth and USB) via the GUI can be achieved through IPC.

[0004] When users want to achieve the aforementioned interactive behaviors, they typically use a bidirectional communication method between the rendering process and the main process via the GUI. This means the GUI accesses methods in the main process through the rendering process to achieve the corresponding functionality. In Electron, because the main process and the rendering process communicate via IPC, methods defined in the main process cannot be directly accessed in the rendering process. This is because the main process and the rendering process run in different contexts. Therefore, to access methods defined in the main process from within the rendering process, different interfaces need to be registered to communicate with Node.js and the Native API. The more methods the rendering process accesses from the main process, the more interfaces need to be registered, leading to a large amount of code, low development efficiency, and consequently, difficulty in subsequent development and maintenance. Summary of the Invention

[0005] This application provides a method and electronic device for bidirectional Electron communication, which solves problems such as large amount of code writing, low development efficiency, and difficulty in subsequent development and maintenance.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0007] Firstly, a method for bidirectional communication using Electron is provided. This method is applied to electronic devices where the desktop application is built using the Electron framework, which includes a main process and a rendering process. The method includes:

[0008] The rendering process calls the target application programming interface (API) provided by the Electron framework, sending a call request to the main process. The call request includes the target method index. The target API encapsulates multiple first method indices, and different first method indices are used to match and call methods registered in the main process. These multiple first method indices include the target method index.

[0009] The main process responds to the call request by invoking the target method corresponding to the target method index.

[0010] Based on the first aspect, the Electron framework in this application only provides a target API, and this target API encapsulates multiple first method indices. Therefore, different first method indices can be used to match and call methods registered in the main process, without needing to register multiple interfaces and use multiple interfaces to match and call methods registered in the main process. Therefore, compared with related technologies that register multiple interfaces, the solution of this application can effectively solve the problems of large amount of code writing, low development efficiency, and difficulty in subsequent development and maintenance.

[0011] In one possible implementation of the first aspect, before the rendering process calls the target API provided by the Electron framework and sends a call request to the main process, the method further includes: the main process registering a listening method, which is used to listen for the call requests from the rendering process.

[0012] In this implementation, the listener method registered by the main process can be used to listen for call requests sent by the rendering process to the target API. Since the target method index included in the call request can be used to match the target method registered in the main process, it is not necessary to register a listener method for each method in the main process. This reduces the amount of code writing, improves development efficiency, and facilitates subsequent development and maintenance.

[0013] In one possible implementation of the first aspect, the main process responds to the call request by invoking the target method corresponding to the target method index. This includes: after the main process detects the call request using a listening method, the main process responds to the call request by invoking the target method corresponding to the target method index. Thus, by invoking the target method corresponding to the target method index immediately after detecting the call request through the listening method, the reliability of communication between the main process and the rendering process can be improved.

[0014] In one possible implementation of the first aspect, the listening method includes multiple second method indices, which correspond to multiple first method indices. Specifically, after the main process detects a call request using the listener, the main process responds to the call request by invoking the target method corresponding to the target method index. This includes: after the main process detects a call request using the listener, if the target method index matches any of the multiple second method indices, the main process responds to the call request by invoking the target method corresponding to the target method index.

[0015] In this implementation, by configuring multiple second method indices in the listening method, when the target method index included in the call request sent by the rendering process to the main process matches the second method index, the main process calls the target method corresponding to the target method index, thereby improving the reliability of communication between the main process and the rendering process.

[0016] In one possible implementation of the first aspect, the main process responds to the call request by invoking the target method corresponding to the target method index, including: the main process responding to the call request by obtaining the target method index included in the call request; the main process verifying whether the target method index exists; if the target method index exists, the main process invoking the target method corresponding to the target method index. This improves the reliability of communication between the main process and the rendering process.

[0017] In one possible implementation of the first aspect, the method further includes: if the target method index does not exist, the main process throws an exception object to the rendering process; the exception object is used to indicate that the main process has not executed the method corresponding to the target method index.

[0018] In this implementation, if the target method index does not exist in the main process, the main process throws an exception object to the rendering process to prevent the program from crashing.

[0019] In one possible implementation of the first aspect, the main process verifies whether the target method index exists by: the main process querying the target method index in the stored registration information to verify whether the target method index exists; wherein, the registration information records the correspondence between the first method index and the method.

[0020] If a target method index exists, the main process calls the target method corresponding to the target method index, including: if a target method index exists, the main process calls the target method corresponding to the target method index from the registration information.

[0021] In one possible implementation of the first aspect, the target method index includes an address identifier and a type identifier; wherein the address identifier is used to indicate the address of the method registered by the main process, and the type identifier is used to indicate the type of operation performed by the main process on the target method.

[0022] In this implementation, the target method index is encapsulated in the target API. The target method index includes an address identifier and a type identifier. That is, the target method index can simultaneously indicate the address of the method registered by the main process and the type of operation performed by the main process on the target method, thereby reducing the amount of code to write.

[0023] In one possible implementation of the first aspect, the target method index further includes a path identifier, which indicates the path of the target controller where the target method is located, and the target controller controls the desktop functions of the controls corresponding to the target controller in the user interface of the desktop application.

[0024] In this implementation, since the target method index also includes a path identifier, the path of the target controller where the target method is located can be quickly queried through the path identifier, thus improving communication efficiency.

[0025] In one possible implementation of the first aspect, the Electron framework also includes preloading; the method further includes: preloading exposes calling methods through a preloading script, the calling methods being used to provide the rendering process with the ability to call the target API.

[0026] In this implementation, preloading exposes the calling methods through the preloading script, which can provide the rendering process with the ability to call the target API. That is, it only exposes the ability to call the target API, thereby further reducing the amount of code to write, improving development efficiency, and thus reducing the difficulty of subsequent development and maintenance.

[0027] In one possible implementation of the first aspect, the method further includes: the main process using the target method to obtain target data; the main process processing the target data and sending a callback processing result to the rendering process; and the rendering process rendering the user interface of the desktop application based on the processing result.

[0028] In a second aspect, an electronic device is provided, which has the functions described in any one of the first aspects above. These functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned functions.

[0029] Thirdly, an electronic device is provided, comprising: a memory and one or more processors, and a camera; the memory stores computer program code, the computer program code including computer instructions; when the computer instructions are executed by the processor, the electronic device performs the method described in the first aspect or any one of the first aspects.

[0030] Fourthly, a chip system is provided, the chip system comprising: at least one processor and an interface for receiving instructions and transmitting them to the at least one processor; the at least one processor executes instructions to cause an electronic device to perform the method described in any one of the first aspects.

[0031] Fifthly, a computer-readable storage medium is provided that stores instructions which, when executed on a computer, cause the computer to perform the method described in any one of the first aspects.

[0032] In a sixth aspect, a computer program product containing instructions is provided, which, when run on a computer, enables the computer to perform the method described in any one of the first aspects above.

[0033] The technical effects of any of the implementation methods in aspects two through six can be referenced from the technical effects of different implementation methods in aspect one, and will not be elaborated here. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of the structure of an Electron framework provided in an embodiment of this application;

[0035] Figure 2 A schematic diagram of the interface of a theme tool APP provided in an embodiment of this application;

[0036] Figure 3 A schematic diagram of the system architecture of a theme tool APP provided in this application embodiment;

[0037] Figure 4 A schematic diagram of bidirectional communication in an Electron framework provided as an embodiment of this application;

[0038] Figure 5 A schematic diagram illustrating a process for registering N interfaces, provided as an embodiment of this application;

[0039] Figure 6 A flowchart illustrating accessing N methods is provided for an embodiment of this application;

[0040] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0041] Figure 8 A schematic diagram illustrating communication between a rendering process and a native API, provided as an embodiment of this application;

[0042] Figure 9 This application provides a schematic flowchart of a method for bidirectional Electron communication.

[0043] Figure 10 A schematic flowchart of another method for bidirectional Electron communication provided in this application embodiment;

[0044] Figure 11 A flowchart illustrating a method for a rendering process to call a main process, provided in an embodiment of this application;

[0045] Figure 12 A schematic diagram illustrating mounting a first method index on a method registered in the main process, as provided in an embodiment of this application;

[0046] Figure 13 A flowchart illustrating the correspondence between a first method index and a method, provided for an embodiment of this application;

[0047] Figure 14 This is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0048] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to be a limitation of this application. As used in the specification and appended claims of this application, the singular expressions "a," "the," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, "at least one" and "one or more" refer to one or more (including two). The term "and / or" is used to describe the relationship between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0049] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The term "connection" includes direct connections and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0050] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being preferred or superior to other embodiments or designs. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0051] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the relevant scenarios involved in the embodiments of this application will be described below with reference to the accompanying drawings.

[0052] In this embodiment, a theme tool application (APP) can be built using the Electron framework. This theme tool APP provides users with the ability to create personalized themes, such as desktop, icon, lock screen, and always-on screen themes. The theme tool APP built with Electron can be launched on different operating systems, allowing users of different operating systems to access and use the theme tool APP through a browser to create personalized themes, thus providing convenience for users.

[0053] Figure 2 This is a schematic diagram of the interface of a theme tool APP provided in an embodiment of this application. For example, as shown... Figure 2 As shown in (a), after the user opens the theme tool app, interface 101 is displayed. Interface 101 includes multiple theme templates 102, which can be themes created by the user using the theme tool app; or, they can be templates pre-provided by the theme tool app, which the user can modify to create new themes. Optionally, interface 101 also includes a new creation control 103, an import control 104, a language switching control 105, and a search box 106. The new creation control 103 instructs the user to create a new theme template, the import control 104 instructs the user to import a theme template (or image, text, etc.), and the language switching control 105 can be used to switch between multiple languages. The search box 106 allows the user to input relevant information and search for corresponding theme templates based on the user's input. Optionally, such as... Figure 2 As shown in (a), the search box 106 also includes prompts to guide the user in searching for relevant topic templates. For example, the search information could be: Please enter the title, version, etc. to search.

[0054] Optionally, in response to user actions on the newly created control 103 (such as click, touch, or swipe actions; the following example uses a click action), such as... Figure 2As shown in (b) of the diagram, interface 107 is displayed. Interface 107 includes a workspace (or preview area) used to display newly created theme templates. The workspace is the main area for theme editing. Users can input text, insert icons, tables, and other elements in the workspace to perform various formatting and layout operations, thereby editing the theme template. Optionally, interface 107 also includes a toolbar 108 and a function bar 109. Users can use some controls in the toolbar 108 and function bar 109 to edit the preview template displayed in the workspace. The toolbar 108 contains a series of icons and command buttons for performing common theme editing and formatting tasks. The toolbar 108 can be customized according to user needs; for example, it can include functions such as creating, opening, importing, exporting, and generating preview images. The function bar 109 includes multiple categories, such as lock screen, wallpaper, desktop, SMS, control center, always-on display, and global. Each category corresponds to a series of commands related to that category, providing users with options for more detailed control over theme editing.

[0055] In other words, when users access and use the theme tool app through a browser, they can... Figure 2 The interface of the theme tool app shown allows users to create personalized themes. After creation, users can export the theme as a compressed resource package, which can then be used within the theme tool app. In summary, using the aforementioned theme tool app provides users with multiple theme design functions, allowing them to easily create personalized themes without coding, simplifying the theme design process and improving work efficiency.

[0056] Furthermore, since the theme utility app is built on the Electron framework, a cross-platform framework, its use allows for the creation and encapsulation of modular packages tailored to the theme utility scenario. This enables unified data management and real-time synchronization, achieving a ready-to-use effect. Whether developers use this framework for secondary development or users directly design themes, it effectively reduces development costs and improves user efficiency. Moreover, the theme utility system framework built using Electron allows for the development of applications across multiple platforms with a single codebase, significantly reducing development costs and increasing efficiency compared to native frameworks lacking cross-platform capabilities.

[0057] The following section, with reference to the accompanying diagrams in the manual, describes the system framework and interaction flow of the theme tool app built on the Electron framework.

[0058] Figure 3 This is a system architecture diagram of a topic tool APP provided in an embodiment of this application. For example... Figure 3 As shown, this system architecture can include a main process and a rendering process. The main process provides almost all system services to the application. The rendering process is mainly responsible for building and displaying the user interface and handling user interaction logic.

[0059] For example, such as Figure 3 As shown, the rendering process is responsible for building and displaying the user interface of the theme tool app. For example, the rendering process is responsible for building and displaying the toolbar of the theme tool app (such as...). Figure 2 The toolbar 108 shown in (b) and the function bar (such as...) Figure 2 The toolbar (b) shows the function bar 109. The toolbar may include controls such as New, Language Switch, Open, Generate Preview, Import, Redo, Export, Undo, Home, and others. The function bar may include controls such as Preview, Message, Lock Screen, Control Center, Icons, Always-on Display (AOD), Desktop, Global, Phone, and others. Optionally, the rendering process is also responsible for building and displaying the preview area and property panel of the theme tool app. The preview area can be used to display the theme, and the property panel includes properties for editing the theme. After editing the theme on the property panel, the edited theme can be displayed in the preview area. The properties displayed on the property panel vary depending on the content of the theme; this embodiment does not limit this.

[0060] Optional, such as Figure 3 As shown, the main process can provide various system services to the application (i.e., the theme tool APP), such as framework initialization service, window management service, upgrade management service, configuration information service, file processing service, communication monitoring service, exception handling service, resource management service, tray management service, and Node Native services. These system services can reside in the main process as threads, and they can achieve bidirectional IPC communication with the rendering process. For example, the rendering process of the theme tool APP can communicate with the file processing service during operation, thereby calling the relevant application programming interface (API) provided by the file processing service to provide corresponding file processing services in the theme tool APP.

[0061] APIs are predefined functions designed to provide applications and developers with the ability to access a set of routines based on certain software or hardware, without needing to access the source code.

[0062] It should be noted that the rendering process and the main process can be the front-end framework of the theme tool app, used to create the programs and resources that run the user interface of the theme tool app. Optional, such as Figure 3As shown, the system architecture of the theme tool APP also includes a backend framework, which can also be called a server-side framework or server-side framework. It is used to create the server-side programs and resources of a complete and runnable theme tool APP, that is, programs and resources that run on the server and do not involve the user interface.

[0063] Optional, such as Figure 3 As shown, the system architecture of the theme utility app also includes local logs. Local logs are primarily used to record the app's operational status, including errors, warnings, and other important information. By recording this information, developers can review the logs to diagnose problems when the application crashes or encounters issues.

[0064] In this embodiment, since the theme tool app is built using the Electron framework, the main process and rendering process within the theme tool app can communicate via IPC. For example, combined with... Figure 3 The system architecture shown is for reference. Figure 4 This section describes the communication process between the main process and the rendering process.

[0065] For example, such as Figure 4 As shown, the Electron framework of the theme tool app includes a main process and a rendering process. The main process creates and manages the theme tool app's window, manages the window's lifecycle, and operates native APIs to process data. The rendering process is the user interface part of the theme tool app; it runs on the Chromium kernel and can load and render HTML, CSS, and JavaScript. In this embodiment, the theme tool app built with Electron can be packaged as an application for Mac, Windows, and Linux systems, thereby meeting the startup, display, and system configuration requirements of different operating systems and achieving better visual performance and interactive experience.

[0066] It should be noted that an application consists of a main process and can have multiple rendering processes. Figure 4 Let's take a theme tool app, which includes a rendering process, as an example.

[0067] In the Electron framework, because the main process and the rendering process are different processes running in different contexts, methods registered and defined in the main process cannot be directly accessed (or called) by the rendering process. Therefore, to enable the rendering process to access methods registered and defined in the main process, IPC communication needs to be established between the rendering process and the main process; that is, the rendering process and the main process communicate via IPC. It should be noted that a method registered and defined in the main process refers to a block of code used to perform a specific task or operation, also known as a function or subroutine. These methods play a crucial role in programming languages ​​and are the smallest unit of execution in a program. In this embodiment, the task or operation corresponding to the method may include creating a file, deleting a file, renaming a file, etc.

[0068] For example, such as Figure 4 As shown, the communication process between the rendering process and the main process includes: the rendering process sending a call event to the main process via IPC to invoke a method defined by the main process. Upon receiving the call event, the main process invokes the method defined by itself, retrieves data from the method, and processes it. Then, the main process sends a callback of the processing result back to the rendering process via IPC. Based on the processing result, the rendering process renders the user interface of the theme tool app.

[0069] For example, combining Figure 2 As shown, when a user clicks on the newly created control 103 in interface 101, in response to the user's click on the newly created control 103, the rendering process sends a call event to the main process via IPC to invoke a method defined by the main process (such as the method corresponding to the newly created control 103). After receiving the call event from the rendering process, the main process invokes the method defined by the main process, retrieves data from the method, and processes it. Then, the main process sends a callback of the processing result to the rendering process via IPC. Based on the processing result, the rendering process renders the user interface of the theme tool APP. For example, after the rendering process renders the user interface of the theme tool APP, the aforementioned interface 107 is displayed.

[0070] It's important to note that the number of methods defined in the main process is related to the number of controls (or buttons) included in the desktop application. One control corresponds to one or more methods. For example, as mentioned above... Figure 2The newly created control 103 shown may correspond to one or more methods defined in the main process, each method corresponding to a function. When the rendering process sends a call event to the main process via IPC, it communicates through the API provided by the Electron framework. For example, the rendering process calls an interface (i.e., API) provided by the Electron framework to send a call event to the main process to access a method in the main process. Typically, one interface corresponds to one method, meaning one interface is used to instruct the rendering process to access a method in the main process. If the rendering process wants to access different methods in the main process, it needs to call different interface implementations provided by the Electron framework. For example, the rendering process can access method 1 defined in the main process by calling interface 1 provided by the Electron framework; the rendering process can access method 2 defined in the main process by calling interface 2 provided by the Electron framework; ...; the rendering process can access method N defined in the main process by calling interface N provided by the Electron framework.

[0071] In other words, if the main process defines N methods, it needs to register N interfaces to allow the rendering process to access those N methods. This results in a large amount of code being written by developers, low development efficiency, and consequently, difficulty in subsequent development and maintenance.

[0072] For example, the rendering process accesses methods defined in the main process typically using bidirectional communication. For instance, accessing methods defined in the main process usually involves the following steps:

[0073] Step a: Define the method in the main process.

[0074] Step b: The main process listens for the rendering process's call events.

[0075] Step c: Preload the interface corresponding to the exposed method through the preload script.

[0076] Step d: The rendering process calls the corresponding interface to access the method defined in the main process.

[0077] Therefore, when developers want to enable the rendering process to access methods in the main process, they need to write multiple files. For example, defining the method requires one file, listening for rendering process call events requires another file, exposing the corresponding interface requires another file, and calling the corresponding interface to access the method defined in the main process requires yet another file. In other words, to enable the rendering process to access methods in the main process, developers need to write multiple files layer by layer, resulting in a large amount of code and low developer efficiency. Furthermore, the larger the amount of code, the more difficult the subsequent development and maintenance work becomes.

[0078] Taking the registration of N interfaces for the rendering process to access N methods in the main process as an example, for instance, as follows: Figure 5 As shown, for registration interface 1, the function of creating files is executed. For example, in response to the developer's code writing operation, file 1 (e.g., makeNewFile) is created, and file 1 is used to define method 1. In response to the developer's code writing operation, file 2 is created (e.g., ipcMin.handle{“file.makeNewFile”,func}), and file 2 is used to listen for the rendering process's call to interface 1 corresponding to method 1. The Electron framework creates file 3 (e.g., contextBridge.exposeinMainWorld{“fileAPI,{makeNewFile:func}}), and file 3 is used to expose the API corresponding to method 1. In response to the developer's code writing operation, file 4 is created (e.g., export const FileAPI={makeNewFile:window.FileAPImakeNewFile}), and file 4 is used by the rendering process to call interface 1 to access method 1 defined in the main process. Optionally, in the case of TypeScript (TS), in response to the developer's code writing operation, file 5 is created to define the type of method 1.

[0079] For registered interface 2, the function to delete files is executed. For example, in response to a developer's code, file 1 (e.g., `delete`) is created, and file 1 defines method 2. In response to a developer's code, file 2 is created (e.g., `ipcMin.handle{"file.delete", func}`), and file 2 listens for calls to interface 2 corresponding to method 2 from the rendering process. The Electron framework creates file 3 (e.g., `contextBridge.exposeinMainWorld{"fileAPI,{delete:func}}`), and file 3 exposes the API corresponding to method 2. In response to a developer's code, file 4 is created (e.g., `export const FileAPI={delete:window.FileAPI delete}`), and file 4 is used by the rendering process to call interface 2 to access method 2 defined in the main process. Optionally, in the TypeScript case, in response to a developer's code, file 5 is created to define the type of method 2.

[0080] For the registered interface N, a renaming function is performed. For example, in response to developer code, file 1 (e.g., `remove`) is created, defining method N. File 2 (e.g., `ipcMin.handle{"file.remove", func}`) is created, listening for calls to the interface N corresponding to method N from the rendering process. The Electron framework creates file 3 (e.g., `contextBridge.exposeinMainWorld{"fileAPI,{remove:func}}`), exposing the API corresponding to method N. File 4 (e.g., `export const FileAPI={remove:window.FileAPI remove}`) is created, allowing the rendering process to access method N defined in the main process via interface N. Optionally, in the TypeScript case, file 5 is created in response to developer code, defining the type of method N.

[0081] As can be seen, to enable the rendering process to access N methods in the main process, N interfaces need to be registered and multiple files need to be created, resulting in a large amount of code to be written by developers and low development efficiency.

[0082] Based on this, this application provides a method for bidirectional communication in Electron. This method registers a single interface (API) and encapsulates multiple method indexes within that interface. Different method indexes are used to match and call methods registered in the main process, thus enabling the rendering process to access methods registered in the main process through only a single interface. Compared to registering multiple interfaces, this solution simplifies the amount of code developers need to write and improves development efficiency.

[0083] Taking the rendering process accessing N methods in the main process as an example, for instance, such as... Figure 6As shown, in response to the developer's code writing operation, file 1 is created. File 1 is used to define method 1 (performing the function of creating a file), method 2 (performing the function of deleting a file), ..., method N (performing the function of renaming). File 1 is also used to encapsulate methods 1 to method N in the same interface (hereinafter referred to as the target API). This target API also encapsulates multiple method indices, which correspond to N methods. In response to the developer's code writing operation, file 2 is created (e.g., ipcMin.handle{“carrera.ipc.Request”,func}). File 2 is used to listen for calls from the rendering process to the target API corresponding to the method in the main process. The Electron framework creates file 3 (e.g., conteBridge.exposeInMainWorld{CarrerAPI.{ipc.Request,func}}). File 3 is used to expose the target API corresponding to the method. In response to the developer's code writing operation, file 4 is created (e.g., export const CarrerAPI=ipc.Request:window.CarrerAPI.ipc.Request). File 4 is used by the rendering process to call the target API to access the method defined in the main process. Optionally, in the case of TypeScript (TS), in response to the developer's code writing action, file 5 is created to define the types of methods 1 through N.

[0084] In summary, in conventional solutions, to achieve bidirectional communication between the rendering process and the main process, the main process defines N methods, and each of steps a to d requires the creation of N files. However, the solution provided in this application, regardless of the number of methods defined by the main process, only requires the creation of one file per step a to d to achieve bidirectional communication between the rendering process and the main process. This simplifies the amount of code developers need to write and improves development efficiency.

[0085] The technical solutions provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0086] For example, the Electron bidirectional communication method provided in this application embodiment can be applied to personal computers (PCs) with operating systems such as Windows, MAC, and Linux. For instance, this method can be applied to electronic devices such as laptops, desktop computers, and ultra-mobile personal computers (UMPCs), and this application embodiment does not impose any limitations on this. Optionally, the method can also be applied to a server, which can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, etc., without limitation.

[0087] For example, Figure 7 A schematic diagram of the structure of the electronic device 100 is shown.

[0088] Electronic device 100 may include processor 110, external memory interface 120, internal memory 121, universal serial bus (USB) interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 171, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, positioning module 181, button 190, motor 191, indicator 192, camera 193, display screen 194, and subscriber identification module (SIM) card interface 195, etc.

[0089] Processor 110 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program according to the present application. In a specific implementation, as one embodiment, processor 110 may also include multiple CPUs, and processor 110 may be a single-core processor or a multi-core processor. Here, processor may refer to one or more devices, circuits, or processing cores used to process data (e.g., computer program instructions).

[0090] Processor 110 may include one or more processing units, such as application processors (APs), graphics processing units (GPUs), image signal processors (ISPs), controllers, memory, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0091] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0092] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0093] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0094] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0095] Antennas 1 and 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In other embodiments, the antennas can be used in conjunction with tuning switches.

[0096] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0097] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0098] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0099] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0100] Electronic device 100 implements display functions through a GPU, a display screen, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU performs mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0101] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Mini-LED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc.

[0102] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0103] The methods described in the following embodiments can all be implemented in the electronic device 100 having the above-described hardware structure.

[0104] It should be noted that, in this embodiment of the application, the desktop application of the electronic device (such as the theme tool APP mentioned above) is built using the Electron framework, which includes a main process and a rendering process. The Electron framework provides a target API, which encapsulates multiple method indexes (hereinafter referred to as first method indexes). Different first method indexes are used to match and call methods registered in the main process. For example, as shown... Figure 8As shown in this embodiment, communication between the rendering process and native APIs (such as Node API and Native API) can be achieved through the target API provided by the Electron framework. Since the target API encapsulates multiple first method indices, different methods registered in the main process can be matched and called through these first method indices. Therefore, bidirectional communication between the rendering process and the main process can be achieved by registering only a single interface (i.e., the target API), reducing interface registration, thereby simplifying the amount of code developers need to write, improving development efficiency, and reducing maintenance costs.

[0105] For example, such as Figure 9 As shown, the method may include the following steps:

[0106] Step 201: The rendering process calls the target API and sends a call request to the main process, including the target method index.

[0107] The target method index is any one of the multiple first method indices, meaning that the multiple first method indices include the target method index.

[0108] It should be noted that the user interface of a desktop application includes multiple controls, and users can achieve different functions of the desktop application by manipulating different controls. Each of these controls corresponds to one or more method indices. For example, combining... Figure 2 As shown, the theme tool app includes a newly created control 103. In response to the user's click on the newly created control 103, the rendering process calls the target API and sends a call request to the main process. The target method index included in this call request is the method index corresponding to the newly created control 103.

[0109] Optionally, when creating the rendering process, the electronic device can configure corresponding configuration information for each control, which may include method indexes. Of course, this configuration information may also include other information, without limitation.

[0110] Optionally, the target method index may include an address identifier and a type identifier; wherein the address identifier indicates the address of the method registered by the main process, and the type identifier indicates the type of operation performed by the main process on the target method. For example, the address identifier may be a Uniform Resource Identifier (URL), and the type identifier may be represented as a method. The URL is a string used to identify the name of an Internet resource, allowing users to interact with any resource through a specific protocol.

[0111] In this embodiment, since the target method index includes a URL and a method, the URL is used to indicate the address of the method registered by the main process, and the method is used to indicate the type of operation performed by the main process on the target method. Therefore, the target method defined in the main process can be uniquely matched by the URL and the method, and the operation type of the target method executed by the main process can be indicated. This reduces the code duplication rate and improves the reliability of Electron bidirectional communication.

[0112] Optionally, the call request sent by the rendering process to the main process can include other information besides the target method index. For example, it can include data passed from the rendering process to the main process, as well as URL parameters, thereby enabling Electron's bidirectional communication to have more powerful communication capabilities and be compatible with more application scenarios.

[0113] For example, the rendering process can send a call request to the main process using the following pseudocode example:

[0114]

[0115]

[0116] For example, in the code example corresponding to the above call request, the meaning and type of different fields can be shown in Table 1.

[0117] Table 1

[0118] field name Field meaning Field type url Interface path String method Request type post|get|delete|put data Request data Object|String params URL parameters Object|String

[0119] It should be noted that the pseudocode and some fields in the code shown above are merely examples and do not constitute a limitation on this application.

[0120] Optionally, the target method index also includes a path identifier, which indicates the path of the target controller where the target method resides. The target controller controls the desktop functionality of the controls corresponding to the target controller in the theme utility app's user interface. It's worth noting that Electron contains multiple controllers, each corresponding to a control in the desktop application's user interface, used to control the native desktop functionality of the desktop application (such as the theme utility app). For example, combined with... Figure 2 As shown, multiple controllers can be used to control native desktop functions such as creating, opening, importing, and exporting in toolbar 108.

[0121] In this embodiment, multiple methods defined by the main process can be grouped together according to the function of each control in the user interface, with methods corresponding to the same function of the same control clustered in the controller corresponding to that control. For example, the "New" control in toolbar 108 may include new, delete, and rename functions. Therefore, all methods registered by the main process to execute the functions included in the "New" control can be clustered in the controller corresponding to the "New" control. Subsequently, the path of the controller where the method is located can be quickly found through the path identifier included in the target method index, thereby enabling the method to be called quickly.

[0122] Step 202: The main process responds to the call request by calling the target method corresponding to the target method index.

[0123] For example, after parsing the rendering process's call request, the main process can obtain the rendering process's request content, and thus call the target method corresponding to the target method index to execute the corresponding command. For instance, calling the target method corresponding to the target method index can perform a file creation operation.

[0124] In step 201, for example, the target method index may include an address identifier (such as a URL), a type identifier (method), and a path identifier (such as a path). Based on this, after the main process parses the call request, the request content of the rendering process can be represented as: window.XXX / YYY. Here, XXX can be used to indicate the path identifier (e.g., it can be represented as path), and YYY can be used to identify the address identifier and the type identifier (e.g., it can be represented as URL+method).

[0125] Optionally, after the main process calls the target method corresponding to the target method index, such as... Figure 9 As shown, the method also includes the following steps:

[0126] Step 203: The main process uses the target method to obtain the target data.

[0127] Step 204: The main process processes the target data and sends the processing result back to the rendering process.

[0128] For example, after the main process completes its operation, it can send the execution result information, such as success or failure, to the rendering process via inter-process communication. Upon receiving the execution result information from the main process, the rendering process can determine whether the current request was successful and decide on the next step. For instance, it can execute step 205.

[0129] Step 205: The rendering process renders the user interface of the desktop application based on the processing results.

[0130] For example, in conjunction with the above Figure 2 As shown, assuming the user clicks the new control 103 in interface 101, the rendering process sends a call request to the main process, instructing the main process to create a new file. After the main process completes the file creation operation, it sends a callback result to the rendering process, indicating that the current request was executed successfully. Then, the rendering process renders the application's user interface, displaying the aforementioned interface 107.

[0131] In summary, using the scheme of this application embodiment, the rendering process sends a call request to the main process by calling the target API; the main process can call the target method corresponding to the target method index included in the call request. Since the target API encapsulates multiple first method indices, and different first method indices are used to match and call methods registered in the main process, the rendering process can send a call request to the main process by calling the same target API, and match and call methods registered in the main process based on the different method indices included in the call request. This reduces the need for interface registration, simplifies the amount of code written by developers, improves development efficiency, and reduces maintenance costs.

[0132] Optional, such as Figure 10 As shown, before the rendering process calls the target API provided by the Electron framework and sends a call request to the main process, the method also includes:

[0133] Step 2001: The main process registers a listener method, which is used to listen for call requests from the rendering process.

[0134] For example, the listener method registered by the main process can be represented as: `ipcMain.handle('carrera.ipcRequest', Function)`. Thus, in subsequent implementations, the main process can use the listener method (such as `ipcMain.handle`) to listen for call requests from the rendering process. After the main process detects a call request using the listener method, it responds to the call request by invoking the target method corresponding to the target method index.

[0135] For example, the main process can register a listener method using the following pseudocode example:

[0136]

[0137] Optionally, the listening methods registered by the main process include multiple second method indices, which correspond to multiple first method indices. The second method indices are used to match the target method index in the call request. For example, after the main process listens for a call request using the listening method, if the target method index matches any of the multiple second method indices, the main process responds to the call request by calling the target method corresponding to the target method index.

[0138] For example, in the code example corresponding to the above listening method, the meaning and type of different fields can be shown in Table 2 below.

[0139] Table 2

[0140] field name Field meaning Field type url The interface path corresponds to the call request. String method Request type, corresponding to the call request. post|get|delete|put handler Functions used to handle call requests. Function params URL parameters, used for GET requests String

[0141] It should be noted that the pseudocode and some fields in the code shown above are merely examples and do not constitute a limitation on this application.

[0142] In the above embodiments, the listening method registered by the main process can be used to listen for call requests sent by the rendering process to the target API. Since the target method index included in the call request can be used to match the target method registered in the main process, it is not necessary to register a listening method for each method in the main process, thereby reducing the amount of code writing, improving development efficiency, and facilitating subsequent development and maintenance.

[0143] Furthermore, by configuring multiple second method indices in the listener method, when the target method index included in the call request sent by the rendering process to the main process matches the second method index, the main process calls the target method corresponding to the target method index, thereby improving the reliability of Electron's bidirectional communication.

[0144] Optionally, the Electron framework also includes preloading, combined with... Figure 10 As shown, the method also includes:

[0145] Step 2002: Preloading exposes calling methods through the preloading script. These calling methods provide the rendering process with the ability to call the target API.

[0146] It's important to note that, typically, the rendering process doesn't have permission to access methods defined in the main process. Therefore, to enable bidirectional communication between the rendering process and the main process, methods can be exposed through preloading, allowing the rendering process to use these methods to communicate with the main process.

[0147] For example, in step 2002, the method to be invoked exposed by the preloaded script can be, for example, ipcRenderer.invoke. Therefore, the rendering process can use ipcRenderer.invoke to send an invocation request to the main process.

[0148] Optionally, the calling method includes the target API. That is, the preloading exposes the target API to the rendering process through the preloading script. Therefore, after the preloading exposes the calling method through the preloading script, the rendering process can use the calling method to call the target API and send a call request to the main process.

[0149] In this application, the name of the target API is not specifically limited, and the actual setting shall prevail. For example, the target API may be called "Carrera API", etc., without limitation.

[0150] For example, the pseudocode for exposing the calling method through the preloading script can be represented as follows:

[0151] contextBridge.exposeInMainWorld('Carrera API',ipcRequest:

[0152] ipcRenderer.invoke{'carrera.ipcRequest'})

[0153] It should be noted that steps 2001 and 2002 are executed before step 201 to provide a bidirectional communication channel between the rendering process and the main process. In this embodiment, the order of steps 2001 and 2002 is not limited and is subject to actual configuration. For example, step 2001 may be executed before step 2002, or after step 2002, or simultaneously with step 2002; there is no limitation.

[0154] Combining steps 201 to 205 above, in this embodiment, the target method index is used as the key, and these keys are mapped one-to-one with the methods defined in the main process. The existence of the key value can be determined; if it exists, the corresponding target method is called, the target data is obtained and processed, and the processing result is then sent back to the rendering process. (See reference...) Figure 11 This is a flowchart illustrating a method for a rendering process to call the main process, provided in an embodiment of this application. The following is a summary of the process. Figure 11 This section describes the general process by which the rendering process calls the main process.

[0155] For example, such as Figure 11As shown, the process includes: in response to the user opening the theme tool app, displaying the theme tool app's user interface. For example, displaying... Figure 2 Interface 101 is shown in (a) above. In response to a user's click on a control in interface 101, the rendering process calls the target API and sends a call request to the main process, the call request including the target method index.

[0156] Subsequently, the main process responds to the call request and obtains the target method index (including URL, method, path, etc.). The main process checks if the target method index exists. If it does, the main process calls the target method corresponding to the index. Then, the main process retrieves the target data from the target method and processes it. After processing the target data, the main process sends a callback of the processing result to the rendering process. Optionally, if the target method index does not exist, the main process throws an exception object to the rendering process, indicating that the method corresponding to the index was not executed. For example, this exception can be a built-in exception type or a custom exception type, etc., without limitation. Optionally, after the main process throws an exception object to the rendering process, the rendering process catches the exception object and handles the exception. The way the rendering process handles the exception can be designed according to specific needs, without limitation. For example, the rendering process can output error information, log, retry the operation (e.g., resend the call request to the main process), or terminate the program, etc., without limitation.

[0157] Optionally, the main process can query the target method index in the stored registration information to verify whether the target method index exists in the main process. The registration information records the correspondence between the first method index and the method.

[0158] Optional, such as Figure 11 As shown, if a target method index exists, the main process calls the target method corresponding to that index from the registration information. Subsequently, the main process retrieves the target data from the target method and processes it. After processing the target data, the main process sends a callback of the processing result to the rendering process.

[0159] In this embodiment, the main process can improve the reliability of communication between the main process and the rendering process by checking whether the target method index exists.

[0160] The stored registration information is obtained by defining methods in the main process and executing the routing mechanism. The following describes the method definition in the main process and the routing process, i.e., how the registration information is obtained.

[0161] It should be noted that in this embodiment, the desktop application (such as the theme tool APP mentioned above) is typically written in JavaScript (or TypeScript). The desktop application includes multiple class files, which can be run during the rendering process after the application starts. These multiple class files correspond to the multiple controllers mentioned above. In other words, after the desktop application starts, the corresponding class files can be run through the controllers to control the desktop functions of the application. For example, in conjunction with the above... Figure 2 As shown, the newly created control 103 corresponds to the target controller, and the target controller corresponds to the target class file. Therefore, the corresponding target class file can be run through the target controller, thereby controlling the creation function of the desktop application.

[0162] Furthermore, in this embodiment of the application, in order to achieve the above-mentioned technical solution of matching and calling methods in the main process through different first method indices, it is necessary to mount the first method index in the class file and the method. For example, a path identifier (such as path) is mounted in the class file, and an address identifier (such as URL) and a type identifier (such as method) are mounted in the method. Here, "mounting" refers to assigning values ​​to the class file and the method, and the assigned values ​​are the first method indexes.

[0163] For example, the first method index (which can also be understood as metadata) can be mounted in class files and methods using Reflect Metadata provided in ES7. For instance, the path can be mounted in the class file using the first modifier (such as @RequestMapping), and the URL and method can be mounted in the method using the second modifier (such as @Route).

[0164] refer to Figure 12 This is a schematic diagram illustrating the mounting of a first method index on a method registered in the main process, as provided in an embodiment of this application. For example, as shown... Figure 12 As shown, the target class file is set as the target using @RequestMapping, and RequestMapping:path is mounted as the key to the target. For example, the value of path mounted on the target class file is "test".

[0165] Correspondingly, the target method is set as the target using @Route, and the Route "url" is attached to the target as the key. For example, the value of the URL attached to the target method is "api / getData". Similarly, the Route "method" is attached to the target as the key. For example, the value of the method attached to the target method is "get".

[0166] For example, the first method index can be mounted in the target class file and the target method using the first and second modifiers, as shown in the following pseudocode example:

[0167] @RequestMapping( / test)

[0168] export class MyController{

[0169] @Route(' / api / getData','get')

[0170] async handleGetDATD(requestData:any){

[0171] console.log('handleGetData',requestData)

[0172] const result=await app.getPath('userData')

[0173] return result

[0174] }

[0175] }

[0176] It should be noted that the process of mounting the first method index in the class file and method described above is merely an example and does not constitute a limitation of this application. Of course, other methods can also be used to achieve mounting, which will not be elaborated upon here.

[0177] After mounting the first method index in the class file and methods, the registration information can be obtained through the route dispatch mechanism and stored in the main process. Optionally, the route dispatch mechanism can include: obtaining all registered controllers, iterating through each controller, obtaining the URLs and methods mounted on all methods corresponding to the controller, and obtaining data such as the path mounted on the class file corresponding to the controller, and combining them into a unique key. Then, the method corresponding to each key is obtained as the value, and the path, URL, and method are combined with the corresponding method to form a key-value pair, which is stored in the route Map to obtain the registration information.

[0178] For example, such as Figure 13 As shown, retrieve all controllers and iterate through each one. Taking iterating through the target controller as an example, for instance... Figure 13As shown, on the one hand, the metadata value mounted on the class file corresponding to the target controller is obtained (for example, getMetadata('request-mapping.path) and the obtained metadata value is used as path).

[0179] On the other hand, all methods corresponding to the target controller are retrieved (e.g., getOwnPropertyNamers). Each method is iterated through, and the metadata values ​​attached to each method are retrieved (e.g., getMetadata: 'route:url' and 'route:method'). The retrieved metadata values ​​are used as the URL and method. Correspondingly, the method value of each method is retrieved (e.g., func: controller[key].bind(controller)). Based on this, the path, URL, and method are combined to form a unique key (e.g., '&(method):&(path+url)'). Based on the above, the mapping between the target method index and the target method can be completed and stored in the route Map (e.g., Map[key] = func).

[0180] It should be noted that, Figure 13 This example uses the target controller to illustrate the mapping between target method indexes and target methods. It's understandable that this mapping can be implemented for all controllers. Figure 13 The process shown completes the one-to-one mapping between the first method index and the method, thereby obtaining the registration information. For details on the specific implementation process, please refer to the relevant descriptions above; they will not be repeated here.

[0181] It should be noted that the contents described in the various embodiments of this application can explain the technical solutions in other embodiments of this application. The technical features described in each embodiment can also be applied in other embodiments and combined with the technical features in other embodiments to form new solutions. This application only provides an exemplary list of several embodiments for illustration and does not mean that this application is limited thereto.

[0182] This application provides an electronic device, which can be the electronic device 100 described above. The electronic device may include a memory and one or more processors; the memory stores computer program code, which includes computer instructions. When the computer instructions are executed by the processor, the electronic device performs the various functions or steps performed by the main process and the rendering process described above. The structure of the electronic device can be referred to the above. Figure 7 The structure of the electronic device 100 shown.

[0183] This application also provides a chip system applied in the aforementioned electronic device, which can be the aforementioned electronic device 100. For example... Figure 14 As shown, the chip system 1100 includes at least one processor 1101 (e.g., an application processor AP and a Sensorhub) and at least one interface circuit 1102. The processor 1101 can be one described in the above embodiments. Figure 7 The processor 110 is shown. The interface circuit 1102 can be, for example, an interface circuit between the processor 110 and external memory; or an interface circuit between the processor 110 and internal memory 121.

[0184] The processor 1101 and interface circuit 1102 described above can be interconnected via lines. For example, interface circuit 1102 can be used to receive signals from other devices (e.g., the memory of electronic device 400). As another example, interface circuit 1102 can be used to send signals to other devices (e.g., processor 1101). Exemplarily, interface circuit 1102 can read instructions stored in memory and send those instructions to processor 1101. When the instructions are executed by processor 1101, the electronic device can perform various functions or steps performed by the main process and rendering process in the electronic device described above. Of course, the chip system may also include other discrete devices, and this application embodiment does not specifically limit this.

[0185] This application also provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform various functions or steps performed by the main process and rendering process in the above method embodiments.

[0186] This application also provides a computer program product that, when run on a computer, causes the computer to perform various functions or steps executed by the main process and rendering process in the above method embodiments.

[0187] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules according to the system, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0188] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0189] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0190] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit described above can be implemented in hardware or as a software functional unit.

[0191] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0192] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method of Electron bidirectional communication, characterized in that, The method is applied to an electronic device, a desktop application of the electronic device is built by an Electron framework, and the Electron framework includes a main process and a rendering process. The rendering process calls a target application programming interface (API) provided by the Electron framework, and sends a calling request to the main process, the calling request including a target method index; wherein the target API encapsulates a plurality of first method indexes, and different first method indexes are used to match the registered methods in the main process; the plurality of first method indexes include the target method index; The main process responds to the calling request and calls a target method corresponding to the target method index.

2. The method of claim 1, wherein, Before the rendering process calls the target API provided by the Electron framework and sends the calling request to the main process, the method further includes: The main process registers a listening method, and the listening method is used to listen to the calling request of the rendering process.

3. The method of claim 2, wherein, The main process responds to the calling request and calls a target method corresponding to the target method index, including: After the main process listens to the calling request using the listening method, the main process responds to the calling request and calls a target method corresponding to the target method index.

4. The method of claim 3, wherein, The listening method includes a plurality of second method indexes, and the plurality of second method indexes correspond to the plurality of first method indexes; After the main process listens to the calling request using the listening method, the main process responds to the calling request and calls a target method corresponding to the target method index, including: After the main process listens to the calling request using the listening method, if the target method index matches any second method index in the plurality of second method indexes, the main process responds to the calling request and calls a target method corresponding to the target method index.

5. The method according to any one of claims 1-4, characterized in that, The main process responds to the calling request and calls a target method corresponding to the target method index, including: The main process responds to the calling request and obtains the target method index included in the calling request; The main process checks whether the target method index exists; If the target method index exists, the main process calls a target method corresponding to the target method index.

6. The method of claim 5, wherein, The method further includes: If the target method index does not exist, the main process throws an exception object to the rendering process; the exception object is used to indicate that the main process does not execute the method corresponding to the target method index.

7. The method according to claim 5 or 6, characterized in that, The main process checks whether the target method index exists, including: The main process queries the target method index in the stored registration information and checks whether the target method index exists; wherein the registration information records the correspondence between the first method index and the method; If the target method index exists, the main process calls a target method corresponding to the target method index, including: If the target method index exists, the main process calls a target method corresponding to the target method index from the registration information.

8. The method of any one of claims 1-7, wherein, the target method index comprises an address identifier and a type identifier; the address identifier is used to indicate an address of a method registered by the main process, and the type identifier is used to indicate an operation type performed by the main process on the target method.

9. The method of claim 8, wherein, the target method index further comprises a path identifier, the path identifier being used to indicate a path of a target controller where the target method is located, the target controller being used to control a desktop function of a control corresponding to the target controller in a user interface of the desktop application.

10. The method according to any one of claims 1-9, characterized in that, The Electron framework further comprises preloading; and the method further comprises: the preloading exposes a calling method through a preloading script, the calling method being used to provide the rendering process with an ability to call the target API.

11. The method according to any one of claims 1-10, characterized in that, The method further comprises: the main process acquires target data using the target method; the main process processes the target data and calls back a processing result to the rendering process; the rendering process renders the user interface of the desktop application based on the processing result.

12. An electronic device, comprising: comprising: a memory and one or more processors; the memory stores computer program code, the computer program code comprising computer instructions; when the computer instructions are executed by the processor, the electronic device performs the method of any one of claims 1-11.

13. A chip system, characterized by application in an electronic device, the chip system comprises: at least one processor and an interface; the interface is used to receive instructions and transmit to the at least one processor; the at least one processor runs the instructions so that the electronic device performs the method of any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, comprising: computer instructions; when the computer instructions run on an electronic device, the electronic device performs the method of any one of claims 1-11.

15. A computer program product, characterised in that, when the computer program product runs on a computer, the computer performs the method of any one of claims 1-11. when the computer program product runs on a computer, the computer performs the method of any one of claims 1-11.

Images