Message transmission device and method among multiple application platforms, equipment and medium

Abstract

The embodiment of the invention provides a message transmission device among multiple application platforms, which can be applied to the technical field of computers. The message transmission device among the multiple application platforms comprises a central star bridge module, a process calling module and a virtual container module. The central star bridge module is used for realizing function message mutual transmission among a plurality of application platforms through a preset interaction interface; the process calling module is used for executing conversion between the function message and the binary message in the function message mutual transmission process; and the virtual container module is used for providing a module-level unified entry in a function message mutual transmission process. The embodiment of the invention also provides a message transmission method and device among multiple application platforms, and a storage medium.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and particularly to a message transmission device, method, equipment, and medium among multiple application platforms. Background Art

[0002] The functional interaction between different application platforms usually depends on the message mutual transmission between each platform. However, different application platforms usually adopt different message transmission protocols, which greatly limits the functional interaction between multiple different application platforms. For example, in today's intelligent portable electronic devices (such as mobile phones), applications based on the Android system can transmit messages to the Unity game engine through the native language, which is very common for application scenarios with multiple game engines. However, different game engines are usually implemented based on different application platforms, and there are different systems of message transmission protocols between different application platforms, making it impossible to uniformly implement the control for multiple game engines.

[0003] Currently, common cross-platform message transmission solutions can adopt schemes such as bridging and process communication. These schemes mainly aim to implement an efficient and unified native UI with less code. Currently, they cannot well solve the problem of business logic code management, cannot ensure the interaction efficiency and accuracy rate, and even instead cause higher complexity, making it difficult to meet the increasingly complex business logic of today's application platforms. Moreover, if separately performing call adaptation for two specific application platforms with different languages, a new set of functions needs to be re-implemented for each pair of call combinations, which cannot solve the message transmission and interaction problem between all different application platforms at once, nor can it provide a unified running environment for unified management. Summary of the Invention

[0004] In view of at least one of the above problems, embodiments of the present invention aim to provide a message transmission method, device, equipment, medium, and product among multiple application platforms that can achieve high-efficiency function calls across languages and platforms, thereby providing an architecture system for a client cross-language and cross-platform functional interaction module, which can solve the function call problem between all application platforms with different languages having the FFI (Foreign Function Interface) call ability at once, and at the same time provide a unified running environment for functional modules in different languages and uniformly manage different language modules.

[0005] An aspect of an embodiment of the present invention provides a message transmission device among multiple application platforms, wherein the message transmission device includes a central star bridge module, a procedure call module, and a virtual container module.

[0006] The central star bridge module is used to realize the mutual transmission of functional messages among multiple application platforms through a preset interaction interface;

[0007] The process call module is used to perform the conversion between functional messages and binary messages during the mutual transmission of functional messages;

[0008] The virtual container module is used to provide a unified entry at the module level during the mutual transmission of functional messages.

[0009] Another aspect of the embodiments of the present invention provides an electronic device, including one or more processors and a memory, where the memory is used to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors are caused to execute the message transmission method between the above-mentioned multiple application platforms.

[0010] Another aspect of the embodiments of the present invention provides a computer-readable storage medium, on which executable instructions are stored. When the instructions are executed by a processor, the processor is caused to execute the message transmission method between the above-mentioned multiple application platforms.

[0011] Another aspect of the embodiments of the present invention provides a computer program product, including a computer program. When the computer program is executed by a processor, the message transmission method between the above-mentioned multiple application platforms is implemented.

[0012] The message transmission method between multiple application platforms provided by the embodiments of the present invention can at least partially solve the problems existing in the function calls between specific multiple different-language application platforms in the related art, and thus can at least achieve one of the following technical effects:

[0013] (1) Realize cross-language function calls between different levels and different components after containerization. Specifically, realize cross-language and cross-platform function calls, reduce the difficulty of mutual calls between different languages including objective-c, java, rust, js, c++, etc., and provide a unified call method.

[0014] (2) Build a virtual running platform for container components.

[0015] (3) Provide the ability to construct general binary messages, keep the message protocols for interaction between platforms unified, erase the differences in cross-language interface calls between different languages, and realize a unified interface call form.

[0016] Therefore, the message transmission device between multiple application platforms of the embodiments of the present invention provides an architecture system of a cross-language and cross-platform functional interaction module for clients, which can solve all function call problems between different-language application platforms with FFI (Foreign Function Interface) call capabilities at one time, and at the same time provide a unified running environment for functional modules in different languages and uniformly manage different-language modules.

[0017] It should be understood that the above general description and the following specific embodiments are only exemplary and explanatory, and cannot limit the scope claimed by the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Through the following description of the embodiments of the present invention with reference to the accompanying drawings, the above content and other objects, features and advantages of the present invention will become clearer. In the drawings:

[0019] Figure 1 A structural block diagram of a message transmission device between multiple application platforms according to an embodiment of the present invention is schematically shown;

[0020] Figure 2 A structural block diagram of an application scenario based on a star topology architecture of a message transmission device between multiple application platforms according to an embodiment of the present invention is schematically shown;

[0021] Figure 3 A structural block diagram of a central star bridge module of a message transmission device between multiple application platforms according to an embodiment of the present invention is schematically shown;

[0022] Figure 4A A timing diagram of a message transmission method between multiple application platforms based on the same language timing according to an embodiment of the present invention is schematically shown;

[0023] Figure 4B A timing diagram of a message transmission method between multiple application platforms based on different language synchronous timing according to an embodiment of the present invention is schematically shown;

[0024] Figure 4C A timing diagram of a message transmission method between multiple application platforms based on different language asynchronous timing according to an embodiment of the present invention is schematically shown; and

[0025] Figure 5 A block diagram of an electronic device suitable for implementing a message transmission method between multiple application platforms according to an embodiment of the present invention is schematically shown.

[0026] The above-mentioned accompanying drawings are a part of the specification of the embodiments of the present invention, which illustrate the exemplary embodiments of the present invention. The accompanying drawings and the description of the specification are used together to explain the principles of the embodiments of the present invention. It should be understood that the above general description of the accompanying drawings and the following specific embodiments are only exemplary and explanatory, and cannot limit the scope claimed by the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0027] To make the objectives, technical solutions and advantages of the embodiments of the present invention more clearly understood, the following will clearly explain the spirit of the content disclosed by the present invention with reference to the drawings and detailed descriptions. After any person skilled in the art understands the embodiments of the content of the present invention, they can make changes and modifications based on the technologies taught by the content of the present invention, which do not depart from the spirit and scope of the content of the present invention.

[0028] The schematic embodiments of the present invention and their descriptions are used to explain the present invention, but do not limit the present invention. In addition, elements / components with the same or similar reference numerals used in the drawings and embodiments are used to represent the same or similar parts.

[0029] Regarding the use of "first", "second",... etc. in the present invention, it does not particularly refer to the meaning of order or sequence, nor is it used to limit the present invention. It is only used to distinguish elements or operations described with the same technical terms.

[0030] Regarding the directional terms used in the present invention, such as: up, down, left, right, front or back, etc., they are only references to the directions in the drawings. Therefore, the directional terms used are for explanation and not for limiting this creation.

[0031] Regarding the use of "comprising", "including", "having", "containing", etc. in the present invention, they are all open-ended terms, that is, they mean including but not limited to.

[0032] Regarding the use of "and / or" in the present invention, it includes any one or all combinations of the described things.

[0033] Regarding "a plurality of" in the present invention, it includes "two" and "more than two"; regarding "a plurality of groups" in the present invention, it includes "two groups" and "more than two groups".

[0034] Regarding the terms "substantially", "about", etc. used in the present invention, they are used to modify any quantity or error that can vary slightly, but these slight variations or errors will not change their essence. Generally, the range of such slight variations or errors modified by such terms can be 20% in some embodiments, 10% in some embodiments, 5% in some embodiments or other values. Those skilled in the art should understand that the aforementioned values can be adjusted according to actual needs and are not limited thereto.

[0035] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used here should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0036] In the case of using expressions such as "at least one of A, B, and C, etc.", generally, it should be interpreted according to the meaning that those skilled in the art usually understand this expression (for example, "a system having at least one of A, B, and C" should include, but not be limited to, a system having only A, only B, only C, having A and B, having A and C, having B and C, and / or having A, B, and C, etc.). In the case of using expressions such as "at least one of A, B, or C, etc.", generally, it should be interpreted according to the meaning that those skilled in the art usually understand this expression (for example, "a system having at least one of A, B, or C" should include, but not be limited to, a system having only A, only B, only C, having A and B, having A and C, having B and C, and / or having A, B, and C, etc.). Those skilled in the art should also understand that substantially any disjunctive conjunction and / or phrase representing two or more alternative items, whether in the specification, claims, or drawings, should be understood to give the possibility of including one of these items, either of these items, or both items. For example, the phrase "A or B" should be understood to include the possibility of "A" or "B", or "A and B".

[0037] In view of at least one of the above problems, embodiments of the present invention aim to provide a message transmission method, apparatus, device, medium, and product among multiple application platforms capable of achieving high-efficiency function calls across languages and platforms, thereby providing an architecture system for a cross-language and cross-platform function interaction module of a client, which can solve all function call problems among different language application platforms with FFI (Foreign Function Interface) call capabilities at one time, and at the same time provide a unified running environment for function modules in different languages and uniformly manage different language modules.

[0038] The following will be through Figures 1 to 3 A detailed description will be given to the message transmission apparatus among multiple application platforms of the disclosed embodiments.

[0039] As Figures 1 to 3 shown, the message transmission apparatus 100 among multiple application platforms of this embodiment includes a central star bridge module 110, a procedure call module 120, and a virtual container module 130.

[0040] The central star bridge module 110 is used to realize the mutual transmission of function messages among multiple application platforms through a preset interaction interface;

[0041] The procedure call module 120 is used to perform the conversion between function messages and binary messages during the mutual transmission of function messages;

[0042] The virtual container module 130 is used to provide a module-level unified entry during the mutual transmission of function messages.

[0043] The message transmission device according to an embodiment of the present invention provides a cross - language and cross - platform message inter - transmission architecture based on a star topology (as shown in Figure 2 ), to dock with each application platform and achieve cross - language inter - transmission between multiple application platforms. Among them, the application platform can be understood as the execution environment architecture of application programs implemented based on different computer languages, such as the game engine of a game application program. Therefore, the application platform can specifically be a running platform based on Objective - C, Swift, C++ etc. of the iOS system, or a running platform based on Java, Kotlin etc. of the Android system, or a running platform based on C#, Lua etc. of the Unity system, or a running platform based on JavaScript, C++ of the Cocos system, or a running platform based on Dart of Flutter, or even a running platform based on ArkTS, Cangjie etc. of the HarmonyOS system. Different application platforms have different running languages for function calls.

[0044] As Figure 1 shown, the central star bridge module 110 serves as the core architecture of the message transmission device 100, mainly used as the message relay intermediary of the above - mentioned message inter - transmission architecture of the star topology. Among them, the preset interaction interface can be implemented based on the message interface rules stipulated by the cross - language foreign function interface protocol (FFI for short). In addition, the function message is mainly a message generated by a function call from one application platform to other application platforms. For example, in a game application platform, text or voice messages are sent to an instant messaging application platform. Therefore, the message transmission device according to an embodiment of the present invention can be used as a specified plugin of a certain application platform for actual applications to achieve multi - language message inter - transmission based on the central star bridge module 110.

[0045] Generally, the technical bottleneck of the traditional star topology architecture lies in the excessive burden on the central node. To avoid this situation, although the central star bridge module 110 in the embodiment of the present invention has the message routing function of different application platforms, it does not include the message routing table itself, and only simply responsible for passing the binary messages converted by the procedure call module 120 to the corresponding application platform through the binary message construction function of the built - in procedure call module 120 (specifically, it can be passed to the hash - map call unit of the function routing module 140 described later, that is, the Mediator).

[0046] The process call module 120 can be a binary message conversion processing module based on a preset Adaptive Local Procedure Call (ALPC). Specifically, through a binary message model, it can convert and generate binary messages from functional messages in other languages based on a binary encoding protocol with the properties of Protocol Buffers (PB). Among them, the complete request for each set of functional messages sent to the process call module 120 can be divided into a request message (Request, abbreviated as Req) and a response message (Response, abbreviated as Res). The message request Req is usually generated by the sending end, and the message response Res is generated by the receiving end. It should be noted that the complete request for the functional message corresponds to the complete process of message sending and receiving. Among them, when the message sending end is the application platform relative to the process call module 120, the message receiving end can be the central star bridge module 110; conversely, when the message sending end is the central star bridge module 110, the message receiving end can be the application platform.

[0047] The virtual container module 130 is usually designed corresponding to the application platform (i.e., Container) and can be used to provide a unified entry at the module level in aspects such as external function calls, lifecycle management, global constant acquisition, and monitoring information embedding. Therefore, the virtual container module 130 usually includes corresponding business function container components. Each container component can contain a set of virtual runs, providing the basic capabilities of the application platform during the inter - transmission of functional messages, including function call entry, lifecycle management, global common parameter acquisition, and monitoring probe capabilities.

[0048] In summary, the above - mentioned message transmission method among multiple application platforms in the embodiments of the present invention can construct a basic operating framework for cross - platform and container - oriented development, and realize the standardization in aspects such as the construction of basic core components and basic interaction protocols. Among them, the cross - language interaction framework of this basic operating framework is the intersection of the PB support range and the language FFI support. Moreover, the container components based on the virtual container module 130 are business - layer container components. Therefore, it is possible to realize cross - language function calls between different levels and different components after containerization, reduce the difficulty of mutual calls between application platforms in different languages, and provide a unified call method; moreover, by providing the ability to construct general binary messages, the message protocols for interaction between each application platform are kept unified, erasing the differences in cross - language interface calls between different languages, and realizing a unified interface call form.

[0049] It can be seen that the message transmission method between multiple application platforms in the embodiments of the present invention provides an architecture system for a function interaction module that enables cross - language and cross - platform capabilities of clients. It can solve the problem of function calls between application platforms in different languages with the ability to call the Foreign Function Interface (FFI) protocol at one time. At the same time, it provides a unified running environment for function modules in different languages and manages different language modules uniformly.

[0050] To enable those skilled in the art to have a clearer understanding of the message transmission device between the above - mentioned multiple application platforms in the embodiments of the present invention, the following Figures 2 - 3 description is further provided.

[0051] As Figures 1 to 3 shown, according to an embodiment of the present invention, the message transmission device 100 between multiple application platforms further includes a function routing module 140.

[0052] The function routing module 140 is used to interface with different application platforms. During the mutual transmission of function messages, it dynamically calls different function components of the corresponding application platform according to the function messages;

[0053] Among them, for the mutual transmission of function messages between the same language within the same process, dynamic calls are implemented through the function routing module; for the mutual transmission of function messages between different languages within the same process, they are forwarded to the procedure call module through the function routing module for dynamic calls.

[0054] As Figure 2 shown, the function routing module 140 is mainly independently implemented for each application platform and all need to access the corresponding preset interaction interfaces (i.e., FFI interfaces) of the central star bridge module 201 (i.e., Figure 1 the central star bridge module 110 shown). The function routing module 140 can provide the dynamic call ability for different method functions of different function modules within the same language (i.e., the internal call mode). For cross - language calls, it needs to use the preset interaction interfaces provided by the central star bridge module 201 for access, and specifically needs to interface with the procedure call module 120. At the same time, the function routing module 140 also needs to implement the container module registration ability of the application platform currently interfacing with the central star bridge module 201 and provide module life - cycle management ability.

[0055] To implement the functions of decoding binary messages and subsequent message forwarding and processing within the application platform, the function routing module 140 needs to meet the following requirements: For message transmission between the same language within the same process, dynamic function calls are made using the above internal call mode; for message transmission between different languages within the same process, the function routing module 140 can forward the functional message to the procedure call module 120 to complete message delivery and function calls, thereby significantly improving the operating efficiency. It should be noted that the function calls of the function routing module 140 can be divided into three different cases: message sending within the same thread within the same process, message sending between different threads within the same process, and message sending between different processes.

[0056] As Figures 1 to 3 shown, according to an embodiment of the present invention, the function routing module includes a hash map call unit.

[0057] The hash map call unit is used to implement dynamic calls based on a preset call entry, where the preset call entry includes a local call entry for a single process, a remote call entry based on a uniform resource identifier, and a cross-language call entry based on a preset interaction interface.

[0058] As Figure 2 shown, the function routing module 140 (Mediator) integrates the business function components (Module) of the corresponding application platform. For example, the function routing module 140 can include a first hash map call unit 241 (Mediator Core), a second hash map call unit 242 (Mediator Native), and a third hash map call unit 243 (MediatorScript). Among them, the first hash map call unit 241 correspondingly integrates function components a, function components b, and function components c, the second hash map call unit 242 correspondingly integrates function components 1, function components 2, and function components 3, and the third hash map call unit 243 correspondingly integrates function components α, function components β, and function components γ. According to different functional messages, calls to different business function components (module) of the application platform can be realized, and then the corresponding application platform functions can be completed.

[0059] The first hash map call unit 241, the second hash map call unit 242, and the third hash map call unit 243 can respectively implement function dynamic calls based on the hash map (Hash-map) method. The entrances of function calls can be divided into three types: a local call entry for a single process, a remote call entry based on a uniform resource identifier, and a cross-language call entry based on a preset interaction interface.

[0060] For example, for the local call entry of a single process, it is usually designed in the way of "target+action+params", and the interface form is as follows:

[0061] wanba::mediator

[0062] .target("callee_target")

[0063] .action("callee_action")

[0064] .params(value)

[0065] .callback(|in_params|{ / / ...lambda});

[0066] (Empty line)

[0067] wanba::mediator

[0068] .target("callee_target")

[0069] .action("callee_action")

[0070] .params(value)

[0071] .handle(my_handle_func);

[0072] In addition, the remote call entry based on the Uniform Resource Identifier usually uses the rules of the preset Uniform Resource Identifier (URI) for calling; the cross-language call entry based on the preset interaction interface usually uses the rules of the above-mentioned preset Foreign Function Interface (FFI) protocol for calling the central star bridge module 201.

[0073] As Figures 1 to 3 shown, according to an embodiment of the present invention, the central star bridge module 201 includes a message queue unit 211.

[0074] The message queue unit 211 is used to realize message intertransmission between different application platforms with the process call module 120 through a preset interaction interface.

[0075] As Figures 1 to 3 shown, according to an embodiment of the present invention, the central star bridge module 201 further includes a thread pool unit 212.

[0076] The thread pool unit 212 is used to provide idle threads for asynchronous result waiting during the asynchronous message inter - transmission process, and to provide the main thread for synchronous result waiting during the synchronous message inter - transmission process.

[0077] As Figure 2 and Figure 3 shown, in the embodiment of the present invention, the essence of the central star - bridge module 201 is a message queue unit 311 based on the Rust language. Through a preset foreign function interface (FFI) protocol, input interfaces for different application platforms can be provided to achieve cross - platform message inter - transmission. Among them, for asynchronous messages, idle threads are selected from the thread pool unit (ThreadPool) 312 for asynchronous result waiting. Otherwise, during the synchronous message inter - transmission process, the main thread is directly used. Among them, during asynchronous calls, the callback uses the function message with message numbers (such as Figure 2 and Figure 3 shown msg_id 1, msg_id2, and msg_id 3) as a handle for callback. Specifically, the message number can be set as the callback handle to define the return rule when identifying the return result after message sending.

[0078] As Figure 3 shown, the message transmission method of the central star - bridge module 301 (i.e., the central star - bridge module 110 as Figure 1 shown or the central star - bridge module 201 as Figure 2 shown) can first perform message broadcasting, sending global messages to all other application platforms except the message source (such as Figure 3 shown source application platform, i.e., Source). Among them, the so - called message broadcasting can be understood as a message - sending mechanism for global message sending. Since each function component (module) corresponding to the hash - map call unit (Mediator) of each application platform has an introduced module function action (i.e., Action, such as message forwarding action) judgment function, it can be used to judge whether the application platform needs to perform message response (i.e., Res). If there is a hash - map call unit that can respond (i.e., the target application platform 333, Target), the binary data can be passed to the message queue unit 311 (i.e., the message queue unit 211 as Figure 2 shown) by calling the target procedure call unit 322 (MQ FFI) of the corresponding procedure call module 120, and then passed to the source procedure call unit 321 (MQ FFI) of the corresponding source application platform 331. If there is no application platform that can respond, the central star - bridge module 301 returns an exception message to the source application platform 331 (i.e., the message sender).

[0079] At this time, in the message queue unit 311 of the central star bridge module 301, since the message queue unit 311 itself is in the core layer and has global uniqueness, and the messages passed into the message queue unit 311 have been converted into a unified binary message format through the corresponding process call unit, the central star bridge module 301 can thus handle the message passing of cross-platform and cross-thread messages.

[0080] It should be noted that since the client load is relatively small and the real-time requirement is high, the consumption mode can be set to the push mode, and the message passing mode can be the publish-subscribe mode. Among them, the so-called push mode is usually a mode in which the sending end actively pushes messages to the receiving end, and the receiving end receives them passively. Among them, the push mode usually requires the sending end to identify the receiving end, and the receiving end information is already included in the message body, so it is usually suitable for message calls with clear targets (Targets), and is also suitable for sending messages one-to-one. In addition, the so-called publish-subscribe mode can be understood as that the message sender (i.e., the Source) sends messages to a specified topic (Topic), and subscribers can subscribe to the topic according to their interests and receive messages. The two are decoupled through the message queue unit 311 as an intermediate agent. Usually, the sender does not need to identify the receiving end, and it is suitable for one-to-many or many-to-many message passing scenarios.

[0081] Furthermore, as Figure 3 shown, an external register (External Register, abbreviated as Ext) 313 can be further provided in the central star bridge module 301, which can provide the corresponding message temporary storage and processing functions of three parts: a target cache (Target Cache) 313a, a flow monitor (Flow Monitor) 313b, and a message packager (Msg Packager) 313c. Details are not described here.

[0082] As Figures 1 to 3 shown, according to an embodiment of the present invention, the process call module 120 is implemented based on the local call conceptual model of a preset adaptive local process call protocol, and is used to build a message sending entry and a message receiving entry for different languages on different application platforms, and perform the conversion between functional messages and binary messages based on a preset binary data transmission protocol.

[0083] As Figure 2As shown in the figure, the process call module 120 may include a first process call unit 221 (such as Core ALPC Req and Core ALPC Res), a second process call unit 222 (such as Native ALPC Req and Native ALPC Res), and a third process call unit 223 (such as Script ALPC Req and Script ALPC Res). Among them, each process call unit can build a message sending entry and a message receiving entry for the function call language of each application platform based on the local call concept model of the preset adaptive local procedure call protocol (ALPC).

[0084] Specifically, each process call unit can perform message conversion and transmission of PB - type binary data based on the preset adaptive local procedure call protocol (ALPC). Among them, the preset adaptive local procedure call protocol can be designed as follows:

[0085]

[0086]

[0087]

[0088]

[0089]

[0090] Therefore, by means of the above - mentioned process call module, the ability to build general binary messages can be provided, enabling the message protocols for interaction between platforms to be unified, erasing the differences in cross - language interface calls between different languages, and achieving a unified interface call form.

[0091] As Figures 1 to 3 shown, according to an embodiment of the present invention, the virtual container module 130 includes an Action Inject unit, a Public Constant unit, a LifecyclePriority unit, and a Monitor Probe unit.

[0092] The Action Inject unit provides a type range corresponding to a single functional component of the application platform. The Action Inject unit is used for the function routing module to implement function query within the type range, realize the function opening of the functional component, and ensure the dynamic function call boundary;

[0093] The Public Constant unit is used to store key - value type data to provide query feedback of key - value type data to the corresponding application platform;

[0094] The lifecycle callback unit is used to uniformly manage the global lifecycle through the central star bridge module, provide lifecycle callback functions in the intelligent components of the corresponding application platform, and provide a service registration function with priorities.

[0095] The monitoring probe point unit is used to provide a unified business monitoring probe class for the functional components of the corresponding application platform, so as to complete the automatic message reporting through function polling and inheritance features.

[0096] The virtual container module 130 mainly provides the message processing functions of the above-mentioned action entry unit, common parameter unit, lifecycle callback unit, and monitoring probe point unit (it may also include other functional units, namely Other).

[0097] Among them, the action entry unit can provide an action entry. The action entry is essentially to define a specific type, use inheritance and other features to fix the type, and then let the function routing module 140 only query functions within the scope of this type. Correspondingly, each functional component (module) is only allowed to have one action entry, and the internal functions are opened through the action entry to ensure the dynamic function call boundary. Among them, this dynamic function call boundary can be determined according to the message transmission support range of the central star bridge module 110 in the embodiments of the present invention. Specifically, this support range requires that the language of the corresponding action entry itself has the message access ability of the above-mentioned preset interaction interface (i.e., the FFI language interaction interface protocol), and the language of the corresponding application platform can perform encoding and decoding in the PB format (i.e., the data exchange format of Protobuf).

[0098] The common parameter unit can usually utilize the global features of the central star bridge module 110 to store simple key-value type data (key-value). Application platforms in other languages can obtain the corresponding value through the key, so that small batches of data can be shared using this common parameter function.

[0099] The lifecycle callback unit can then uniformly manage the global lifecycle through the central star bridge module 110, provide a series of lifecycle callback functions in the specified type of the corresponding functional component (module), and at the same time provide a service registration function with priorities.

[0100] The form of the monitoring probe point unit is similar to the action entry provided by the action entry unit, provides a unified business monitoring probe class for the corresponding functional component (module), and completes the automatic message reporting through function polling and inheritance features.

[0101] Therefore, through the containerized virtual container module 130, cross-language and cross-platform function calls between different components at different levels can be realized, the difficulty of mutual calls between different languages including objective-c, java, rust, js, c++, etc. can be reduced, and a unified call method can be provided.

[0102] It should be noted that cross-process calls can usually be implemented through a preset inter-process communication protocol (Inter-Process Communication, abbreviated as IPC). For example, in an entertainment application platform based on the Android system (such as an application App), the game process is usually implemented as an independent subprocess. Even if there are exceptions in the game script or problems in the engine, it will not cause the entire App main body to crash and flash back. At this time, cross-process communication needs to be considered. Among them, considering the limited IPC implementation means of the application platform based on the iOS system, the Local Socket solution can also be used specifically. In the embodiments of the present invention, the message transmission architecture based on the central star bridge module does not include cross-process message passing.

[0103] In addition, Protobuf3 can be used as the carrier for data transmission. By using the cross-platform construction and binary transmission characteristics of Protobuf, the differences in data structures between different languages are smoothed out. And each data transmission is essentially a value copy, so there will be no memory leak problem. Among them, the so-called data structure differences can be understood as the differences in the memory models processed by different languages and application platforms of different operating systems. For example, the structure of a java class is inconsistent with the structure of a c++ class, and the two cannot directly recognize each other. Converting to a common binary protocol can erase the differences in the memory models between data structures.

[0104] Since the Ser / De overhead and memory overhead of Protobuf will increase exponentially for data volumes exceeding 1MB, Protobuf is used as the protocol carrier for large batches of data. The resources of the specific message body are synchronized through local files, and then accessed through the file IO interface of the corresponding application platform (i.e., the operating system platform). Among them, the local file is usually the local file generated by saving the message and can be directly read by the receiving end.

[0105] Such as Figure 1As shown, according to an embodiment of the present invention, any multiple of the central star bridge module 110, the procedure call module 120, the virtual container module 130, and the function routing module 140 may be combined and implemented in one module, or any one of them may be split into multiple modules. Alternatively, at least part of the functions of one or more of these modules may be combined with at least part of the functions of other modules and implemented in one module. According to an embodiment of the present invention, at least one of the central star bridge module 110, the procedure call module 120, the virtual container module 130, and the function routing module 140 may be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on chip, a system on substrate, a system on package, an application specific integrated circuit (ASIC), or may be implemented by any other reasonable means such as integrating or packaging circuits, etc., in hardware or firmware, or implemented in any one of the three implementation manners of software, hardware, and firmware, or in an appropriate combination of any several of them. Alternatively, at least one of the central star bridge module 110, the procedure call module 120, the virtual container module 130, and the function routing module 140 may be at least partially implemented as a computer program module, and when the computer program module is run, it may execute the corresponding functions.

[0106] Based on the message transmission device 100 between the above-mentioned multiple application platforms, the present invention also provides a message transmission method between multiple application platforms. The following will be combined with Figures 4A to 4C to describe this device in detail.

[0107] As shown in FIGS. 2 to Figure 4C As shown, another aspect of the embodiment of the present invention provides a message transmission method between multiple application platforms, wherein it is implemented based on the message transmission device 100 between multiple application platforms as shown in Figure 1 above.

[0108] As shown in Figure 2 and Figure 4A For the same-language timing of the same application platform, with reference to Figure 2, the first hash mapping call unit 241 (Mediator Core) corresponding to the function routing module 140 corresponds to the functional component a (i.e., Module a). Among them, a function call request call_func is sent to the first hash mapping call unit 241 through the functional component a. The call request may include a target functional component target (such as module b), a target action action, and callback information callback. The first hash mapping call unit 241 can perform a target search find_target. If the target functional component target cannot be found, an exception message return error is returned through the callback information callback. If the target functional component target is found and the corresponding functional action action is obtained, the first hash mapping call unit 241 sends a processing action exec_action to the corresponding target functional component target. The target functional component target will execute the corresponding function (do something), and finally feedback (return) the action execution result result to the first hash mapping call unit 241, which further feeds back the execution result to the functional component a. If the corresponding functional action action cannot be found, the first hash mapping call unit 241 will directly feedback an exception message return error. Therefore, the message transmission method of the embodiment of the present invention based on the same-language timing can be completed.

[0109] As Figure 2 and Figure 4B shown, for the cross-language synchronous timing of different application platforms, referring to Figure 2, the first hash mapping call unit 241 (Mediator Core) corresponding to the function routing module 140 corresponds to the functional component a (i.e., Modulea). Among them, a function call request call_func is sent to the first hash mapping call unit 241 through the functional component a. The call request may include a target functional component target (such as module b and module 1), a target action action, and callback information callback. The first hash mapping call unit 241 can perform a target search find_target on the central star bridge module 110. If the central star bridge module 110 cannot find the target functional component target, the central star bridge module 110 provides a target search cache find_target_cache with a search failure failed, and at the same time provides a notification notification of the target search cache find_target_cache with a search failure failed to other application platforms (such as moduleM). If the central star bridge module 110 finds the target functional component target, the central star bridge module 110 provides a target search cache find_target_cache with a search pass, and at the same time sends a function call request call_func to the target functional component (module 1) of the second hash mapping call unit 242. At this time, the function call request at least includes the target functional component target (such as module b and module 1) and the target action action. The second hash mapping call unit 242 sends the corresponding processing action exec_action to the corresponding target functional component target (such as module b and module 1), and the target functional component target executes the corresponding function (do something), and finally feeds back the execution result result (return). Specifically, it can be fed back to the corresponding functional component a of the first hash mapping unit 241 that sends the source message through the central star bridge module 110, which will not be elaborated here.

[0110] In addition, those skilled in the art should understand that for the message transmission method of the embodiments of the present invention with different languages and asynchronous timings for different application platforms, specifically as Figure 2 and Figure 4C shown, which will not be elaborated here. Therefore, the message transmission method between multiple application platforms in the embodiments of the present invention can implement the cross-language and cross-platform function interaction process of the client based on the above message transmission device, can solve the function call problem between all application platforms with FFI call capabilities in different languages at one time, and at the same time provide efficient and accurate management for the unified operation of functional modules in different languages, and can also provide message transmission processes including same-language timing, different-language synchronous timing, and different-language asynchronous timing.

[0111] Figure 5 A block diagram of an electronic device suitable for implementing a message transmission method between multiple application platforms according to an embodiment of the present invention is schematically shown.

[0112] The above-mentioned electronic device provided by an embodiment of the present invention includes one or more processors and a memory. The memory is used to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors are caused to execute the message transmission method between the above-mentioned multiple application platforms.

[0113] As Figure 5 shown, an electronic device 500 according to an embodiment of the present invention includes a processor 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage section 508 into a random access memory (RAM) 503. The processor 501 may include, for example, a general microprocessor (e.g., CPU), an instruction set processor, and / or a related chipset, and / or a dedicated microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 501 may also include on-board memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present invention.

[0114] In the RAM 503, various programs and data required for the operation of the electronic device 500 are stored. The processor 501, the ROM 502, and the RAM 503 are connected to each other via a bus 504. The processor 501 performs various operations of the method flow according to an embodiment of the present invention by executing the programs in the ROM 502 and / or the RAM 503. It should be noted that the programs may also be stored in one or more memories other than the ROM 502 and the RAM 503. The processor 501 may also perform various operations of the method flow according to an embodiment of the present invention by executing the programs stored in the one or more memories.

[0115] According to an embodiment of the present invention, the electronic device 500 may further include an input / output (I / O) interface 505, and the input / output (I / O) interface 505 is also connected to the bus 504. The electronic device 500 may further include one or more of the following components connected to the I / O interface 505: an input portion 506 including a keyboard, a mouse, etc.; an output portion 507 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc. and a speaker, etc.; a storage portion 508 including a hard disk, etc.; and a communication portion 509 including a network interface card such as a LAN card, a modem, etc. The communication portion 509 performs communication processing via a network such as the Internet. The drive 510 is also connected to the I / O interface 505 as needed. A removable medium 511, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 510 as needed so that a computer program read from it can be installed into the storage portion 508 as needed.

[0116] Among them, the electronic device according to the embodiment of the present invention may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, etc.

[0117] The present invention also provides a computer-readable storage medium, on which executable instructions are stored, and when the instructions are executed by a processor, the processor is caused to execute the message transmission method between the above-mentioned multiple application platforms.

[0118] Among them, the computer-readable storage medium may be included in the device / device / system described in the above embodiment; or it may exist separately without being assembled into the device / device / system. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed, the method according to the embodiment of the present invention is implemented.

[0119] According to an embodiment of the present invention, the computer-readable storage medium may be a non-volatile computer-readable storage medium, for example, it may include but not be limited to: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, the computer-readable storage medium may be any tangible medium that contains or stores a program, and the program can be used by or in combination with an instruction execution system, device, or device. For example, according to an embodiment of the present invention, the computer-readable storage medium may include the above-described ROM 502 and / or RAM 503 and / or one or more memories other than ROM 502 and RAM 503.

[0120] An embodiment of the present invention further includes a computer program product, which includes a computer program that, when executed by a processor, implements the message transmission method between the above-mentioned multiple application platforms.

[0121] Wherein, the computer program includes program code for executing the method shown in the flowchart. When the computer program product runs in a computer system, the program code is used to enable the computer system to implement the method provided by the embodiment of the present invention.

[0122] When the computer program is executed by the processor 501, it executes the above-mentioned functions defined in the system / apparatus of the embodiment of the present invention. According to an embodiment of the present invention, the above-mentioned systems, apparatuses, modules, units, etc. described above can be implemented by computer program modules.

[0123] In one embodiment, the computer program can rely on tangible storage media such as optical storage devices and magnetic storage devices. In another embodiment, the computer program can also be transmitted and distributed in the form of a signal on a network medium, and be downloaded and installed through the communication part 509, and / or be installed from the removable medium 511. The program code included in the computer program can be transmitted by any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0124] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 509, and / or be installed from the removable medium 511. When the computer program is executed by the processor 501, it executes the above-mentioned functions defined in the system of the embodiment of the present invention. According to an embodiment of the present invention, the above-mentioned systems, devices, apparatuses, modules, units, etc. described above can be implemented by computer program modules.

[0125] According to an embodiment of the present invention, the program code for executing the computer program provided by the embodiment of the present invention can be written in any combination of one or more programming languages. Specifically, these computing programs can be implemented using high-level procedures and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages include but are not limited to, such as Java, C++, python, the "C" language or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user's computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, by using an Internet service provider to connect through the Internet).

[0126] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, a segment of a program, or a part of code, and the above-mentioned module, segment of a program, or part of code contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than that marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, as well as combinations of blocks in the block diagram or flowchart, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0127] In addition, all actions of obtaining information, signals, or data in the present invention are carried out on the premise of complying with the corresponding data protection laws, regulations, and policies of the country where the location is located and obtaining authorization from the owner of the corresponding device.

[0128] Those skilled in the art can understand that the features described in various embodiments and / or claims of the present invention can be combined or / and combined in various ways, even if such combinations or combinations are not explicitly described in the present invention. In particular, without departing from the spirit and teachings of the present invention, the features described in various embodiments and / or claims of the present invention can be combined and / or combined in various ways. All such combinations and / or combinations fall within the scope of the present invention.

[0129] The above describes the embodiments of the present invention. However, these embodiments are only for illustrative purposes and not for limiting the scope of the present invention. Although the embodiments are described separately above, this does not mean that the measures in each embodiment cannot be used advantageously in combination. The scope of the present invention is defined by the appended claims and their equivalents. Without departing from the scope of the present invention, those skilled in the art can make various substitutions and modifications, and all such substitutions and modifications should fall within the scope of the present invention.

Claims

1. A message transmission device between multiple application platforms, characterized in that Comprising: A central star bridge module, configured to implement mutual transmission of functional messages between multiple application platforms through a preset interaction interface; A process call module, configured to perform conversion between the functional messages and binary messages during the mutual transmission of the functional messages; A virtual container module, configured to provide a unified module-level entry during the mutual transmission of the functional messages.

2. The device according to claim 1, wherein Further comprising: A function routing module, configured to interface with different application platforms and, during the mutual transmission of the functional messages, dynamically call different functional components of the corresponding application platforms according to the functional messages; Wherein, for the mutual transmission of functional messages between the same process and in the same language, the dynamic call is implemented through the function routing module; for the mutual transmission of functional messages between the same process and in different languages, the dynamic call is implemented by forwarding through the function routing module to the process call module.

3. The device according to claim 2, wherein The function routing module comprises: A hash map call unit, configured to implement the dynamic call based on a preset call entry, wherein the preset call entry includes a local call entry for a single process, a remote call entry based on a uniform resource identifier, and a cross-language call entry based on a preset interaction interface.

4. The device according to claim 2, wherein The central star bridge module comprises: A message queue unit, configured to implement message mutual transmission between different application platforms with the process call module through a preset interaction interface.

5. The device according to claim 4, characterized in that, The central star bridge module further comprises: A thread pool unit, configured to provide idle threads for asynchronous result waiting during asynchronous message mutual transmission, and provide a main thread for synchronous result waiting during synchronous message mutual transmission.

6. The device according to claim 2, characterized in that, The process call module is implemented based on a local call conceptual model of a preset adaptive local process call protocol, configured to construct a message sending entry and a message receiving entry for different languages of different application platforms, and perform conversion between the functional messages and binary messages based on a preset binary data transmission protocol.

7. The device according to claim 2, wherein The virtual container module comprises: An action entry unit, providing a type range corresponding to a single functional component of an application platform, for the function routing module to implement function query within the type range, implement the function opening of the functional component, and ensure the dynamic function call boundary; A common parameter unit, configured to store key-value type data to provide query feedback of the key-value type data to the corresponding application platform; A lifecycle callback unit, configured to perform unified management of the global lifecycle through the central star bridge module, provide lifecycle callback functions in intelligent components of the corresponding application platform, and provide a service registration function with priorities; A monitoring probe point unit, configured to provide a unified service monitoring probe class for functional components of the corresponding application platform to complete automatic message reporting through function polling and inheritance characteristics.

8. A message transmission method between multiple application platforms, characterized in that, Implemented based on the message transmission device between multiple application platforms according to any one of claims 1-7.

9. An electronic device, comprising: One or more processors; A memory, configured to store one or more programs, Wherein, when the one or more programs are executed by the one or more processors, the one or more processors are caused to execute the method according to claim 8.

10. A computer-readable storage medium having executable instructions stored thereon, which when executed by a processor cause the processor to perform the method recited in claim 8.

Images