Data processing method for application communication

Abstract

The invention provides a data processing method for application communication. The method comprises the following steps: monitoring a life cycle event of a native application of a mobile terminal in a communication system through a life cycle manager; based on the life cycle event of the mobile terminal native application, updating the life cycle state of the three-dimensional vehicle control application in the communication system, so that the updated life cycle state of the three-dimensional vehicle control application and the life cycle state of the mobile terminal native application are kept synchronous; wherein the life cycle manager is located in a framework layer between a native application of the mobile terminal and a three-dimensional vehicle control application; the three-dimensional vehicle control application and the mobile terminal native application have different life cycle division modes. According to the scheme, the life state of the native application of the mobile terminal and the life state of the three-dimensional vehicle control application can be kept synchronous, and therefore the stability problem and the resource leakage problem caused by state inconsistency can be avoided.

Description

Technical Field

[0001] This application relates to communication technology, and more particularly to a data processing method for application communication. 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] 3D vehicle control applications are typically embedded within native mobile applications, requiring interaction between the two at runtime. Different types of applications often employ different lifecycle management mechanisms. Therefore, coordinating the lifecycle states of both applications in scenarios involving interaction between 3D vehicle control and native mobile applications becomes a critical technical challenge. Summary of the Invention

[0004] To address the aforementioned problems, this application provides at least one data processing method for application communication.

[0005] The technical solution of this application is implemented as follows: Firstly, this application provides a data processing method for application communication, the method comprising: listening to the lifecycle events of a mobile native application in a communication system through a lifecycle manager; updating the lifecycle state of a 3D vehicle control application in the communication system based on the lifecycle events of the mobile native application, so that the updated 3D vehicle control application keeps synchronized with the lifecycle state of the mobile native application; wherein, the lifecycle manager is located in the architecture layer between the mobile native application and the 3D vehicle control application; the 3D vehicle control application and the mobile native application have different lifecycle division methods.

[0006] This solution can keep the lifecycle of the native mobile application and the 3D vehicle control application synchronized, thereby avoiding stability issues and resource leaks caused by inconsistent states. Attached Figure Description

[0007] Figure 1 This is a schematic diagram of an optional structure of the application communication system provided in an embodiment of this application; Figure 2 A schematic flowchart of an optional data processing method for application communication provided in an embodiment of this application; Figure 3 This is an optional schematic diagram of the lifecycle state provided in an embodiment of this application. Detailed Implementation

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

[0009] To facilitate understanding, let's first explain the communication system.

[0010] 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 at least two native mobile applications 1012; each native application 1012 corresponds to an operating system type.

[0011] For example, the 3D vehicle control application 1011 here can be a Unity application. The mobile native application 1012 can include, but is not limited to, any of the following: native applications of the Android operating system (also referred to as Android applications), native applications of the Apple mobile operating system (iPhone Operating System, iOS) (also referred to as iOS applications), native applications of the HarmonyOS operating system (also referred to as HarmonyOS applications), etc.

[0012] The architecture layer 102 includes a lifecycle manager, a resource sharing processor, etc., which are used to realize data sending and receiving, lifecycle management, and resource sharing between the 3D vehicle control application 1011 and the mobile native application 1012.

[0013] The 3D vehicle control application 1011 is embedded in the native mobile application 1012 to realize the control of the vehicle's 3D model and 3D display, etc.

[0014] The following describes various embodiments of the data processing method, apparatus, device, storage medium, and program product for application communication provided in this application.

[0015] In a first aspect, embodiments of this application provide a data processing method for application communication. The functions implemented by this method can be achieved by an electronic device calling program code. Of course, the program code can be stored in a computer storage medium. It can be seen that the electronic device includes at least a processor and a processor.

[0016] This application provides a data processing method for application communication, used to synchronize the lifecycles of native mobile applications and 3D vehicle control applications. (Reference) Figure 2 The process may include, but is not limited to, S201 and S202 described below.

[0017] S201, The lifecycle manager listens to the lifecycle events of mobile native applications in the communication system.

[0018] A lifecycle manager is an architectural layer component deployed between a native mobile application and a 3D vehicle control application. It listens to the lifecycle events of the native mobile application and updates the lifecycle state of the 3D vehicle control application accordingly, thereby achieving consistency in behavior between cross-platform applications.

[0019] Lifecycle events refer to a series of state change events that an application undergoes during its operation in a mobile operating system, such as launch, pause, resume, and stop. Lifecycle events are triggered by the operating system and can be listened to by applications to execute corresponding processing logic. For example, when a user opens an application, the operating system sends a launch event; when the user switches to another application, the operating system sends a pause event; when the user returns to the application, the operating system sends a resume event; and when the user closes the application, the operating system sends a stop event.

[0020] The lifecycle manager can uniformly abstract and encapsulate these lifecycle events across different platforms (such as Android, iOS, and HarmonyOS), enabling 3D vehicle control applications to recognize and respond to these events. For example, in a 3D vehicle control application developed in Unity, although the application itself does not directly manage lifecycle events, through the coordination of the lifecycle manager, it can receive the same lifecycle state changes as native mobile applications and perform corresponding initialization, state saving, and state restoration operations.

[0021] The lifecycle manager's process of listening to lifecycle events is fundamental to the entire data processing flow. Only by accurately capturing the lifecycle changes of the native mobile application can the state of the 3D vehicle control application be ensured to respond and synchronize correctly. By accurately capturing the lifecycle changes of the native mobile application and ensuring that the state of the 3D vehicle control application responds and synchronizes correctly, the compatibility and stability of cross-platform applications are improved, while resource utilization is optimized, system overhead is reduced, and the user interaction experience is enhanced.

[0022] S202. The lifecycle manager updates the lifecycle state of the 3D vehicle control application in the communication system based on the lifecycle events of the mobile native application, so that the updated 3D vehicle control application keeps synchronized with the lifecycle state of the mobile native application.

[0023] The lifecycle manager is located in the architecture layer between the mobile native application and the 3D vehicle control application; the 3D vehicle control application and the mobile native application have different lifecycle division methods.

[0024] 3D vehicle control applications typically refer to applications developed based on 3D graphics engines (such as Unity) to implement visualization functions related to vehicle control, such as virtual dashboards, 3D model displays, and interactive user interfaces. 3D vehicle control applications usually have high computational and rendering resource requirements.

[0025] Because 3D vehicle control applications and native mobile applications differ in their lifecycle segmentation methods, a lifecycle manager is needed for state synchronization.

[0026] The lifecycle manager calls the corresponding event handling function in the 3D vehicle control application based on the received lifecycle events to update the lifecycle state of the 3D vehicle control application. For example, when the mobile native application enters the startup state, the lifecycle manager notifies the 3D vehicle control application to also enter the startup state and begin loading basic resources, initializing subsystems, and other operations; when the mobile native application enters the paused state, the lifecycle manager notifies the 3D vehicle control application to enter the paused state and releases some non-critical resources to reduce system load; when the mobile native application enters the resumed state, the lifecycle manager notifies the 3D vehicle control application to restore the previous state and reload necessary resources; when the mobile native application enters the stopped state, the lifecycle manager notifies the 3D vehicle control application to perform cleanup and destruction operations.

[0027] This synchronization mechanism ensures that the behavior of the 3D vehicle control application is consistent with that of the native mobile application, avoiding problems such as resource waste, performance degradation, or poor user experience caused by the synchronization mechanism leading to a mismatch in lifecycle.

[0028] In practice, the lifecycle manager dynamically adjusts the state of the 3D vehicle control application by calling the event handling interface, enabling the application to respond flexibly to changes in the lifecycle of the native mobile application. This process not only ensures the collaborative capabilities of cross-platform applications but also enhances the overall stability and reliability of the system.

[0029] This method manages the lifecycles of both the 3D vehicle control application and the mobile native application through a lifecycle manager located in the architectural layer between the mobile native application and the 3D vehicle control application. Since the lifecycles of the 3D vehicle control application and the native application are divided differently, the lifecycle manager, not belonging to either application, can act as an intermediary for coordination, effectively resolving the issue of inconsistent lifecycles across platforms. During synchronization, lifecycle events of the mobile native application are monitored, and the lifecycle state in the 3D vehicle application is updated based on these events. This ensures that the resource usage of the 3D vehicle control application matches the running state of the native application, thus avoiding stability issues, resource leaks, resource waste, or application crashes caused by inconsistent states, and improving the stability and response efficiency of the communication system.

[0030] The process of S202 will now be described. In one possible implementation, the process may include, but is not limited to, at least one of S2021 to S2023.

[0031] S2021. When the Lifecycle Manager detects a revelation event from the native mobile application, it calls the initialization and startup events of the 3D vehicle control application to perform initialization and startup processing.

[0032] For example, when a user opens a native mobile application, the application emits a launch event, indicating that it needs to start. At this moment, the lifecycle coordinator receives the launch event and immediately triggers the initialization and launch events of the 3D vehicle control application.

[0033] Initialization events are used to perform basic settings for the 3D engine, such as configuring the rendering pipeline, loading the core 3D model, and initializing the physics system; startup events are used to activate the user interface, establish communication channels, and complete the final scene construction.

[0034] By binding the launch event of the native mobile application with the initialization and launch events of the 3D vehicle control application, the startup states of the 3D vehicle control application and the native mobile application are matched in their lifecycles, thus avoiding crashes or lag issues caused by startup mismatch. Specifically, the lifecycle manager binds these two events and controls the execution timing of the 3D vehicle control application based on the binding relationship.

[0035] S2022. When the Lifecycle Manager detects a pause event in the native mobile application, it calls the pause event of the 3D vehicle control application to adjust the lifecycle state of the 3D vehicle control application.

[0036] For example, when a user switches out of the current native mobile application (e.g., to answer a call or open another application), the native mobile application emits an event called "Pause." Upon receiving this pause event, the lifecycle coordinator immediately sends a command to the 3D vehicle control application, requesting it to execute the pause event. The purpose of the pause event is to stop unnecessary computational tasks, release some graphics processor resources, and record the current running state for later resumption.

[0037] In practical applications, the handling strategy for pause events can vary depending on the reason for the pause. For example, for a short pause (such as answering a phone call), the 3D vehicle control application can reduce the frame rate and retain the state data in memory; for a long pause, the 3D vehicle control application can release most of the non-critical resources and retain only the core state information.

[0038] S2023. When the Lifecycle Manager detects a recovery event of the mobile native application, it determines the target recovery type; it calls the recovery event of the 3D vehicle control application and adjusts the lifecycle state of the 3D vehicle control application based on the target recovery type.

[0039] For example, when a user returns to the native mobile app, the app sends a restore event. Upon receiving this restore event, the lifecycle coordinator first determines the duration of the pause and the system state to ascertain the target restore type. The target restore type may be either a quick restore or a full restore.

[0040] Quick recovery is suitable for short-term pauses, requiring only the restoration of the previous rendering and user interaction states; full recovery is suitable for long-term pauses, requiring the reloading of some resources and a complete state synchronization. Depending on the target recovery type, the lifecycle manager invokes the 3D vehicle control application's recovery event to restore the application's lifecycle to an appropriate level.

[0041] In this embodiment of the application, collaborative management between the 3D vehicle control application and the native mobile application is implemented. This collaborative management improves the stability and response speed of both the 3D vehicle control application and the native mobile application. For the handling of other events, please refer to the descriptions in S2021 to S2023 above, which will not be repeated here.

[0042] The following is a description of each event.

[0043] When the native mobile application is an Android application, the launch event includes the application creation event and the application launch event, the pause event includes the application pause event or the application stop event, and the resume event includes the application resume event or the application restart event.

[0044] In Android applications, application lifecycle management follows the Android Framework. The application creation event refers to the `onCreate` callback triggered when a user first opens the application. The application startup event corresponds to the `onStart` callback, indicating that the application is ready to interact with the user. The application pause event is `onPause`, which typically occurs when the user switches to another application or answers a phone call. The application stop event is `onStop`, indicating that the application is completely invisible. The application resume event corresponds to `onResume`, indicating that the application returns to the foreground, resuming rendering and interactive functionality. The application restart event corresponds to `onRestart`, which is triggered when the application process is restarted after being recycled.

[0045] When the native mobile application is an Apple operating system iOS application, the launch event includes the application launch event, the pause event includes the application inactive event or the application entering the background event, and the resume event includes the application entering the foreground event.

[0046] In Apple's iOS operating system, application lifecycle management is controlled by the UI ApplicationDelegate. The application launch event corresponds to the `application Did Finish Launching` callback, marking the official start of the application's operation. The application inactivity event corresponds to the `application Will Resig Active` callback, typically caused by incoming calls, notifications, or other reasons that temporarily reduce the application's focus. The application entering the background event corresponds to the `application Did Enter Background` callback, indicating that the application has been moved to the background and resource consumption should be reduced. The application entering the foreground event corresponds to the `application Will Enter Foreground` callback, indicating that the application is about to resume its active state.

[0047] By accurately mapping the lifecycle events of Apple's iOS application platform, the behavior of the 3D vehicle control application can be dynamically adjusted in different states. For example, when running in the background, the rendering loop of the 3D vehicle control application can be stopped to extend the device's battery life. At the same time, when the user switches back to the 3D vehicle control application, the application can quickly restore to its previous state.

[0048] When the native mobile application is a HarmonyOS application, the startup event includes the application creation event, the pause event includes the application entering the background event, and the resume event includes the application entering the foreground event.

[0049] In HarmonyOS applications, lifecycle management adopts the Ability model. The application creation event in a HarmonyOS application corresponds to the `onCreate` method of the Ability. The application entering the background event corresponds to `onBackground`, indicating that the application is no longer in the foreground. The application entering the foreground event corresponds to `onForeground`, indicating that the application has become the user's focus again.

[0050] For example, the lifecycle correspondence between the 3D vehicle control application and each mobile native application can be seen in Table 1.

[0051] Table 1. Example of the lifecycle correspondence between 3D vehicle control applications and various native mobile applications.

[0052] In this embodiment of the application, by accurately mapping the lifecycle events of three mainstream mobile operating systems—Android, iOS, and HarmonyOS—a unified management strategy for 3D vehicle control applications across different platforms can be achieved. This method of achieving a unified management strategy for 3D vehicle control applications through accurate mapping of lifecycle events improves cross-platform compatibility, thereby optimizing resource scheduling and power consumption management, and further enhancing user experience and system stability.

[0053] The process of S2021 will now be described. In one possible implementation, the process may include, but is not limited to, S20211 to S20214 described below.

[0054] S20211, The lifecycle manager initializes the 3D vehicle control application.

[0055] Initialization refers to the process of configuring and preparing the basic environment, runtime framework, and core modules before a 3D vehicle control application starts. Initializing the 3D vehicle control application ensures that subsequent rendering, logic processing, and communication functions can operate normally. Initialization operations include loading runtime dependency libraries, setting up the logging system, allocating memory space, and registering global callback functions. For example, in the Unity engine, the initialization phase of a 3D vehicle control application checks platform compatibility and adjusts default parameters based on device performance. By completing the initialization of the 3D vehicle control application, a stable basic runtime environment can be provided for it.

[0056] S20212, The lifecycle manager configures the rendering pipeline of the 3D vehicle control application and loads the first resource of the 3D vehicle control application.

[0057] The rendering pipeline is a series of processing stages in the graphics rendering process, used to convert 3D model data into the final image displayed on the screen. Configuring the rendering pipeline includes selecting an appropriate rendering mode (such as forward rendering or deferred rendering), setting the lighting calculation method, and defining the material processing flow. The first resource typically refers to key resources that must be loaded at the initial stage of application startup, such as core 3D models, texture maps, and animation data. The first resource determines the basic visual presentation and interactivity of a 3D vehicle control application. In a car control interface, the first resource may include elements such as vehicle models, dashboards, and button icons. By configuring the rendering pipeline and loading the first resource, a preliminary visual foundation can be established for 3D vehicle control applications.

[0058] S20213, The lifecycle manager initializes the business logic components of the 3D vehicle control application.

[0059] Business logic components are a collection of modules responsible for handling the internal functions of 3D vehicle control applications, including but not limited to vehicle status monitoring, user input response, animation playback, and data synchronization. Initializing these components means loading necessary scripts, registering event listeners, creating object instances, and setting the initial state of the object instances.

[0060] S20214. The lifecycle manager establishes a communication connection between the 3D vehicle control application and the native mobile application.

[0061] A communication connection refers to the data transmission channel established between a 3D vehicle control application and a native mobile application, used to exchange instructions, status information, and control commands. Communication connections can be implemented in various ways, such as using local message queues, shared memory, inter-process communication (IPC) mechanisms, or network sockets. Establishing a communication connection typically involves steps such as protocol handshake, authentication, and service registration to ensure the security and real-time performance of data transmission. For example, communication between Unity and native Android applications can be achieved using the Java Native Interface (JNI); on iOS, Objective-C bridging technology can be used. By establishing a communication connection, collaborative work between the 3D vehicle control application and the native application can be realized.

[0062] In this embodiment, by establishing a communication connection between the 3D vehicle control application and the mobile native application, efficient data interaction between the 3D vehicle control application and the mobile native application can be achieved, thereby supporting the development needs of complex hybrid applications.

[0063] This embodiment enables 3D vehicle control applications to have complete functionality and visualization foundations during the startup phase. This improves system stability and user experience, meeting the needs of multi-platform mobile application development.

[0064] In one possible implementation, S20212 may include, but is not limited to, S202121 to S202123 described below.

[0065] S202121, The lifecycle manager loads the basic 3D data, key textures, and audio files of the vehicle 3D model in the 3D vehicle control application based on the first priority.

[0066] Basic 3D data refers to the fundamental geometric structure information that constitutes the 3D vehicle model in 3D vehicle control applications, including vertex coordinates, patch indices, and normal directions. This data determines the shape and basic outline of the 3D vehicle model in 3D space.

[0067] Key textures are textures that are directly related to the appearance of the 3D vehicle model in 3D vehicle control applications, such as the paint surface of the vehicle body and glass reflections. These key textures directly affect the user's perception of the appearance of the 3D vehicle model in 3D vehicle control applications.

[0068] The audio files include key sound effects such as engine start-up sounds, acceleration sounds, and braking sounds, used to enhance the user's immersive experience. The first priority is loaded with the basic 3D data, key textures, and audio files required for the 3D vehicle control application. These are crucial for the implementation of the core functions of the 3D vehicle control application, and are loaded first to ensure that users can quickly see and operate the 3D vehicle model in the application.

[0069] By prioritizing the loading of basic 3D data, key textures, and audio files, a clear 3D model of the vehicle and necessary auditory feedback can be provided to the user in the shortest possible time, thereby improving the smoothness and intuitiveness of the user experience.

[0070] S202122, The lifecycle manager loads high-precision data, decorative textures, and background music of the vehicle's 3D model based on the second priority.

[0071] First priority is higher than second priority. High-precision data is model data that is further refined based on basic 3D data, such as adding more detailed faces, complex material mapping, and refined lighting and reflection effects, in order to improve rendering quality.

[0072] Decorative textures refer to non-functional textures that enhance visual appeal, such as car body patterns, logos, and wheel rim designs.

[0073] Background music is ambient music or theme music that matches the scene's atmosphere, used to create an immersive 3D car control experience. The second priority loads non-core resources such as decorative textures and background music. While these resources are not essential for core functions, they significantly enhance the user experience, and therefore are loaded after the basic resources have been loaded.

[0074] S202123, The lifecycle manager loads the extended function modules and visual effects modules of the 3D vehicle control application based on the third priority.

[0075] The second priority level is higher than the third priority level. Extended function modules refer to additional functions provided beyond the basic functions, such as virtual key binding, remote control command settings, and vehicle status monitoring. These modules typically rely on network communication or local database support. Visual effects modules include dynamic lighting effects, particle effects (such as smoke and sparks), and UI animations, used to enhance the visual appeal of the interface. The resources loaded with the third priority level are optional; their loading time will not affect the core workflow of the 3D vehicle control application and are suitable for asynchronous loading in the background.

[0076] By adopting a priority-based hierarchical loading strategy, system resources can be allocated reasonably, thereby avoiding lag or delay caused by loading a large number of resources at once, and ensuring the stable operation of 3D vehicle control applications and a good user experience.

[0077] After S2021 is executed, S2024 may be performed, including but not limited to the following.

[0078] S2024. The Lifecycle Manager provides feedback on the initialization and startup progress to the mobile native application, so that the mobile native application can display the initialization and startup progress on the screen.

[0079] The startup progress includes the current stage name, completion percentage, estimated remaining time, and the type of resources being loaded.

[0080] Initialization and startup progress refers to the execution status and completion status of each stage during the initialization and startup process of a 3D vehicle control application. By feeding this information back to the native mobile application in real time, the user interface can promptly display the current processing status, thereby improving the user experience and reducing waiting anxiety.

[0081] The initialization and startup progress typically includes the current stage name (e.g., initializing the rendering system, loading vehicle models), the percentage completed (e.g., 70% loaded), the estimated remaining time (e.g., approximately 10 seconds remaining), and the type of resources being loaded (e.g., texture files, audio data, etc.).

[0082] The current stage name identifies the specific execution point of the 3D vehicle control application during startup, helping users understand the ongoing operations. Examples include initializing the Unity engine, loading the basic 3D model, and establishing a communication channel.

[0083] The completion percentage indicates the proportion of work completed during the startup process of the 3D vehicle control application, allowing users to intuitively perceive the overall progress. This percentage is determined through a weighted calculation method, rather than a simple linear increase. The initialization phase accounts for 20% of the progress, while the critical resource loading phase accounts for 40%.

[0084] The estimated remaining time is calculated based on the amount of work completed and historical average speed, helping users to plan their operations or waiting time accordingly. While not absolutely accurate, the time provides a general reference, preventing users from becoming impatient due to long waits.

[0085] The type of resource being loaded informs the user about the type of content currently being loaded, such as 3D models, texture maps, and audio files. This information helps users understand why loading 3D models, texture maps, or audio files takes longer, enhancing their understanding and trust in the system's behavior.

[0086] In this embodiment, the initialization and startup progress of the 3D vehicle control application is fed back to the native mobile application, enabling the display screen to show the startup status in real time. This feedback mechanism helps improve the user's perception of the system's operating status. This enhanced capability further improves the user experience.

[0087] In one possible implementation, S2022 may include, but is not limited to, at least one of S20221 to S20223 described below.

[0088] S20221. When the pause event is a call pause, the lifecycle manager maintains the status monitoring function of the 3D vehicle control application and reduces the rendering quality of the 3D vehicle control application.

[0089] When a user receives a call while using the 3D vehicle control application, the lifecycle manager, upon listening for a call pause event, triggers a call pause event. At this time, to avoid affecting the display and control experience of the 3D vehicle control application after the call, the application does not completely stop running but enters a low-power state. The lifecycle manager continues to monitor the status of the 3D vehicle control application, allowing the application's status and data to be monitored even during a call. Simultaneously, to reduce the load on the CPU and GPU, the rendering quality of the 3D vehicle control application is reduced, such as lowering the screen resolution, disabling shadow effects, and reducing particle effects. By reducing the rendering quality of the 3D vehicle control application, system resources are saved, avoiding impact on call quality, while maintaining real-time monitoring of the vehicle's status.

[0090] In the event of a call interruption, continuous status monitoring of the 3D vehicle control application and lowering its rendering quality can achieve reasonable allocation of system resources, maintaining basic vehicle control functions without affecting user experience, thereby improving continuity.

[0091] S20222. When the pause event is a switch application pause, the lifecycle manager saves the state of each parameter of the 3D vehicle control application and releases all the running resources of the 3D vehicle control application.

[0092] When a user actively switches the 3D vehicle control application to the background (e.g., by clicking the Home button or opening another application), this action is detected, triggering an application switching pause event. At this point, to free up resources for other foreground applications, the 3D vehicle control application will no longer be active. First, all key parameters of the current 3D vehicle control application are saved, including but not limited to the vehicle's position, speed, steering angle, and lighting settings. This state data is persistently stored in the device's storage system so that the application can be accurately restored to its state before being paused when the user returns. Next, all running resources, including memory and processor resources, are released to minimize the impact on performance.

[0093] S20223. When the pause event is a pause due to insufficient memory, the lifecycle manager actively releases some of the cache and some of the running resources of the 3D vehicle control application.

[0094] When the lifecycle manager detects high memory pressure, the 3D vehicle control application will trigger a memory shortage pause event. Based on the current memory usage, the system intelligently and selectively releases some cached and runtime resources. For example, the system can clear non-critical texture caches, unload unused 3D models, and disable unnecessary animation effects. This strategy of intelligently and selectively releasing cached and runtime resources based on current memory usage can free up sufficient memory space without significantly impacting application functionality, preventing the 3D vehicle control application from being forcibly terminated by the system. Proactively releasing some cached and runtime resources ensures that users can quickly restore the 3D vehicle control application's state and continue using it in subsequent operations.

[0095] In this embodiment, different processing strategies are adopted according to different types of pause events to optimize the lifecycle management of the 3D vehicle control application, thereby improving the stability and responsiveness of the system and ultimately bringing users a smoother and more reliable vehicle control experience.

[0096] In another possible implementation, the pause event is differentiated according to its duration, with different durations corresponding to different processing methods. This processing may include, but is not limited to, at least one of S20224 to S20226 below.

[0097] S20224. When the pause duration of a pause event is within the first duration range, the lifecycle manager reduces the rendering quality and frame rate of the 3D vehicle control application.

[0098] When a pause event is detected and its duration falls within the first timeframe, the lifecycle manager invokes the first pause event to reduce the rendering quality and frame rate of the 3D vehicle control application. Rendering quality refers to the level of detail used by the graphics engine when rendering a 3D scene, such as whether shadow effects, particle effects, and high-precision textures are enabled. Frame rate represents the number of frames updated per second, directly affecting animation smoothness. Reducing rendering quality can decrease GPU load, while reducing the frame rate can save CPU resources and power. Reducing rendering quality and frame rate is suitable for situations where the user is briefly in the background, to maintain responsiveness while preserving the availability of critical functions.

[0099] S20225. When the pause duration of the pause event is within the second duration range, the lifecycle manager releases the first cache and first memory resources of the 3D vehicle control application to maintain the operation of core data.

[0100] When the pause time enters the second duration range, the system management module of the 3D vehicle control application will release some non-essential first cache and first memory resources to free up more system resources for other applications. The first cache typically refers to temporarily stored image, model, or texture data, used to accelerate repeated loading processes; the first memory resources refer to dynamically allocated memory that is not directly used, such as storage space for temporary objects or calculation results. By releasing the first cache and first memory resources, the management module of the 3D vehicle control application can maintain the operation of core data, including critical information such as vehicle status and user preference settings, thereby avoiding system instability caused by prolonged excessive memory usage.

[0101] Core data refers to data that must be retained in memory to ensure the rapid recovery of the 3D vehicle control application, such as current vehicle control parameters, connection status, and user identity information. This data is typically not released but is saved to local storage using a dedicated persistence mechanism. This allows the system management module of the 3D vehicle control application to quickly read and reconstruct critical states when resuming foreground operation, without having to reinitialize the entire application.

[0102] There is a priority relationship between the first cache and the first memory resource. The first cache mainly involves temporary data related to graphics, while the first memory resource is more inclined towards temporary variables in logical calculations. Therefore, when releasing resources, the system management module of the 3D vehicle control application usually releases the first cache first, and then gradually releases the first memory resource as needed, in order to maximize the stability and response speed of the system.

[0103] S20226. When the pause duration of the pause event is within the third duration range, the lifecycle manager releases the second memory resources of the 3D vehicle control application to maintain the operation of basic data.

[0104] The second memory resource is greater than the first memory resource.

[0105] The duration in the first duration range is shorter than the duration in the second duration range, and the duration in the second duration range is shorter than the duration in the third duration range.

[0106] When the pause time is relatively long, entering the third duration range, the management module of the 3D vehicle control application will further release more memory resources, the so-called second memory resources, to optimize resource allocation to the greatest extent. Second memory resources typically include more complex object instances, larger buffers, and non-real-time dependent data structures. Because the size of the second memory resources is larger than the first memory resources, releasing them can significantly reduce memory pressure and prevent the 3D vehicle control application process from being forcibly terminated due to insufficient resources.

[0107] This method ensures minimal functionality is maintained during long-term background operation, such as maintaining basic communication channels with the native application, recording important vehicle status changes, and quickly rebuilding the user interface and interaction logic when the application resumes foreground operation. This approach guarantees system stability and efficient resource utilization without completely shutting down the 3D vehicle control application.

[0108] The three duration ranges are set to accommodate the need for pausing in different scenarios.

[0109] In practice, a progressive resource release strategy was implemented across the various steps. As the pause time increased, the system management module of the 3D vehicle control application sequentially reduced the graphics rendering quality, released the first cache and first memory resources, and finally released a larger amount of second memory resources to cope with longer background operation. This series of operations ensured that critical functions could still operate normally under resource constraints, while avoiding unnecessary resource waste.

[0110] In this embodiment, the rendering quality, frame rate, and memory resource usage of the 3D vehicle control application are adjusted in stages according to the different pause durations. This allows for the rational allocation of system resources during pauses. This resource allocation method can extend the device's battery life and reduce lag. Ultimately, this method can improve the overall stability of the 3D vehicle control application and user satisfaction.

[0111] In one possible implementation, S2023 may include, but is not limited to, S20231 and S20232 described below.

[0112] S20231. When the target recovery type is the first recovery type, the lifecycle manager uses a fast path to restore the 3D vehicle control application to its state and settings before it was paused.

[0113] The first recovery type is used to characterize recovery after the initial pause.

[0114] The first type of recovery refers to situations where a user briefly stays in the background and then returns to the foreground, such as answering a phone call or switching to another lightweight application. In recovery scenarios corresponding to the first type of recovery, the absence time is short, and a fast recovery strategy can be used to improve the user experience. The first pause time is typically defined as a period of 5 minutes or less. The fast path is an optimized recovery process that skips some resource reloading and state verification steps, performing only necessary state synchronization and rendering settings restoration operations. This can significantly shorten the recovery time, making the delay almost imperceptible to the user.

[0115] Fast path implementations include: not reinitializing non-core subsystems (such as the audio system), not reloading high-precision models and texture resources, and only restoring the user interaction state and vehicle control state. Fast paths are suitable for scenarios with sufficient system resources and high recovery time requirements, ensuring that 3D vehicle control applications can be restored to an interactive state in the shortest possible time.

[0116] S20232. When the target recovery type is the second recovery type, the lifecycle manager uses the full path to restore the state and settings of the 3D vehicle control application.

[0117] The second recovery type is used to characterize recovery after a second pause; the second pause is longer than the first pause.

[0118] The second type of recovery refers to situations where a user returns to the foreground after a prolonged period in the background, such as when the user closes the application, switches to an application that consumes significant system resources, or the device enters low-power mode. In this recovery scenario, the system cannot guarantee that the critical resources of the 3D vehicle control application are still in memory; therefore, a complete recovery process is necessary. The second pause time is typically defined as a period exceeding 5 minutes. The complete path is a comprehensive recovery process that includes reinitializing critical system components, reloading resources, verifying data consistency, and synchronizing the state with the native application.

[0119] The complete path implementation includes: reinitializing some modules of the Unity engine, reloading 3D models and texture resources, verifying the consistency between the vehicle state and the native application, and restoring user preference settings. The complete path is suitable for scenarios where system resources may be reclaimed and where high-quality restoration is required, ensuring the stability and accuracy of the restored 3D vehicle control application.

[0120] In this embodiment, by distinguishing different recovery types and adopting corresponding recovery paths, the recovery strategy can be flexibly adjusted in different scenarios. By distinguishing different recovery types and adopting corresponding recovery paths, the contradiction between recovery speed and recovery integrity can be effectively balanced, thereby improving the user experience and ultimately enhancing the operating efficiency and stability of 3D vehicle control applications on mobile platforms.

[0121] The sharing of vehicle 3D model resources may include, but is not limited to, the following S301 to S304.

[0122] S301: The mobile native application receives the first notification information sent by the 3D vehicle control application.

[0123] The first notification information is used to characterize the resource sharing of the vehicle's 3D model in 3D vehicle control applications.

[0124] The first notification message refers to a message sent by a 3D vehicle control application to a native mobile application to indicate the existence of shareable resources within the 3D vehicle control application, such as a high-precision 3D vehicle model. The first notification message typically includes metadata such as a resource identifier (Resource ID) and the address of a shared memory region, enabling the native mobile application to quickly locate and access shared resources like the high-precision 3D vehicle model.

[0125] The first notification message is typically sent after the 3D vehicle control application has completed initialization, the model has finished loading, or the user has triggered a specific action. Sending the first notification message ensures that the mobile native application obtains available resources at the appropriate time, avoiding rendering anomalies or performance issues caused by unavailable resources. By having the 3D vehicle control application proactively send the first notification message, real-time synchronization of resource status can be achieved, thereby improving the efficiency of cross-platform resource access and enhancing the consistency of the user experience.

[0126] S302. The mobile native application obtains the shared data of the vehicle's 3D model based on the resource identifier and shared memory area in the first notification information.

[0127] A resource identifier is a string or numeric code that uniquely represents a shareable resource, used for finding and referencing resources across multiple modules. A shared memory region is a segment of memory reserved by the operating system for sharing data between different processes. Shared memory regions allow different processes to read and write the same data without copying data, thus saving system resources and improving access speed. In this embodiment, the 3D vehicle control application places relevant data of the vehicle's 3D model (such as vertices, textures, animations, etc.) in the shared memory region and uses resource identifiers to inform the mobile native application how to access this data. After locating the shared memory region based on the resource identifiers, the mobile native application can directly read the model data without reloading or parsing the original files.

[0128] S303: The mobile native application converts the shared data into a format supported by the mobile operating system to obtain the first format of shared data.

[0129] Since 3D vehicle control applications are typically developed using Unity or other cross-platform engines, the internal resource formats of Unity or other cross-platform engines may be incompatible with the graphics APIs (such as OpenGL ES, Metal, Vulkan, etc.) used by native mobile applications. Therefore, after sharing data, native mobile applications need to convert this data into a format suitable for their own platform. For example, converting the texture format in Unity to the ETC2 compression format supported by the Android platform, or converting the mesh structure of the 3D model to a platform-specific buffer format. The process of converting the data of a 3D vehicle control application into a format suitable for native mobile applications may involve multiple sub-steps such as data reorganization, format conversion, and data verification to ensure that the converted data can be correctly displayed and rendered in the native environment.

[0130] In this embodiment of the application, by converting shared data into a format supported by the mobile device operating system, the compatibility and consistency of resources on different platforms are guaranteed, thereby preventing rendering errors or crashes caused by format mismatch and further improving the stability and reliability of cross-platform collaboration.

[0131] S304. Mobile native applications share vehicle 3D models based on shared data in the first format.

[0132] After data conversion, the native mobile application can use the converted first-format shared data to display the vehicle's 3D model. The process of displaying the 3D model after data conversion includes operations such as binding the shared data to the corresponding buffer in the graphics pipeline, setting material properties, and executing rendering commands. The shared 3D model can be used in various scenarios, such as dashboard display, remote control feedback, and AR navigation assistance. Furthermore, the native mobile application can dynamically adjust the display method of the vehicle's 3D model by monitoring changes in the state of the 3D vehicle control application, such as switching detail levels, playing animations, and changing the viewing angle.

[0133] In this embodiment, a resource-sharing mechanism enables efficient data exchange between the 3D vehicle control application and the native application. This mechanism allows the 3D vehicle control application to share complex 3D model resources with the native application in a standardized manner, thereby improving cross-platform collaboration capabilities and achieving richer visualization and interactive experiences.

[0134] The following describes how the mobile native application converts shared data into a format supported by the mobile operating system in S303. In one possible implementation, when the shared data is binary data, this process may include, but is not limited to, at least one of S3031 to S3033 described below.

[0135] S3031. If the mobile native application is an Android application, the mobile native application converts the binary shared data into the first format of the OpenGL ES buffer object of the Open Graphics Library Embedded System.

[0136] When the target platform is an Android application, the operation of converting raw binary 3D model data into a first format suitable for OpenGL ES buffer objects for embedded systems includes converting raw binary 3D model data into buffer objects that conform to the Open Graphics Library for Embedded Systems (OpenGL ES) specification.

[0137] OpenGL ES, an open-source graphics library for embedded systems, is a lightweight graphics rendering API designed specifically for mobile devices and widely used in 3D graphics processing on the Android platform. A buffer object is a memory structure used to store graphics data such as vertices and indices, facilitating fast GPU access and rendering. The aforementioned operation of converting shared binary data into the first format of OpenGL ES buffer objects ensures that 3D models shared between the Unity engine and native applications can be efficiently parsed and rendered in Android applications, thereby improving graphics performance and reducing resource waste.

[0138] S3032. If the mobile native application is an Apple operating system iOS application, the mobile native application will convert the binary shared data into the first format of the Metal buffer.

[0139] When the target platform is an Apple iOS application, the first format operation is performed to convert the shared binary data into a Metal buffer. Specifically, this involves converting the shared binary data into a buffer within the Metal framework. Metal is a high-performance graphics and computing API from Apple, designed to replace older versions of OpenGL, thereby achieving lower latency and higher efficiency in graphics rendering.

[0140] The function of the buffer is to store resources such as vertex data and texture information so that Metal can quickly read this data at runtime. By performing an operation to convert binary shared data into the first format of the Metal buffer, the hardware acceleration capabilities of Apple's iOS operating system can be fully utilized, thereby improving rendering speed and image quality, and reducing CPU load.

[0141] S3033. If the mobile native application is a HarmonyOS application, the mobile native application will convert the binary shared data into the first format of the graphical application programming interface (API) object.

[0142] For the HarmonyOS application platform, the process of converting binary shared data into the first format of a graphics application programming interface (API) object refers to converting the shared data into an object format that conforms to the HarmonyOS API specification. The HarmonyOS application platform provides its own graphics API system, supporting cross-device collaboration and low-power rendering. The steps for converting binary shared data into the first format of a graphics API object typically include data structure mapping, format standardization, and resource optimization. These steps aim to ensure that graphics data can run efficiently on the HarmonyOS application platform.

[0143] In this embodiment, shared data is adapted to corresponding graphics formats based on different types of native mobile applications. For example, Android applications use OpenGL ES buffer objects for embedded systems, Apple's iOS applications use Metal buffers, and HarmonyOS applications use graphics application programming interface (API) objects. By adapting shared data to corresponding graphics formats based on different types of native mobile applications, efficient rendering of 3D model data on different platforms can be guaranteed. This method can improve graphics performance and user experience, and enhance the consistency and stability of cross-platform applications.

[0144] In the process of data sharing, in one embodiment, before the mobile native application obtains the shared data of the vehicle 3D model based on the resource identifier and shared memory area in the first notification information in S302, it is also necessary to perform verification. If the verification is successful, S302 is executed.

[0145] In one possible implementation, the verification process may include, but is not limited to, S305 to S308 described below.

[0146] S305. The mobile native application obtains the access token and access permissions from the first notification information and performs the first verification based on the access token and access permissions.

[0147] The first verification is used to characterize whether the mobile native application can access the shared resources of the vehicle's 3D model.

[0148] An access token is a time-sensitive and unique string used to verify whether a requester has permission to access a specific resource. Access permissions refer to the scope of operations set for a specific resource, such as read-only, write-only, or full control. In this embodiment, when the Unity engine sends a resource availability notification to the mobile native application, it includes an access token and access permission fields. After receiving the first notification from the Unity engine, the mobile native application first extracts the access token and access permission fields and submits them to the security module for verification. Only when the access token is valid and the access permission fields match the required permissions is the mobile native application allowed to continue accessing the shared resources of the vehicle's 3D model.

[0149] By setting up access control mechanisms, unauthorized applications can be prevented from accessing sensitive vehicle 3D model data. The implementation of access control mechanisms can ensure the security of in-vehicle information systems, and enhanced security of in-vehicle information systems can improve the overall reliability of cross-platform communication.

[0150] S306. The mobile native application obtains the data size in the first notification information and performs a second verification based on the data size.

[0151] The second verification is to confirm the completeness of the data used to characterize the shared resources of the vehicle's 3D model.

[0152] Data size refers to the length of the binary data of the shared resource, usually expressed in bytes. The second verification process compares the actual received data size with the expected data size to determine data integrity. If the actual received data size differs from the expected data size, it may indicate packet loss, truncation, or other errors during data transmission. In this case, access to the shared resource of the vehicle's 3D model should be denied until the relevant issue is resolved.

[0153] This ensures that the shared data received by the mobile native application is complete, thus preventing rendering anomalies or functional failures caused by missing data. Consequently, the system can improve the stability and consistency of cross-platform resource sharing.

[0154] S307. The mobile native application obtains the resource type from the first notification information and performs third verification based on the resource type.

[0155] The third verification is used to characterize whether the mobile native application is compatible with the shared resources of the vehicle 3D model.

[0156] Resource type refers to the format and purpose of shared resources, such as texture maps, mesh models, and animation sequences. Different native platforms (such as Android, iOS, and HarmonyOS) have different processing methods and compatibility requirements for different types of resources. The third verification checks whether the resource type matches the format supported by the mobile native application, ensuring that the mobile native application can correctly parse and use the shared resources of the vehicle's 3D model. If the resource type is incompatible, the mobile native application will be unable to load the shared resources of the vehicle's 3D model correctly and will need to prompt the user or automatically convert it to a compatible format.

[0157] By ensuring that native mobile applications can correctly identify and use shared 3D model resources, runtime errors caused by format incompatibility can be avoided, thereby improving the universality and interoperability of cross-platform resource use.

[0158] S308. If the first verification, second verification and third verification are all passed, the mobile native application executes the shared data of the vehicle 3D model based on the resource identifier and shared memory area in the first notification information.

[0159] Only after successful verification of access tokens and access permissions, successful data integrity verification, and confirmation of resource type compatibility will a mobile native application with specific functions officially execute the access operation for shared data. These security verification steps before accessing data resources ensure that a mobile native application with specific functions can legally access the vehicle 3D model resources provided by the Unity engine only after meeting all security, integrity, and compatibility conditions.

[0160] In practice, there is a close logical relationship between the four steps of determining access tokens and permissions, data size, and resource type: First, authentication is performed using access tokens and permissions to ensure the caller has the necessary access rights; next, data integrity is checked based on data size to ensure the data is not corrupted; then, resource type compatibility is checked to prevent errors caused by unsupported formats; finally, if all verifications—access token and permission, data integrity, and resource type compatibility—pass, the system allows the mobile native application to access the shared data of the vehicle's 3D model. This process design effectively ensures the security, stability, and interoperability of cross-platform data sharing.

[0161] In one embodiment, the resource sharing process may also include, but is not limited to, the following S309.

[0162] S309. Maintain the lifecycle of shared resources for the vehicle 3D model through the resource sharing manager.

[0163] The resource sharing manager is located in the architecture layer between the native mobile application and the 3D vehicle control application.

[0164] The resource sharing manager is an architecture layer component that also manages the lifecycle of shared resources.

[0165] The lifecycle of a shared resource refers to the entire process from its creation to its destruction, including stages such as initialization, activation, use, hibernation, updating, and final release. The key to lifecycle management is ensuring a smooth transition between different resource states and preventing system crashes or data loss due to abnormal situations. For example, when a user switches out of the application, the resource sharing manager saves the current state of the resource and puts the resource sharing manager into hibernation. When the user returns, the resource sharing manager restores the resource to its active state, thus avoiding performance waste caused by repeatedly loading resources.

[0166] Native mobile applications refer to applications developed based on mobile operating systems (such as Android, iOS, and HarmonyOS), typically written in languages ​​such as Java, Kotlin, Objective-C, or Swift. These applications have high privileges and good performance, making them suitable for handling low-level logic, network communication, and hardware interaction. In this embodiment, the native application serves as the host environment for the 3D vehicle control application, providing basic functional support and cross-platform communication capabilities.

[0167] 3D vehicle control applications refer to applications built on Unity or other graphics engines used to display and control 3D models of vehicles. 3D vehicle control applications typically possess complex rendering capabilities and interactive logic, but they rely on resource management and lifecycle control provided by the native application's resource sharing manager. In this embodiment, the 3D vehicle control application is deeply integrated with the native application through a resource sharing manager, achieving efficient resource utilization and cross-platform compatibility.

[0168] The Resource Sharing Manager resides in the architectural layer between the native mobile application and the 3D vehicle control application. Its role is to act as a bridge between the two applications, enabling resource scheduling and state synchronization. Specifically, the Resource Sharing Manager receives resource requests from the 3D vehicle control application via a message channel and sends corresponding instructions to the native application to load or release resources at appropriate times. Furthermore, the Resource Sharing Manager monitors resource usage and promptly reclaims unused resources to prevent excessive memory consumption from impacting system performance.

[0169] The resource sharing manager not only acts as an intermediary between resource requests and responses, but also triggers a series of linkage mechanisms when the resource status changes. For example, when a resource enters a dormant state, the resource sharing manager notifies the 3D vehicle control application to reduce the rendering quality to reduce the CPU / GPU load, thereby further optimizing the overall performance.

[0170] By maintaining the lifecycle of shared resources through a resource sharing manager, resource management challenges in cross-platform applications can be effectively solved. For example, during the resource loading phase, the resource sharing manager can dynamically adjust the resolution and complexity of resources based on device performance to adapt to different hardware configurations; during the resource usage phase, the resource sharing manager can monitor the access frequency of resources in real time and optimize resource caching strategies; during the resource release phase, the resource sharing manager can ensure that resources are properly cleaned up, avoiding memory leaks and resource residue issues. These measures—dynamically adjusting resources based on device performance, monitoring resource access frequency in real time and optimizing caching strategies, and ensuring proper resource cleanup—not only improve resource utilization but also enhance stability and reliability.

[0171] In this embodiment, a resource sharing manager is introduced to achieve efficient management and control of vehicle 3D model resources in a cross-platform environment. By introducing the resource sharing manager, it is ensured that resources shared between different platforms (such as Android, iOS, and HarmonyOS) are loaded, used, updated, or released at the correct time. The introduction of the resource sharing manager enables the system to avoid resource conflicts, memory leaks, and other problems, further improving system stability and operating efficiency.

[0172] In one possible implementation, S309 includes, but is not limited to, at least one of S3091 to S3093 described below.

[0173] S3091. During the usage phase of shared resources, the resource sharing manager monitors the access frequency and memory usage of shared resources, and releases some resources in the shared memory area when it detects that the memory usage exceeds the first threshold.

[0174] The Resource Sharing Manager is a system component responsible for coordinating resource allocation and recycling between Unity and the native platform. Its role is to dynamically adjust resource usage in different application scenarios to ensure stable system performance and prevent memory overflow.

[0175] When shared resources are accessed frequently and the amount of memory required for access is high, it may affect the overall system performance. Therefore, the resource sharing manager continuously monitors memory usage, and once it detects that memory usage exceeds a preset first threshold, it will proactively release some resources that are no longer frequently used to reduce memory pressure.

[0176] S3092. If the 3D vehicle control application updates the vehicle 3D model, the resource sharing manager uses an incremental update strategy to update the changed data in the vehicle 3D model.

[0177] Incremental update strategy is a mechanism that updates only the parts of the data that have changed, rather than reloading the entire model, thereby reducing the amount of data transferred and processing time.

[0178] In 3D vehicle control applications, when users make configuration changes, such as replacing the appearance or upgrading parts, the vehicle model will undergo partial changes due to these configuration changes. In this case, the resource sharing manager will not resend the complete model data, but will instead package and send the differences, such as newly added textures or modified vertex information, to the native application.

[0179] The incremental update strategy relies on model version control and differential algorithms to ensure that only the necessary data is transmitted with each update.

[0180] S3093. If the mobile native application exits the application or exits resource sharing, the resource sharing manager releases the shared memory area of ​​the vehicle 3D model.

[0181] When users close applications or switch to other tasks, system resources that have been allocated but are no longer in use should be promptly cleared to avoid unnecessary memory consumption. The Resource Sharing Manager will immediately release shared memory regions upon receiving notification of application exit or end of resource sharing, ensuring that system resources are reclaimed in a timely manner. The process of releasing shared memory regions typically includes unmapping memory, clearing related caches, and notifying native applications that resources are unavailable.

[0182] By releasing shared memory regions when an application exits, memory leaks can be effectively prevented, thereby improving system resource utilization and enhancing the robustness and stability of cross-platform applications.

[0183] In this embodiment, the resource sharing manager performs fine-grained management of the lifecycle of shared resources, including memory usage monitoring, incremental update strategies, and shared memory area release operations. The resource sharing manager can achieve efficient resource utilization and fast response, thereby optimizing the performance of cross-platform applications and improving the user's interactive experience and the reliability of system operation.

[0184] When sharing data, before executing S301, the following steps may be performed, including but not limited to S401 to S404.

[0185] S401, the 3D vehicle control application creates a shared memory area in the communication system for running the 3D model of the vehicle.

[0186] A shared memory region is a memory space reserved in a communication system that can be accessed by multiple processes simultaneously. Shared memory regions are used to implement cross-process data exchange.

[0187] The 3D vehicle control application is responsible for initializing and managing the shared memory area of ​​the vehicle's 3D model to ensure that the Unity engine and native mobile applications can efficiently read and write data. The communication system, by using a shared memory mechanism, avoids frequent data copying and serialization operations, thereby improving system response speed and resource utilization.

[0188] The creation of shared memory regions typically relies on low-level APIs provided by the communication system, such as the MemoryFile or SharedMemory interface on Android, and system calls like mach_vm_map on iOS. The communication system refers to operating system-level services that support inter-process communication, such as POSIX shared memory in Linux, NamedPipe in Windows, and XPC services in iOS.

[0189] S402, the 3D vehicle control application maps the shared data of the vehicle's 3D model to a shared memory area.

[0190] After mapping the shared data of the vehicle's 3D model to the shared memory area of ​​the vehicle's 3D model, the Unity engine and native mobile applications can directly access it through memory addresses, without having to transmit data through the traditional IPC (Inter-Process Communication) method.

[0191] S403, the first notification message generated by the 3D vehicle control application to share the vehicle's 3D model.

[0192] The first notification message for sharing the vehicle's 3D model is a signal sent by the 3D vehicle control application to the native mobile application. This signal informs the 3D vehicle control application that the shared memory area for the vehicle's 3D model is ready and contains usable vehicle 3D model data. For example, the first notification message typically includes metadata such as the shared memory identifier, data version number, data size, and checksum, enabling the native mobile application to verify the validity and integrity of the data.

[0193] S404, the 3D vehicle control application sends the first notification information to the mobile native application.

[0194] The initial notification message for sharing the vehicle's 3D model is sent via a pre-defined message channel, which establishes a bidirectional communication link between the Unity engine and the native mobile application. The message channel can be implemented using Socket-based communication, file descriptor passing, or a platform-specific IPC mechanism.

[0195] By sending an initial notification message about sharing the vehicle's 3D model, the mobile native application can promptly learn that the 3D vehicle control application is ready to share data and initiate the subsequent rendering process based on this status. This initial notification and subsequent rendering initiation improves overall system efficiency, reliability, and stability. It avoids the performance overhead of traditional data copying, reducing system latency, improving rendering efficiency, and ultimately providing a smoother user experience.

[0196] In one embodiment, prior to performing S401 as described above, S405 to S408 may also be performed, including but not limited to the following.

[0197] S405, 3D vehicle control application evaluation: assesses the rendering capabilities and memory limitations of the platform to which the mobile native application belongs.

[0198] Native mobile applications run on platforms such as Android, iOS, and HarmonyOS. Due to differences in hardware configurations, graphics API support, and memory management mechanisms across these platforms, their capabilities for rendering 3D vehicle models vary. For example, high-end Android devices may support OpenGL ES 3.2 or the Vulkan graphics API, while some low-end devices may only support OpenGL ES 2.0. Memory limitations refer to the maximum amount of memory a platform can allocate to a native mobile application during runtime; this limitation is typically influenced by the system's total memory and multitasking scheduling strategies.

[0199] The evaluation process includes detecting the GPU model of the current platform, the maximum texture size, the vertex cache size, the available video memory capacity, and whether advanced features such as anti-aliasing and shadow mapping are supported. Simultaneously, frame rate performance and memory usage under different image quality settings are evaluated through simulated or actual loading tests. The evaluation results obtained from this process will serve as an important basis for subsequent simplification processing.

[0200] By assessing the rendering capabilities and memory limitations of the platform to which the mobile native application resides, it can be ensured that the loaded 3D vehicle model will not lag or crash on the target device due to insufficient resources, nor will it waste performance due to excessive complexity of the 3D vehicle model, thereby improving user experience and ensuring cross-platform compatibility.

[0201] S406, a 3D vehicle control application, simplifies the vehicle 3D model based on rendering capabilities and memory limitations, resulting in a simplified vehicle 3D model.

[0202] Simplification refers to reducing the geometric complexity and material overhead of a vehicle's 3D model without affecting the visual experience. Simplification can include reducing the number of polygons, merging duplicate materials, removing unseen surfaces, and optimizing UV map layout. The simplification method can be dynamically adjusted based on the platform; for example, a more aggressive simplification strategy can be used on lower-end devices, while more detail can be retained to improve image quality on higher-end devices.

[0203] Simplification can also include optimizing animation skeletons, removing unnecessary bone nodes, and reducing computational burden; or developers can compress textures using platform-specific compression formats (such as ETC, PVRTC, and ASTC) to reduce memory usage.

[0204] By implementing simplified processing operations for platform adaptation of vehicle 3D models, rendering load and memory consumption can be effectively reduced while ensuring basic functions and visual quality, thereby improving the smoothness of operation and preventing crashes or stutters caused by resource overload.

[0205] S407, the 3D vehicle control application performs format conversion and serialization processing on simplified 3D vehicle models.

[0206] Format conversion refers to converting a vehicle's 3D model from one file format (such as FBX, OBJ, glTF) to a native format suitable for the target platform (such as Unity's AssetBundle or Android's OpenGL buffer). Serialization, on the other hand, packages the vehicle's 3D model data (including vertices, indices, textures, animations, etc.) into a compact binary format for fast reading and transmission. Differential coding, quantization compression, and other techniques can be used during serialization to further reduce data size.

[0207] In addition, to improve cross-platform sharing efficiency, the serialized data structure should have a unified interface specification to facilitate interoperability between native applications and the Unity engine.

[0208] By converting formats and serializing data, vehicle 3D model data can be standardized and stored and transmitted efficiently, improving model loading speed and cross-platform consistency, and providing a good foundation for subsequent sharing and rendering.

[0209] S408, the 3D vehicle control application identifies the serialized 3D vehicle model as shared data for the 3D vehicle model.

[0210] Shared data refers to a unified data structure that can be accessed and used by both Unity and native applications. The process of determining shared data includes generating unique identifiers for the vehicle 3D models within the shared data, defining data access permissions, and setting up shared memory address spaces. Unity serializes the vehicle 3D models from the shared data and saves them to a shared memory area. Native applications can then retrieve and parse the vehicle 3D model data from the shared data using the unique identifier corresponding to the model, and use this data in their rendering pipeline.

[0211] In this embodiment, by evaluating the rendering capabilities and memory limitations of the platform to which the mobile native application belongs, and accordingly simplifying, converting formats, and processing shared data for the vehicle's 3D model, the compatibility and operational efficiency of cross-platform 3D vehicle control applications can be effectively improved. This results in a high-quality user interaction experience and supports more complex 3D content display and real-time control requirements.

[0212] In one embodiment, S406 may include, but is not limited to, at least one of S4061 to S4064 described below.

[0213] S4061, 3D vehicle control applications use 3D data compression algorithms to process the 3D data in the vehicle 3D model.

[0214] 3D data refers to the basic geometric information that constitutes a 3D model, including vertex coordinates, normal directions, UV mapping, etc., used to describe the model's spatial shape and surface properties. 3D data compression algorithms are efficient compression methods for 3D model data structures, reducing data storage space and transmission bandwidth without significantly sacrificing visual quality. Common 3D data compression algorithms include Octree compression, Squish compression, and compression schemes based on geometry simplification and topology optimization. After processing with 3D data compression algorithms, the file size of 3D models can be significantly reduced, the loading speed of 3D models is improved, and the resources consumed during device operation are reduced.

[0215] By optimizing the model structure, the storage space requirements of the model can be effectively reduced, the model loading speed can be accelerated, the CPU and GPU load of the device can be reduced, and the overall system performance can be improved.

[0216] S4062, 3D vehicle control applications use quantization compression algorithms to process vertex data in the 3D vehicle model.

[0217] Vertex data is the most fundamental part of a 3D model, typically composed of a large number of vertices. Each vertex contains information such as its position (x, y, z), normals, tangents, color, and texture coordinates. Vertex data determines the shape and level of detail of the model. Quantization compression algorithms are a compression method that converts high-precision floating-point numbers into low-precision integers, and are commonly used for vertex data compression. Quantization compression algorithms significantly reduce the memory and bandwidth occupied by vertex data while maintaining the basic shape of the model.

[0218] By employing specific data optimization algorithms, the storage space and memory usage of vertex data can be effectively reduced, thereby reducing memory pressure during the rendering process and improving the rendering efficiency and stability of graphics processing devices.

[0219] The quantization compression method for vertex data is closely related to the overall compression strategy for 3D data. It is necessary to select appropriate quantization precision parameters based on the graphics hardware characteristics of the target platform in order to achieve an effective balance between compression ratio and rendering quality.

[0220] S4063, 3D vehicle control applications use differential coding algorithms to process the index data in the 3D vehicle model.

[0221] Index data defines the connectivity between vertices in the model, i.e., how triangular faces are combined, and is typically composed of a series of integer indices. Differential coding is a compression method that utilizes the small differences between adjacent data points to transform the original data into a sequence of differences. For example, in consecutive indices, if adjacent index values ​​do not change significantly, only the difference can be recorded instead of the complete value, thus achieving a higher compression ratio. Differential coding is particularly suitable for index data with high repetition or continuity.

[0222] By employing specific data compression techniques, the storage space of index data can be effectively compressed, thereby reducing the resources and time consumed in data processing during model loading and rendering, and thus improving overall operating efficiency and response speed.

[0223] S4064, 3D vehicle control applications use a custom compression algorithm to process the texture data in the 3D vehicle model.

[0224] Texture data is image information attached to the surface of a 3D model to enhance its visual realism. Common texture formats include PNG, JPEG, and DDS, each with its own specific compression mechanism. Custom compression algorithms are texture compression methods designed based on specific application scenarios and platform characteristics, achieving more efficient compression while maintaining visual quality. For example, compression formats such as ETC and PVRTC for mobile devices are typical custom compression algorithms. Furthermore, the optimal compression strategy can be selected based on the graphics API support of the target platform.

[0225] The methods described above effectively reduce the storage and transmission costs of texture data, thereby lowering device memory usage and rendering latency, and ultimately improving application smoothness and user experience. By employing various targeted compression algorithms to process different components of the vehicle's 3D model, the overall data size of the model can be significantly reduced, thereby lowering device memory and computing resource consumption, and ultimately improving application efficiency and compatibility.

[0226] The following explanation uses a 3D vehicle control application (a Unity application) as an example to illustrate the data processing process for application communication. The lifecycle management process includes: 1. Lifecycle Coordination at Application Startup. When a native application starts, the lifecycle coordinator first checks the application's current state at the native layer, and then calls the Unity application initialization event. Upon receiving the event, Unity starts each subsystem according to a predefined initialization sequence: first, it initializes the rendering system and configures optimal image quality settings; then, it loads basic 3D assets and vehicle models; next, it initializes the physics engine and audio system; and finally, it establishes a two-way communication channel with the native application. After each initialization step is completed, Unity sends progress updates to the native application to ensure that the user interface displays accurate loading progress.

[0227] 2. State Preservation During Application Pause. When a user switches the application to the background, the native application's lifecycle callback function is triggered, immediately notifying the lifecycle coordinator. The coordinator adopts different pause strategies depending on the reason for the pause (such as answering a phone call, switching applications, insufficient system memory, etc.). For short-term pauses (such as answering a phone call), Unity maintains the basic rendering cycle but reduces the frame rate and image quality, while saving the current vehicle state, user interaction state, and 3D scene state to local storage. For long-term pauses, Unity releases most GPU resources, stops unnecessary computational tasks, but maintains a heartbeat connection with the native application.

[0228] 3. State Synchronization Upon Application Resumption. When the application returns to the foreground, the lifecycle coordinator first assesses the pause duration and system resource status, then formulates a recovery strategy. For short pauses (less than 5 minutes), Unity quickly restores the previous rendering settings and 3D scene state, verifies the consistency of the vehicle state, and performs state synchronization if inconsistencies are found. For long pauses, Unity reinitializes certain system components, reloads resources that may have been reclaimed by the system, and performs a complete state synchronization with the native application to ensure that the information seen by the user is completely consistent with the actual vehicle state.

[0229] 4. Lifecycle Recovery in Abnormal Situations. When abnormal situations such as Unity engine crashes, communication interruptions, or insufficient memory are detected, the lifecycle coordinator initiates the abnormal recovery process. First, it attempts to re-establish the communication connection via a heartbeat mechanism. If the Unity process is still running, a reset command is sent to request Unity to reinitialize critical components. If the Unity process has terminated, the coordinator restarts the Unity subsystem and restores the last saved state from local storage. During the recovery process, the native application displays the recovery progress and provides user-selectable actions, such as skipping 3D rendering and directly using basic functions.

[0230] The design of a complete lifecycle state machine includes: state definition and transition rules, and triggering conditions for state transitions.

[0231] The state definitions and transition rules include: The lifecycle manager defines thirteen main states, covering the complete process from application startup to destruction. The uninitialized state is the application's initial state and can only transition to the initialized state. The initialized state handles the system startup process and can transition to the creation or error state. The creation state indicates that basic components are ready and can transition to the startup state or be directly destroyed. The startup state activates main functions and transitions to the started state upon success. The started state can transition to the restore state to enter active mode or to the stopped state. The active state is the normal operating state, capable of responding to user interaction, and can transition to the paused state or be directly stopped. State transitions strictly follow predefined rules to prevent illegal state jumps.

[0232] For example, lifecycle status can be referenced Figure 3 The content shown can include the following lifecycle states: Uninitialized 501, Initialized 502, Created 503, Started 504, Started 505, Active 506, Paused 507, Stopped 508, Destroyed 509, Error 510.

[0233] The triggering conditions for state transitions include various events, such as user actions, system events, and external interruptions. User actions, such as launching an application, switching to the background, or closing an application, directly trigger the corresponding state transition. System events, such as insufficient memory, low battery, or changes in network connectivity, trigger adaptive state transitions. External interruptions, such as incoming calls, SMS messages, or system updates, trigger paused or degraded state transitions. Each triggering condition has a corresponding handling strategy to ensure the rationality and consistency of state transitions.

[0234] The following section explains the lifecycle management of cold start.

[0235] Initialization is performed in phases: The cold start process is broken down into multiple interdependent phases to ensure a stable and reliable system startup. The first phase initializes core framework components, including the message channel manager, serialization engine, and platform adapter. The second phase initializes the Unity engine, configuring the rendering pipeline, loading basic resources, and setting scene parameters. The third phase initializes business logic components, including the vehicle controller, user interface, and data manager. The fourth phase establishes communication connections with the native application and performs initial data synchronization. Each phase has clearly defined success criteria and failure handling strategies.

[0236] Resource loading priority management: Resource loading during startup is managed according to priority, ensuring that critical resources are loaded first. High-priority core resources include basic 3D models, key textures, and audio files; these resources determine the basic functionality of the application. Medium-priority auxiliary resources include high-precision models, decorative textures, and background music, which enhance the user experience without affecting core functionality. Low-priority optional resources include extended functional modules and additional visual effects, which can be loaded asynchronously in the background.

[0237] Real-time startup progress feedback: Report startup progress to the native application in real time to ensure the user interface displays the accurate loading status. Progress information includes the current stage name, completion percentage, estimated remaining time, and types of resources being loaded. Progress updates are non-blocking and do not affect the actual loading process. When a stage takes too long, provide detailed status descriptions to help users understand the current operation.

[0238] Recovery strategies for startup failures: When errors occur during startup, different recovery strategies are adopted based on the error type and severity. For resource loading failures, try using alternative or degraded resources. For component initialization failures, attempt to reinitialize or skip non-critical components. For critical errors, log detailed diagnostic information and provide user-selectable actions such as restart, safe mode startup, and error reporting.

[0239] The following section explains the hot-swap lifecycle management process.

[0240] Intelligent recognition of pause trigger reasons: It can identify different pause trigger reasons and take corresponding optimization strategies. When a call is paused, vehicle status monitoring is maintained but rendering quality is reduced to ensure quick resumption after the call ends. When a user actively switches applications, complete state saving and resource release are performed to make room for other applications. When memory is insufficient, cache and unnecessary resources are proactively released to avoid forced termination by the system. Each pause reason has a corresponding handling strategy and recovery plan.

[0241] A gradual resource release strategy is employed: the pause process uses gradual resource release, dynamically adjusting resource usage based on the pause duration. Short pauses (less than 1 minute) only reduce rendering quality and frame rate, preserving resources in memory. Medium pauses (1-5 minutes) release some cached and temporary resources, retaining core data. Long pauses (more than 5 minutes) release most memory resources, retaining only the most basic state information. This strategy conserves resources while allowing for rapid recovery.

[0242] State preservation ensures integrity: State preservation during pauses ensures that the user's usage state can be fully restored after the application resumes. Preserved content includes the current vehicle state, user interface state, 3D scene state, user preference settings, etc. State data is saved incrementally, only recording the changed parts, reducing storage space usage and saving time. The state preservation process employs a transaction mechanism to ensure data consistency and integrity.

[0243] Intelligent recovery timing selection: The system intelligently selects the recovery timing and strategy based on multiple factors. Recovery after a short pause uses a fast path, directly restoring the previous state and settings. Recovery after a long pause uses a full path, re-verifying the system state and resource availability. During the recovery process, the system monitors the device's performance status, such as battery level, network connectivity, and memory usage, adjusting the recovery strategy according to current conditions.

[0244] The resource sharing process will be explained below.

[0245] Unity Resource Preparation and Optimization Phase: When Unity needs to share a high-precision vehicle 3D model with a native application, the Resource Sharing Manager first analyzes and optimizes the model. The analysis process includes calculating the model's vertex count, face count, texture size, and material complexity, and assessing the native platform's rendering capabilities and memory limitations. The optimization process includes model simplification (reducing unnecessary details), texture compression (selecting the most suitable compression format for the target platform), and material merging (reducing rendering batches). The optimized model data is organized into a standardized format, containing geometric data, texture data, animation data, and metadata.

[0246] Resource Serialization and Memory Mapping: The resource sharing manager uses a high-efficiency binary serialization engine to convert optimized 3D models into a compact binary format. The serialization process employs compression algorithms optimized for 3D data, such as quantization compression for vertex data, differential encoding for index data, and platform-specific compression formats for texture data. After serialization, the manager creates a shared memory region in system memory, maps the binary data to this region, and generates unique resource identifiers and access tokens.

[0247] Cross-Layer Resource Notification Mechanism: Once resources are prepared, Unity sends a resource availability notification to the native application via a message channel. The notification message includes detailed information such as the resource identifier, resource type, data size, compression ratio, memory address, and access permissions. The message also contains metadata about the resource, such as the model's bounding box, number of materials, and animation frame rate, helping the native application pre-allocate rendering resources. The notification message is transmitted with high priority to ensure that the native application receives resource availability information promptly.

[0248] Native application resource acquisition and usage: Upon receiving a resource notification, the native application accesses the shared memory area via the resource identifier to obtain binary resource data. The acquisition process includes permission verification, data integrity checks, and format compatibility verification. The native application converts the binary data into a platform-specific rendering format, such as converting it to an OpenGLES buffer object on Android, a Metal buffer on iOS, and a corresponding graphics API object on HarmonyOS. After conversion, the native application can use the shared 3D model in its own rendering pipeline to achieve the same visual effects as Unity.

[0249] Resource Lifecycle and Memory Management: The resource sharing manager maintains the complete lifecycle of shared resources, including creation, use, update, and destruction phases. During the use phase, the manager monitors resource access frequency and memory usage, automatically releasing infrequently used resources when memory pressure is detected. When Unity updates 3D models, the manager uses an incremental update strategy, transferring only the changed parts, significantly reducing data transfer volume. When the application exits or resources are no longer needed, the manager ensures timely release of shared memory to prevent memory leaks.

[0250] Secondly, embodiments of this application provide a data processing apparatus for application communication. The data processing apparatus 60 for application communication includes: a listening unit 601, used to listen to the lifecycle events of a mobile native application in the communication system through a lifecycle manager; and an updating unit 602, used to update the lifecycle state of a 3D vehicle control application in the communication system based on the lifecycle events of the mobile native application, so that the updated 3D vehicle control application is synchronized with the lifecycle state of the mobile native application; wherein, the lifecycle manager is located in the architecture layer between the mobile native application and the 3D vehicle control application; the 3D vehicle control application and the mobile native application have different lifecycle division methods.

[0251] In some embodiments, the update unit 602 is further configured to: upon detecting a startup event of the mobile native application, invoke the initialization event and startup event of the 3D vehicle control application to perform initialization and startup processing; upon detecting a pause event of the mobile native application, invoke the pause event of the 3D vehicle control application to adjust the life state of the 3D vehicle control application; upon detecting a restore event of the mobile native application, determine the target restore type; invoke the restore event of the 3D vehicle control application, and adjust the life state of the 3D vehicle control application based on the target restore type.

[0252] In some embodiments, the updating unit 602 is further configured to: when the native mobile application is an Android application, identify the startup event as an application creation event and an application startup event, identify the pause event as an application pause event or an application stop event, and identify the resume event as an application resume event or an application restart event; when the native mobile application is an Apple operating system (iOS) application, identify the startup event as an application startup event, the pause event as an application inactive event or an application entering the background event, and the resume event as an application entering the foreground event; when the native mobile application is a HarmonyOS application, identify the startup event as an application creation event, the pause event as an application entering the background event, and the resume event as an application entering the foreground event.

[0253] In some embodiments, the update unit 602 is further configured to initialize the 3D vehicle control application; configure the rendering pipeline of the 3D vehicle control application and load the first resource of the 3D vehicle control application; initialize the business logic components of the 3D vehicle control application; and establish a communication connection between the 3D vehicle control application and the mobile native application.

[0254] In some embodiments, the updating unit 602 is further configured to: load the basic 3D data, key textures, and audio files of the vehicle 3D model in the 3D vehicle control application based on a first priority; load the high-precision data, decorative textures, and background music of the vehicle 3D model based on a second priority; and load the extended function modules and visual effect modules of the 3D vehicle control application based on a third priority; wherein the first priority is higher than the second priority, and the second priority is higher than the third priority.

[0255] In some embodiments, the apparatus further includes a feedback unit for providing feedback on the initialization and startup processing progress to the mobile native application, so that the mobile native application displays the initialization and startup processing progress on the display screen; wherein the startup progress includes the current stage name, completion percentage, estimated remaining time, and the type of resources loaded.

[0256] In some embodiments, the updating unit is further configured to: maintain the status monitoring function of the 3D vehicle control application and reduce the rendering quality of the 3D vehicle control application when the pause event is paused due to incoming call; save the status of each parameter of the 3D vehicle control application and release all running resources of the 3D vehicle control application when the pause event is paused due to application switching; and actively release part of the cache and part of the running resources of the 3D vehicle control application when the pause event is paused due to insufficient memory.

[0257] In some embodiments, the updating unit is further configured to: reduce the rendering quality and frame rate of the 3D vehicle control application when the pause duration of the pause event is within a first duration range; release the first cache and first memory resources of the 3D vehicle control application to maintain the operation of core data when the pause duration of the pause event is within a second duration range; and release the second memory resources of the 3D vehicle control application to maintain the operation of basic data when the pause duration of the pause event is within a third duration range; wherein the second memory resources are greater than the first memory resources; and wherein the duration in the first duration range is less than the duration in the second duration range, and the duration in the second duration range is less than the duration in the third duration range.

[0258] In some embodiments, the updating unit is further configured to, when the target recovery type is a first recovery type, use a fast path to restore the 3D vehicle control application to its state and settings before the pause; the first recovery type is used to characterize recovery after a first pause; when the target recovery type is a second recovery type, use a full path to restore the state and settings of the 3D vehicle control application; the second recovery type is used to characterize recovery after a second pause; the second pause is greater than the first pause.

[0259] In some embodiments, the apparatus further includes a sharing unit for receiving first notification information sent by a 3D vehicle control application; the first notification information is used to characterize that the resources of the vehicle 3D model in the 3D vehicle control application are shareable; based on the resource identifier and shared memory region in the first notification information, shared data of the vehicle 3D model is obtained; the shared data is converted into a format supported by the operating system of the mobile terminal to obtain shared data in a first format; and the vehicle 3D model is shared based on the shared data in the first format.

[0260] In some embodiments, the sharing unit is further configured to: if the mobile native application is an Android application, convert the binary shared data into a first format of an OpenGL ES buffer object for an embedded system of open graphics libraries; if the mobile native application is an Apple operating system iOS application, convert the binary shared data into a first format of a Metal buffer; and if the mobile native application is a HarmonyOS application, convert the binary shared data into a first format of a graphics application programming interface (API) object.

[0261] In some embodiments, the sharing unit is further configured to: before acquiring the shared data of the vehicle 3D model based on the resource identifier and shared memory region in the first notification information, acquire the access token and access permissions in the first notification information, and perform a first verification based on the access token and access permissions; the first verification is used to characterize whether the mobile native application can access the shared resources of the vehicle 3D model; acquire the data size in the first notification information, and perform a second verification based on the data size; the second verification is used to characterize whether the data of the shared resources of the vehicle 3D model is complete; acquire the resource type in the first notification information, and perform a third verification based on the resource type; the third verification is used to characterize whether the mobile native application is compatible with the data of the shared resources of the vehicle 3D model; and if the first verification, the second verification, and the third verification all pass, execute the acquisition of the shared data of the vehicle 3D model based on the resource identifier and shared memory region in the first notification information.

[0262] In some embodiments, the device further includes a resource sharing management unit for maintaining the lifecycle of shared resources of the vehicle 3D model; wherein the resource sharing manager is located in the architecture layer between the mobile native application and the 3D vehicle control application.

[0263] In some embodiments, the resource sharing management unit is further configured to: monitor the access frequency and memory usage of the shared resources during the usage phase of the shared resources; and release a portion of the resources in the shared memory area when the memory usage is detected to be greater than a first threshold; if the 3D vehicle control application updates the vehicle 3D model, it adopts an incremental update strategy to update the changed data in the vehicle 3D model; and if the mobile native application exits the application or exits resource sharing, it releases the shared memory area of ​​the vehicle 3D model.

[0264] In some embodiments, the sharing unit is further configured to: before the mobile native application receives the first notification information sent by the 3D vehicle control application, the 3D vehicle control application creates a shared memory region in the communication system for running the vehicle 3D model; maps the shared data of the vehicle 3D model to the shared memory region; generates the first notification information for sharing the vehicle 3D model; and sends the first notification information to the mobile native application.

[0265] In some embodiments, the sharing unit is further configured to: assess the rendering capabilities and memory limitations of the platform to which the mobile native application belongs before the 3D vehicle control application creates a shared memory region for running the vehicle 3D model in the communication system; simplify the vehicle 3D model based on the rendering capabilities and memory limitations to obtain a simplified vehicle 3D model; perform format conversion and serialization processing on the simplified vehicle 3D model; and determine the serialized vehicle 3D model as the shared data of the vehicle 3D model.

[0266] In some embodiments, the shared unit is further configured to process the three-dimensional data in the vehicle three-dimensional model using a three-dimensional data compression algorithm; process the vertex data in the vehicle three-dimensional model using a quantization compression algorithm; process the index data in the vehicle three-dimensional model using a differential coding algorithm; and process the texture data in the vehicle three-dimensional model using a custom compression algorithm.

[0267] It should be noted that the data processing device for application communication 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.

[0268] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

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

[0270] Thirdly, embodiments of this application provide an electronic device that can implement the data processing method for application communication provided in the first aspect above.

[0271] 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 any of the application communication data processing methods provided in the first aspect of the above embodiments.

[0272] Fifthly, embodiments of this application provide a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by a processor, they implement the steps in any of the application communication data processing methods provided in the first aspect of the above embodiments.

[0273] It should be noted that the descriptions of the above embodiments of storage media, devices, apparatuses, and program products are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of storage media, devices, apparatuses, and program products of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0274] 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 data processing method for application communication, characterized by, The method comprises: listening to a life cycle event of a mobile terminal native application in a communication system by a life cycle manager; updating a state of a life cycle of a three-dimensional vehicle control application in the communication system based on the life cycle event of the mobile terminal native application, so that the three-dimensional vehicle control application after the updating and the state of the life cycle of the mobile terminal native application are kept in synchronization; wherein the life cycle manager is located in an architecture layer between the mobile terminal native application and the three-dimensional vehicle control application; the three-dimensional vehicle control application and the mobile terminal native application are different in life cycle division mode.

2. The method of claim 1, wherein, The updating of the state of the life cycle of the three-dimensional vehicle control application based on the life cycle event of the mobile terminal native application comprises: in a case where an enabling event of the mobile terminal native application is detected, calling an initialization event and a starting event of the three-dimensional vehicle control application to perform initialization and starting processing; in a case where a pausing event of the mobile terminal native application is detected, calling a pausing event of the three-dimensional vehicle control application to adjust a life state of the three-dimensional vehicle control application; in a case where a resuming event of the mobile terminal native application is detected, determining a target resuming type; calling a resuming event of the three-dimensional vehicle control application to adjust the life state of the three-dimensional vehicle control application based on the target resuming type.

3. The method of claim 2, wherein in a case where the mobile terminal native application is an Android application, the starting event comprises an application creation event and an application starting event, the pausing event comprises an application pausing event or an application stopping event, and the resuming event comprises an application resuming event or an application restarting event; in a case where the mobile terminal native application is an IOS application of an Apple operating system, the starting event comprises an application starting event, the pausing event comprises an application inactivation event or an application entering background event, and the resuming event comprises an application entering foreground event; in a case where the mobile terminal native application is a Harmony application, the starting event comprises an application creation event, the pausing event comprises an application entering background event, and the resuming event comprises an application entering foreground event.

4. The method of claim 2, wherein, The calling of the initialization event and the starting event of the three-dimensional vehicle control application to perform initialization and starting processing comprises: initializing the three-dimensional vehicle control application; configuring a rendering pipeline of the three-dimensional vehicle control application, and loading first resources of the three-dimensional vehicle control application; initializing a business logic component of the three-dimensional vehicle control application; establishing a communication connection between the three-dimensional vehicle control application and the mobile terminal native application.

5. The method of claim 4, wherein, The loading of the first resources of the three-dimensional vehicle control application comprises: loading basic three-dimensional data, key textures, and audio files of a vehicle three-dimensional model in the three-dimensional vehicle control application based on a first priority; loading high-precision data, decorative textures, and background music of the vehicle three-dimensional model based on a second priority; loading an extended function module and a visual effect module of the three-dimensional vehicle control application based on a third priority; wherein the first priority is higher than the second priority, and the second priority is higher than the third priority.

6. The method according to any one of claims 2-5, characterized in that, After the initialization event and the start event of the three-dimensional vehicle control application are called to perform initialization and start processing, the method further comprises: feeding back the initialization and start processing progress to the mobile terminal native application, so that the mobile terminal native application displays the initialization and start processing progress on a display screen; wherein the start progress comprises a current stage name, a completion percentage, a predicted remaining time, and a loaded resource type.

7. The method according to any one of claims 2-5, characterized in that, The pause event of the three-dimensional vehicle control application adjusts the life state of the three-dimensional vehicle control application, comprising: in the case of incoming call pause, maintaining the state monitoring function of the three-dimensional vehicle control application and reducing the rendering quality of the three-dimensional vehicle control application; in the case of switching application pause, saving the state of each parameter of the three-dimensional vehicle control application and releasing all running resources of the three-dimensional vehicle control application; in the case of insufficient memory pause, actively releasing part of the cache and part of the running resources of the three-dimensional vehicle control application.

8. The method according to any one of claims 2-5, characterized in that, The pause event of the three-dimensional vehicle control application adjusts the life state of the three-dimensional vehicle control application, comprising: in the case that the pause duration of the pause event is in a first duration range, the rendering quality and frame rate of the three-dimensional vehicle control application are reduced; in the case that the pause duration of the pause event is in a second duration range, the first cache and the first memory resource of the three-dimensional vehicle control application are released to maintain the running of core data; in the case that the pause duration of the pause event is in a third duration range, the second memory resource of the three-dimensional vehicle control application is released to maintain the running of basic data; the second memory resource is greater than the first memory resource; wherein the duration in the first duration range is less than the duration in the second duration range, and the duration in the second duration range is less than the duration in the third duration range.

9. The method of claim 1, wherein, The method comprises: The mobile terminal native application receives the first notification information sent by the three-dimensional vehicle control application; the first notification information is used to represent that the resources of the vehicle three-dimensional model in the three-dimensional vehicle control application can be shared; based on the resource identifier and the shared memory area in the first notification information, the shared data of the vehicle three-dimensional model is obtained; the shared data is converted into a format supported by the operating system of the mobile terminal to obtain shared data in a first format; based on the shared data in the first format, the vehicle three-dimensional model is shared.

10. The method of claim 9, wherein, In the case that the shared data is binary data, the conversion of the shared data into a format supported by the operating system of the mobile terminal comprises: if the mobile terminal native application is an Android application, the binary shared data is converted into a first format of an OpenGL ES buffer object; if the mobile terminal native application is an IOS application of Apple operating system, the binary shared data is converted into a first format of a Metal buffer; if the mobile terminal native application is a Harmony application, the binary shared data is converted into a first format of a graphics API object.

11. The method of claim 9, wherein, Before the obtaining the shared data of the vehicle three-dimensional model based on the resource identifier and the shared memory area in the first notification information, the method further comprises: obtaining an access token and an access authority in the first notification information, and performing a first verification based on the access token and the access authority; the first verification is used to represent whether the mobile terminal native application can access the shared resource of the vehicle three-dimensional model; obtaining a data size in the first notification information, and performing a second verification based on the data size; the second verification is used to represent whether the data of the shared resource of the vehicle three-dimensional model is complete; obtaining a resource type in the first notification information, and performing a third verification based on the resource type; the third verification is used to represent whether the mobile terminal native application is compatible with the data of the shared resource of the vehicle three-dimensional model; if the first verification, the second verification and the third verification are all passed, the obtaining the shared data of the vehicle three-dimensional model based on the resource identifier and the shared memory area in the first notification information is executed.

12. The method according to any one of claims 9-11, characterized in that, The method further comprises: maintaining a life cycle of the shared resource of the vehicle three-dimensional model by a resource sharing manager; wherein the resource sharing manager is located in an architecture layer between the mobile terminal native application and the three-dimensional vehicle control application.

13. The method of claim 12, wherein, The maintaining the life cycle of the shared resource of the vehicle three-dimensional model by the resource sharing manager comprises: in a use stage of the shared resource, the resource sharing manager monitors an access frequency and a memory occupation of the shared resource, and releases part of the resources in the shared memory area when detecting that the memory occupation is greater than a first threshold value; if the three-dimensional vehicle control application updates the vehicle three-dimensional model, the resource sharing manager adopts an incremental update strategy to update the changed data in the vehicle three-dimensional model; if the mobile terminal native application exits the application or exits the resource sharing, the resource sharing manager releases the shared memory area of the vehicle three-dimensional model.

Images