Communication bridge-based web end and native end interaction method
By injecting multiple bridge files when loading web pages on the Native side and saving them separately to the instance library, the problem of the Web container component being incompatible with different types of bridge instances is solved, enabling communication and interaction between multiple services on the Web side and the Native side, and improving communication efficiency and flexibility.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHINA PING AN LIFE INSURANCE CO LTD
- Filing Date
- 2023-07-19
- Publication Date
- 2026-04-21
AI Technical Summary
In existing technologies, Web container components are not compatible with different types of bridge instances, which prevents the Web client and the Native client from achieving multi-service communication and interaction.
Multiple bridge files are injected when loading a webpage on the Native side. Each bridge file defines a bridge instance with a different communication protocol format. These bridges are distinguished and saved in an instance library. After receiving a function call request, the target bridge instance is obtained and the corresponding operation is performed.
It enables multi-service communication and interaction between the Web client and the Native client, and can be compatible with different types of bridge instances without modifying the original business logic, thus improving communication efficiency and flexibility.
Smart Images

Figure CN116962508B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a method for interaction between a Web client and a Native client based on a communication bridge. Background Technology
[0002] Currently, mobile projects often adopt a hybrid development model, which uses H5 pages on the native side to display activity pages or content introduction pages. When the H5 page on the web side needs to call native capabilities, such as making a phone call, opening the camera album, or jumping to the functional module page on the native side, the web side needs to interact with the native side.
[0003] To solve the communication and interaction between the web and native ends, JavaScript is usually executed in the web container to build a communication bridge JSBridge with the H5 page on the web end to handle data transfer and logical communication between the two ends.
[0004] In related technologies, web containers are usually encapsulated as separate components. However, as more and more business modules are introduced into the project, the original encapsulated web container components can no longer support different types of bridge instances in H5 pages, thus making it impossible to realize communication and interaction between multiple services on the native and web sides. Summary of the Invention
[0005] The main objective of this application is to propose a method, apparatus, electronic device, and computer-readable storage medium for interaction between a Web client and a Native client based on a communication bridge, which is compatible with different types of bridge instances to realize multi-service communication interaction between the Web client and the Native client.
[0006] To achieve the above objectives, a first aspect of this application proposes a method for interaction between a Web client and a Native client based on a communication bridge, the method comprising:
[0007] In response to the loading of a webpage on the Native side, multiple pre-created bridge files are injected into the webpage. Each bridge file defines multiple bridge instances, and the communication protocol format corresponding to the bridge instances in each bridge file is different.
[0008] The bridge instances in each bridge file are distinguished and saved to a preset instance library through the communication bridge;
[0009] The communication bridge receives a function call request sent by the web client. The function call request carries the bridge name and communication protocol format of the target bridge instance. The function call request is used to request the native client to execute the function operation corresponding to the target bridge instance.
[0010] The target bridge instance is obtained from the instance library through the communication bridge according to the bridge name and communication protocol format of the target bridge instance;
[0011] The target bridge instance is invoked through the communication bridge to enable the native end to perform the functional operation corresponding to the target bridge instance.
[0012] According to some embodiments of this application, the method for interaction between a Web client and a Native client based on a communication bridge, wherein the function call request also carries call parameter information of the target bridge instance;
[0013] The step of invoking the target bridge instance through the communication bridge to enable the native end to execute the function operation corresponding to the target bridge instance includes:
[0014] The communication bridge transmits the call parameter information to the target bridge instance, and calls the target bridge instance so that the native end executes the function operation corresponding to the target bridge instance according to the call parameter information.
[0015] According to some embodiments of this application, the method for interaction between a Web client and a Native client based on a communication bridge, after calling the target bridge instance through the communication bridge to cause the Native client to execute the functional operation corresponding to the target bridge instance, the method further includes:
[0016] The communication bridge invokes a preset callback function to send the processing result of the Native end executing the function operation corresponding to the target bridge instance to the Web end.
[0017] According to some embodiments of this application, the method for interaction between a Web client and a Native client based on a communication bridge includes the step of distinguishing and saving bridge instances in each bridge file to a preset instance library via the communication bridge, which includes:
[0018] By using attribute-value pairs where the bridge name is an attribute and the bridge instance is the attribute value, each bridge instance in the bridge file is distinguished and saved to a preset instance library.
[0019] According to some embodiments of this application, the method for interaction between a Web client and a Native client based on a communication bridge includes the step of distinguishing and saving bridge instances in each bridge file to a preset instance library via the communication bridge, which includes:
[0020] The prefix identifier of each bridge instance in the bridge file is determined according to the preset mapping relationship and the communication protocol format of the bridge instances in the bridge file. The prefix identifier corresponding to each bridge instance in the bridge file is different.
[0021] The bridge instances in each bridge file are saved to a preset instance library by using a prefix identifier to distinguish them.
[0022] The step of retrieving the target bridge instance from the instance library based on the bridge name and communication protocol format of the target bridge instance via the communication bridge includes:
[0023] The prefix identifier of the target bridge instance is determined based on the mapping relationship and the communication protocol format of the target bridge instance;
[0024] The communication bridge retrieves the target bridge instance from the instance library based on the prefix identifier and bridge name of the target bridge instance.
[0025] According to some embodiments of this application, the method for interaction between a Web client and a Native client based on a communication bridge, prior to injecting multiple pre-created bridge files into the webpage, further includes:
[0026] Obtain a script file that defines a bridge building instance for generating a communication bridge;
[0027] Load the script file to generate a communication bridge between the Native and Web ends in the Web container.
[0028] According to some embodiments of this application, the method for interaction between a Web client and a Native client based on a communication bridge, after loading the script file to generate a communication bridge between the Native client and the Web client in the Web container, the method further includes:
[0029] The Web container is initialized to trigger the communication bridge to create an instance library for storing bridge instances.
[0030] To achieve the above objectives, a second aspect of this application provides a web-to-native interaction device based on a communication bridge, the device comprising:
[0031] The injection module is used to inject multiple pre-created bridge files into the webpage in response to the loading of the webpage on the Native side. Each bridge file defines multiple bridge instances, and the communication protocol format corresponding to the bridge instances in each bridge file is different.
[0032] The registration module is used to distinguish and save the bridge instances in each bridge file to a preset instance library through the communication bridge;
[0033] The receiving module is used to receive a function call request sent by the Web client through the communication bridge. The function call request carries the bridge name and communication protocol format of the target bridge instance. The function call request is used to request the Native client to execute the function operation corresponding to the target bridge instance.
[0034] The acquisition module is used to acquire the target bridge instance from the instance library through the communication bridge according to the bridge name and communication protocol format of the target bridge instance;
[0035] The calling module is used to call the target bridge instance through the communication bridge so that the native end can execute the functional operation corresponding to the target bridge instance.
[0036] To achieve the above objectives, a third aspect of this application provides an electronic device, the electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the method described in the first aspect.
[0037] To achieve the above objectives, a fourth aspect of the present application provides a storage medium, which is a computer-readable storage medium for computer-readable storage, wherein the storage medium stores one or more computer programs that can be executed by one or more processors to implement the method described in the first aspect.
[0038] This application proposes a method, apparatus, electronic device, and computer-readable storage medium for interaction between a Web client and a Native client based on a communication bridge. The method includes: in response to the Native client loading a webpage, injecting multiple pre-created bridge files into the webpage, each bridge file defining multiple bridge instances, and the communication protocol format corresponding to the bridge instances in each bridge file being different; using the communication bridge to distinguish and save the bridge instances in each bridge file to a preset instance library; and then, when the communication bridge receives a function call request sent by the Web client, retrieving the target bridge instance from the instance library according to the bridge name and communication protocol format of the target bridge instance carried in the function call request, thereby calling the target bridge instance through the communication bridge to enable the Native client to execute the function operation corresponding to the target bridge instance. This application injects multiple bridge files, each containing multiple bridge instances, into the webpage when loading it on the Native side. The bridge instances in different bridge files correspond to different communication protocol formats under different business types. When the communication bridge receives a function call request from the Web side, it can retrieve the target bridge instance from the instance library containing multiple bridge instances, and then call the target bridge instance to make the Native side perform the corresponding function operation. It can respond to bridge instances from different business types on a single Native side, realizing multi-business communication interaction between the Web side and the Native side. Attached Figure Description
[0039] Figure 1 This is a flowchart illustrating a method for interaction between a Web client and a Native client based on a communication bridge, as provided in an embodiment of this application.
[0040] Figure 2 yes Figure 1 A flowchart illustrating the sub-steps of step S120;
[0041] Figure 3 yes Figure 1 A flowchart illustrating the sub-steps of step S140;
[0042] Figure 4 This is a flowchart illustrating a method for interaction between a Web client and a Native client based on a communication bridge, according to another embodiment of this application.
[0043] Figure 5 This is a flowchart illustrating a method for interaction between a Web client and a Native client based on a communication bridge, according to another embodiment of this application.
[0044] Figure 6 This is a schematic diagram of the structure of a Web-based and Native-based interactive device based on a communication bridge, provided in an embodiment of this application.
[0045] Figure 7This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0046] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0047] It should be noted that, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.
[0048] First, let's analyze some of the terms used in this application:
[0049] Native App development, also known as native development, refers to the application (APP) development model on mobile platforms such as Android and iOS that utilizes the official development languages, libraries, and tools provided by the developers.
[0050] Web App development refers to the development model of apps using web technologies. Web technologies themselves require browser support for display and user interaction, and the main technologies used are HTML5 (Hypertext Markup Language 5), Java, and CSS (Cascading Style Sheets).
[0051] Hybrid app development, also known as hybrid development, refers to a development model that combines native and HTML5 development technologies. It typically consists of two parts: an HTML5 cloud website and an app client. The app client includes a native side and a web side. The native code uses a WebView plugin or other framework to provide a web container for the HTML5 pages, thus displaying the HTML5 pages on the native side. In this hybrid development model, the HTML5 pages frequently need to use native side functions, such as opening QR code scanning, calling native pages, and retrieving user information. Simultaneously, the native side also needs to send push notifications and update status to the web side. Because the JavaScript code in the HTML5 pages runs in a separate JSContext, isolated from the native side's runtime environment, a JSBridge is needed to enable bidirectional communication between the native and web sides. Using a JavaScript engine or WebView container as a medium, a protocol is established to achieve bidirectional communication between the native and web sides. Through JSBridge, the web side can call the native side's Java interfaces, and similarly, the native side can call the web side's JavaScript interfaces through JSBridge, achieving bidirectional communication between them.
[0052] Currently, mobile projects often adopt a hybrid development model, which uses H5 pages on the native side to display activity pages or content introduction pages. When the H5 page on the web side needs to call native capabilities, such as making a phone call, opening the camera album, or jumping to the functional module page on the native side, the web side needs to interact with the native side.
[0053] To solve the communication and interaction between the web and native ends, JavaScript is usually executed in the web container to build a communication bridge JSBridge with the H5 page on the web end to handle data transfer and logical communication between the two ends.
[0054] In related technologies, web containers are usually encapsulated as separate components. However, as more and more business modules are introduced into the project, the original encapsulated web container components can no longer support different types of bridge instances in H5 pages, thus making it impossible to realize communication and interaction between multiple services on the native and web sides.
[0055] Based on this, embodiments of this application provide a method, apparatus, electronic device, and computer-readable storage medium for interaction between a Web client and a Native client based on a communication bridge, which can be compatible with different types of bridge instances to realize multi-service communication interaction between the Web client and the Native client.
[0056] First, the interaction method between the Web client and the Native client based on the communication bridge in the embodiments of this application is described:
[0057] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.
[0058] Please see Figure 1 , Figure 1 This illustration shows a flowchart of a web-based and native-based interaction method based on a communication bridge, as provided in an embodiment of this application. Figure 1 As shown, the interaction method between the Web client and the Native client based on the communication bridge includes, but is not limited to, steps S110 to S150.
[0059] Step S110: In response to the loading of a webpage on the Native side, inject multiple pre-created bridge files into the webpage. Each bridge file defines multiple bridge instances, and the communication protocol format corresponding to each bridge instance in the bridge file is different.
[0060] Understandably, each pre-created bridge file defines multiple bridge instances, and the bridge instances in different bridge files correspond to different communication protocol formats. In other words, the bridge instances in each bridge file come from business modules that use different communication protocol formats. Therefore, injecting these multiple bridge files into the webpage enables JSBridge to recognize the bridge instances with the communication protocol formats specified in the bridge files and respond to different business type function call requests sent by the web on a native side.
[0061] For example, please see Figure 5 , Figure 5 This illustration shows a flowchart of a web-based and native-based interaction method based on a communication bridge, according to another embodiment of this application. Figure 5As shown, an application (App) has H5 pages for a first business module and a second business module on its web interface. The first business module has a first communication protocol format of xxx: / / yyy, and the second business module has a second communication protocol format of aaa: / / bbb. The pre-created bridge files include a first bridge file that specifies the first communication protocol format and a second bridge file that specifies the second communication protocol format. That is, the first bridge file defines multiple first bridge instances with the first communication protocol format, and the second bridge file defines multiple second bridge instances with the second communication protocol format.
[0062] It should be understood that the bridge file is a JavaScript script file.
[0063] In some embodiments, see Figure 4 , Figure 4 This illustration shows a flowchart of a web-to-native interaction method based on a communication bridge, according to another embodiment of this application. Figure 4 As shown, before injecting the pre-created multiple bridge files into the webpage, the method further includes steps S410 and S420.
[0064] Step S410: Obtain a script file, which defines a bridge construction instance for generating a communication bridge.
[0065] Step S420: Load the script file to generate a communication bridge between the Native and Web ends in the Web container.
[0066] It should be understandable that when loading a webpage on the native side, a bridge building instance defined in the script file is injected to generate a JSBridge in the web container, thereby building a JSBridge between the native and web sides.
[0067] When responding to the loading of a webpage on the native side, the bridge building instance used to generate the JSBridge can be injected in advance by loading a script file. This can build the JSBridge in advance, improve the communication efficiency between the native and web sides, and the method of injecting the bridge building instance through the script file does not require manual configuration, which can reduce the implementation difficulty and cost.
[0068] In some embodiments, such as Figure 4 As shown, after loading the script file to generate a communication bridge between the Native and Web ends in the Web container, the method further includes step S430.
[0069] Step S430: Initialize the Web container to trigger the communication bridge to create an instance library for storing bridge instances.
[0070] For example, such as Figure 5 As shown, the initialization of the Web container triggers JSBridge to create a collection of messageHandlers to store all instance methods registered locally in H5, which is an instance library used to store bridge instances.
[0071] Step S120: Save the bridge instances in each bridge file to a preset instance library through the communication bridge.
[0072] It should be understood that bridge instances in different bridge files correspond to different communication protocol formats. In order for the communication bridge to correctly respond to bridge instances from different business modules with different communication protocol formats, during the process of injecting bridge instances, the communication bridge distinguishes and saves the bridge instances in each bridge file to a preset instance library.
[0073] For example, the pre-created bridge files include a first bridge file and a second bridge file. The first bridge file defines multiple first bridge instances from a first business module, and the second bridge file defines multiple second bridge instances from a second business module. The first business module and the second business module use a first communication protocol format and a second communication protocol format, respectively. The communication bridge distinguishes the first bridge instances corresponding to the first communication protocol format and the second bridge instances corresponding to the second communication protocol format and saves them to the instance library. Thus, in the communication interaction between the Native end and the Web end, the communication bridge can respond to the bridge instances from the first business module or the second business module without modifying the business logic and bridge instances in the first business module or the second business module.
[0074] In some embodiments, the step of distinguishing and saving bridge instances in each bridge file to a preset instance library via a communication bridge includes:
[0075] By using attribute-value pairs where the bridge name is an attribute and the bridge instance is the attribute value, each bridge instance in the bridge file is distinguished and saved to a preset instance library.
[0076] For example, such as Figure 5As shown, the Web container initialization triggers JSBridge to create a collection called `messageHandler` to store all instance methods registered locally in H5. This `messageHandler` serves as an instance library for storing bridge instances. It is a collection of attribute-value pairs, where the attribute is the instance name and the value is the instance itself. In other words, `messageHandler` is a key-value pair collection, where the key is the instance name and the value is the instance itself. The communication bridge saves each bridge instance from the bridge file to the instance library as attribute-value pairs. During communication between the Native and Web sides, the communication bridge can directly retrieve the bridge instance method from the instance library using the instance name, improving response speed.
[0077] Step S130: Receive a function call request sent by the Web client through the communication bridge. The function call request carries the bridge name and communication protocol format of the target bridge instance. The function call request is used to request the Native client to execute the function operation corresponding to the target bridge instance.
[0078] It is understandable that the function call requests received from the Web client via the communication bridge can occur in the following situations: a user requests a function operation belonging to the first business module from an H5 page within the first business module; or a user requests a function operation belonging to the second business module from an H5 page within the first business module. In other words, when an H5 page on the Web client mixes functions from multiple business types, such as the first and second business modules, even though they correspond to bridge instances with different communication protocol formats, this application can achieve compatibility with all business H5 pages and simultaneously meet function call requests from different business types by injecting bridge files specifying multiple communication protocol formats into JSBridge, without affecting the original business or requiring any changes to the business logic of any party.
[0079] Step S140: Obtain the target bridge instance from the instance library through the communication bridge according to the bridge name and communication protocol format of the target bridge instance.
[0080] Understandably, the function call request carries the bridge name and communication protocol format of the target bridge instance. In response to receiving the function call request sent by the web client, the function call request is parsed to obtain the bridge name and communication protocol format of the target bridge instance, and then the target bridge instance is retrieved from the instance library based on the bridge name and communication protocol format of the target bridge instance.
[0081] In some embodiments, see Figure 2 , Figure 2 It shows Figure 1 A flowchart illustrating the sub-steps of step S120 is shown below. Figure 2 As shown, the step of distinguishing and saving the bridge instances in each bridge file to a preset instance library through the communication bridge includes, but is not limited to, steps S210 and S220.
[0082] Step S210: Determine the prefix identifier of each bridge instance in the bridge file according to the preset mapping relationship and the communication protocol format of the bridge instances in the bridge file. The prefix identifier corresponding to each bridge instance in the bridge file is different.
[0083] Step S220: Save the bridge instance in each bridge file to a preset instance library by using the communication bridge in a prefix identification manner.
[0084] Please see Figure 3 , Figure 3 It shows Figure 1 A flowchart illustrating the sub-steps of step S140 is shown below. Figure 3 As shown, the step of obtaining the target bridge instance from the instance library through the communication bridge according to the bridge name and communication protocol format of the target bridge instance includes, but is not limited to, steps S310 and S320.
[0085] Step S310: Determine the prefix identifier of the target bridge instance based on the mapping relationship and the communication protocol format of the target bridge instance.
[0086] Step S320: Obtain the target bridge instance from the instance library through the communication bridge based on the prefix identifier and bridge name of the target bridge instance.
[0087] It should be understood that the preset mapping relationship is a one-to-one correspondence between communication protocol formats and prefix identifiers. That is, the prefix identifier corresponding to the bridge instance in the bridge file is determined from the preset mapping relationship based on the communication protocol format of the bridge instance. Different bridge instances in different bridge files correspond to different prefix identifiers. After determining the prefix identifier corresponding to the bridge instance in the bridge file, the bridge instance in each bridge file is saved to a preset instance library based on the prefix identifier distinction. Similarly, when the communication bridge needs to retrieve a target bridge instance from the instance library, the prefix identifier corresponding to the target bridge instance is determined from this mapping relationship, and then the target bridge instance is retrieved from the instance library based on the prefix identifier and bridge name of the target bridge instance.
[0088] In one specific embodiment, the step of distinguishing and saving bridge instances in each bridge file to a preset instance library using attribute-value pairs where the bridge name is an attribute and the bridge instance is the attribute value includes:
[0089] By using attribute value pairs where the bridge name combined with a prefix identifier is an attribute and the bridge instance is the attribute value, each bridge instance in the bridge file is distinguished and saved to a preset instance library.
[0090] For example, such as Figure 5 As shown, based on the communication protocol format, the prefix identifier of the bridge instance belonging to the first communication protocol format is determined from the preset mapping relationship as "A_". Assuming there is an instance name of a bridge instance belonging to the first communication protocol format as "setNumber", this instance name is combined with the prefix identifier, i.e., "A_setNumber", as an attribute in the attribute value pair for differentiation and storage. Similarly, when the communication bridge needs to retrieve and call the target bridge instance "setNumber" belonging to the first communication protocol format from the instance library, the prefix identifier corresponding to the target bridge instance is determined from the preset mapping relationship based on the communication protocol format as "A_". The instance name and prefix identifier of the target bridge instance are combined to obtain "A_setNumber", and then the target bridge instance is retrieved from the instance library based on "A_setNumber".
[0091] Step S150: The target bridge instance is invoked through the communication bridge to enable the Native end to execute the functional operation corresponding to the target bridge instance.
[0092] In some embodiments, the function call request also carries call parameter information of the target bridge instance;
[0093] The step of invoking the target bridge instance through the communication bridge to enable the native end to execute the function operation corresponding to the target bridge instance includes:
[0094] The communication bridge transmits the call parameter information to the target bridge instance, and calls the target bridge instance so that the native end executes the function operation corresponding to the target bridge instance according to the call parameter information.
[0095] It is understandable that the Native side may need initial parameter information to perform the corresponding functional operation. In this case, the function call request needs to carry the call parameter information related to the target bridge instance, and the call parameter information is passed to the target bridge instance through the communication bridge so that the Native side can execute the functional operation corresponding to the target bridge instance according to the call parameter information.
[0096] In some embodiments, after invoking the target bridge instance via the communication bridge to cause the native end to execute the functional operation corresponding to the target bridge instance, the method further includes:
[0097] The communication bridge invokes a preset callback function to send the processing result of the Native end executing the function operation corresponding to the target bridge instance to the Web end.
[0098] It should be understandable that when the web client requests the native server to perform a corresponding function operation and needs to obtain the processing result after the native server performs the function operation, it can send the processing result of the native server completing the corresponding function operation of the target bridge instance to the web client by calling a preset callback function through the communication bridge.
[0099] It should be noted that the callback function name carried in the function call request can be used to retrieve the corresponding callback function through the communication bridge. After the corresponding function operation is completed on the native side, the processing result obtained from the native side is sent to the web side by calling the callback function. The callback function can be obtained by injecting a corresponding instance into JSBridge by loading a JavaScript script file.
[0100] The following is a specific embodiment describing a web-to-native interaction method based on a communication bridge provided in this application:
[0101] This method is applied to application clients on mobile devices. These application clients are hybrid applications, including native and web versions. The native version can be used to run native pages and implement the functions provided by the operating system by calling the operating system's application programming interface. The web version is used to utilize H5 pages.
[0102] The native application embeds a WebView, which acts as a web container to load web pages in the application client and display the loaded page content. A JSBridge runs within the web container for communication and interaction between the native and web applications.
[0103] like Figure 5 As shown, the H5 page on the web client involves functions of both a first business type and a second business type. The first business type uses a bridge instance with a first communication protocol format, while the second business type uses a bridge instance with a second communication protocol format. The first and second communication protocol formats are different. When a user accesses the H5 page on the web client, a first bridge file is injected into the H5 page so that JSBridge can recognize the first bridge instance with the first communication protocol format defined in the first bridge file. Simultaneously, a second bridge file is injected into the H5 page so that JSBridge can recognize the second bridge instance with the second communication protocol format defined in the second bridge file.
[0104] Specifically, when a user clicks on a page, the Web container initializes to trigger JSBridge to create a collection of messageHandlers to store all instances registered locally in the H5 page. JSBridge calls the registerHandler function to add the first and second bridge instances to the messageHandler collection. Therefore, when a user triggers any function of the first or second business type on the H5 page, the communication bridge can retrieve and call the corresponding bridge instance from the instance library through the callHandler function to trigger the native to execute the corresponding function operation. This ensures that an application can respond to bridge instances from different business modules and execute corresponding function operations without modifying the business logic and bridge instances of either the first or second business type.
[0105] This application proposes a method for interaction between a Web client and a Native client based on a communication bridge. The method includes: in response to the Native client loading a webpage, injecting multiple pre-created bridge files into the webpage, each bridge file defining multiple bridge instances, and the communication protocol format corresponding to the bridge instances in each bridge file being different; using the communication bridge to distinguish and save the bridge instances in each bridge file to a preset instance library; and then, when the communication bridge receives a function call request sent by the Web client, retrieving the target bridge instance from the instance library according to the bridge name and communication protocol format of the target bridge instance carried in the function call request, thereby calling the target bridge instance through the communication bridge to enable the Native client to execute the function operation corresponding to the target bridge instance. This application injects multiple bridge files, each containing multiple bridge instances, into the webpage when loading it on the Native side. The bridge instances in different bridge files correspond to different communication protocol formats under different business types. When the communication bridge receives a function call request from the Web side, it can retrieve the target bridge instance from the instance library containing multiple bridge instances, and then call the target bridge instance to make the Native side perform the corresponding function operation. It can respond to bridge instances from different business types on a single Native side, realizing multi-business communication interaction between the Web side and the Native side.
[0106] Please see Figure 6 This application also provides a Web-to-Native interaction device 100 based on a communication bridge, which includes:
[0107] The injection module 110 is used to inject multiple pre-created bridge files into the webpage in response to the loading of the webpage on the Native side. Each bridge file defines multiple bridge instances, and the communication protocol format corresponding to the bridge instances in each bridge file is different.
[0108] The registration module 120 is used to distinguish and save the bridge instances in each bridge file to a preset instance library through the communication bridge;
[0109] The receiving module 130 is used to receive a function call request sent by the Web client through the communication bridge. The function call request carries the bridge name and communication protocol format of the target bridge instance. The function call request is used to request the Native client to execute the function operation corresponding to the target bridge instance.
[0110] The acquisition module 140 is used to acquire the target bridge instance from the instance library through the communication bridge according to the bridge name and communication protocol format of the target bridge instance;
[0111] The calling module 150 is used to call the target bridge instance through the communication bridge so that the native end can execute the functional operation corresponding to the target bridge instance.
[0112] In some embodiments, the function call request also carries call parameter information corresponding to the target bridge instance;
[0113] The calling module 150 is also used to pass the calling parameter information to the target bridge instance through the communication bridge, and call the target bridge instance so that the Native end executes the function operation corresponding to the target bridge instance according to the calling parameter information.
[0114] In some embodiments, the device 100 further includes:
[0115] The callback module 160 is used to call a preset callback function through the communication bridge after the calling module 150 calls the target bridge instance through the communication bridge to make the native end execute the function operation corresponding to the target bridge instance, so as to send the processing result of the native end executing the function operation corresponding to the target bridge instance to the web end.
[0116] In some embodiments, the registration module 120 is further configured to distinguish and save the bridge instances in each bridge file to a preset instance library by using attribute value pairs with the bridge name as an attribute and the bridge instance as the attribute value.
[0117] In some embodiments, the registration module 120 further includes:
[0118] The first registration submodule 121 is used to determine the prefix identifier of each bridge instance in the bridge file according to the preset mapping relationship and the communication protocol format of the bridge instances in the bridge file, and the prefix identifier corresponding to each bridge instance in the bridge file is different.
[0119] The second registration submodule 122 is used to save each bridge instance in the bridge file to a preset instance library by using the communication bridge in a prefix identification method;
[0120] The acquisition module 140 further includes:
[0121] The first acquisition submodule 141 is used to determine the prefix identifier of the target bridge instance according to the mapping relationship and the communication protocol format of the target bridge instance;
[0122] The second acquisition submodule 142 is used to acquire the target bridge instance from the instance library through the communication bridge based on the prefix identifier and bridge name of the target bridge instance.
[0123] In some embodiments, the device 100 further includes:
[0124] The script acquisition module 170 is used to acquire a script file before the injection module 110 injects multiple pre-created bridge files into the webpage. The script file defines a bridge construction instance for generating a communication bridge.
[0125] The script loading module 180 is used to load the script file to generate a communication bridge between the Native end and the Web end in the Web container.
[0126] In some embodiments, the device 100 further includes:
[0127] The initialization module 190 is used to initialize the Web container after the script loading module 180 loads the script file to generate a communication bridge between the Native end and the Web end in the Web container, so as to trigger the creation of an instance library for storing bridge instances.
[0128] This application proposes a web-to-native interaction device based on a communication bridge. In response to the native client loading a webpage, the device injects multiple pre-created bridge files into the webpage. Each bridge file defines multiple bridge instances, and the communication protocol format corresponding to the bridge instances in each bridge file is different. The communication bridge distinguishes and saves the bridge instances in each bridge file to a preset instance library. Then, when the communication bridge receives a function call request sent by the web client, it retrieves the target bridge instance from the instance library according to the bridge name and communication protocol format of the target bridge instance carried in the function call request. Thus, the communication bridge calls the target bridge instance to enable the native client to execute the function operation corresponding to the target bridge instance. This application injects multiple bridge files, each containing multiple bridge instances, into the webpage when loading it on the Native side. The bridge instances in different bridge files correspond to different communication protocol formats under different business types. When the communication bridge receives a function call request from the Web side, it can retrieve the target bridge instance from the instance library containing multiple bridge instances, and then call the target bridge instance to make the Native side perform the corresponding function operation. It can respond to bridge instances from different business types on a single Native side, realizing multi-business communication interaction between the Web side and the Native side.
[0129] It should be noted that the information interaction and execution process between the modules of the above-mentioned device are based on the same concept as the method embodiment of this application. For details on their specific functions and technical effects, please refer to the method embodiment section, and they will not be repeated here.
[0130] Please see Figure 7 , Figure 7 This application illustrates the hardware structure of an electronic device according to an embodiment of the present application. The electronic device includes:
[0131] The processor 210 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant computer programs to implement the technical solutions provided in the embodiments of this application.
[0132] The memory 220 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 220 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 220 and called and executed by the processor 210 to execute the Web-to-Native interaction method based on the communication bridge in the embodiments of this application.
[0133] Input / output interface 230 is used to implement information input and output;
[0134] The communication interface 240 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.); and the bus 250 is used to transmit information between each component of the device (such as processor 210, memory 220, input / output interface 230 and communication interface 240).
[0135] The processor 210, memory 220, input / output interface 230 and communication interface 240 are connected to each other within the device via bus 250.
[0136] This application embodiment also provides a storage medium, which is a computer-readable storage medium for computer-readable storage. The storage medium stores one or more computer programs, which can be executed by one or more processors to implement the above-described method for interaction between the Web end and the Native end based on the communication bridge.
[0137] Memory, as a computer-readable storage medium, can be used to store software programs and computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
[0138] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.
[0139] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.
[0140] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.
[0141] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0142] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0143] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "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 three cases: only A exists, only B exists, and both A and B exist simultaneously, 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. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.
[0144] 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 the units described above 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 system, 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 apparatuses or units may be electrical, mechanical, or other forms.
[0145] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0146] Furthermore, the functional units in each embodiment of this application can be integrated into a single processing unit, or each unit can exist independently, or two or more units can be integrated into a single unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0147] If the assembled units are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of each embodiment of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0148] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.
Claims
1. A method for interaction between a Web client and a Native client based on a communication bridge, characterized in that, The method includes: In response to the loading of a webpage on the Native side, multiple pre-created bridge files are injected into the webpage. Each bridge file defines multiple bridge instances, and the communication protocol format corresponding to the bridge instances in each bridge file is different. The bridge instances in different bridge files correspond to the communication protocol formats under different business types. The bridge instances in each bridge file are distinguished and saved to a preset instance library through the communication bridge; The communication bridge receives a function call request sent by the web client. The function call request carries the bridge name and communication protocol format of the target bridge instance. The function call request is used to request the native client to execute the function operation corresponding to the target bridge instance. The target bridge instance is obtained from the instance library through the communication bridge according to the bridge name and communication protocol format of the target bridge instance; The target bridge instance is invoked through the communication bridge to enable the native end to execute the functional operation corresponding to the target bridge instance.
2. The method according to claim 1, characterized in that, The function call request also carries the call parameter information of the target bridge instance; The step of invoking the target bridge instance through the communication bridge to enable the native end to execute the function operation corresponding to the target bridge instance includes: The communication bridge transmits the call parameter information to the target bridge instance, and calls the target bridge instance so that the native end executes the function operation corresponding to the target bridge instance according to the call parameter information.
3. The method according to claim 1, characterized in that, After invoking the target bridge instance via the communication bridge to cause the native end to execute the function operation corresponding to the target bridge instance, the method further includes: The communication bridge invokes a preset callback function to send the processing result of the Native end executing the function operation corresponding to the target bridge instance to the Web end.
4. The method according to claim 1, characterized in that, The step of distinguishing and saving bridge instances in each bridge file to a preset instance library via a communication bridge includes: By using attribute-value pairs where the bridge name is an attribute and the bridge instance is the attribute value, each bridge instance in the bridge file is distinguished and saved to a preset instance library.
5. The method according to claim 1, characterized in that, The step of distinguishing and saving bridge instances in each bridge file to a preset instance library via a communication bridge includes: The prefix identifier of each bridge instance in the bridge file is determined according to the preset mapping relationship and the communication protocol format of the bridge instances in the bridge file. The prefix identifier corresponding to each bridge instance in the bridge file is different. The bridge instances in each bridge file are saved to a preset instance library by using a prefix identifier to distinguish them. The step of retrieving the target bridge instance from the instance library based on the bridge name and communication protocol format of the target bridge instance via the communication bridge includes: The prefix identifier of the target bridge instance is determined based on the mapping relationship and the communication protocol format of the target bridge instance; The communication bridge retrieves the target bridge instance from the instance library based on the prefix identifier and bridge name of the target bridge instance.
6. The method according to claim 1, characterized in that, Prior to injecting the pre-created multiple bridge files into the webpage, the method further includes: Obtain a script file that defines a bridge building instance for generating a communication bridge; Load the script file to generate a communication bridge between the Native and Web ends in the Web container.
7. The method according to claim 6, characterized in that, After loading the script file to generate a communication bridge between the Native and Web ends in the Web container, the method further includes: The Web container is initialized to trigger the communication bridge to create an instance library for storing bridge instances.
8. A web-based and native-based interactive device based on a communication bridge, characterized in that, The device includes: The injection module is used to inject multiple pre-created bridge files into the webpage in response to the loading of the webpage on the Native side. Each bridge file defines multiple bridge instances, and the communication protocol format corresponding to the bridge instances in each bridge file is different. The bridge instances in different bridge files correspond to the communication protocol formats under different business types. The registration module is used to distinguish and save the bridge instances in each bridge file to a preset instance library through the communication bridge; The receiving module is used to receive a function call request sent by the Web client through the communication bridge. The function call request carries the bridge name and communication protocol format of the target bridge instance. The function call request is used to request the Native client to execute the function operation corresponding to the target bridge instance. The acquisition module is used to acquire the target bridge instance from the instance library through the communication bridge according to the bridge name and communication protocol format of the target bridge instance; The calling module is used to call the target bridge instance through the communication bridge so that the native end can execute the functional operation corresponding to the target bridge instance.
9. An electronic device, characterized in that, include: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that is executed by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1 to 7.
10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.
Citation Information
Patent Citations
Bridging method and device
CN112925658A
Web page and native application interaction method, electronic equipment and storage medium
CN116414377A