Cloud local application non-inductive switching method, system and device and storage medium

Abstract

The invention discloses a cloud local application non-inductive switching method, system and device and a storage medium, and relates to the technical field of cloud virtualization and intelligent vehicle machine interaction, and the method comprises the steps: loading and uniformly displaying cloud and local applications when a vehicle machine is started; when the network is available, preloading the high-frequency cloud application based on the historical use data, and obtaining the unique serial number of the process of the high-frequency cloud application; when a user calls any cloud application, response data (such as application video streams) are directly obtained from the cloud according to whether the serial number is cached or not. According to the scheme, complete cloud mirror image pre-loading is abandoned, the single application serves as the minimum operation unit, the response time is reduced to be within the driving safety threshold value, and safety is improved; the delay is obviously reduced through intelligent preloading and instance multiplexing; seamless fusion of cloud local experience is realized and interaction splitting is eliminated through unified entrance, adaptive vehicle machine UI and cockpit hardware linkage.

Description

Technical Field

[0001] This application relates to the fields of cloud virtualization and intelligent vehicle-machine interaction technology, and in particular to a method, system, device and storage medium for seamless switching of cloud local applications. Background Technology

[0002] With the widespread adoption of intelligent connected vehicles, in-vehicle infotainment systems have evolved into the central hub for cockpit interaction. However, limited by hardware bottlenecks such as weak computing power and small storage capacity, they generally rely on cloud apps to compensate for local capabilities. However, existing solutions, which directly port the mobile app's "launch a complete cloud image → enter the desktop → open the app" calling pattern, are severely unsuitable for in-vehicle infotainment scenarios. On the one hand, the image loading takes 8-12 seconds, far exceeding the safety requirement of ≤2 seconds for a single operation while driving, which can easily cause distraction; on the other hand, the complete image has high resource consumption, which exacerbates the vehicle's system lag and cannot be cached, resulting in large delays when called repeatedly.

[0003] Meanwhile, the interaction is severely fragmented: voice commands require waking up the mirror first, resulting in several seconds of no response; the interface is designed for mobile phone landscape mode, which causes misalignment and obstruction when projected onto the car's screen; the cloud APP runs in an isolated environment and cannot be linked to cockpit hardware such as the dashboard and HUD, forcing users to frequently turn their heads, increasing the risk.

[0004] Existing technologies may rely on touch icons, which violates the limited logic of in-vehicle voice control, or fail to resolve the fundamental conflict between "mirror-mounted front start" and driving safety.

[0005] Therefore, there is an urgent need for a fusion solution designed specifically for the characteristics of in-vehicle systems, which can solve the technical problems of high driving safety risks, large response delays, and fragmented interactive experiences caused by the requirement to start the complete cloud image in advance in existing cloud APP calling solutions.

[0006] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0007] The main purpose of this application is to provide a method, system, device, and storage medium for seamless switching of cloud-local applications, aiming to solve the technical problems of high vehicle-machine driving safety risks, large response latency, and fragmented interactive experience caused by existing technologies.

[0008] To achieve the above objectives, this application proposes a method for seamless switching of cloud-local applications, which is applied to in-vehicle systems. The method includes: When a start command is received, the list of cloud applications stored locally is loaded, and the cloud applications and local applications are displayed on the vehicle's infotainment interface. Given the current network availability, at least one preloaded cloud application is determined based on the historical usage data of each cloud application in the cloud application list. Send a preload request to the cloud to trigger the cloud to start the preloaded cloud application, and receive the unique process number corresponding to each preloaded cloud application returned by the cloud; In response to a user's command to invoke any target cloud application, a data retrieval request is initiated from the cloud based on the unique process ID corresponding to the target cloud application, and the response data returned by the cloud is received.

[0009] In one embodiment, the step of determining at least one preloaded cloud application based on the historical usage data of each cloud application in the cloud application list includes: The usage frequency of each cloud application is determined based on the historical usage data of each cloud application in the cloud application list. Cloud applications whose usage frequency is higher than a preset frequency threshold are selected as candidate cloud applications, and sorted according to the most recent usage time of each candidate cloud application. Select preloaded cloud applications from the sorted candidate cloud applications, with a number not exceeding a preset threshold.

[0010] In one embodiment, the step of initiating a corresponding call request to the cloud based on the unique process ID corresponding to the target cloud application further includes: Determine whether the vehicle system has cached the unique process ID corresponding to the target cloud application; If so, the execution steps involve initiating a data retrieval request to the cloud based on the unique process ID corresponding to the target cloud application, and receiving the response data returned by the cloud. If not, an application launch request is sent to the cloud so that the cloud can launch the target cloud application based on the application launch request, and after generating a unique process number corresponding to the target cloud application, the corresponding response data is returned to the vehicle system.

[0011] In one embodiment, the data retrieval request includes at least one of the following: user identifier, cloud application unique identifier, process unique number, call operation instruction for cloud application, vehicle system information, and current network signal strength; The response data includes at least one of the following: a status code, a unique process ID corresponding to the target cloud application, and an application video stream corresponding to the target cloud application.

[0012] In one embodiment, after the step of receiving the response data returned by the cloud, the method further includes: In response to a user's exit command for a currently running cloud application via touch or voice, an exit request is sent to the cloud so that the cloud can pause the execution of the currently running cloud application and retain its current running state so that it can be quickly resumed when called again within a preset time.

[0013] Furthermore, to achieve the above objectives, this application also proposes a method for seamless switching of cloud-local applications. This method is applied in the cloud, where a server is deployed. The method includes: Receive the preload request sent by the vehicle's infotainment system; According to the preloading request, the preloading cloud application is started through the server and a unique process number is generated to identify the preloading cloud application. The preloading cloud application is determined by the vehicle system based on the historical usage data of each cloud application in the locally stored cloud application list. The unique process ID is returned to the vehicle's infotainment system so that the system can initiate a data retrieval request from the cloud based on the unique process ID. Receive the data retrieval request sent by the vehicle's infotainment system; Based on the data retrieval request, the corresponding response data is obtained through the server and transmitted to the vehicle system.

[0014] In one embodiment, the call request includes a data fetch request or an application launch request; the response data includes at least the application video stream, status code, and process unique ID; The step of obtaining the corresponding response data from the server according to the data retrieval request and transmitting the response data to the vehicle system includes: Based on the unique process ID carried in the data retrieval request, the real-time interface output of the target cloud application is used as an application video stream. Based on the current network signal strength contained in the call request, the encoding parameters of the application video stream are adjusted to obtain the adjusted application video stream; The response data, including the adjusted application video stream, the process's unique ID, and the status code, will be transmitted to the vehicle's infotainment system.

[0015] In one embodiment, before the step of receiving the data retrieval request sent by the vehicle-mounted system, the method further includes: When an application launch request is received from the vehicle's infotainment system, the target cloud application indicated by the application launch request is launched based on the current resource status of the server. After the target cloud application completes initialization, its interface output is obtained as the application video stream, and a corresponding unique process ID is generated. The process's unique ID and the application video stream are returned to the vehicle's infotainment system.

[0016] In one embodiment, after the step of transmitting the response data including the adjusted application video stream, the process unique number, and the status code to the vehicle-mounted system, the method further includes: When a request to exit the application is received from the vehicle system, the execution of the currently running cloud application is paused on the server side, while the current running state of the currently running cloud application is retained. If a data retrieval request for the same user and the same cloud application is received within a preset time period, the execution of the currently running cloud application is resumed, and the application video stream is transmitted to the vehicle.

[0017] In addition, to achieve the above objectives, this application also proposes a cloud-local application seamless switching system, which includes an in-vehicle system and a cloud platform; The vehicle infotainment system includes: The application loading module is used to load the list of cloud applications stored locally when a start command is received, and to display the cloud applications and local applications on the vehicle's interactive interface. The preloading module is used to determine at least one cloud application to be preloaded based on the historical usage data of each cloud application in the cloud application list, provided that the current network is available. The request sending model is used to send a preload request to the cloud to trigger the cloud to start the preloaded cloud application, and to receive the unique process number corresponding to each preloaded cloud application returned by the cloud. The application scheduling and processing module is used to respond to the user's call operation command for any target cloud application, initiate a data retrieval request to the cloud according to the unique process number corresponding to the target cloud application, and receive the response data returned by the cloud. The cloud includes: The receiving module is used to receive preload requests sent by the vehicle's infotainment system. The number generation module is used to start the preloaded cloud application through the server according to the preload request, and generate a unique process number to identify the preloaded cloud application. The preloaded cloud application is determined by the vehicle system based on the historical usage data of each cloud application in the cloud application list stored locally. The number sending module is used to return the unique process number to the vehicle system, so that the vehicle system can initiate a data retrieval request to the cloud based on the unique process number; The receiving module is also used to receive data retrieval requests sent by the vehicle-mounted system; The response return module is used to obtain the corresponding response data through the server according to the data retrieval request, and transmit the response data to the vehicle system.

[0018] In addition, to achieve the above objectives, this application also proposes a cloud-local application seamless switching device, the device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the cloud-local application seamless switching method described above.

[0019] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the cloud-local application seamless switching method described above.

[0020] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the cloud-local application seamless switching method described above.

[0021] This application proposes a method, system, device, and storage medium for seamless switching between cloud and local applications. The method includes: when the vehicle's infotainment system receives a startup command, loading a list of locally stored cloud applications and displaying both cloud and local applications on the vehicle's interactive interface; if the current network is available, determining at least one pre-loaded cloud application based on the historical usage data of each cloud application in the cloud application list; sending a pre-load request to the cloud to trigger the cloud to start the pre-loaded cloud application, and receiving the unique process IDs corresponding to each pre-loaded cloud application returned by the cloud; when the vehicle's infotainment system responds to a user's command to call any target cloud application, initiating a corresponding call request to the cloud based on the unique process ID of the target cloud application, and receiving response data returned by the cloud. This solution abandons the full cloud image pre-launch mode and uses a single cloud application as the smallest operating unit for on-demand scheduling and state caching. This avoids lengthy desktop loading processes for users, significantly shortening interaction response time to within the threshold allowed by driving safety, thus improving driving safety. At the same time, by intelligently preloading high-frequency applications based on historical usage data and caching their unique process IDs, it prioritizes reusing existing instances to directly pull application-level video streams when users call them, achieving second-level recovery for hot starts, significantly reducing response latency compared to traditional cold start solutions. In addition, by unifying the display of cloud and local applications on the vehicle's infotainment interface and adapting to the vehicle's UI layout and cockpit hardware linkage logic, users do not need to perceive the differences between cloud and local applications. Voice commands can directly reach the target application, eliminating the disconnect between cloud and local application experiences. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating an embodiment of the cloud-local application seamless switching method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the cloud-local application seamless switching method provided in this application; Figure 3 This is a flowchart illustrating Embodiment 3 of the cloud-local application seamless switching method provided in this application; Figure 4 This is a flowchart illustrating Embodiment 4 of the cloud-local application seamless switching method provided in this application; Figure 5 This is a flowchart illustrating Embodiment 5 of the cloud-local application seamless switching method of this application; Figure 6 This is a flowchart illustrating Embodiment Six of the cloud-local application seamless switching method provided in this application; Figure 7 A simplified flowchart illustrating the cloud-local application seamless switching method provided in Embodiments 1 and 4 of this application; Figure 8 A schematic diagram of the vehicle-mounted scheduling app startup process provided for the seamless switching method of cloud-local applications in this application; Figure 9 A schematic diagram of the vehicle-mounted scheduling app operation process provided for the seamless switching method of cloud-local applications in this application; Figure 10 A schematic diagram of the cloud-based scheduling app operation process provided for the cloud-local application seamless switching method of this application; Figure 11 This is a schematic diagram of the module structure of the cloud-local application seamless switching system according to an embodiment of this application; Figure 12 This is a schematic diagram of the device structure of the hardware operating environment involved in the cloud-local application seamless switching method in the embodiments of this application.

[0025] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0026] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0027] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0028] The main solution of this application embodiment is as follows: When the vehicle system receives a start command, it loads the locally stored list of cloud applications and displays the cloud applications and local applications on the vehicle system's interactive interface; when the current network is available, based on the historical usage data of each cloud application in the cloud application list, it determines at least one preloaded cloud application; it sends a preload request to the cloud to trigger the cloud to start the preloaded cloud application, and receives the unique process number corresponding to each preloaded cloud application returned by the cloud; when the vehicle system responds to the user's call operation command for any target cloud application, it initiates a data retrieval request to the cloud according to the unique process number corresponding to the target cloud application, and receives the response data returned by the cloud.

[0029] In this embodiment, for ease of description, the following description will focus on the cloud-local application seamless switching system.

[0030] The existing solution, which directly ports the mobile client's "launch full cloud image → enter desktop → open APP" calling pattern, is severely unsuitable for in-vehicle infotainment systems. On the one hand, the image loading takes 8-12 seconds, far exceeding the safety requirement of ≤2 seconds for a single operation while driving, which can easily cause distraction; on the other hand, the complete image has high resource consumption, which exacerbates the vehicle's system lag and cannot be cached, resulting in large delays when called repeatedly.

[0031] Meanwhile, the interaction is severely fragmented: voice commands require waking up the mirror first, resulting in several seconds of no response; the interface is designed for mobile phone landscape mode, which causes misalignment and obstruction when projected onto the car's screen; the cloud APP runs in an isolated environment and cannot be linked to cockpit hardware such as the dashboard and HUD, forcing users to frequently turn their heads, increasing the risk.

[0032] In addition, the vehicle network environment is highly variable (such as tunnels and high-speed switching). Traditional solutions rely on continuously pushing a complete image, which is prone to repeated failures under weak network conditions, resulting in a very poor user experience.

[0033] Existing technologies may rely on touch icons, which violates the limited logic of in-vehicle voice control, or fail to resolve the fundamental conflict between "mirror-mounted front start" and driving safety.

[0034] This application provides a solution that pre-deploys a custom Android-based ROM (Read-Only Memory) as a server in the cloud. The server has a built-in dedicated scheduling mechanism for starting, managing, and recycling cloud application processes on demand, and assigning a unique process identifier to each running cloud app. The vehicle's infotainment system is equipped with a dedicated scheduling application that loads a pre-installed list of cloud applications and seamlessly integrates these cloud applications into the vehicle's desktop with icons that are identical to those of local applications. This allows users to operate the system without needing to distinguish the source of the applications, enabling seamless access and switching between cloud and local applications. When a user triggers any cloud application, the vehicle-mounted scheduling application determines whether to initiate a data retrieval request or an application startup request to the cloud based on whether the corresponding process identifier has been cached; after the cloud server responds, it encodes the application interface output as a video stream and returns it. In addition, in weak network environments, the vehicle-mounted dispatch application can dynamically adjust the resolution of the requested video stream based on the current network signal strength to ensure smooth video playback and interactive usability.

[0035] It should be noted that the executing entity in this embodiment can be a computing terminal (such as a personal computer, tablet computer, or smartphone), or a vehicle-specific electronic device (such as a vehicle infotainment system, smart cockpit controller), vehicle information preview system, etc. The following description uses a vehicle infotainment system as an example to illustrate this embodiment and the subsequent embodiments.

[0036] Based on this, the embodiments of this application provide a method for seamless switching of cloud-local applications, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the cloud-local application seamless switching method of this application.

[0037] In this embodiment, the cloud-local application seamless switching method is applied to the vehicle system, and the method includes steps S10~S40: Step S10: When a start command is received, load the list of cloud applications stored locally and display the cloud applications and local applications on the vehicle infotainment interface. In this embodiment, when a user installs an application through the software center, they can choose to enable its cloud version. If enabled, the cloud application is added to the locally saved list of cloud applications, and its corresponding icon and other interface display resources are cached synchronously. Subsequently, when the user invokes the application, the system will launch and run the application in a cloud-based manner.

[0038] Furthermore, when a user starts the vehicle's infotainment system, the system loads a list of locally saved cloud applications and displays these cloud applications on the vehicle's desktop in the same way as the local applications, so that users do not need to distinguish the source of the applications and can achieve a unified and seamless operating experience.

[0039] Through the above steps, cloud applications are deeply integrated into the vehicle's native interactive interface. Users can directly click or use voice to activate cloud applications just like using local applications, avoiding the multi-level operation process of entering the cloud desktop and then searching for the target application in the traditional solution, which significantly reduces the complexity of interaction and the risk of driver distraction.

[0040] Step S20: If the current network is available, determine at least one preloaded cloud application based on the historical usage data of each cloud application in the cloud application list; It should be noted that the unique process ID is an identifier (such as a process ID or session token) generated by the cloud server after the cloud app program is successfully launched, used to uniquely identify the running instance.

[0041] Understandably, in-vehicle infotainment systems have extremely high requirements for response time in driving scenarios (interactions typically need to be completed within 2 seconds), while the average time to fully launch a cloud application is 8-12 seconds. If a cold start is performed for each call, it will not only cause significant delays but also force users to stare at the screen for a long time, increasing the risk of distraction while driving. Therefore, step S30 is executed to pre-launch frequently used cloud app programs and cache their unique process IDs when the network is available. This avoids lengthy waiting times and repeated initialization overhead when users call the application, thereby achieving "click and play" and seamless switching of cloud applications, significantly improving interaction efficiency and driving safety.

[0042] In addition, when the network is unavailable, the preloading operation is paused, and all cloud application icons are displayed as unavailable in the vehicle's infotainment interface (e.g., grayed out, marked with "No Network" or disabled for click response) to clearly inform the user that cloud services are currently unavailable, thus avoiding unnecessary operations and user experience confusion.

[0043] In one feasible embodiment, step S20 may include steps S21 to S23: Step S21: Determine the usage frequency of each cloud application based on the historical usage data of each cloud application in the cloud application list. In this embodiment, when network availability is available, the vehicle-mounted system calculates the usage frequency of each cloud application in the cloud application list based on the user's historical usage data. This historical usage data includes, but is not limited to, the number of times the application was launched, the cumulative usage time, and the most recent usage time. The usage frequency can be quantified using methods such as the number of calls per unit time or a weighted activity score. This usage frequency will serve as an important basis for subsequently selecting candidate pre-loaded applications.

[0044] Step S22: Select cloud applications whose usage frequency is higher than a preset frequency threshold as candidate cloud applications, and sort them according to the most recent usage time of each candidate cloud application. In this embodiment, recently active applications are given priority as candidate cloud applications. For example, if a cloud application is used frequently but has not been used for more than 7 days, it will be ranked lower. Applications that are used less frequently but were used during the last boot will be given higher priority to improve the relevance and hit rate of preloading.

[0045] Step S23: Select preloaded cloud applications from the sorted candidate cloud applications, with a number not exceeding a preset threshold.

[0046] In this embodiment, the preset quantity threshold is 2, that is, a maximum of 2 preloaded cloud applications are preloaded to balance server resource consumption and user experience; the preload request also carries a unique user identifier, which is used by the cloud scheduling module to identify the user context and start the corresponding preloaded cloud application.

[0047] Through the above steps, the in-vehicle infotainment system can intelligently select and preload cloud applications most likely to be recently accessed by the user, provided the network is available. This avoids wasting server resources or causing local cache redundancy by blindly launching a large number of applications. This strategy balances usage frequency and time freshness, significantly improving the preload hit rate. At the same time, by limiting the number of preloaded applications (e.g., no more than two), it effectively controls cloud resource consumption and in-vehicle management complexity while ensuring a fast response experience, laying the foundation for seamless "click-and-play" switching in the future.

[0048] Step S30: Send a preloading request to the cloud to trigger the cloud to start the preloaded cloud application, and receive the unique process number corresponding to each preloaded cloud application returned by the cloud. In this embodiment, the preloading request carries a user identifier and a list of cloud applications to be preloaded. After receiving the request, the cloud server creates an independent running instance for each preloaded cloud application and generates a globally unique process ID to identify the lifecycle and status of the instance. The vehicle system associates the received process ID with the corresponding cloud application and caches it in the local storage module, serving as the basis for determining whether a warm start is possible during subsequent calls. This process ID remains valid within the validity period of the cloud instance. If the instance is destroyed due to timeout or resource reclamation, the process ID becomes invalid, and the vehicle system will trigger a cold start process when calling it again.

[0049] Step S40: In response to the user's call operation command for any target cloud application, initiate a data retrieval request to the cloud based on the unique process ID corresponding to the target cloud application, and receive the response data returned by the cloud.

[0050] It should be noted that the data retrieval request includes at least: User ID: Used to identify user context in the cloud and ensure that data corresponding to the user session is returned; Unique identifier for cloud applications: indicates the type of application to be invoked (such as navigation, music, etc.); Unique process ID: Used to accurately locate the corresponding application instance that is already running in the cloud; Vehicle infotainment system information: including operating system version, screen resolution and input device type, for cloud-based interface adaptation and interaction mapping; Strong current network signal: used to dynamically adjust video encoding parameters (such as resolution and bitrate) in the cloud to ensure smoothness in weak network environments; Call operation instructions: The specific operation triggered by the user (such as "open", "play", etc.).

[0051] The application launch request includes the user identifier, the unique identifier of the cloud application, the vehicle system information and operation instructions, but does not include a valid process unique number.

[0052] It should also be noted that the response data includes: Status codes: used to indicate the result of request processing (such as success, instance not found, permission denied, etc.); The unique process ID of the cloud-based app is used to verify session consistency. Application video stream: A real-time encoded stream output from the cloud-based app interface.

[0053] Understandably, since the unique process ID of the target cloud application has been cached during the preloading phase, and the cloud application instance identified by this ID is still running, there is no need to restart the application when the user triggers the call operation. Therefore, step S40 is executed to directly pull the corresponding response data (such as the application video stream) from the cloud through the unique process ID, thereby skipping the application cold start and initialization process, significantly reducing response latency, and achieving a seamless switching experience of "click and use".

[0054] Specifically, the unique process ID is generated by the cloud during the pre-loading phase and returned to the vehicle's infotainment system. It is then cached locally by the system and bound to the corresponding cloud application's identifier (such as the application ID) and the user session. When the user clicks the cloud application icon on the vehicle's interface, the system immediately queries its local cache. If a valid ID is found, it is embedded in the data retrieval request and sent to the cloud server. The server locates the running application process based on this ID, directly captures its current frame, encodes it into a video stream, and pushes it back to the vehicle's infotainment system for rendering and display in real time. The entire process does not require reloading application logic, initializing the UI, or rebuilding the user context. The response time can be controlled within hundreds of milliseconds, far superior to the traditional "start-load-render" cold start path (which typically takes several seconds). This ensures functional integrity while achieving an instant response experience consistent with local apps.

[0055] Using the methods described above, the vehicle infotainment system loads and displays both cloud and local applications upon startup. When the network is available, frequently used cloud applications are preloaded based on historical usage data, and their unique process IDs are obtained. When a user calls any cloud application, the system directly retrieves the response data (such as application video streams) from the cloud, depending on whether the ID is cached. This solution eliminates the need for preloading of complete cloud images, using a single application as the smallest operating unit, reducing response time to within driving safety thresholds and improving safety. Intelligent preloading and instance reuse significantly reduce latency. A unified entry point, adaptation to the vehicle infotainment UI, and linkage with cockpit hardware achieve seamless integration of cloud and local experiences, eliminating interaction fragmentation.

[0056] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Before step S40, the cloud-local application seamless switching method further includes steps S401 to S403: Step S401: Determine whether the vehicle system has cached the unique process ID corresponding to the target cloud application; In actual operation, some users may be using a cloud application for the first time, or the preloading may not be triggered, or the cache may have expired, resulting in the absence of a valid process unique ID locally. If a data retrieval request is still forcibly initiated at this time, an error will be returned because the cloud cannot locate the corresponding application instance, causing the interface to freeze or the interaction to fail. Therefore, this embodiment also proposes a seamless switching mechanism based on the cache state to adaptively switch the call path. It can intelligently select the "hot pull" or "cold start" strategy according to the local cache situation to ensure the reliability and smoothness of the operation response.

[0057] Step S402: If yes, then execute the step of initiating a data retrieval request to the cloud based on the unique process ID corresponding to the target cloud application, and receiving the response data returned by the cloud. The data retrieval request includes the process's unique ID, user identifier, vehicle system information, and current network status.

[0058] Specifically, when the vehicle's local cache detects that it has the unique process ID of the target cloud application that the user requested to call, it directly sends a data retrieval request containing the unique process ID of the target cloud application to the cloud.

[0059] When the cloud server receives the request, it directly associates the running application instance with the unique process ID in the request, captures its graphic output in real time and encodes it into a video stream, and returns it along with the status code and session verification information; after the vehicle system receives the response, it immediately decodes and renders the video stream, achieving a millisecond-level opening experience, skipping the cold start process such as application initialization, resource loading and login.

[0060] Step S403: If not, then initiate an application launch request to the cloud so that the cloud can launch the target cloud application based on the application launch request, and after generating a unique process number corresponding to the target cloud application, return the corresponding response data to the vehicle system.

[0061] Specifically, after determining that the vehicle's infotainment system does not have the unique process ID of the target cloud application invoked by the user cached locally, it generates an application launch request and sends it to the cloud. When the cloud server receives this request, it launches the corresponding target cloud application for the user in a customized Android ROM environment. After initialization, it captures the first frame of the interface and encodes it as a video stream, returning it to the vehicle's infotainment system along with the newly assigned unique process ID. The vehicle's infotainment system immediately renders the video upon receiving it, achieving a fast response in cold start scenarios.

[0062] Through the methods described above, the vehicle-mounted system can automatically trigger a complete cold start process for cloud applications when the target cloud application has not been pre-loaded or its running instance has expired, ensuring that user calls to any cloud application can receive an effective response. This mechanism, as a necessary supplement to the pre-loading path, avoids functional unavailability or interaction interruption due to missing instances, ensuring the system's availability and robustness across all scenarios. Simultaneously, it maintains consistent operation entry points and interaction logic with pre-loaded applications, further enhancing the seamless experience of integrating cloud and local applications.

[0063] Based on the first embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 After step S40, the cloud-local application seamless switching method further includes step S400: Step S400: In response to the user's exit command for the currently running cloud application via touch or voice, an exit application request is sent to the cloud so that the cloud can suspend the execution of the currently running cloud application and retain the current running state of the currently running cloud application so that it can be quickly resumed when called again within a preset time period.

[0064] Compared to the first embodiment, this embodiment also provides a cloud application state maintenance and rapid recovery mechanism, which can maintain the application in a "hot state" after the user temporarily exits, avoiding repeated initialization.

[0065] Specifically, when the vehicle's infotainment system receives a user-triggered action to exit the currently running cloud application (such as clicking the back button or using the voice prompt "Exit navigation"), it does not directly destroy the session. Instead, it sends an application exit request carrying a unique process ID to the cloud. Upon receiving this request, the cloud server suspends the corresponding currently running cloud application, freezing its CPU computing and rendering threads, but retains the running context in memory (including the interface state, playback progress, login session, etc.).

[0066] Based on actual resource usage and user behavior statistics, the cloud server retains this suspended state for a maximum of 20 minutes by default. During this period, if the user calls the same cloud application again, the vehicle's infotainment system initiates a recovery request based on the cached process's unique ID. The cloud then wakes up the instance and continues outputting the application's video stream, achieving a seamless interactive experience with "instant exit and instant re-entry."

[0067] Through the methods described above, while ensuring the continuity of user experience, on-demand retention and intelligent release of cloud resources are achieved. On the one hand, when a user re-invokes a cloud application that has been exited within 20 minutes, there is no need to go through a cold start process; the application can be directly restored to its state before exiting, significantly shortening response time and maintaining the operational context. On the other hand, resources are automatically reclaimed after the retention period expires, avoiding server-side memory leaks or resource waste caused by prolonged suspension, effectively improving the stability and resource utilization efficiency of the system in high-concurrency scenarios. This mechanism further improves the closed-loop experience of "seamless switching" between cloud and local applications, enabling cloud applications in in-vehicle scenarios to truly possess the ability to be "available when needed, economical when not in use, and as good as new when returned."

[0068] Based on this, the embodiments of this application provide a method for seamless switching of cloud-local applications, referring to... Figure 4 , Figure 4 This is a flowchart illustrating the fourth embodiment of the cloud-local application seamless switching method of this application.

[0069] In this embodiment, the cloud-local application seamless switching method is applied to the cloud, and the method includes steps S50~S90: Step S50: Receive a preload request sent by the vehicle's infotainment system; It should be noted that a custom Android-based ROM (Read-Only Memory) is pre-deployed in the cloud as the server-side runtime environment. This server has a built-in dedicated scheduling mechanism for creating, managing, and recycling cloud application processes on demand, and supports multi-user isolation and dynamic resource allocation.

[0070] In this embodiment, when the vehicle system determines the target cloud application that needs to be preloaded based on the user's historical usage data while the network is available, it will send a preload request to the cloud carrying the user identifier and the application identifier. After receiving the request, the cloud scheduling module will verify the user's permissions and prepare to start the corresponding application instance.

[0071] Step S60: According to the preloading request, start the preloading cloud application through the server and generate a unique process number to identify the preloading cloud application. The preloading cloud application is determined by the vehicle system based on the historical usage data of each cloud application in the cloud application list stored locally. In this embodiment, the cloud preloads a sandbox instance of a cloud application in a customized ROM environment to ensure isolation from other users or applications. After the preloaded cloud application starts successfully, the cloud assigns a unique process ID to it through the scheduling module. This ID is bound to the user identifier and the application identifier and is used for subsequent video streaming. It also enables precise addressing for pulling, state maintenance, and resource reclamation.

[0072] Step S70: Return the unique process number to the vehicle system so that the vehicle system can initiate a data stream retrieval request to the cloud based on the unique process number; In this embodiment, after successfully launching the preloaded cloud application, the cloud server assigns it a globally unique process ID and binds this process ID with the user identifier and the cloud application's unique identifier, returning it to the vehicle's infotainment system via a secure channel. Upon receiving this, the vehicle's infotainment system caches the process ID in its local storage module. Simultaneously, in response to a user's command to invoke any target cloud application, it sends a data stream retrieval request to the cloud, based on the process ID corresponding to that target cloud application, to retrieve the response data for that application.

[0073] Step S80: Receive the data stream retrieval request sent by the vehicle system; In this embodiment, the data retrieval request includes a user identifier, a unique identifier for the cloud application, a unique process number, a command to invoke the cloud application, vehicle system information, and the current network signal strength.

[0074] Step S90: Based on the data retrieval request, obtain the corresponding response data through the server and transmit the response data to the vehicle system.

[0075] It should be noted that the response data includes at least the application video stream, status code, and process unique ID.

[0076] It is understandable that since the data retrieval request already carries a valid unique process ID, indicating that the corresponding target cloud application instance is already running on the server and is in an interactive state, when executing step S90, the server does not need to restart the application or initialize the session. Instead, it can directly locate the existing process based on the ID, quickly extract its current interface output and encapsulate it into response data, thereby avoiding the delay and resource overhead caused by cold start and ensuring a smooth "click and use" experience for users.

[0077] In one feasible embodiment, step S90 may include steps S91 to S93: Step S901: Based on the unique process ID carried in the data retrieval request, the real-time interface output of the target cloud application is used as an application video stream. Specifically, the server queries whether the ID is valid and has not been recycled; if valid, the image capture interface is called to obtain the latest frame as the video stream source; if invalid, the status code "404 Instance does not exist" is returned, and the cold start process is triggered.

[0078] Step S902: Based on the current network signal strength contained in the data retrieval request, adjust the encoding parameters of the application video stream to obtain the adjusted application video stream; Specifically, if the current network signal strength is high (e.g., RSRP > -90 dBm), high resolution (e.g., 1280×720), high frame rate (30 fps), and relatively high bit rate (2–4 Mbps) encoding will be used; if the signal is weak (e.g., RSRP < -110 dBm), it will automatically be reduced to low resolution (e.g., 640×360), 15 fps, and low bit rate (800 kbps–1.5 Mbps) to prioritize the continuity of the video stream and its anti-stuttering capability.

[0079] Step S903: The response data, including the adjusted application video stream, the process unique number, and the status code, is transmitted to the vehicle's infotainment system.

[0080] Specifically, the response data is encapsulated using a low-latency transmission protocol (such as WebRTC or a custom UDP stream protocol) and pushed to the vehicle's infotainment system. The unique process ID is used by the vehicle's infotainment system to verify session consistency, the status code is used for exception handling (such as retry or prompt), and the video stream is rendered to the interactive interface in real time by the vehicle's decoding module.

[0081] Through the above steps, this embodiment achieves hot-pull based on cache number, network-adaptive video encoding, and efficient backhaul. While ensuring consistent user experience, it significantly optimizes system resource utilization and availability in weak network environments, truly achieving the technical effect of "seamless switching" of cloud-local applications.

[0082] The method described above involves receiving a preloading request from the vehicle's infotainment system; based on the preloading request, starting a preloaded cloud application via the server and generating a unique process ID to identify the preloaded cloud application, wherein the preloaded cloud application is determined by the vehicle's infotainment system based on historical usage data of each cloud application in a locally stored cloud application list; returning the unique process ID to the vehicle's infotainment system so that it can initiate a data retrieval request from the cloud based on the unique process ID; receiving the data retrieval request from the vehicle's infotainment system; obtaining the corresponding response data via the server based on the data retrieval request, and transmitting the response data to the vehicle's infotainment system. This solution effectively solves the technical problems of high startup latency, sluggish interaction, and fragmented user experience of traditional cloud applications in in-vehicle scenarios through a preloading and hot-pull mechanism that coordinates vehicle and cloud systems.

[0083] Based on the fourth embodiment of this application, in the fifth embodiment of this application, the content that is the same as or similar to that in the fourth embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 5 Before step S80, the cloud-local application seamless switching method further includes steps S800~S802: Step S800: When an application launch request is received from the vehicle system, the target cloud application indicated by the application launch request is launched based on the current resource status of the server. Step S801: After the target cloud application completes initialization, its interface output is obtained as the application video stream, and a corresponding unique process number is generated. Step S802: Return the process unique number and the application video stream to the vehicle system.

[0084] Compared to the fourth embodiment (which focuses on the "hot pull" path in the preloading scenario), this embodiment is aimed at the "cold start" scenario where a user calls a cloud application for the first time or the local process ID is not cached. In this case, the existing instance cannot be directly reused. Therefore, this embodiment further proposes a resource-aware cloud application on-demand startup and context initialization mechanism, which can efficiently create new application instances and establish reusable session identifiers while ensuring system stability, laying the foundation for possible rapid switching in the future.

[0085] In this embodiment, when the cloud server receives an application launch request from the vehicle's infotainment system, it first assesses the current system resource status, including CPU utilization, available memory, GPU load, and the number of concurrent running instances. If the resources meet the preset launch threshold, a new running instance of the target cloud application is created for the user in an isolated container or a customized Android ROM environment, and its context (such as user account and preference settings) is loaded. After the application completes its initial rendering and enters an interactive state, its interface output frames are captured and encoded to generate an application video stream. Simultaneously, the server assigns a globally unique process ID to the instance. This process ID is bound to the user identifier, application type, and instance lifecycle, and is returned to the vehicle's infotainment system along with the response data for subsequent hot-start reuse. If resources are insufficient, the status code "Resources Busy" is returned, and queuing or degradation strategies may be triggered.

[0086] Furthermore, during the generation of the application video stream, the server synchronously parses the current network signal strength carried in the application startup request and dynamically adjusts the video encoding parameters accordingly. For example, when the network signal strength is lower than a preset threshold, the resolution is reduced from 1080p to 480p, and the bitrate is reduced from 4 Mbps to 1.5 Mbps to reduce bandwidth usage and avoid playback stuttering; when the signal is good, high-quality output is maintained to improve the user experience.

[0087] The methods described above not only achieve reliable application delivery in cold start scenarios, but also take into account system resource scheduling efficiency and user experience in weak network environments. Together with the third embodiment, they constitute a complete seamless switching technology system covering "preloaded warm start" and "on-demand cold start".

[0088] Based on the third embodiment of this application, in the sixth embodiment of this application, the content that is the same as or similar to that in the third embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 6 After step S93, the cloud-local application seamless switching method further includes steps S100~S101: Step S100: When a request to exit the application is received from the vehicle system, the execution of the currently running cloud application is paused on the server side, and the current running state of the currently running cloud application is retained. Compared to the third embodiment, this embodiment also proposes a cloud application state maintenance and rapid recovery mechanism, which can maintain the application in a "hot state" after the user temporarily exits, avoid repeated initialization, thereby significantly shortening the response time when called again and improving the multi-task switching experience.

[0089] Specifically, when the cloud receives an application exit command carrying the user identifier, application identifier, and process unique number, it does not immediately destroy the currently running cloud application. Instead, it places it in a suspend state: freezing CPU computing and rendering threads, stopping video stream output, but preserving the complete running context in memory. This state is maintained for a default preset duration (e.g., 20 minutes), during which core resources are not released to support rapid wake-up.

[0090] Step S101: If a data retrieval request for the same user and corresponding to the same cloud application is received within a preset time period, the execution of the currently running cloud application is resumed, and the application video stream is transmitted to the vehicle.

[0091] Specifically, when the cloud receives a data retrieval request containing the same unique process ID from the vehicle's infotainment system within the retention window, it first verifies the user identity and instance validity carried in the request, then immediately wakes up the suspended cloud application, resumes its rendering thread, and encodes the current interface as a video stream and pushes it to the vehicle's infotainment system in real time.

[0092] The above-described embodiments enable this application to achieve a continuous interactive experience of "instant exit and instant return" without reloading the application or rebuilding the session, effectively reducing user waiting time and server cold start overhead.

[0093] For example, to help understand the implementation process of the cloud-local application seamless switching method obtained by combining Embodiment 1 and Embodiment 4 above, please refer to... Figure 7 , Figure 7 A simplified flowchart illustrating a method for seamless switching of cloud-local applications is provided, specifically: This embodiment includes three main modules: the vehicle-mounted scheduling app module, which loads the user's list of pre-installed cloud apps, processes user requests, interacts with the cloud scheduling app, and retrieves video streams from the cloud server; the cloud scheduling app module, which communicates with the vehicle-mounted scheduling app module and schedules server-side resources; and the server-side module, a customized Android ROM deployed in the cloud, which actually executes the cloud apps.

[0094] like Figure 8 As shown, Figure 8 This is a schematic diagram illustrating the startup process of the vehicle-mounted dispatch app. Specifically, after the vehicle-mounted system starts up, the vehicle-mounted dispatch app is loaded and run. This app first reads the user's cloud-based app list stored locally and then displays all cloud applications as local applications on the vehicle-mounted interface, ensuring a consistent user operation path and improving ease of use.

[0095] Then, the current network status is checked: if there is no network signal, all cloud app icons are displayed as unavailable to avoid invalid operations; if there is a network signal, the user's historical usage data for each cloud app (such as number of launches, cumulative duration, recent usage time, etc.) is further read, the priority of each application is calculated based on the usage frequency, and a preloading request is sent to the cloud scheduling module to trigger the cloud to launch the corresponding cloud app program for high-frequency applications and return the unique process number.

[0096] like Figure 9 As shown, Figure 9 This is a schematic diagram of the operation process of the vehicle-mounted dispatch app. Specifically, when a user invokes an application via touch or voice, the system first determines whether the application is a local application: if so, it directly invokes the local program; if not, it is identified as a cloud application and enters the remote interaction process. At this time, the vehicle-mounted dispatch app encapsulates parameters such as user ID, operation command, unique cloud app ID, unique process number (if it exists), vehicle system information, and current network signal strength into a data retrieval request and sends it to the cloud.

[0097] like Figure 10 As shown, Figure 10 This is a schematic diagram of the cloud-based dispatch app's operation process. Specifically, after receiving a data retrieval request from the vehicle-mounted app dispatch module, the cloud-based dispatch app module determines whether the target cloud app program is already running. If it is running, it directly reads its interface output and encodes it as a video stream for return. If it is not running, it starts a new instance based on server resource availability, performs cross-platform adaptation processing for user operations, and dynamically adjusts the video stream resolution based on network signal strength to optimize transmission efficiency. The video stream is continuously pushed to the vehicle's infotainment system, enabling real-time interaction.

[0098] When a user exits the cloud app, the vehicle's infotainment system sends an exit command, and the cloud suspends the app and retains its running state for up to 20 minutes. During this period, if the same app is called again, it can be resumed directly, achieving "instant exit and instant return". After the timeout, resources are automatically released to avoid long-term occupation.

[0099] Through the methods described in the above embodiments, this application achieves seamless integration of client applications and local applications in terms of interface display, operation entry and interaction logic. Combined with preloading, state maintenance and intelligent bitrate adjustment mechanisms, it significantly improves response speed, user experience consistency and system resource utilization while ensuring driving safety, and truly realizes a seamless switching experience of "cloud as local".

[0100] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the cloud-local application seamless switching method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0101] This application also provides a cloud-local application seamless switching system; please refer to [link / reference]. Figure 11 The cloud-local application seamless switching system includes: Including in-vehicle systems and cloud computing; The vehicle infotainment system includes: The application loading module 10 is used to load the list of cloud applications stored locally when a start command is received, and to display the cloud applications and local applications on the vehicle infotainment interface. The preloading module 20 is used to determine at least one preloaded cloud application based on the historical usage data of each cloud application in the cloud application list, provided that the current network is available. The request sending model 30 is used to send a preloading request to the cloud to trigger the cloud to start the preloaded cloud application, and to receive the unique process number corresponding to each preloaded cloud application returned by the cloud. The application scheduling and processing module 40 is used to respond to the user's call operation command for any target cloud application, initiate a data retrieval request to the cloud according to the unique process number corresponding to the target cloud application, and receive the response data returned by the cloud. The cloud includes: The receiving module 50 is used to receive the preload request sent by the vehicle's infotainment system; The number generation module 60 is used to start the preloaded cloud application through the server according to the preload request, and generate a unique process number to identify the preloaded cloud application, wherein the preloaded cloud application is determined by the vehicle system based on the historical usage data of each cloud application in the cloud application list stored locally. The number sending module 70 is used to return the unique process number to the vehicle system, so that the vehicle system can initiate a data retrieval request to the cloud based on the unique process number; The receiving module 50 is also used to receive a data retrieval request sent by the vehicle-mounted system; The response return module 80 is used to obtain the corresponding response data through the server according to the data retrieval request, and transmit the response data to the vehicle system.

[0102] The cloud-local application seamless switching system provided in this application, employing the cloud-local application seamless switching method in the above embodiments, can solve the technical problems of high vehicle-to-everything (V2X) driving safety risks, large response delays, and fragmented interactive experiences caused by existing technologies. Compared with the prior art, the beneficial effects of the cloud-local application seamless switching system provided in this application are the same as those of the cloud-local application seamless switching method provided in the above embodiments, and other technical features of the cloud-local application seamless switching system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0103] This application provides a cloud-local application seamless switching device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the cloud-local application seamless switching method in the first embodiment described above.

[0104] The following is for reference. Figure 12 This document illustrates a structural schematic diagram of a cloud-local application seamless switching device suitable for implementing embodiments of this application. The cloud-local application seamless switching device in this application embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 12 The cloud-local application seamless switching device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0105] like Figure 12As shown, the cloud-local application seamless switching device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the cloud-local application seamless switching device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the cloud-local application seamless switching device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a cloud-local application seamless switching device with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0106] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0107] The cloud-local application seamless switching device provided in this application, employing the cloud-local application seamless switching method in the above embodiments, can solve the technical problems of high vehicle-to-everything (V2X) driving safety risks, large response delays, and fragmented interactive experiences caused by existing technologies. Compared with the prior art, the beneficial effects of the cloud-local application seamless switching device provided in this application are the same as those of the cloud-local application seamless switching method provided in the above embodiments, and other technical features of this cloud-local application seamless switching device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0108] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0109] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions 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. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0110] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the cloud-local application seamless switching method in the above embodiments.

[0111] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0112] The aforementioned computer-readable storage medium may be included in the cloud-local application seamless switching device; or it may exist independently and not be assembled into the cloud-local application seamless switching device.

[0113] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the cloud-local application seamless switching device, the cloud-local application seamless switching device performs the following actions: When the vehicle-mounted system receives a startup command, it loads a list of cloud applications stored locally and displays the cloud applications and local applications on the vehicle-mounted system's interactive interface; when the current network is available, based on the historical usage data of each cloud application in the cloud application list, it determines at least one pre-loaded cloud application; it sends a pre-load request to the cloud to trigger the cloud to start the pre-loaded cloud application and receives the unique process IDs corresponding to each pre-loaded cloud application returned by the cloud; when the vehicle-mounted system responds to a user's command to call any target cloud application, it initiates a corresponding data retrieval request to the cloud based on the unique process ID corresponding to the target cloud application and receives the response data returned by the cloud.

[0114] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0115] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0116] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0117] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described seamless switching method for cloud-local applications. This addresses the technical problems of high vehicle-to-everything (V2X) driving safety risks, large response delays, and fragmented interactive experiences caused by existing technologies. Compared to existing technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the seamless switching method for cloud-local applications provided in the above embodiments, and will not be elaborated upon here.

[0118] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the cloud-local application seamless switching method described above.

[0119] The computer program product provided in this application can solve the technical problems of high vehicle-machine driving safety risks, large response delays, and fragmented interactive experiences caused by existing technologies. Compared with existing technologies, the beneficial effects of the computer program product provided in this application are the same as those of the cloud-local application seamless switching method provided in the above embodiments, and will not be repeated here.

[0120] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for seamless switching of cloud-local applications, characterized in that, The cloud-local application seamless switching method is applied to the vehicle system, and the method includes: When a start command is received, the list of cloud applications stored locally is loaded, and the cloud applications and local applications are displayed on the vehicle's infotainment interface. Given the current network availability, at least one preloaded cloud application is determined based on the historical usage data of each cloud application in the cloud application list. Send a preload request to the cloud to trigger the cloud to start the preloaded cloud application, and receive the unique process number corresponding to each preloaded cloud application returned by the cloud; In response to a user's command to invoke any target cloud application, a data retrieval request is initiated from the cloud based on the unique process ID corresponding to the target cloud application, and the response data returned by the cloud is received.

2. The cloud-local application seamless switching method as described in claim 1, characterized in that, The step of determining at least one preloaded cloud application based on the historical usage data of each cloud application in the cloud application list includes: The usage frequency of each cloud application is determined based on the historical usage data of each cloud application in the cloud application list. Cloud applications whose usage frequency is higher than a preset frequency threshold are selected as candidate cloud applications, and sorted according to the most recent usage time of each candidate cloud application. Select preloaded cloud applications from the sorted candidate cloud applications, with a number not exceeding a preset threshold.

3. The cloud-local application seamless switching method as described in claim 1, characterized in that, Before the step of initiating a data retrieval request to the cloud based on the unique process ID corresponding to the target cloud application, the method further includes: Determine whether the vehicle system has cached the unique process ID corresponding to the target cloud application; If so, the execution steps involve initiating a data retrieval request to the cloud based on the unique process ID corresponding to the target cloud application, and receiving the response data returned by the cloud. If not, an application launch request is sent to the cloud so that the cloud can launch the target cloud application based on the application launch request, and after generating a unique process number corresponding to the target cloud application, the corresponding response data is returned to the vehicle system.

4. The cloud-local application seamless switching method as described in claim 3, characterized in that, The data retrieval request includes at least one of the following: user identifier, unique identifier of cloud application, unique process number, call operation instruction for cloud application, vehicle system information, and current network signal strength. The response data includes at least one of the following: a status code, a unique process ID, and an application video stream.

5. The cloud-local application seamless switching method as described in claim 1, characterized in that, After the step of receiving the response data returned from the cloud, the method further includes: In response to a user's exit command for a currently running cloud application via touch or voice, an exit request is sent to the cloud so that the cloud can pause the execution of the currently running cloud application and retain its current running state so that it can be quickly resumed when called again within a preset time.

6. A method for seamless switching of cloud-local applications, characterized in that, The cloud-local application seamless switching method is applied to the cloud, where a server is deployed. The method includes: Receive the preload request sent by the vehicle's infotainment system; According to the preloading request, the preloading cloud application is started through the server and a unique process number is generated to identify the preloading cloud application. The preloading cloud application is determined by the vehicle system based on the historical usage data of each cloud application in the locally stored cloud application list. The unique process ID is returned to the vehicle's infotainment system so that the system can initiate a data retrieval request from the cloud based on the unique process ID. Receive the data retrieval request sent by the vehicle's infotainment system; Based on the data retrieval request, the corresponding response data is obtained through the server and transmitted to the vehicle system.

7. The cloud-local application seamless switching method as described in claim 6, characterized in that, The response data includes at least the application video stream, status code, and process unique ID; The step of obtaining the corresponding response data from the server according to the data retrieval request and transmitting the response data to the vehicle system includes: Based on the unique process ID carried in the data retrieval request, the real-time interface output of the target cloud application is used as an application video stream. Based on the current network signal strength contained in the data retrieval request, the encoding parameters of the application video stream are adjusted to obtain the adjusted application video stream; The response data, including the adjusted application video stream, the process's unique ID, and the status code, will be transmitted to the vehicle's infotainment system.

8. The cloud-local application seamless switching method as described in claim 6, characterized in that, Before the step of receiving the data retrieval request sent by the vehicle system, the method further includes: When an application launch request is received from the vehicle's infotainment system, the target cloud application indicated by the application launch request is launched based on the current resource status of the server. After the target cloud application completes initialization, its interface output is obtained as the application video stream, and a corresponding unique process ID is generated. The process's unique ID and the application video stream are returned to the vehicle's infotainment system.

9. The cloud-local application seamless switching method as described in claim 7, characterized in that, After the step of transmitting the response data, including the adjusted application video stream, the process unique number, and the status code, to the vehicle system, the method further includes: When a request to exit the application is received from the vehicle system, the execution of the currently running cloud application is paused on the server side, while the current running state of the currently running cloud application is retained. If a data retrieval request for the same user and the same cloud application is received within a preset time period, the execution of the currently running cloud application is resumed, and the application video stream is transmitted to the vehicle.

10. A cloud-local application seamless switching system, characterized in that, The cloud-local application seamless switching system includes both in-vehicle infotainment and cloud-based systems. The vehicle infotainment system includes: The application loading module is used to load the list of cloud applications stored locally when a start command is received, and to display the cloud applications and local applications on the vehicle's interactive interface. The preloading module is used to determine at least one cloud application to be preloaded based on the historical usage data of each cloud application in the cloud application list, provided that the current network is available. The request sending model is used to send a preload request to the cloud to trigger the cloud to start the preloaded cloud application, and to receive the unique process number corresponding to each preloaded cloud application returned by the cloud. The application scheduling and processing module is used to respond to the user's call operation command for any target cloud application, initiate a data retrieval request to the cloud according to the unique process number corresponding to the target cloud application, and receive the response data returned by the cloud. The cloud includes: The receiving module is used to receive preload requests sent by the vehicle's infotainment system. The number generation module is used to start the preloaded cloud application through the server according to the preload request, and generate a unique process number to identify the preloaded cloud application. The preloaded cloud application is determined by the vehicle system based on the historical usage data of each cloud application in the cloud application list stored locally. The number sending module is used to return the unique process number to the vehicle system, so that the vehicle system can initiate a data retrieval request to the cloud based on the unique process number; The receiving module is also used to receive data retrieval requests sent by the vehicle-mounted system; The response return module is used to obtain the corresponding response data through the server according to the data retrieval request, and transmit the response data to the vehicle system.

11. A cloud-local application seamless switching device, characterized in that, The device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the cloud-local application seamless switching method as described in any one of claims 1 to 9.

12. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the cloud local application seamless switching method as described in any one of claims 1 to 9.

Images