Communication system and method of application

Abstract

The invention provides an application communication system and method. The system at least comprises an application layer and a framework layer. The application layer is used for sending first information of a first format generated by a first application to the architecture layer through a target interface; the architecture layer is used for receiving first information in a first format through a target interface, calling a target processing module matched with the first information in processing modules of N operating systems, and converting the first information in the first format into first information in a second format supported by a second application through the target processing module, the first information in the second format is sent to the application layer through the target interface; and the application layer is also used for receiving the first information in the second format through the target interface and transmitting the first information in the second format to a second application of the application layer. According to the scheme, communication between the three-dimensional vehicle control application and the native application of any operation system can be achieved, universality and compatibility are good, and expandability is high.

Description

Technical Field

[0001] This application relates to communication technology, and more particularly to an application communication system and method. Background Technology

[0002] With the rapid development of smart mobile devices and automotive electronics technology, users' demand for visual interactive functions such as 3D vehicle control is constantly growing. 3D vehicle control engines (such as Unity) are widely used in developing 3D vehicle control applications due to their cross-platform compatibility and powerful graphics rendering capabilities.

[0003] In related technologies, communication between 3D vehicle control applications and native applications requires design for a single platform. It can only enable communication between the 3D vehicle control application and a native application specifically designed for that operating system, and cannot enable communication between the 3D vehicle control application and any application on multiple platforms. Summary of the Invention

[0004] To address the aforementioned issues, this application provides at least one communication system and method for an application. This solution enables communication between a 3D vehicle control application and a native application of any operating system, exhibiting good versatility, compatibility, and scalability.

[0005] The technical solution of this application is implemented as follows: In a first aspect, this application provides a communication system for an application, comprising an application layer and an architecture layer; the application layer includes a 3D vehicle control application and a native application; the architecture layer includes processing modules of N operating systems, where N is greater than 1; the operating system of the native application is any one of the N operating systems; the application layer is used to: send first information in a first format generated by a first application to the architecture layer through a target interface; the architecture layer is used to: receive the first information in the first format through the target interface, and call a target processing module matching the first information in the processing modules of the N operating systems, convert the first information in the first format into first information in a second format supported by a second application through the target processing module, and send the first information in the second format to the application layer through the target interface; the application layer is also used to: receive the first information in the second format through the target interface, and transmit the first information in the second format to the second application of the application layer; wherein, when the first application is a 3D vehicle control application, the second application is a native application; when the first application is a native application, the second application is a 3D vehicle control application.

[0006] Secondly, this application provides a communication method for an application, applied to the architecture layer of an application's communication system; the communication system further includes an application layer, which includes a 3D vehicle control application and a native application; the architecture layer includes processing modules of N operating systems, and the operating system of the native application is any one of the N operating systems; N is greater than 1; the method includes: receiving first information in a first format sent by the application layer through a target interface of the architecture layer; the first information is information to be sent from a first application to a second application; the first application is either a 3D vehicle control application or a native application; calling a target processing module matching the first information in the processing modules of the N operating systems, and converting the first information in the first format into first information in a second format supported by the second application through the target processing module; sending the first information in the second format to the application layer through the target interface, so that the application layer can parse the first information in the second format; wherein, when the first application is a 3D vehicle control application, the second application is a native application of any operating system; when the first application is a native application of any operating system, the second application is a 3D vehicle control application.

[0007] Thirdly, this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program or instructions, which, when executed by the processor, implement the method provided in the second aspect.

[0008] Fourthly, this application also provides a storage medium storing a computer program or instructions that, when executed by a processor, implement any of the methods provided in the second aspect above.

[0009] Fifthly, this application also provides a computer program product comprising a computer program or instructions that, when executed by a processor, implement any of the methods provided in the second aspect above.

[0010] This solution achieves efficient communication between applications on different platforms (3D vehicle control applications and native applications) through the collaborative work of the application layer and the architecture layer. The application layer sends and receives information through the target interface, while the architecture layer is responsible for parsing and format conversion of the information. Format conversion enables the application layer and the architecture layer to perceive and interpret information, such as the perception and interpretation of information between the first application and the second application, thereby ensuring the readability, consistency, and stability of information across different platforms. Furthermore, the architecture layer includes processing modules for N operating systems, ensuring compatibility with applications on multiple operating systems. Applications on different operating systems can be directly applied without modification, offering high convenience. The communication system provided in this application embodiment is particularly suitable for communication scenarios between Unity 3D vehicle control applications and native applications such as Android, iOS, and HarmonyOS, exhibiting excellent scalability and compatibility. For example, if a new operating system emerges, relevant format conversion information for that new operating system can be directly added to the architecture layer to achieve compatibility with the new operating system, demonstrating good scalability. Attached Figure Description

[0011] Figure 1 A schematic diagram of a first optional structure of a communication system for an application provided in an embodiment of this application; Figure 2 A schematic diagram of a second optional structure of the communication system for the application provided in this application embodiment; Figure 3 A schematic diagram of a third optional structure of the communication system for the application provided in this application embodiment; Figure 4 A schematic diagram of a fourth optional structure of the communication system for the application provided in this application embodiment; Figure 5 A fifth optional structural diagram of the communication system for the application provided in this application embodiment; Figure 6 A schematic diagram of a sixth optional structure of the communication system for the application provided in this application embodiment; Figure 7 A schematic diagram of a seventh optional structure of the communication system for the application provided in this application embodiment; Figure 8 This is a schematic diagram of an optional structure of the communication system provided in an embodiment of this application; Figure 9 This is an optional flowchart illustrating the process by which a native application sends vehicle control commands to Unity, as provided in an embodiment of this application. Figure 10 This is a schematic flowchart of an optional communication method for an application provided in an embodiment of this application.

[0012] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the specific technical solutions of the application will be further described in detail below with reference to the accompanying drawings of the embodiments of this application. The following embodiments are used to illustrate this application, but are not intended to limit the scope of this application.

[0014] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0015] In the following description, the terms "first," "second," and "third" are used only to distinguish different objects and do not represent a specific order of objects or have any chronological limitation. It is understood that "first," "second," and "third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0016] 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.

[0017] This application provides communication systems, methods, devices, storage media, and program products for applications.

[0018] The following describes various embodiments of the communication system, method, device, storage medium, and program product provided in the embodiments of this application.

[0019] In a first aspect, embodiments of this application provide an application communication system.

[0020] refer to Figure 1 The application's communication system 10, as shown, includes an application layer 101 and an architecture layer 102. The application layer 101 includes a 3D vehicle control application 1011 and a native application 1012; the architecture layer 102 includes processing modules of N operating systems, where N is greater than 1; the operating system of the native application 1012 is any one of the N operating systems.

[0021] Application layer 101 is used to send the first information in the first format generated by the first application to architecture layer 102 through the target interface.

[0022] Architecture layer 102 is used to: receive first information in a first format through the target interface, call the target processing module that matches the first information in the processing modules of N operating systems, parse the first information in the first format through the target processing module and convert it into first information in a second format supported by the second application, and send the first information in the second format to application layer 101 through the target interface.

[0023] Application layer 101 is also used to: receive first information in a second format through a target interface, and transmit the first information in the second format to a second application of application layer 101.

[0024] In the case where the first application is a 3D vehicle control application, the second application is a native application; and in the case where the first application is a native application, the second application is a 3D vehicle control application.

[0025] For Application Layer 101: Application Layer 101 includes both the 3D vehicle control application 1011 and the native application 1012. The native application here can be a native application from any of the multiple operating systems. For example, it can include, but is not limited to, any of the following: native applications from the Android operating system, native applications from the Apple mobile operating system (iPhone Operating System, iOS), native applications from the HarmonyOS operating system, etc.

[0026] 3D Vehicle Control Application 1011 is an application used for controlling 3D vehicle models. In one example, 3D Vehicle Control Application 1011 can be a Unity application.

[0027] Application layer 101 is used to send first information in a first format generated by the first application to architecture layer 102 through a target interface. Among the first and second applications, one is a 3D vehicle control application 1011, and the other is a native mobile application 1012. That is, the communication system provided in this embodiment is used to realize communication between the first and second applications, specifically communication between the 3D vehicle control application 1011 and multiple native applications 1012 of different operation types.

[0028] In one possible implementation, the first application is a native mobile application 1012, the second application is a 3D vehicle control application 1011, and the first format is a format supported by the native mobile application 1012.

[0029] In another possible implementation, the first application is a 3D vehicle control application 1011, the second application is a native mobile application 1012, and the first format is a format supported by the 3D vehicle control application 1011.

[0030] The first information in the first format refers to the data format generated and output by the first application. For example, the first format can be a data form such as a structure or array, which is usually developed based on the C# language.

[0031] A target interface is an abstract concept representing a communication protocol or Application Programming Interface (API). The purpose of a target interface is to shield the differences between different platforms, enabling cross-platform information transfer. The design of a target interface allows the application layer to avoid concern itself with the specific implementation details of the underlying platform (architecture layer); the application layer only needs to call the interface according to the specification to complete information exchange.

[0032] In implementation, the target interface can be a well-encapsulated library that provides a unified entry point for calls. Cross-platform communication can be achieved simply by calling a simple function. The design of the target interface not only reduces development difficulty but also improves code maintainability and reusability. Through the standardized design of the target interface, the system can efficiently handle communication requests between multiple platforms, ensuring the consistency and reliability of information transmission.

[0033] For architecture layer 102: it is used to implement information format conversion, parsing, and information reception and transmission.

[0034] The parsing process refers to extracting key information from the original data in the first format and mapping it to a structure in the second format. For example, if the information in the first format is a Vector3 structure in Unity, it might be converted into a Java float array if the second application is a native Android application, and into an Objective-C CGPoint structure if the second application is a native iOS application.

[0035] In implementation, after receiving information in the first format, the architecture layer 102 first selects a matching processing module from among the processing modules of N operating systems as the target processing module based on the first information (e.g., the sender and receiver of the first information). Then, the target processing module performs format conversion according to its format conversion rules. After the conversion is complete, the architecture layer sends the information in the second format back to the application layer through the target interface for use by native applications. The process of the architecture layer receiving information in the first format, selecting the target processing module, determining the formatting rules, and sending the information in the second format back to the application layer ensures information compatibility between different platforms and avoids parsing errors or performance degradation caused by inconsistent data formats.

[0036] Furthermore, to improve communication efficiency, the architecture layer can cache commonly used data format mappings, reducing the time overhead of repeated parsing and conversion. Simultaneously, by introducing a priority mechanism, the architecture layer can prioritize important messages under high load, ensuring the responsiveness of critical operations.

[0037] Application layer 101 is also used to: receive first information in a second format through a target interface, and transmit the first information in the second format to a second application of the application layer.

[0038] Here, the first piece of information in the second format is information transformed by the architecture layer, i.e., the format supported by the second application. This information format is adapted to the platform characteristics of the second application. For example, if the second application is a native application on the Android platform, the first piece of information in the second format might be a Parcelable object, which can be directly read and displayed by the Android UI thread.

[0039] The communication system provided in this application embodiment achieves efficient communication between applications on different platforms (3D vehicle control applications and native applications) through the collaborative work of the application layer and the architecture layer. The application layer sends and receives information through a unified target interface, while the architecture layer is responsible for parsing and format conversion of the information. Format conversion enables the application layer and the architecture layer to perceive and interpret information, such as the perception and interpretation of information by the first application and the second application, thereby achieving readability, consistency, and stability of information across different platforms. Furthermore, the architecture layer includes processing modules for N operating systems, ensuring compatibility with applications on multiple operating systems. Applications on different operating systems can be directly applied without modification, offering high convenience. The communication system provided in this application embodiment is particularly suitable for communication scenarios between Unity 3D vehicle control applications and native applications such as Android, iOS, and HarmonyOS, exhibiting excellent scalability and compatibility. For example, if a new operating system emerges, relevant format conversion information for that new operating system can be directly added to the architecture layer to achieve compatibility with the new operating system, demonstrating good scalability.

[0040] The structure of architecture layer 102 will be described below.

[0041] Architecture layer 102 is the core component of the cross-platform communication framework. Its role is to act as an intermediary between the 3D vehicle control application and the native application. Architecture layer 102 consists of interface layer 1021 and processing layer 1022, which are responsible for data reception and forwarding, and data processing and logic control, respectively.

[0042] refer to Figure 2As shown, the architecture layer 102 may include an interface layer 1021 and a processing layer 1022. The interface layer 1021 includes parsing interfaces for N operating systems and parsing interfaces for 3D vehicle control applications, and the processing layer 1022 includes processing modules for N operating systems.

[0043] For interface layer 1021: Interface layer 1021 is used to receive first information and first status identifier in first format through first interface, and based on the first status identifier, call the first target parsing interface that matches the first information in the parsing interfaces of N operating systems and the parsing interface of 3D vehicle control application, parse the first information in first format through the first target parsing interface, convert the first information in first format into third format, and send the first information in third format to processing layer 1022 through second interface.

[0044] The first interface is the interface between the interface layer 1021 and the application layer 101, that is, the upward interface of the interface layer 1021.

[0045] The second interface is the interface between the interface layer 1021 and the processing layer 1022, that is, the downward interface of the interface layer 1021.

[0046] The main function of Interface Layer 1021 is to interface with raw data input from different platforms (i.e., different applications, such as Android, iOS, and HarmonyOS) and unify this raw data into a standard format so that the processing layer can perform subsequent operations efficiently. At the same time, Interface Layer 1021 is also responsible for outputting the processed data to the native application in a way that is adapted to each platform.

[0047] The first state identifier points to the first application. Based on the first state identifier, it's possible to determine which application is being used, thus identifying the format of the first information. The corresponding first target parsing interface is then invoked to parse the first information in the first format and convert it into a third format. This third format is a dedicated format configured for the architecture layer; regardless of the first application, the first information in the first format can be converted to a unified third format, achieving consistency at the architecture layer. After obtaining the first information in the third format, it is sent to the processing layer 1022 via the second interface.

[0048] The third format can be configured according to actual needs, and this application embodiment does not limit it. For example, the third format may include a message header and a message body. The message header includes basic information such as version number, message type, channel name, priority, timestamp, sender identifier, and receiver identifier. The message body includes the actual data content. The message trailer contains security verification information such as checksum and digital signature. This standardized design ensures the consistency and integrity of messages when transmitted across different platforms.

[0049] The first status identifier can be sent together with the first message, or it can be sent separately.

[0050] The sending and receiving of messages between interfaces can be implemented using a message subscription mechanism. This is achieved by configuring the sender and receiver of the interfaces to manage message transmission between them.

[0051] By introducing the first and second interfaces, data from different platforms (different types of applications) can be treated consistently in the same processing flow, achieving data reception and standardized output, and improving the stability and flexibility of communication.

[0052] For processing layer 1022: The processing layer 1022 focuses on parsing, transforming, and logically judging data. The design of the processing layer gives the entire system good decoupling, making it easy to expand and maintain.

[0053] The processing layer 1022 is used to: receive first information in a third format through the second interface, and send the first information in the third format and the second status identifier to the interface layer 1021 through the second interface.

[0054] In the processing modules of N operating systems, the target processing module that matches the first information is called. After the target processing module processes the first information in the third format, the first information in the third format and the second status identifier are sent to the interface layer 1021 through the second interface.

[0055] The processing here may include, but is not limited to: serialization, deserialization, etc.

[0056] The processing layer 1022 receives third-format data from the interface layer through the second interface. After the third-format data from the interface layer has undergone preliminary processing, the processing layer can focus on executing business logic, such as analyzing, calculating, storing, or triggering other events on the data. After processing is complete, the processing layer 1022 returns the processing result along with a second status identifier to the interface layer 1021 through the second interface.

[0057] Interface layer 1021 is also used to: receive first information in a third format through a second interface; based on the indication of a second status identifier, it can perceive who the second application is and know the recipient of the first information. Then, based on the indication of the second status identifier, it calls a second target parsing interface matching the first information from among the parsing interfaces of N operating systems and the parsing interface of the 3D vehicle control application; through the second target parsing interface, it converts the first information in the third format into first information in the second format; and sends the first information in the second format to application layer 101 through the first interface.

[0058] Interface layer 1021 receives the third-format data returned by the processing layer again through the second interface, and determines whether a final format conversion is needed based on the second status flag. If necessary, interface layer 1021 will convert the third-format data into a second format suitable for the second application to ensure that the data meets the requirements of the target platform (second application).

[0059] After the conversion is complete, the interface layer sends the data in the second format to the application layer 101 through the first interface, completing the entire communication process. This communication process ensures the integrity of cross-platform communication, enabling seamless data transfer between Unity applications and native applications.

[0060] By dividing the architecture layer into an interface layer and a processing layer, data transmission functions and business logic processing can be effectively separated, improving the system's modularity and thus enhancing overall development efficiency and operational stability. Furthermore, by adopting a unified interface design and status identification mechanism, efficient cross-platform communication can be achieved. This division shields the underlying differences between different platforms, enabling "develop once, deploy on multiple platforms," ​​significantly reducing development and maintenance costs and improving system scalability and compatibility.

[0061] The structure of the processing layer 1022 will be described below.

[0062] In one possible implementation, refer to Figure 3 The processing layer 1022 includes a core layer 10221, a platform abstraction layer 10222, and a platform native layer 10223. The platform abstraction layer 10222 includes adapters for N operating systems. The platform native layer 10223 includes a native layer of N operating systems embedded with a 3D vehicle control program.

[0063] The processing layer 1022 is responsible for coordinating communication and data processing between the 3D vehicle control application and different operating systems. The processing layer consists of three layers: the core layer 10221, the platform abstraction layer 10222, and the native platform layer 10223. The core layer provides a unified communication interface and message processing logic, the platform abstraction layer shields the underlying platform differences, and the native platform layer is responsible for interacting with the specific implementations of each operating system.

[0064] The platform native layer 10223 refers to the actual operating system environment running on the terminal device, such as Android, iOS, and HarmonyOS. These operating systems each have different APIs and communication mechanisms. To improve compatibility and flexibility, the platform native layer embeds a 3D vehicle control program, supporting the simultaneous operation of at least two operating systems. Because the platform native layer embeds a 3D vehicle control program and supports the operation of multiple operating systems, 3D vehicle control applications can seamlessly connect to multiple platforms, reducing redundant development work.

[0065] By introducing a multi-layered processing architecture, consistency and efficiency in cross-platform communication can be achieved. This multi-layered architecture reduces platform adaptation costs, thereby improving development efficiency and enabling broader platform coverage.

[0066] The core layer 10221 is used to: receive first information in a third format through the second interface, and after performing first processing on the first information in the third format, send it to the platform abstraction layer 10222 through the third interface.

[0067] The first processing may include, but is not limited to, at least one of the following: message routing, serialization processing, message priority determination and downward transmission, lifecycle management, shared memory management, etc.

[0068] The third interface is the data transmission interface between the core layer 10221 and the platform abstraction layer 10222.

[0069] The platform abstraction layer 10222 is used to: receive first information in a third format through a third interface; call the target adapter that matches the first information in the adapters of N operating systems based on the indication of the first status identifier or the second status identifier; convert the first information in the third format into first information in a fourth format supported by the target operating system through the target adapter; and send the first information in the fourth format to the platform native layer 10223 through the fourth interface.

[0070] The fourth interface is the data transmission interface between the platform abstraction layer 10222 and the platform native layer 10223.

[0071] For example, if the first application is an Android application, the platform abstraction layer 1022 converts the first information in the third format into the first information in the fourth format that can be interpreted by the Android application based on the indication of the first state identifier.

[0072] For example, in the case of a three-dimensional vehicle control application, the platform abstraction layer 1022 converts the first information in the third format into the first information in the fourth format that can be interpreted by the second application based on the indication of the second state identifier.

[0073] The fourth format is a data format optimized for a specific operating system. For example, Android might use Java objects, iOS might use Objective-C objects, and HarmonyOS might use ArkTS objects. After the platform abstraction layer converts the first information in the third format into the first information in the corresponding fourth format for the platform, it sends this first information to the platform's native layer through the fourth interface. In this way, the platform abstraction layer ensures that messages can be executed correctly on different platforms.

[0074] The platform abstraction layer (PAL) conversion mechanism enables flexible adaptation between platforms. This avoids the complexities of directly connecting to each platform's API. The PAL conversion mechanism simplifies the development process and improves code reusability.

[0075] The platform native layer 10223 is used to: receive the first information in the fourth format through the fourth interface, then call the target operation native layer that matches the first information in the native layers of N operating systems through the target adapter, and after the target operation native layer verifies the first information in the fourth format, send the first information in the fourth format to the platform abstraction layer through the fourth interface.

[0076] The platform native layer 10223 is responsible for interacting with the underlying operating system and executing specific business logic. The platform native layer receives first information in a fourth format from the platform abstraction layer 10222 through the fourth interface and verifies that the format and content of the first information in the fourth format are correct. After successful verification, the platform native layer sends the first information in the fourth format to the platform abstraction layer through the fourth interface, completing a full two-way communication process.

[0077] This verification mechanism is crucial for ensuring system security, especially in sensitive scenarios involving vehicle control and user authentication. It can prevent unauthorized data from entering the system, thereby helping to improve the overall stability and reliability of the system.

[0078] By employing a platform-native verification mechanism, invalid or malicious data can be effectively filtered out. This mechanism enhances the system's security capabilities, thereby mitigating potential security risks and increasing user trust.

[0079] The platform abstraction layer 10222 is also used to: receive first information in a fourth format through a fourth interface, convert the first information in the fourth format into first information in a third format based on the indication of a first state identifier or a second state identifier, and send the first information in the third format to the core layer through a third interface.

[0080] For example, if the first application is an Android application, the platform abstraction layer 1022 converts the first information in the fourth format into the first information in the third format based on the indication of the first state identifier.

[0081] For example, in the case of a three-dimensional vehicle control application, the platform abstraction layer 1022 converts the first information in the fourth format into the first information in the third format based on the indication of the second state identifier.

[0082] After receiving the first information in the fourth format returned by the platform's native layer, the platform abstraction layer converts the first information in the fourth format into the first information in the third format based on either the first or second status identifier, and then sends it to the core layer through the third interface. This process of the platform abstraction layer converting the first information in the fourth format into the first information in the third format based on the status identifier and sending it to the core layer through the third interface achieves a closed loop for cross-platform communication. In this way, the platform abstraction layer ensures accurate message transmission between multiple layers.

[0083] The reverse translation mechanism of the platform abstraction layer (PAL) ensures the integrity of cross-platform communication. It guarantees data consistency across all layers, improves communication reliability, and enhances the overall robustness of the system.

[0084] The core layer 10221 is also used to: receive first information in three formats through the third interface, perform second processing on the first information in the third format, and then send the first information in the third format to the interface layer through the second interface.

[0085] After receiving the first information in the third format returned by the platform abstraction layer 10222, the core layer 10221 will perform a second processing on the information. The second processing usually includes further logical processing, data aggregation, or state updates. After completing the second processing, the core layer sends the first information in the third format to the interface layer through the second interface, so that the upper-layer application can call or display the information.

[0086] The secondary processing mechanism at the core layer enables more complex data logic processing. This mechanism enhances the system's capabilities in data integration and decision support, thereby improving user experience and meeting the needs of a wider range of application scenarios.

[0087] In this embodiment, a layered design and message conversion mechanism enable efficient communication between the 3D vehicle control application and Android, iOS, and HarmonyOS platforms. By adopting this layered design and message conversion mechanism, the difficulty of cross-platform development can be reduced, thereby improving development efficiency and enabling wider application deployment.

[0088] The structure of the platform abstraction layer 10222 will be explained below.

[0089] In one possible implementation, refer to Figure 4 As shown, the platform abstraction layer 10222 includes three adapters; The first adapter 102221 is used to: convert first information between Android supported formats and third formats.

[0090] When the native application is an Android application, the first adapter is used to convert the first information between Android-supported formats and third formats.

[0091] The first adapter is an interface module specifically designed for the Android platform. It is responsible for bidirectional conversion between data formats supported by the Android system (such as Parcelable, Bundle, JSON, etc.) and the unified data format defined internally by the framework (i.e., the third format). Android supported formats refer to the standardized data representations commonly used in the Android operating system, such as Intent objects, Bundle objects, Parcel objects, etc. These formats are widely used in the Android system but are not universally applicable to other platforms.

[0092] The first adapter encapsulates messages sent from 3D applications to the Android platform in Android-supported formats, facilitating native application reception and processing. Simultaneously, it converts data returned from the Android platform into a third-party format for 3D vehicle control applications to parse and use. This first adapter implements a cross-platform message format conversion mechanism, freeing developers from concern themselves with the underlying platform's specific data formats; they can focus solely on business logic, significantly reducing development difficulty and maintenance costs.

[0093] The second adapter 102222 is used to: convert first information between iOS supported formats and third formats.

[0094] When the native application is an iOS application, the conversion of the first information between iOS supported formats and the third format is achieved through the second adapter.

[0095] The second adapter is an interface module designed for the iOS platform. It is responsible for converting between data formats supported by the iOS system (such as NSDictionary, NSData, NSValue, etc.) and a third format. iOS supported formats are a set of standard data types defined by Apple, primarily used in applications written in Objective-C or Swift. Because iOS and Android have significant differences in data structures, a dedicated adapter is needed to handle interoperability issues between these formats.

[0096] In practical applications, when a Unity application sends control commands to the iOS platform, the second adapter converts the commands into an iOS-recognizable format (such as NSData) so that the native code can correctly parse and execute these commands. Similarly, when the iOS platform responds to a Unity request, the second adapter converts the iOS-formatted data into a third format to ensure that the Unity application can accurately understand the received information.

[0097] By using a second adapter, developers can achieve efficient communication with Unity3D vehicle control applications without modifying the original iOS code. This approach can improve development efficiency and enhance system stability.

[0098] The third adapter 102223 is used to: convert first information between HarmonyOS supported formats and third formats.

[0099] When the native application is a HarmonyOS application, the conversion of the first information between the HarmonyOS support format and the third format is achieved through the second adapter.

[0100] The third adapter is an interface module specifically designed for HarmonyOS, used to convert data between HarmonyOS-supported formats (such as ArkTS objects, distributed capability-related data structures, etc.) and third-party formats. HarmonyOS-supported formats are based on HarmonyOS-specific languages ​​(such as ArkTS) and a set of data types defined by those languages, offering strong distributed characteristics and modular design advantages.

[0101] The third adapter fills the technological gap in the market by providing a solution for communication between Unity and the HarmonyOS operating system, enabling 3D vehicle control applications to run stably within the HarmonyOS ecosystem, thereby improving the compatibility and market adaptability of 3D vehicle control applications.

[0102] In this embodiment, by setting up three adapters corresponding to the Android, iOS, and HarmonyOS platforms respectively, this application embodiment achieves efficient conversion between a unified data format (third format) and the local formats of each platform. Through the above method, this application embodiment can effectively solve the problem of format inconsistency in cross-platform communication, thereby improving communication efficiency and system stability, and ultimately enabling a smoother and more intelligent 3D vehicle control experience.

[0103] The structure of the platform's native layer 10223 will be explained below.

[0104] In one possible implementation, the platform native layer includes the Android native layer, the iOS native layer, and the HarmonyOS native layer.

[0105] The native Android layer is used to verify the first information that supports the fourth format of the Android system.

[0106] When the native application is an Android application, the first information that supports the fourth format of the Android system is verified through the native Android layer.

[0107] After receiving the first message, the Android native layer will verify the first message according to the Android platform's security policies and communication specifications to ensure that the first message is in the correct format, has a legitimate source, and is free from malicious behavior.

[0108] The native iOS layer is used to: validate the first information in the fourth format that supports the iOS system.

[0109] When the native application is an iOS application, the first information in the fourth format that supports the iOS system is verified through the native Android layer.

[0110] Upon receiving the initial information, the iOS native layer will verify it according to the iOS platform's security mechanisms, including signature verification and permission checks, to prevent unauthorized access or abnormal operations.

[0111] The HarmonyOS native layer is used to verify the first information in the fourth format that supports the HarmonyOS system.

[0112] When the native application is a HarmonyOS application, the first information supporting the fourth format of the HarmonyOS system is verified through the Android native layer.

[0113] The HarmonyOS native layer will verify the first information in accordance with the characteristics of the HarmonyOS system, such as by using a distributed security model and multi-terminal identity authentication. The HarmonyOS native layer ensures the reliability and consistency of information in cross-device scenarios.

[0114] The platform's native layer implements verification operations through a mechanism that validates the initial information, effectively ensuring the security and stability of communication. The platform's native layer also prevents interference or damage to the system caused by unauthorized requests or erroneous data. These measures contribute to improving the overall system's robustness and user experience.

[0115] In this embodiment, by expanding the native layer into three types—Android native layer, iOS native layer, and HarmonyOS native layer—and introducing the corresponding platform native layer to verify the first information in the fourth format, unified communication and efficient management of 3D vehicle control applications across multiple platforms can be achieved. This can reduce development costs, improve system compatibility, and enhance the market adaptability and promotion efficiency of cross-platform applications.

[0116] The structure of interface layer 1021 will be described below.

[0117] In one possible implementation, refer to Figure 5 If the application layer includes a 3D vehicle control application, an Android application, an iOS application, and a HarmonyOS application, then the interface layer 1021 includes: a first interface 10211, a second interface 10212, a third interface 10213, and a fourth interface 10214.

[0118] Application Layer 101 is the top layer of the communication system, containing 3D vehicle control applications and native applications from various operating systems. These applications communicate through a unified message channel, eliminating the need to directly handle differences between underlying platforms. The application layer supports the following four types of applications: A 3D vehicle control application is software that can control vehicle status, display a 3D model, and enable user interaction with the 3D model; it is a type of 3D graphical user interface application. An Android application is a native application that runs on the Android platform and is developed by developers using Java or Kotlin programming languages. An iOS application is an application that runs on the iOS platform; these applications are typically developed by developers using Objective-C or Swift. HarmonyOS applications run on the HarmonyOS platform and are primarily developed using the ArkTS language.

[0119] The first interface 10211 is used to: convert first information between the format supported by Android applications and the third format.

[0120] The first format is a format supported by Android applications. For example, the first interface 10211 can be used to convert first information in the first format (a format supported by Android applications) into first information in the third format; or to convert first information in the third format into first information in the first format.

[0121] The first interface is a data conversion module designed for the Android platform. It is responsible for converting specific data formats used by Android applications (such as JSON, Parcelable, etc.) into a unified third-party format used by the architecture layer, and vice versa. Because the Android platform's API is relatively open, but there are significant differences between different versions, the first interface uses abstraction to ensure stable data conversion regardless of changes in the Android version.

[0122] For example, when updating vehicle status, an Android application might send a JSON object containing the vehicle's speed, direction, and position. The first interface parses the JSON object and converts it into a third format for efficient processing on the Unity side. This operation by the first interface not only improves data transmission efficiency but also reduces errors caused by format inconsistencies.

[0123] The second interface 10212 is used to: convert the first information between the format supported by the iOS application and the third format.

[0124] The first format is a format supported by iOS applications. For example, the second interface 10212 can be used to convert the first information in the first format (the format supported by iOS applications) into the first information in the third format; or to convert the first information in the third format into the first information in the first format.

[0125] The second interface is a data conversion module designed for the iOS platform. Due to the strict limitations of the iOS platform on memory management and thread scheduling, the second interface specifically optimizes data serialization and deserialization performance to ensure smooth operation even in high-frequency communication scenarios. Furthermore, considering the mixed use of Objective-C and Swift languages ​​on the iOS platform, the second interface provides a highly compatible encapsulation method, ensuring that native components written in different languages ​​can be called smoothly.

[0126] For example, when a user operates the vehicle control buttons on an iOS device, the second interface converts the user's operation command into a third format and transmits it to the Unity application via a message channel, causing the 3D model to update synchronously. The design of the second interface ensures consistency and real-time performance across platforms.

[0127] The third interface 10213 is used to: convert the first information between the format supported by HarmonyOS applications and the third format.

[0128] The first format is a format supported by HarmonyOS applications. For example, the third interface 10213 can be used to convert the first information in the first format (the format supported by HarmonyOS applications) into the first information in the third format; or to convert the first information in the third format into the first information in the first format.

[0129] The third interface is a communication adaptation module specifically designed for the HarmonyOS system. HarmonyOS's communication mechanism differs significantly from Android and iOS. Through deep integration of ArkTS language features, the third interface achieves efficient format conversion and message routing functions. Because HarmonyOS emphasizes distributed capabilities, the third interface also supports multi-device collaborative communication. The third interface allows 3D vehicle control applications to seamlessly switch between multiple terminals such as mobile phones, in-vehicle screens, and tablets.

[0130] For example, when a user starts the 3D vehicle control function on a HarmonyOS device, the third interface will automatically identify the device type and dynamically adjust the communication strategy according to the resource status of the HarmonyOS device, thereby improving the overall response speed and user experience.

[0131] The fourth interface 10214 is used to: realize the conversion of first information between the format supported by the three-dimensional vehicle control application and the third format.

[0132] The first format is a format supported by 3D vehicle control applications. For example, the fourth interface 10214 can be used to convert the first information in the first format (the format supported by 3D vehicle control applications) into the first information in the third format; or to convert the first information in the third format into the first information in the first format.

[0133] The fourth interface is a data conversion module specifically designed for 3D vehicle control applications. Because Unity uses the C# language, Unity's data structures differ significantly from those of native platforms. The fourth interface converts 3D data types such as vectors, matrices, and colors used in 3D vehicle control applications into a unified third-party format, facilitating cross-platform communication. Furthermore, the fourth interface supports efficient sharing of large resources such as textures and models, reducing performance overhead from repeated loading.

[0134] For example, during the vehicle model rendering process, the 3D vehicle control application generates a large amount of 3D data. The fourth interface will package the large amount of 3D data generated by the 3D vehicle control application into a standard format and pass this data to the native application through the resource sharing manager so that the native application can load and display the 3D model. Thus, the cross-platform display of the 3D model is achieved through the collaboration between the 3D vehicle control application and the native application.

[0135] For example, by adopting an interface layered design approach, developers can deploy primary information (such as applications) to multiple different platforms (such as Android, iOS, or HarmonyOS) without modifying the business logic code, thereby significantly reducing the workload and complexity involved in cross-platform development.

[0136] The structure of the core layer 10221 will be explained below.

[0137] In one possible implementation, refer to Figure 6 The core layer 10221 shown may include: a serialization module 102211, a lifecycle management module 102212, and a resource processing module 102213.

[0138] The serialization module 102211 is used to serialize and deserialize the first information in the third format.

[0139] The first process includes serialization, and the second process includes deserialization.

[0140] For example, when the first application needs to transmit data to the second application, the data is converted to a third format and serialized during the first transmission to the core layer 10221, thereby improving the transmission efficiency of subsequent data. During the second transmission to the core layer 10221, the serialized binary data is restored to its original format, making it easier for the second application to interpret.

[0141] Using efficient binary encoding instead of the traditional JSON text format improves communication efficiency and reduces network bandwidth and memory consumption.

[0142] The lifecycle management module 102212 is used to manage the lifecycle between the first application and the second application, so that the lifecycles of the first application and the second application are kept synchronized, so that the first application can send the first information to the second application under the synchronized lifecycle.

[0143] The primary function of the lifecycle management module is to coordinate state changes between the first and second applications, such as initialization, pause, resumption, and destruction. Through a unified lifecycle event listening mechanism, the lifecycle management module ensures that the first application automatically pauses rendering and physics simulation when entering the background and quickly resumes upon reactivation, thus avoiding resource waste and state inconsistencies. Furthermore, the lifecycle management module can proactively clean up shared resources when either the first or second application exits, preventing memory leaks.

[0144] The resource processing module 102213 is used to: realize resource sharing between the first application and the second application under the instruction of the resource sharing identifier when the first information includes a resource sharing identifier.

[0145] The resource processing module 102213 enables efficient resource sharing between the first and second applications upon receiving the first information, including a resource sharing identifier. Especially for large resources such as 3D models, textures, and audio, the module employs memory mapping technology to avoid redundant loading and data copying as in traditional methods. By generating a unique resource ID and notifying either the first or second application to access the shared resource, the module significantly reduces memory usage and improves overall performance. The module also supports dynamic updates; when a resource change is detected, it re-shares some data, further reducing transmission overhead.

[0146] In this embodiment, by dividing the core layer into a serialization module, a lifecycle management module, and a resource processing module, functional decoupling and modular design can be achieved, thereby improving the system's stability and maintainability, and further enhancing the overall efficiency of cross-platform communication.

[0147] The serialization module is responsible for converting data structures into a binary format suitable for transmission, while deserialization restores the received binary data back to its original structure. The lifecycle management module ensures state synchronization between the first and second applications, preventing abnormal behavior caused by state inconsistencies. The resource processing module coordinates shared resources between the first and second applications, such as 3D models and textures, reducing redundant loading and memory consumption.

[0148] In practice, the serialization module and the lifecycle management module work together. For example, before data transmission, the lifecycle management module will confirm whether the target application is available, and then the serialization module will perform the serialization operation to ensure the orderliness and reliability of the communication process.

[0149] The structure of the serialization module 102211 will be described below.

[0150] In one possible implementation, refer to Figure 7 As shown, the serialization module 102211 may include a basic type codec 1022111, a three-dimensional type codec 1022112, and a complex object codec 1022113.

[0151] Basic type codecs are used to serialize and deserialize basic data.

[0152] The core function of a basic type codec is to convert basic data types in C# (such as int, float, bool, etc.) into binary format for network transmission or storage, and vice versa. The process of converting basic data types in C# into binary format is called serialization and deserialization. Since basic data types in C# are widely used in communication between Unity and the native platform, the encoding and decoding efficiency of the basic type codec directly affects the overall communication performance.

[0153] In practical applications, basic type codecs select the optimal encoding method based on platform characteristics. For example, on the Android platform, the Java NIO library might be used for byte buffer operations, on iOS, the Objective-C NSData class might be used, and on the HarmonyOS platform, the ArkTS ArrayBuffer interface might be used. This method of selecting the appropriate encoding method based on different platform characteristics ensures efficient processing of basic types on different platforms.

[0154] By efficiently handling basic data types, unnecessary memory copies and type conversions can be reduced. This speeds up data exchange, ultimately improving the overall system efficiency.

[0155] 3D type codecs are used for serializing and deserializing vectors, matrices, quaternions, and 3D data.

[0156] The 3D type codec is specifically designed for 3D mathematical structures commonly used in 3D vehicle control applications, including Vector3, Matrix4x4, and Quaternion. These data types play important roles in vehicle control, physics engines, and animation systems, and the 3D type codec must ensure high fidelity and low latency for these data types in cross-platform communication.

[0157] To achieve this goal, the 3D type codec employs a compact binary format and preprocesses common operations to avoid redundant calculations. For example, for the Vector3 type, the 3D type codec can directly write the three components (x, y, z) of the Vector3 type into a byte array in sequence without additional wrapping.

[0158] In addition, the 3D type codec supports version compatibility, meaning that when the data format changes, the 3D type codec can still correctly parse the old version of the data, ensuring that applications with different versions of the 3D type codec can communicate normally.

[0159] By employing a customized encoding and decoding strategy for 3D data, this strategy enables more efficient serialization and deserialization operations, reduces data transmission time and memory usage, and enhances system stability and real-time response capabilities.

[0160] Complex object codecs are used for serialization and deserialization of third-format data.

[0161] Complex object codecs are responsible for handling non-basic data structures, such as GameObject, Transform, and ScriptableObject in Unity. These objects typically contain multiple properties, nested structures, and even event bindings, making their serialization and deserialization processes more complex.

[0162] To address this issue, complex object codecs employ a reflection and metadata-based mechanism to automatically identify object member variables and their types, generating corresponding serialization instructions. Furthermore, complex object codecs support user-defined serialization logic, allowing developers to deeply customize specific types to meet unique needs.

[0163] In practice, complex object codecs generate a unique identifier (ID) for each object and record the complete structure of each object generated by the complex object codec during the initial transmission. Subsequently, if the objects generated by the complex object codec undergo partial changes, only the differing parts need to be transmitted, thereby reducing data transmission volume and improving efficiency.

[0164] Basic type codecs are used for serialization and deserialization of basic data types such as integers, floating-point numbers, and booleans. These basic data types are the most commonly used data formats in cross-platform communication, and using efficient basic type codecs can significantly improve data conversion efficiency.

[0165] The 3D type codec is specifically optimized for 3D mathematical structures such as vectors, matrices, and quaternions used in 3D vehicle control applications. Since the 3D type codec is designed to represent vehicle position, rotation state, and physical simulation parameters using these frequently used data types in 3D vehicle control scenarios, an efficient encoding / decoding mechanism is required to reduce CPU overhead and accelerate data transmission speed.

[0166] Complex object codecs are used to handle data consisting of multiple custom data types, and three-dimensional type codecs ensure consistency of complex objects across different platforms. For example, complex object codecs are used to handle data in third-party formats.

[0167] In this way, by processing different types of data separately, more precise data control can be achieved, thereby improving the efficiency and accuracy of overall serialization, which in turn can reduce communication latency and improve system response speed.

[0168] The communication system of the application will be described below through an example.

[0169] With the widespread adoption of smart mobile devices and the continuous improvement of automotive intelligence, the demand for 3D vehicle control functionality within mobile applications is growing rapidly. Unity, as a leading global 3D real-time rendering engine, is widely used in mobile 3D scene development due to its powerful cross-platform capabilities and excellent graphics rendering performance. However, when 3D vehicle control applications developed using Unity need to be embedded into native applications, these applications face several key technical challenges: 1. Severe Platform Fragmentation: Currently, mobile device operating systems mainly include Android and iOS, while HarmonyOS, which has developed rapidly in China in recent years, has also occupied a certain market share. Android, iOS, and HarmonyOS differ significantly in architecture, API interfaces, and communication mechanisms. Traditional application development requires separate development for different platforms, resulting in high maintenance costs and difficulty in unified management.

[0170] 2. Inconsistent Communication Mechanisms: Communication between Unity and native platforms exists in multiple ways, but lacks a unified standard and framework. On Android, it's primarily implemented through JNI (Java Native Interface); on iOS, it mainly relies on Objective-C interoperability; while on HarmonyOS, it requires the use of a specific interface provided by the Unity engine for communication with ArkTS. These multiple communication implementations necessitate developers mastering multiple technical systems and implementation methods.

[0171] 3. Low Data Exchange Efficiency: Data exchange between Unity and native applications typically relies on serialization methods such as JSON and strings. Because these serialization methods are inefficient when handling large amounts of data communication, latency during data exchange directly impacts the final user experience, especially in real-time vehicle control scenarios.

[0172] 4. Complex resource management: Unity applications (equivalent to the aforementioned 3D vehicle control applications) differ significantly from native applications in terms of resource management, especially in how to efficiently share heavy resources such as 3D models, textures, and animations. The current technology system has not yet provided an effective solution.

[0173] 5. Difficulty in lifecycle management: Unity applications and native applications have different lifecycle management mechanisms. Developers need to coordinate the initialization, pause, resumption and destruction states of Unity applications and native applications, which is a challenge faced by existing technologies.

[0174] While there are some solutions on the market, such as Unity's official "Unity as a Library" feature, which allows Unity to be integrated into native applications as a library, these solutions are mainly designed for a single platform and lack unified abstraction and management for multiple platforms. At the same time, there is still considerable room for optimization in terms of communication efficiency, resource sharing, and lifecycle management.

[0175] In the field of automotive smart cockpits, 3D HMI applications typically use Unity to develop functions such as 3D vehicle control, navigation, and virtual assistants. When developers embed these functions into the vehicle's operating system (usually based on Android, Linux, or QNX), they often use customized communication solutions, resulting in a lack of universality and scalability. As the application of HarmonyOS in the connected vehicle field gradually increases, traditional communication solutions cannot meet the platform requirements of HarmonyOS.

[0176] Therefore, there is an urgent need for a cross-platform framework that can uniformly handle communication between Unity 3D vehicle control applications and Android, iOS, and HarmonyOS native applications, in order to improve development efficiency, reduce maintenance costs, and enhance application performance and user experience.

[0177] To address the aforementioned issues and achieve more efficient cross-platform communication, the core of this embodiment's technical solution lies in enabling efficient and stable communication between the Unity 3D vehicle control application and the native platform through layered design and a unified interface. This not only resolves compatibility issues arising from platform differences but also provides specific optimizations for 3D vehicle control applications. Consequently, the overall system performance and user experience are improved.

[0178] The core concept of this embodiment is to design a multi-layered abstract cross-platform communication framework. It adopts the basic principles of "layered design, unified interface, adaptation and conversion, and bidirectional channel". The core concept enables efficient and stable communication between 3D vehicle control applications developed in Unity and native applications of operating systems such as Android, iOS, and HarmonyOS.

[0179] This embodiment introduces the following core technical concepts: 1. Platform Abstraction Layer (PAL): An abstraction layer is designed between Unity and the native platform. This layer hides platform-specific API calls and provides a unified communication interface to the Unity engine. Through the isolation provided by the PAL, upper-layer applications do not need to be concerned with the differences of the underlying platform, thus achieving "write once, run on multiple platforms".

[0180] 2. Unified Message Channel (UMC): Developers designed a channel-based messaging mechanism that abstracts all cross-platform communication into the sending and receiving of messages. The message channel uses a publish-subscribe pattern, supports both synchronous and asynchronous communication methods, and can schedule messages based on priority.

[0181] 3. Efficient Serialization Engine (ESE): Developed as a binary serialization engine optimized for cross-platform scenarios, ESE offers higher efficiency and lower memory usage compared to traditional text serialization methods such as JSON. ESE provides specialized encoding and decoding optimizations for common data types (such as vectors, matrices, and colors) in 3D vehicle control applications.

[0182] 4. Lifecycle Coordinator (LC): The Lifecycle Coordinator (equivalent to the resource processing module mentioned above) is designed to establish a lifecycle coordination mechanism between Unity and native applications. The Lifecycle Coordinator can ensure that Unity and native applications remain synchronized during state transitions such as initialization, pause, resumption, and destruction, thereby preventing resource leaks and state inconsistencies.

[0183] 5. The Resource Sharing Manager (RSM) is used to achieve efficient resource sharing between Unity and native applications. Specifically, for large resources such as 3D models, textures, and audio, the Resource Sharing Manager uses memory mapping and other techniques to avoid duplicate loading and redundant data copying between Unity and native applications.

[0184] This embodiment not only addresses the technical challenges faced in traditional cross-platform communication but also optimizes for the specific needs of 3D vehicle control applications. Compared to related technologies, this embodiment provides a more unified, efficient, and easily scalable solution, allowing developers to focus on application logic and user experience development without needing to worry too much about the underlying communication details.

[0185] The technical solution of this embodiment will be described in detail below, including the structural composition, workflow, and specific implementation of key components of the technical solution created by this embodiment.

[0186] The overall architecture of the communication system adopts a layered design, mainly composed of the following core layers.

[0187] refer to Figure 8 The communication system shown includes: application layer 101, interface layer 1021, core layer 10221, platform abstraction layer 10222, and platform native layer 10223.

[0188] The application layer 101 may include: Unity 3D application 8011, Android application 8012, iOS application 8013, and HarmonyOS application 8014.

[0189] Interface layer 1021 may include: Unity 3D interface 8021, Android interface 8022, iOS interface 8023 and HarmonyOS interface 8024.

[0190] The core layer 10221 may include: message channel 8031, serialization module 8032, lifecycle management module 8033, and resource sharing module 8034.

[0191] The platform abstraction layer 10222 may include: Android adapter 8041, iOS adapter 8042, and HarmonyOS adapter 8043.

[0192] The platform native layer 10223 may include: Android system 8051, iOS system 8052 and HarmonyOS system 8053.

[0193] 1. The Application Layer includes 3D vehicle control applications developed with Unity, as well as native applications for Android, iOS, and HarmonyOS platforms.

[0194] 2. Interface Layer: The interface layer provides a unified API interface to the application layer, hiding the underlying implementation details.

[0195] Unity side interface: A C# interface provided for Unity applications to call.

[0196] Native side interfaces: Platform-specific interfaces provided for native applications to call (Java / Kotlin for Android, Objective-C / Swift for iOS, ArkTS for HarmonyOS).

[0197] 3. Core Layer: Implements the core functionalities of the framework, including message routing, serialization, lifecycle management, and resource sharing. This includes: Message Channel Manager, Serialization Engine, Lifecycle Coordinator, and Resource Sharing Manager.

[0198] 4. Platform Abstraction Layer: Handles platform-specific implementation details and provides a unified interface to higher-level systems. Includes: Android Adapter, iOS Adapter, and HarmonyOS Adapter.

[0199] 5. Native Platform Layer: The native platform layer is the underlying implementation module of each platform. It is used to interact with the operating system and perform platform-related low-level operations.

[0200] Based on the above architecture, this embodiment further defines the specific functions and implementation methods of each core component, as follows: The Platform Abstraction Layer (PAL) is the bridge connecting Unity with various operating system platforms. Its main responsibility is to shield the differences between platforms and provide a unified calling interface.

[0201] The unified messaging channel is responsible for managing message routing and distribution, and supports multiple communication modes and priority mechanisms.

[0202] The high-efficiency serialization engine is responsible for serializing and deserializing communication data, and it is specially optimized for data types in 3D vehicle control applications.

[0203] The lifecycle coordinator is responsible for managing the lifecycle synchronization between Unity applications and native applications.

[0204] The Resource Sharing Manager is responsible for managing resource sharing between Unity and native applications, and it supports efficient transfer of large resources.

[0205] The workflow of this embodiment will be described below, including the initialization process, message communication process, resource sharing process, and lifecycle management process.

[0206] 1. The initialization process may include: When the Unity application starts, the framework automatically selects the corresponding platform adapter based on the running platform; the platform adapter initializes and establishes a connection with the native platform; the system sequentially initializes the message channel manager, serialization engine, lifecycle coordinator, and resource sharing manager. The system registers default channels and message handlers to prepare for receiving and sending messages.

[0207] 2. The message communication process can include: the Unity application sends messages through a unified interface; the message content is processed by the serialization engine and then passed to the native platform by the platform adapter. After receiving the message, the native platform distributes it to the corresponding handler based on the message channel. The native platform can also send messages to the Unity application through the unified interface. Messages can be synchronous or asynchronous, and the framework will schedule them according to message priority.

[0208] 3. The resource sharing process can include: The Unity application serializes or memory-maps the resources to be shared (such as 3D models, textures, etc.) through the resource sharing manager. The resource sharing manager generates a unique resource ID and notifies the native platform that the resource is available. The native platform can obtain the shared resource through the resource ID. The lifecycle of the shared resource is managed uniformly by the framework to avoid memory leaks.

[0209] 4. The lifecycle management process can include: The lifecycle coordinator monitors lifecycle events in both Unity and native applications. When it receives events such as pause, resume, or destroy, the coordinator notifies the relevant components to synchronize their states. The resource manager is responsible for cleaning up shared resources when the application exits. Lifecycle events can also be passed through message channels, and the system uses a message mechanism to ensure that the state of the Unity engine and the native application remains consistent.

[0210] The following section explains the interaction process between Unity applications and native applications.

[0211] The interaction process from the application layer to the interface layer is as follows: When a user clicks the "Turn on Air Conditioning" button in the native application interface, the application layer first constructs a vehicle control command object, containing the command type (air_condition) and parameter values ​​(1.0 indicates on). The application layer calls the unified API provided by the interface layer to pass the command to the interface layer. The interface layer, acting as a bridge between the application layer and the framework, is responsible for validating the validity of the parameters, checking the current connection status, and converting the application layer's call into the framework's internal standard format.

[0212] The processing flow from the interface layer to the core layer is as follows: After receiving a call from the application layer, the interface layer forwards it to the message channel manager of the core layer. The core layer first preprocesses the message, including generating a unique message identifier, setting a timestamp, and determining the message priority. Then, it calls the serialization engine to convert the vehicle control command object into an efficient binary format. The core layer also decides whether to send the message immediately or add it to a priority queue for processing based on the current system load.

[0213] The transition from the core layer to the platform abstraction layer: The core layer passes the processed messages to the platform abstraction layer. The platform abstraction layer selects the appropriate adapter for processing based on the currently running operating system platform. For Android, the adapter converts the unified message format to JNI call format; for iOS, it converts it to Objective-C runtime call format; and for HarmonyOS, it converts it to ArkTS interface call format. Each adapter includes platform-specific optimization strategies, such as using the Binder mechanism for efficient transmission on Android and Core Foundation memory management on iOS.

[0214] Transmission from the Platform Abstraction Layer (PAL) to the Platform Native Layer: The PAL passes messages to the Platform Native Layer for final cross-process transmission. On the Android platform, messages are passed to the Android system's Native layer via the JNI layer, utilizing shared memory or the Binder mechanism for efficient inter-process communication. On the iOS platform, Objective-C runtime directly calls Unity's C interfaces. On the HarmonyOS platform, ArkTS calls the underlying Native library interfaces.

[0215] The Unity receiver's processing flow is as follows: After receiving the message, the Unity platform's native layer first performs integrity verification and security checks, then passes the message to the platform abstraction layer for format restoration. Upon receiving the message, the core layer distributes it to the corresponding message handler based on the channel identifier in the message. The serialization engine deserializes the binary data into a vehicle control command object. Finally, the application layer's vehicle control logic receives the command and updates the state of the 3D vehicle model, such as playing an air conditioning activation animation or adjusting the interior temperature display.

[0216] The optimized mechanism for reverse message transmission: After Unity completes command processing, it constructs a status feedback message to report the operation result to the native application. The reverse transmission process undergoes the same layered processing, but adopts a transmission strategy optimized for state data. Since state data is usually small but updated frequently, the framework uses a batch transmission and incremental update mechanism, transmitting only the changed state fields, significantly reducing the amount of communication and processing latency.

[0217] For example, refer to Figure 9 The process by which a native application sends vehicle control commands to Unity, as shown, may include, but is not limited to, S901 to S934 described below.

[0218] S901. User clicks the air conditioning button. S902. Construct a vehicle control command object. S903. Set command type: air_condition. S904. Set parameter value: 1.0. S905. Call the unified API of the interface layer. S906. Verify parameter validity. S907. Check connection status. S908. Convert to internal standard format. S909. Generate a unique message ID. S910. Set timestamp. S911. Determine message priority. S912. Serialize to binary format. S913. System load check. S914. Send immediately. S915. Add to priority queue. S916. Select platform adapter. S917. JNI call format + Binder optimization. S918. Objective-C runtime + CoreFoundation. S919. ArkTS interface + Native optimization. S920. Cross-process communication. S921. Shared memory / Binder. S922. Objective-C runtime. S923. ArkTS calls Native. S924. Encryption processing. S925. Error retransmission mechanism. S926. Integrity verification. S927. Security check. S928. Platform abstraction layer format restoration. S929. Core layer message distribution. S930. Deserialization into command objects. S931. Execution of vehicle control logic. S932. Update vehicle model 30. S933. Play air conditioning activation animation. S934. Adjust in-vehicle temperature display.

[0219] The following section explains the message channel expansion scheme.

[0220] Dynamic channel registration and configuration: The framework supports dynamic registration of new message channels at runtime to meet the needs of different application scenarios. Developers can define the attributes of new channels through configuration files or API calls, including channel name, default priority, message size limit, time-to-live, security policies, etc. The system verifies the legality of the channel configuration, checks for conflicts with existing channels, and then creates a channel instance and registers it with the channel manager. For channels that require persistence, the configuration information is saved to local storage and automatically restored after the application restarts.

[0221] Channel security and access control: The framework implements a fine-grained channel security mechanism, supporting identity-based access control. Each channel can be configured with a list of allowed senders and receivers, ensuring that only authorized components can access specific channels. For sensitive data channels, the system supports end-to-end encryption to ensure data security during transmission. Access control policies can be configured based on various factors such as roles, permissions, and time.

[0222] Channel fault tolerance and degradation strategies: To cope with various abnormal situations, the framework implements robust fault tolerance and degradation strategies. When a channel fails, the system can automatically switch to a backup channel or degrade to basic functional mode. For example, when a high-priority vehicle control channel encounters a problem, the system can temporarily use a low-bandwidth backup channel to ensure that basic vehicle control functions are not affected. Degradation strategies can be customized according to the fault type and severity.

[0223] This embodiment has the following advantages when compared with related technologies: This embodiment provides a unified messaging channel and API, enabling developers to deploy across Android, iOS, and HarmonyOS platforms using a single codebase, significantly reducing the complexity and maintenance costs of cross-platform development. Compared to existing solutions that require writing different communication code for different platforms, this embodiment reduces the amount of platform adaptation code by approximately 70%.

[0224] This embodiment employs a binary serialization engine optimized for 3D data, achieving a 300%-500% efficiency improvement and a 40%-60% reduction in memory usage when processing 3D data such as vectors and matrices. Highly efficient binary serialization is particularly important for vehicle control applications with high real-time requirements.

[0225] This embodiment's resource sharing manager achieves efficient resource sharing between Unity and native applications through techniques such as memory mapping, avoiding redundant loading and unnecessary data copying in traditional methods. When sharing large resources such as 3D models and textures, the resource sharing manager can save 30%-50% of memory consumption and improve application performance.

[0226] This embodiment provides a lifecycle coordination mechanism between Unity and native applications, ensuring that Unity and native applications remain synchronized during various state transitions, avoiding the state inconsistency problem existing in the prior art, and greatly reducing the possibility of memory leaks and crashes.

[0227] Unlike existing communication solutions primarily targeting Android and iOS, this implementation specifically considers the architectural characteristics of the HarmonyOS system, providing deep integration with the ArkTS / TS language and filling the market gap in supporting communication between Unity and HarmonyOS. The solution provided by this implementation allows applications to fully utilize the features of the HarmonyOS system, such as distributed capabilities and SuperTerminal functionality.

[0228] This embodiment is optimized for the specific needs of 3D vehicle control applications, such as realizing vehicle status synchronization, sending control commands, and sharing 3D models. It designs and provides dedicated APIs and data structures, allowing developers to focus more on the design of vehicle control business logic and the improvement of user experience.

[0229] This implementation employs a layered architecture and plug-in design, giving the framework excellent scalability. Developers can customize message channels, serialization rules, and resource sharing strategies, and can extend support for new platforms without modifying the framework's core code.

[0230] This implementation can be integrated into existing projects as a library without requiring large-scale refactoring of Unity projects or native applications, thus reducing adoption costs. Furthermore, the framework provides a concise API, making it easy to use and with a gentle learning curve.

[0231] In summary, compared with existing technologies, this embodiment has significant advantages in cross-platform compatibility, communication efficiency, resource management, architectural scalability, and optimization for specific scenarios. Its support for the HarmonyOS system fills a market gap. This embodiment provides a comprehensive solution for cross-platform development of Unity 3D vehicle control applications.

[0232] Specifically optimized for Unity 3D vehicle control applications, it provides APIs and data structures that better meet practical needs. Employing a multi-layered abstraction design, it offers a unified interface while fully leveraging the characteristics of various platforms. Efficient binary serialization and memory mapping mechanisms significantly improve communication efficiency and resource sharing performance. Comprehensive lifecycle management avoids common issues such as state inconsistencies and resource leaks. Product developers particularly support HarmonyOS, which fills a market gap and provides broader platform coverage for various applications.

[0233] Secondly, embodiments of this application provide a communication method for an application, applied to the architecture layer of an application's communication system; the communication system further includes an application layer, which includes a 3D vehicle control application and a native application; the architecture layer includes processing modules of N operating systems, and the operating system of the native application is any one of the N operating systems; N is greater than 1; as shown Figure 10 As shown, the method may include, but is not limited to, S1001 to S1003 described below. This method is applied to the communication system of the application provided in the first aspect above.

[0234] S1001, Receive the first information in the first format sent by the application layer through the target interface of the architecture layer.

[0235] The first information is the information that the first application needs to send to the second application; the first application is a 3D vehicle control application or a native application.

[0236] Wherein, if the first application is a 3D vehicle control application, the second application is a native application of any operating system; if the first application is a native application of any operating system, the second application is a 3D vehicle control application.

[0237] The implementation of S1001 can be found in the detailed description in the above architecture layer 102, and will not be repeated here.

[0238] S1002. In the processing modules of N operating systems, call the target processing module that matches the first information, and convert the first information in the first format into the first information in the second format supported by the second application through the target processing module.

[0239] The implementation of S1002 can be found in the detailed description in the above architecture layer 102, and will not be repeated here.

[0240] S1003. Send the first information in the second format to the application layer through the target interface so that the application layer can parse the first information in the second format.

[0241] The implementation of S1003 can be found in the detailed description in the above architecture layer 102, and will not be repeated here.

[0242] This method enables efficient communication between applications on different platforms (3D vehicle control applications and native applications). The application layer sends and receives information through the target interface. Based on information parsing and format conversion, the application layer and architecture layer can perceive and interpret the information. For example, the first application and the second application can perceive and interpret the information, thereby achieving readability, consistency, and stability of information across different platforms. The communication method provided in this application is particularly suitable for communication scenarios between Unity 3D vehicle control applications and native applications such as Android, iOS, and HarmonyOS, and has good scalability and compatibility. For example, if a new operating system emerges, relevant format conversion information about the new operating system can be directly added to the architecture layer to achieve compatibility with the new operating system, demonstrating good scalability.

[0243] In the case where the first application is a 3D vehicle control application and the second application is any one of the native applications of at least two mobile devices, the first information includes: update information of the 3D vehicle control model.

[0244] Update information for a 3D vehicle control model refers to data on changes in the state of the vehicle's 3D model. For example, when a user rotates the vehicle model or adjusts the lighting effects in the 3D vehicle control interface, update information for the 3D vehicle control model is generated. This update information typically includes key data such as the model transformation matrix, material properties, and animation status.

[0245] In the case where the first application is a 3D vehicle control application and the second application is any one of the native applications of at least two mobile terminals, the first information includes: first feedback information; the first feedback information is the feedback of the update information of the 3D vehicle control model.

[0246] The first feedback message is a response to the updated information of the 3D vehicle control model, indicating whether the update of the 3D vehicle control model is complete and whether the relevant information has been processed. The first feedback message may include the status code of the processing result, timestamp, error message, etc. For example, if the native application successfully renders the new model state, the first feedback message may include a rendering completion indicator; if an exception occurs, such as insufficient memory, the first feedback message may include an error code and prompt message.

[0247] It should be noted that the communication device of the application provided in this application embodiment includes all the units included, which can be implemented by a processor in an electronic device; of course, it can also be implemented by specific logic circuits; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor (MPU), a digital signal processor (DSP), or a field-programmable gate array (FPGA), etc.

[0248] The description of the above device embodiments is similar to that of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0249] It should be noted that, in the embodiments of this application, if the above-described vehicle driving control method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0250] Thirdly, embodiments of this application provide an electronic device that can implement the communication method of the application provided in the second aspect above.

[0251] Fourthly, embodiments of this application provide a storage medium, namely a computer-readable storage medium, on which a computer program or instructions are stored, which, when executed by a processor, implement the steps in the communication method of any application provided in the second aspect of the above embodiments.

[0252] Fifthly, embodiments of this application provide a computer program product, which includes a computer program or instructions that, when executed by a processor, implement the steps in the communication method of any of the applications provided in the second aspect of the above embodiments.

[0253] The above are merely embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A communication system for an application, characterized in that, The system includes an application layer and an architecture layer; the application layer includes a 3D vehicle control application and a native application; the architecture layer includes processing modules of N operating systems, where N is greater than 1; the operating system of the native application is any one of the N operating systems. The application layer is used to: send first information in a first format generated by the first application to the architecture layer through a target interface; The architecture layer is used to: receive first information in the first format through the target interface, and call a target processing module that matches the first information in the processing modules of the N operating systems, convert the first information in the first format into first information in the second format supported by the second application through the target processing module, and send the first information in the second format to the application layer through the target interface; The application layer is also configured to: receive first information in the second format through the target interface, and transmit the first information in the second format to the second application of the application layer; Wherein, if the first application is the 3D vehicle control application, the second application is the native application; if the first application is the native application, the second application is the 3D vehicle control application.

2. The system according to claim 1, characterized in that, The architecture layer includes an interface layer and a processing layer. The interface layer includes parsing interfaces for N operating systems and parsing interfaces for the 3D vehicle control application. The processing layer includes processing modules for N operating systems. The interface layer is used to: receive first information and first status identifier in the first format through a first interface; based on the first status identifier, call a first target parsing interface that matches the first information in the parsing interfaces of the N operating systems and the parsing interface of the three-dimensional vehicle control application; parse the first information in the first format through the first target parsing interface; convert the first information in the first format into a third format; and send the first information in the third format to the processing layer through a second interface. The processing layer is configured to: receive the first information in the third format through the second interface; call a target processing module matching the first information among the conversion modules of the N operating systems; process the first information in the third format through the target processing module; and send the first information in the third format and the second status identifier to the interface layer through the second interface; the second status identifier is used to point to the second application. The interface layer is further configured to: receive the first information in the third format through the second interface; based on the indication of the second status identifier, call the second target parsing interface that matches the first information in the parsing interfaces of the N operating systems and the parsing interface of the three-dimensional vehicle control application; convert the first information in the third format into the first information in the second format through the second target parsing interface; and send the first information in the second format to the application layer through the first interface.

3. The system according to claim 2, characterized in that, The processing layer includes a core layer, a platform abstraction layer, and a platform native layer; the platform abstraction layer includes adapters for N operating systems, and the platform native layer includes native layers of N operating systems embedded with 3D vehicle control programs; The core layer is used to: receive the first information in the third format through the second interface, and after performing a first processing on the first information in the third format, send it to the platform abstraction layer through the third interface; The platform abstraction layer is used to: receive the first information in the third format through the third interface, call the target adapter that matches the first information in the adapters of the N operating systems, convert the first information in the third format into the first information in the fourth format supported by the target operating system through the target adapter, and send the first information in the fourth format to the platform native layer through the fourth interface; The platform native layer is used to: receive the first information in the fourth format through the fourth interface, then call the target operation native layer that matches the first information in the native layers of the N operating systems, verify the first information in the fourth format through the target operation native layer, and then send the first information in the fourth format to the platform abstraction layer through the fourth interface. The platform abstraction layer is also used to: receive the first information in the fourth format through the fourth interface, convert the first information in the fourth format into the first information in the third format through the target adapter, and send the first information in the third format to the core layer through the third interface; The core layer is also used to: receive the first information in the three formats through the third interface, perform a second processing on the first information in the third format, and then send the first information in the third format to the interface layer through the second interface.

4. The system according to claim 3, characterized in that, The platform abstraction layer includes three adapters; The first adapter is used to: convert the first information between Android supported formats and the third format; The second adapter is used to: convert the first information between the iOS supported format and the third format; The third adapter is used to: convert the first information between the HarmonyOS supported format and the third format.

5. The system according to claim 3, characterized in that, The platform native layer includes the Android native layer, the iOS native layer, and the HarmonyOS native layer; The Android native layer is used to: verify the first information in the fourth format that supports the Android system; The iOS native layer is used to: verify the first information in the fourth format that supports the iOS system; The HarmonyOS native layer is used to: verify the first information in the fourth format that supports the HarmonyOS system.

6. The system according to claim 2, characterized in that, In the case where the application layer includes 3D vehicle control applications, Android applications, Apple mobile operating system iOS applications, and HarmonyOS applications, the interface layer includes: a first interface, a second interface, a third interface, and a fourth interface. The first interface is used to: convert the first information between the format supported by the Android application and the third format; the first format is the format supported by the Android application; The second interface is used to: convert the first information between a format supported by the iOS application and the third format; the first format is a format supported by the iOS application; The third interface is used to: convert the first information between the format supported by the HarmonyOS application and the third format; the first format is the format supported by the HarmonyOS application; The fourth interface is used to: convert the first information between the format supported by the 3D vehicle control application and the third format; the first format is the format supported by the 3D vehicle control application.

7. The system according to any one of claims 3-6, characterized in that, The core layer includes a serialization module, a lifecycle management module, and a resource processing module; The serialization module is used to: serialize and deserialize the first information in the third format; the first process includes serialization, and the second process includes deserialization; The lifecycle management module is used to: manage the lifecycle between the first application and the second application, and control the lifecycles of the first application and the second application to keep them synchronized, so that the first application can send the first information to the second application under the synchronized lifecycle. The resource processing module is used to: when the first information includes a resource sharing identifier, realize resource sharing between the first application and the second application under the instruction of the resource sharing identifier.

8. The system according to claim 7, characterized in that, The serialization module includes a basic type codec, a three-dimensional type codec, and a complex object codec; Basic type codecs are used for: serializing and deserializing basic data; 3D type codecs are used for serializing and deserializing vectors, matrices, quaternions, and 3D data. The complex object codec is used for serialization and deserialization of the third format data.

9. A communication method for an application, characterized in that, The architecture layer is applied to the communication system of the application; the communication system also includes an application layer, which includes a 3D vehicle control application and a native application; the architecture layer includes processing modules of N operating systems, and the operating system of the native application is any one of the N operating systems; The N is greater than 1; the method includes: The architecture layer receives first information in a first format sent by the application layer through the target interface of the architecture layer; the first information is information to be sent from the first application to the second application; the first application is a 3D vehicle control application or a native application. In the processing modules of the N operating systems, a target processing module matching the first information is called, and the first information in the first format is converted into the first information in the second format supported by the second application through the target processing module; The first information in the second format is sent to the application layer through the target interface, so that the application layer can parse the first information in the second format. Wherein, if the first application is the 3D vehicle control application, the second application is a native application of any operating system; if the first application is a native application of any operating system, the second application is the 3D vehicle control application.

10. The method according to claim 9, characterized in that, When the first application is the 3D vehicle control application and the second application is any native application, the first information includes: update information of the 3D vehicle control model; When the first application is the 3D vehicle control application and the second application is any native application, the first information includes: first feedback information; the first feedback information is feedback on the update information of the 3D vehicle control model.

Images