A card display method

Abstract

The application discloses a card display method, and belongs to the technical field of visualization. The method comprises the following steps: in response to a dynamic card display request under a target scene, loading a target container corresponding to the dynamic card, and simultaneously acquiring a resource package associated with the dynamic card; under the condition that the target container is loaded and the resource package is acquired, processing the resource package; and rendering the processed resource package through the loaded target container, so as to display the dynamic card under the target scene. The core of the application is to process the time-consuming container loading and resource package acquisition processes in parallel, break the performance bottleneck of traditional serial loading, significantly shorten the total loading time, improve the loading efficiency, reduce the user perception delay, optimize the user experience, and improve the parallel utilization rate of system hardware resources.

Description

Technical Field

[0001] This application relates to the field of visualization technology, and more specifically, to a card display method in the field of visualization technology. Background Technology

[0002] Card interaction is a new type of interaction method in current in-vehicle Android systems. The convenience, diversity, and update speed of the card implementation scheme will affect the user experience of this interaction design.

[0003] Current in-vehicle system cards use a native widget approach, relying on Over-the-Air Technology (OTA) for addition and upgrades. Introducing dynamic cards allows for rapid updates, but their loading speed directly impacts the user experience. Existing technologies suffer from numerous issues when handling dynamic card loading.

[0004] Traditional card loading methods often employ a synchronous loading strategy, resulting in slow application response times when loading card content. Furthermore, the loading process for dynamic cards lacks an effective error handling mechanism. When the network environment is unstable or the data source is unavailable, the cards cannot be displayed correctly. In short, existing technologies suffer from slow card loading response times and a lack of effective error management mechanisms, leading to inefficient card loading and poor card display, thus reducing user satisfaction. Summary of the Invention

[0005] In view of the above problems, this disclosure provides a card display method to overcome or at least partially solve the above problems, the technical solution of which is as follows:

[0006] On one hand, a card display method is provided, the method comprising: in response to a dynamic card display request in a target scene, loading a target container corresponding to the dynamic card, and simultaneously obtaining a resource package associated with the dynamic card; when the target container is loaded and the resource package is obtained, parsing the resource package; and rendering the parsed resource package through the loaded target container to display the dynamic card in the target scene.

[0007] On one hand, a card display device, the device comprising:

[0008] The parallel processing module is configured to respond to a dynamic card display request in the target scenario, load the target container corresponding to the dynamic card, and simultaneously obtain the resource package associated with the dynamic card.

[0009] The parsing and rendering module is configured to parse the resource package after the target container has been loaded and the resource package has been acquired; and to render the parsed resource package through the loaded target container to display the dynamic card in the target scene.

[0010] Compared with the prior art, the beneficial effects achieved by this application are as follows:

[0011] This invention improves response speed through parallel loading by setting the loading of the target container and the acquisition of resource packages to be executed in parallel, breaking the performance bottleneck of traditional serial operations. This method effectively utilizes the multi-core processing power and concurrent I / O characteristics of modern mobile devices, allowing operations that originally required sequential waiting to be performed concurrently, thus significantly shortening the total waiting time from request initiation to rendering start. This results in a faster loading speed perceived by the user. The parallel loading strategy greatly reduces card display latency, allowing users to see dynamic content faster in the target scene, effectively eliminating white screens or static placeholders caused by long waiting times, thereby improving application smoothness and user satisfaction. Furthermore, it ensures process stability through conditional triggering. By setting the completion of target container loading and resource package acquisition as prerequisites for starting parsing, this method establishes a reliable synchronization point. This mechanism ensures that the rendering process only starts after all necessary dependencies are ready, avoiding rendering errors, blank pages, or application crashes caused by unprepared resources, reducing system resource idle time, improving overall application efficiency, and enhancing the stability and predictability of the entire loading process. Furthermore, by decoupling resource loading from UI rendering, this decoupling design makes the logic for acquiring resource packages independent of the rendering logic, improving the modularity and maintainability of the code, and laying the foundation for optimizing the performance of each stage separately.

[0012] The above description is merely an overview of the technical solution disclosed herein. In order to better understand the technical means of this disclosure and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this disclosure more apparent and understandable, specific embodiments of this disclosure are described below. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating the card display method provided in an embodiment of this application;

[0014] Figure 2 This is a schematic diagram of the process for obtaining resource packages associated with dynamic cards provided in an embodiment of this application;

[0015] Figure 3 This is a flowchart illustrating the fallback handling process for resource package download failures provided in this application embodiment;

[0016] Figure 4 This is a flowchart illustrating the fallback handling process for resource package parsing failures provided in this application embodiment;

[0017] Figure 5 This is a flowchart illustrating a successfully resolved resource rendering exception provided in an embodiment of this application.

[0018] Figure 6 This is a schematic diagram of the vehicle structure provided in the embodiments of this application;

[0019] Figure 7 This is a detailed flowchart illustrating the card display process provided in the embodiments of this application;

[0020] Figure 8 This is a schematic diagram of the structure of the card display device provided in the embodiments of this application;

[0021] Figure 9 This is a detailed flowchart illustrating another card display provided in an embodiment of this application;

[0022] Figure 10 This is a schematic diagram of the parallel loading process provided in an embodiment of this application;

[0023] Figure 11 This is a schematic diagram of another card display process provided in an embodiment of this application;

[0024] Figure 12 This is a schematic diagram of the dynamic configuration distribution process provided in the embodiments of this application;

[0025] Figure 13 This is a flowchart illustrating the process of handling JS exceptions within a resource package, as provided in an embodiment of this application.

[0026] Figure 14 This is a schematic diagram of the resource package processing flow provided in the embodiments of this application;

[0027] Figure 15 This is a schematic diagram of the rendering process of the processed resource package provided in the embodiments of this application. Detailed Implementation

[0028] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " indicates "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0029] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features reflected. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0030] In order to illustrate the technical solutions provided in the embodiments of this application, some terms involved in the embodiments of this application will be introduced below.

[0031] Dynamic cards are modular components in the user interface whose content and style are not hardcoded into the application's native code, but are dynamically loaded and rendered through an independent resource bundle. This allows developers to update the functionality and appearance of cards without updating the entire app, and is commonly used in scenarios such as news feeds, quick access points, and advertisements. The core value of dynamic cards lies in their flexibility, rapid iteration, and cross-platform deployment capabilities. A typical dynamic card resource bundle usually includes JavaScript code to describe the logic, HTML / XML layout files to define the structure, CSS files to control styles, and static resources such as images and fonts.

[0032] Target scenario: This refers to the specific context in which the dynamic card display is triggered. For example, the app's homepage, a specific function page, or a pop-up window after a user clicks a button. Different scenarios may require displaying cards with different content or styles. Defining the target scenario helps the system accurately locate the card resources that need to be loaded and associate them with the corresponding rendering strategies and error handling logic.

[0033] Target container: A reserved space or frame on the native UI. It's a native component (like Android's FrameLayout or iOS's UIView) specifically designed to hold the rendering results of dynamic cards. Its role is to allow dynamic content to be seamlessly embedded into the native UI. The target container itself doesn't contain business logic; its main responsibility is providing the drawing surface, managing the view hierarchy, and receiving user input events. Choosing the appropriate container type (such as SurfaceView for Android, which supports independent thread drawing, avoiding UI thread blocking) is crucial for rendering performance.

[0034] Resource bundle: A standalone compressed file (such as .zip or .resource_bundle) containing all the resources needed to render a dynamic card. It typically includes:

[0035] Code: JavaScript or other scripting language files, responsible for the logic and dynamic behavior of the cards, such as data retrieval, user interaction response, animation execution, etc.

[0036] Layout: A file that describes the UI structure of the cards (such as HTML or a custom-formatted layout file), defining the arrangement and nesting relationships of the components.

[0037] Style: Defines the appearance of the card using CSS (Cascading Style Sheets) or style sheet files, controlling colors, fonts, spacing, animation effects, etc.

[0038] Resources: Static materials such as images, fonts, and icons.

[0039] Resource packages are typically generated by development toolchains and managed and distributed through a cloud-based package management platform.

[0040] Aurora Service: In the embodiments of this application, it specifically refers to a self-developed backend service deployed on the vehicle terminal, which is built on the cross-platform framework Lynx and is specifically responsible for the entire lifecycle management of dynamic cards, including receiving requests, cache management, loading, rendering and exception handling.

[0041] Lynx framework: A high-performance, cross-platform front-end framework that allows the development of native applications using front-end technology stacks, and is particularly good at rendering dynamic content.

[0042] Bridge communication: In a hybrid development framework, this serves as a communication bridge connecting the Native layer (native code, such as Java or Swift) and the JavaScript layer (dynamic card logic). It allows JavaScript code to safely invoke functions provided by the Native module (such as device APIs and network requests), and also allows the Native layer to notify the JavaScript environment of events or exceptions. In this application, this mechanism is used to pass rendering execution exception information from the Native layer to the framework layer.

[0043] Current in-vehicle system cards use a native widget solution, with additions and upgrades relying on system OTA updates. Introducing dynamic cards allows for rapid updates, but their loading speed directly impacts the user experience. Traditional card loading methods often employ synchronous loading strategies, resulting in slow application response times when loading card content. Furthermore, the loading process for dynamic cards lacks effective error handling mechanisms. When the network environment is unstable or the data source is unavailable, the cards cannot display correctly. In short, existing technologies suffer from slow card loading response times and a lack of effective error management mechanisms, leading to low card loading efficiency and poor card display, thus reducing user satisfaction.

[0044] Based on the above application scenarios, and in order to solve the technical problem of poor display effect due to card loading efficiency in existing related technologies, this application provides a card display method, such as... Figure 1 and Figure 9As shown, Figure 1 This is a schematic flowchart of a card display method provided in an embodiment of this application.

[0045] Example 1

[0046] This embodiment provides a card display method that can be applied to the operating systems or applications of mobile terminals such as smartphones and tablets. It is particularly suitable for in-vehicle Android systems, which have extremely high requirements for loading speed and stability, and is used to improve the loading speed and display stability of dynamic cards such as information feeds and function entry points. The core innovation of this method lies in transforming the originally serial loading process into parallel execution, supplemented by a comprehensive exception handling mechanism.

[0047] Reference Figure 9 , Figure 9 This is a schematic diagram illustrating the implementation environment of a card display method provided in this application embodiment. The environment includes a cloud component and an in-vehicle terminal component. The cloud component includes a package management platform and a cloud platform, responsible for the storage, version management, and distribution of resource packages. The in-vehicle terminal component includes AIUI (Intelligent Voice Interaction Interface) as the business unit, as well as core backend services.

[0048] Reference Figure 1 Taking the vehicle-mounted terminal as the executing entity as an example, the card display method in this embodiment includes the following steps.

[0049] Step S101: In response to the dynamic card display request in the target scene, load the target container corresponding to the dynamic card, and at the same time obtain the resource package associated with the dynamic card.

[0050] See Figure 10 and Figure 11In this embodiment, when a user performs a pull-to-refresh operation on the application's homepage (the target scene) of the in-vehicle terminal, the application triggers a dynamic card display request. This request aims to display a dynamic card for recommending news information. This request typically carries the card's unique identifier (Card ID) and any necessary context parameters. In response to this request, the in-vehicle system executes two tasks in parallel: loading the target container corresponding to the dynamic card and obtaining the resource package associated with the dynamic card. These two tasks run in different threads to maximize the utilization of multi-core CPUs and concurrent I / O capabilities. The in-vehicle system calls the native UI interface in the main thread (UI thread) to initialize and load a FrameLayout (in the Android platform) as the target container. This container is a placeholder view used to subsequently hold the rendered content of the dynamic card. This process involves view measurement, layout, and initial drawing, typically completed within 10-20 milliseconds. FrameLayout is chosen because it is lightweight and suitable for overlaying dynamic content. In some high-performance scenarios, SurfaceView can also be used, as it has an independent drawing surface and higher rendering efficiency.

[0051] Meanwhile, in a background thread (worker thread), a resource package retrieval request is initiated from the local cache manager based on the unique identifier (ID) of the dynamic card. This resource package is a compressed file (such as a ZIP file) containing the JavaScript logic files, HTML layout files, CSS style files, and necessary image resources used to render the card. The resource package retrieval process first attempts to read from the local cache; if the cache misses, a network request is initiated to download it from the cloud server. This parallel design breaks the traditional serial model of container-first, resource-later, allowing time-consuming network I / O operations (resource package retrieval) and relatively fast UI initialization operations (container loading) to occur simultaneously.

[0052] Step S102: If the target container has been loaded and the resource package has been acquired, process the resource package.

[0053] The completion status of the two parallel tasks mentioned above is monitored in real time through event listening mechanisms or asynchronous programming models such as Promise / Future. When the callback event indicating the completion of FrameLayout initialization is heard, and the resource package data returned by the local cache manager (whether read from local storage or downloaded from the network) is received, it is determined that the loading conditions have been met. This waiting point ensures that subsequent operations will only begin after all necessary resources are ready, avoiding rendering errors or waiting caused by incomplete resources. At this point, a parsing process is started, usually executed in a background thread, to decompress and parse the acquired resource package. Specifically, decompression involves unpacking the ZIP format resource package into memory or a temporary directory, extracting the internal HTML, CSS, JS, and resource files. Parsing involves reading the HTML files and constructing the Document Object Model (DOM), a tree-like data structure representing the page structure. The CSS files are parsed to construct the CSS Object Model (CSSOM), which contains application information for all CSS rules. If necessary, the JavaScript files are parsed to prepare for subsequent execution. The parsing process is a crucial step in converting static resource files into an in-memory representation that the rendering engine can understand and manipulate.

[0054] Step S103: Render the processed resource package using the loaded target container to display the dynamic card in the target scene.

[0055] After parsing, a JavaScript engine, such as V8 or JavaScriptCor, is launched to execute the JS scripts in the resource package. These scripts may manipulate the DOM tree built in step S102, for example, dynamically inserting data or binding event handlers. Simultaneously, combining the DOM and CSSOM, the final style of each node is calculated; this process is called style calculation or RecalcStyle. Layout / Reflow calculates the exact position and size of each element on the screen based on the calculated styles and DOM structure. Painting converts the layout results into actual pixels, generating a list of drawing instructions. For complex animations or frequently updated cards, GPU acceleration may be used. Compositing combines the drawn layers into a final image, which may include the native UI layer and card layers, and submits it to the display system. Finally, the in-vehicle system delivers these rendering instructions to the native rendering engine, which draws the complete user interface within the loaded FrameLayout, the target container. Users can then see content-rich, interactive, dynamic news cards on the application's homepage.

[0056] The technical solution in this embodiment significantly improves loading efficiency. By loading the target container and resource package in parallel, the total time consumed by the traditional serial loading method—namely, container loading time and resource package acquisition time—is reduced to nearly the maximum of the two. Due to the drastically reduced loading wait time, the perceived latency from initiating a refresh to seeing the card content is significantly reduced, avoiding prolonged white screens or loading animations. This results in a smoother user experience, improved application responsiveness, and enhanced user satisfaction. The parallel loading mechanism allows the CPU (handling container initialization) and network I / O (downloading resource packages) to work simultaneously, avoiding idle waiting of a single resource and improving the utilization efficiency of mobile terminal hardware resources.

[0057] Example 2

[0058] This embodiment, based on Embodiment 1, further describes in detail the local caching strategy during the resource package acquisition process. Local caching is a key technology for reducing network requests, improving loading speed, and ensuring a good experience in weak network / offline environments.

[0059] Reference Figure 2 , Figure 11 and Figure 12 In step S101 of Embodiment 1, obtaining the resource package associated with the dynamic card specifically includes the following sub-steps:

[0060] Step S1011: In response to the dynamic card display request in the target scenario, perform a status query on the resource package associated with the dynamic card in the local storage space to determine the storage status of the resource package.

[0061] Based on the card ID, a query is performed on the local storage space reserved for dynamic cards, such as the application's cache directory or a dedicated `card_resources` directory. A local resource package index table is maintained, for example, an SQLite database or a JSON file. This table records metadata for each cached resource package, including its ID, version number, file path, file hash used for integrity verification, last access time, and storage time. By querying this index table, it is possible to quickly determine whether the resource package corresponding to the ID exists and whether its version meets the requirements. The resource package storage status is determined to be either present and the version is valid and the file is intact, or non-existent, including if the version is too low or the file is corrupted.

[0062] Step S1012: If the resource package is stored in the state of "existence", read the resource package.

[0063] If the record exists in the index table, and the file hash verification confirms that the resource package file is complete and undamaged, then the resource package is considered to exist and be valid. The system directly reads the resource package file from local storage into memory. Since the read speed of local storage, such as eMMC / UFS, is much higher than that of network transmission, this process takes a very short time, usually less than 5 milliseconds, achieving the so-called "instant loading" effect, and providing a user experience close to that of a native page.

[0064] Step S1013: When the resource package storage status is non-existent, download the resource package from the cloud and obtain the resource package.

[0065] If the record is not found in the index table, or if the record exists but the version is too low, or the file is corrupted (i.e., hash verification fails), the resource package is determined to be non-existent or invalid. A network request is initiated via HTTP / HTTPS protocol using a preset cloud URL associated with the card ID to download the latest, compatible resource package from the server. A loading progress bar or skeleton screen may be displayed during the download process to improve the waiting experience.

[0066] This embodiment significantly reduces network dependence by introducing a local caching mechanism. For cached cards, the loading process is completely independent of the network, allowing for normal display even in weak network or offline environments, thus improving application availability and robustness. Local reading speed is much faster than network download, greatly improving the display speed of frequently accessed cards. It avoids repeatedly downloading the same resource packages, reducing bandwidth pressure on cloud servers and saving mobile data for users.

[0067] Example 3

[0068] This embodiment, based on Embodiment 2, further describes the local storage space management mechanism. This is to prevent the cache from expanding indefinitely and consuming excessive device storage space.

[0069] See Figure 2 and Figure 12 Before downloading the resource package from the cloud in step S1013 of Embodiment 2, the card display method further includes:

[0070] Step S1014: Check whether the local storage space has reached the preset threshold and determine the storage space status.

[0071] Before initiating a download, the vehicle system checks the current size of the local cache directory. This threshold can be statically configured, such as 100MB, or it can be a dynamically calculated percentage based on the device's total storage space, such as not exceeding 5% of the available space. If the size has reached or exceeded the preset threshold, the storage space is determined to be full or needs to be cleared.

[0072] Step S1015: When the storage space status reaches the preset threshold, clean up the storage space according to the least recently used principle until the cleaned storage space does not reach the preset threshold.

[0073] The in-vehicle system initiates a cleanup task. This task iterates through the metadata of all local resource packages, recording the last access time and storage time of each package. Using the LRU algorithm, it prioritizes cleaning up one or more older resource packages with the furthest last access time, until sufficient space is freed up, for example, until the storage space is below 80MB. The specific cleanup process is as follows: Obtain a list of metadata for all cached resource packages. Sort the packages in ascending order by last access time, with the earliest accessed package at the top. Starting from the beginning of the list, i.e., the least used resource package, delete the corresponding resource package files one by one and update the metadata index. After each deletion, check if the current cache directory size is below a preset cleanup target threshold, for example, clean up to below 80MB, leaving some buffer space. Continue until sufficient space is freed up to meet the storage needs of new resource packages. Additionally, a periodic cleanup task, such as once a day, can be initiated to directly delete expired resource packages (e.g., those stored for more than 7 days) regardless of their access frequency, ensuring the freshness of cached content.

[0074] This embodiment employs an intelligent cache management mechanism to ensure stable operation, preventing user device storage space exhaustion due to unlimited cache growth and maintaining the health of applications and devices. The LRU algorithm ensures that the least frequently used resource packages are cleaned up, while retaining the most frequently accessed resource packages, maximizing cache efficiency and allowing limited cache space to achieve maximum performance benefits. Parameters such as cleanup threshold, target space, and maximum storage time are configurable to adapt to different device specifications and business needs.

[0075] Example 4

[0076] Network requests are inherently unstable, and preparations must be made for download failures. This example describes fallback handling for resource package download failures.

[0077] Reference Figure 3 and Figure 13 Based on the process of Embodiment 1, if the resource package download fails in the resource package acquisition task of step S101, for example, due to network connection timeout, DNS resolution failure, or server returning 4xx / 5xx error codes, the system will not leave the card area blank or throw an exception, but will instead execute the following fallback steps:

[0078] Step S401: Obtain the first preset rendering information.

[0079] Load a lightweight local resource built into the application installer: the initial preset rendering information. This information might be a simple JSON object describing a static message, possibly containing text indicating a potential network problem and prompting you to retry, along with a refresh button style. Specifically: `message` indicates a network issue and requests a retry; `icon` represents `retry_icon.png` (the built-in icon resource); `buttonText` indicates a retry option; and `action` defines the retry behavior. This preset rendering information is small, loads quickly, and is network-independent.

[0080] Step S402: Once the target container has been loaded, render the first preset rendering information using the target container.

[0081] Once the FrameLayout, the target container, is loaded, native rendering capabilities are used instead of a JS engine that relies on dynamic cards to directly draw the error message interface within the target container based on the content described by the first preset rendering information. This interface will include error message text, an icon, and a clickable retry button, instead of waiting for dynamic resource packs.

[0082] This embodiment employs an exception fallback mechanism to prevent interface blankness or crashes. Even in extreme situations such as network anomalies, users still see a user-friendly, consistently designed prompt interface, rather than a blank card area or confusing error codes, ensuring basic user experience and interface integrity. It also provides clear user feedback and recovery paths: clear error messages let users know the problem is a network issue, while the rendered interactive retry button provides users with a proactive recovery method, enhancing the application's fault tolerance and user control. When the user clicks retry, the resource package download process is retried. This ensures that the dynamic cards remain stable and usable even in environments with fluctuating network conditions.

[0083] Example 5

[0084] Resource packages may be corrupted during download, or version incompatibility may cause parsing errors. This example describes fallback handling for resource package parsing failures.

[0085] If, in step S102 of Embodiment 1, file corruption (such as ZIP format errors), missing necessary files, HTML / CSS syntax errors, or JS syntax errors are found during the parsing of the resource package, resulting in parsing failure, please refer to... Figure 4 and Figure 13 Then perform the following steps:

[0086] Step S501: Obtain the second preset rendering information.

[0087] This message is used to indicate to the user that content loading failed and to ask them to try again later, or a similar prompt. Similar to the first preset message, it is also a built-in, lightweight native resource.

[0088] Step S502: Once the target container has been loaded, render the second preset rendering information using the target container.

[0089] Display a message to the user indicating that the parsing failed. This screen can also include a retry button, which allows the user to try downloading again, potentially obtaining a new, undamaged version or clearing the local cache before retrying.

[0090] This embodiment provides a specific fallback solution for anomalies in the parsing process. It can accurately provide users with feedback that there is a problem with the resource itself, which is more precise than a general loading failure message. This helps users understand the problem and also provides developers with clearer signals for troubleshooting, such as checking the resource package generation process.

[0091] Example 6

[0092] This example describes advanced exception fallback handling for rendering execution errors. This is the most complex exception scenario, occurring when the resource package has been successfully downloaded and parsed, but a runtime error occurs during the execution of JavaScript logic for rendering.

[0093] Reference Figure 5 and Figure 13 In step S103 of Embodiment 1, if the resource package has been successfully parsed, but an error occurs during JavaScript rendering, such as undefined variables, function call stack overflow, insufficient memory, or asynchronous operation timeout, resulting in a runtime exception, then the following steps are executed:

[0094] Step S601: Perform error isolation on the dynamic card that has experienced a rendering execution exception.

[0095] The exception is caught using a two-layer protection mechanism. Once the exception is successfully caught at either layer, isolation measures are immediately taken. The specific catching process is as follows: First layer: JavaScript layer. In the context of executing the card's JS code, a try...catch block is used to wrap the critical execution logic. If the exception is thrown at the JS level and can be caught by catch, the error handling flow at the JS level is entered. Second layer: Native layer. If the try...catch block at the JS level fails to catch the exception—for example, due to some underlying engine error, or the exception causing instability in the JS engine—the error handling system at the native level will intervene. This is typically achieved by setting a global error handler for the JS engine, such as V8:SetFatalErrorHandler, or by monitoring the JS engine's runtime status.

[0096] The isolation measures implemented include: stopping the rendering loop; if a card has animations or continuously updating logic, immediately stopping its rendering loop or timer; and destroying the execution environment, unloading and destroying the card's unique JavaScript execution environment, such as a separate WebView instance or JS context. This ensures that abnormal JS code does not continue to run, its occupied memory can be reclaimed, and it does not pollute other cards or the main application logic through global variables.

[0097] Step S602: Determine the severity of the execution anomaly.

[0098] The exception event object is passed from the Native layer via the bridge communication mechanism. This object contains rich diagnostic information, such as: error type (Error object, such as ReferenceError, TypeError, SyntaxError, etc.), error message, error call stack trace, resource URL and line number where the error occurred.

[0099] Based on this information, assess the severity of the anomaly. The assessment strategy can be rule-based, for example: Minor: Style errors that do not affect core functionality, console warnings, some negligible asynchronous timeouts. Moderate: Data loading failures, JS errors in non-critical functional modules. Severe: Errors that prevent the main card UI from rendering, signs of memory leaks, errors blocking the main thread, repeated occurrences of the same error.

[0100] Step S603: If the execution exception is severe, obtain the fourth preset rendering information.

[0101] The fourth preset rendering information is only retrieved when the exception is deemed severe. This information indicates that the card is malfunctioning, prompts for a reload, and typically includes a prominent retry button. For minor or general errors, a silent approach may be chosen, such as logging or displaying a less intrusive notification.

[0102] Step S604: Render the fourth preset rendering information using the loaded target container to obtain the fourth preset rendering information display.

[0103] Using native rendering capabilities again, the error message interface described by the fourth preset rendering information is rendered in the target container. This interface clearly informs the user that a runtime error has occurred and provides the option to reload. Clicking this option triggers the card's full reload process, starting from the request.

[0104] This embodiment ensures overall application stability through refined runtime exception handling. By employing an error isolation mechanism, the impact of anomalies in a single card is limited to its own scope, effectively preventing the serious problem of a single card crashing and affecting the entire application, thus greatly improving application robustness. It also improves problem localization efficiency. Through a dual-layer protection mechanism and bridge communication, detailed exception information can be captured. This information can be automatically reported to the log system or remote server, providing valuable data support for developers to remotely diagnose and repair problems, accelerating the problem resolution cycle. Furthermore, it optimizes the user experience. By differentiating the severity of exceptions, it avoids frequently disturbing users with minor, non-functional errors. Clear error messages and recovery operations are only displayed to users when serious errors that truly impact the functional experience occur, achieving intelligent and user-friendly error management.

[0105] Example 7

[0106] See Figure 14 In step S102 of Embodiment 1, after the target container has been loaded and the resource package has been acquired, the resource package is processed, which specifically includes the following sub-steps:

[0107] Step S701: After the target container has been loaded and the resource package has been obtained, decompress the resource package to obtain the code files, layout files, style files and resource files inside the resource package.

[0108] The resource package is decompressed to obtain its internal file structure. Once the target container has finished loading and the resource package has been acquired, the resource package parsing process is initiated. First, the acquired compressed resource package is decompressed, releasing its contents to memory or a temporary directory. In this embodiment, the compressed resource package is typically in ZIP format. The decompressed files include: code files (JavaScript files with the .js extension), used to implement the business logic and interactive behavior of the dynamic cards, including data acquisition, event handling, and animation control; layout files (document structure files with the .html or .xml extension), used to define the UI component hierarchy and layout relationships of the dynamic cards; style files (style rule files with the .css extension), used to define the visual presentation of the dynamic cards, including colors, fonts, spacing, and animation effects; and resource files, including image resources in .png and .jpg formats, font files in .ttf and .otf formats, and other static materials used to construct the visual elements of the dynamic cards.

[0109] Step S702: Based on the layout file and style file, generate the document object model and cascading style sheet object model, and construct the document object model and style sheet object model.

[0110] Based on the decompressed layout and style files, the corresponding parser is started. The HTML parser is used to perform syntax analysis on the layout file, build a Document Object Model (DOM), and form a node tree describing the card UI structure, where each HTML element corresponds to a node in the DOM tree. The CSS parser is used to parse the style file rules, build a Cascading Style Sheets Object Model (CSSOM), and form a style rule tree containing all style rules and their cascading relationships.

[0111] Step S703: Assemble the processed resource package by taking the document object model, cascading style sheet object model, code file, and resource file as the processed resource package.

[0112] The various files and organizational structures obtained in steps S701 and S702 are integrated to form a complete renderable resource package, including: a structured Document Object Model (DOM), a rule-based Cascading Style Sheets Object Model (CSSOM), executable JavaScript code files, and loadable resource files such as images and fonts. This processed resource package provides standardized and structured input data for subsequent rendering stages.

[0113] The technical solution in this embodiment achieves standardized resource processing: through a unified decompression and parsing process, resource packages from different sources and in different formats are converted into standard data structures recognizable by the rendering engine, ensuring consistency in subsequent rendering. By pre-building DOM and CSSOM models, the real-time parsing overhead during rendering is avoided, laying the foundation for fast rendering and optimizing rendering performance; through a systematic file extraction and model building process, it is ensured that all resource elements required for dynamic cards are fully identified and prepared.

[0114] Example 8

[0115] See Figure 15 This embodiment, based on embodiment nine, describes in detail how to use the processed resource package for the final rendering and display of dynamic cards.

[0116] In step S103 of Embodiment 1, the parsed resource package is rendered using the loaded target container, specifically including the following sub-steps:

[0117] Step S801: Based on the Document Object Model and Cascading Style Sheets Object Model, execute the code file through the loaded target container to generate rendering instructions.

[0118] Once the target container is ready and the resource package has been processed, the system starts the JavaScript execution environment, such as the V8 engine, injecting the DOM and CSSOM constructed in step S702 as the execution context. Then, the JavaScript code files in the resource package are executed. This execution process includes: associating business data with DOM nodes through data binding; adding user event listeners to interactive elements through event binding; dynamically modifying style rules in the CSSOM according to business logic through dynamic style calculation; and generating rendering instructions by calling the rendering engine API to generate a specific sequence of instructions describing how to draw each UI element.

[0119] Step S802: By loading the completed target container, based on rendering instructions and in conjunction with resource files, draw the user interface to display dynamic cards in the target scene.

[0120] The rendering instructions generated in step S801 are submitted to the graphics rendering pipeline. Combined with the visual elements in the resource files, the actual drawing is performed in the loaded target container: through layout calculation, the precise position and size of each element in the container are calculated according to the DOM structure and CSSOM styles; through resource loading, resource files such as images and fonts are loaded asynchronously and displayed after they are ready; then pixel drawing is performed, and the rendering instructions are converted into actual pixel data through the underlying graphics library, such as OpenGL ES and Skia; finally, the interface is composited, and the drawn card layer is composited with other layers of the native interface, so that the interactive dynamic card is fully displayed in the target scene.

[0121] The technical solution in this embodiment achieves dynamic interaction capabilities. By executing JavaScript code, it endows dynamic cards with rich interactive logic and data processing capabilities, realizing a truly dynamic experience. It also improves rendering efficiency by executing rendering instructions based on a pre-built DOM and CSSOM, avoiding repetitive layout calculations and style parsing, significantly improving rendering performance. Furthermore, it ensures visual consistency by using a unified rendering pipeline and resource loading mechanism to ensure that dynamic cards maintain a consistent visual appearance across different devices and scenarios. Finally, it achieves seamless native integration by using the target container as a bridge to perfectly blend dynamic content with the native interface, making the boundaries of the technical implementation imperceptible to the user.

[0122] Example 9

[0123] In this embodiment, the system applying the method of the present invention deploys a self-developed backend service on the vehicle's infotainment system. This service is built on the cross-platform dynamic framework Lynx and is used to support high-performance loading and display of dynamic cards developed using front-end technology stacks (HTML / CSS / JavaScript) on the vehicle's infotainment system. The resources of the dynamic cards are stored, version-managed, and distributed in the form of asset bundles on a cloud-based package management platform.

[0124] When a system using the method of this invention starts up, the background service performs the following initialization process (see below). Figure 7 and Figure 9To prepare for card display, the first step is establishing a metadata index. The background service scans a pre-defined local storage directory, such as ` / data / data / com.aurora / cache / bundles / `, traversing all existing `.zip` resource package files. For each resource package, its metadata information is read. This metadata may be written to a separate `manifest.json` file during download or appended to the ZIP file's comments. Metadata includes, but is not limited to: a unique resource package identifier (Bundle ID), version number, file size, SHA-256 file hash for integrity verification, last access timestamp, and storage timestamp. Subsequently, a hash table with the Bundle ID as the key is built in memory as a metadata index to enable millisecond-level query, update, and management operations. This in-memory index is resident during service operation and is synchronously maintained every time a resource package is accessed or updated. The background service loads cache management policies from a cloud or local configuration file. This configuration can be dynamically distributed from the cloud based on different vehicle information, such as vehicle model code and hardware storage specifications, enabling personalized resource management. Configuration details include: Disk space management: Maximum total size of resource package cache (default value is 500MB); Maximum storage time for a single resource package (TTL, default value is 7 days); Threshold for triggering cleanup (e.g., reaching 95% of the limit). Dynamic update strategy: Define whether configuration updates take effect immediately or require an application restart.

[0125] The detailed card loading process is as follows: Taking the recommended scenario in the vehicle system as an example, when a user triggers a specific scenario through voice or touch screen, AIUI (intelligent voice interaction interface), as the business party, will send a dynamic card display request to the backend service.

[0126] Step S201: Request issuance and rendering trigger.

[0127] The cloud-based Aurora Package Management Platform determines which cards to display based on user profiles and scene context, and pushes card information, including the resource package ID and minimum compatible version, to the vehicle's message gateway or cloud platform integration module. The cloud platform integration module then distributes this card information to the vehicle's AIUI application. Upon receiving the package information, the AIUI application initiates a rendering request to the vehicle's resident background service via inter-process communication, such as Binder for Android or local API calls. This request includes the target resource package ID and necessary rendering parameters.

[0128] Step S202: Parallel loading and local detection.

[0129] Upon receiving the rendering request, the background service breaks away from the traditional serial loading mode and immediately launches two parallel tasks:

[0130] Task 1: Container Loading. In this thread, the Android native UI interface is called to initialize a SurfaceView as the target container for holding the dynamic card content. SurfaceView is chosen because its drawing interface is independent of the application's main window, and rendering can be performed in a separate thread without blocking the main UI thread. Its double-buffering mechanism can also efficiently and smoothly handle frequent interface updates, making it very suitable for dynamic content such as cards with animations or real-time data updates, effectively avoiding interface stuttering or flickering caused by frequent redraws.

[0131] Task 2: Resource Package Acquisition. In a background worker thread, based on the resource package ID in the request, the metadata index established in step S1 is queried to quickly determine whether the required, version-compatible, and complete resource package exists locally.

[0132] Step S203: Local existence determination and subsequent processing.

[0133] The local existence check will result in two outcomes: the resource package exists locally or it does not exist locally. Specifically:

[0134] Scenario 1 (Local Cache Hit): If a valid record corresponding to the resource package ID exists in the metadata index, and its version number is greater than or equal to the minimum version requirement issued by the cloud platform, and the file hash verification passes, then a local cache hit is determined. The system directly reads the resource package file from local storage into the memory buffer through the local read subunit, then skips the download step and directly enters the subsequent parsing and rendering process. This is the fastest path.

[0135] Scenario 2 (Local Cache Miss): If the resource package ID does not exist locally, or the record exists but the version is too low, or the file is corrupted (i.e., hash verification fails), then a cache miss is determined. The system will initiate an HTTPS request to the JPush Package Management Platform in the cloud via the cloud download subunit to obtain the download address of the latest version of the resource package and possible differential update information.

[0136] Step S204: Cache management and download.

[0137] In scenario 2 (cache miss), before initiating a new download task, a cache management process must be executed to ensure sufficient space to store the new resource package. This includes a space threshold check, loading the storage configuration information from step S1, and checking if the used storage space in the current cache directory has reached a preset threshold, such as 500MB. Specifically, an LRU (Least Recently Used) algorithm is used for cleanup. If the used space reaches or exceeds the threshold, the LRU cleanup process is triggered. The specific cleanup process is as follows: 1. Retrieve all resource package records from the metadata index. 2. Sort all records in ascending order by the last access time field, with the earliest accessed record at the top. 3. Starting from the beginning of the sorted list, delete the corresponding resource package file one by one, remove the record from the metadata index, and release the storage space it occupies. 4. Continue cleanup until the used space is below a safe target threshold, for example, cleanup until the occupied space is below 450MB. 5. In addition, a separate scheduled task will periodically, such as running every 24 hours, check and delete all resource packages stored for more than 7 days, regardless of their access frequency, to prevent cache zombie resource packages.

[0138] After ensuring sufficient storage space, the system downloads the latest resource package from the cloud. Once downloaded, the system verifies the integrity and signature of the resource package, if a signature mechanism was used. After successful verification, the resource package file is saved to the local cache directory, and the metadata index is updated: recording the new last access time (which is the current time), storage time, and calculating and storing information such as the file hash.

[0139] Step S205: Analyze rendering and display.

[0140] When both parallel tasks are completed—that is, the SurfaceView container is loaded (notification via main thread callback) and the resource package is acquired (notification via background thread)—the background service starts the core rendering engine. The rendering engine performs the following operations: Parsing: Uncompress the resource package and read the HTML template, CSS stylesheet, and JavaScript logic file. Building the DOM / CSSOM: Parse the HTML to build the DOM tree and parse the CSS to build the CSSOM tree. Executing JavaScript: Execute the card's JavaScript scripts in the JS runtime environment provided by the rendering engine. These scripts may perform data binding, event handling, and dynamic modifications to the DOM / CSSOM. Layout and drawing: The engine combines the DOM and CSSOM to calculate styles; layout determines the position and size of each element; drawing generates a list of drawing operations. Submitting for rendering: Finally, the rendering engine submits the generated sequence of rendering instructions to the underlying graphics library, such as OpenGL ES, which then draws the final, interactive, dynamic card interface on the prepared SurfaceView, completing the entire display process.

[0141] This embodiment introduces a refined state machine to manage the entire lifecycle of dynamic cards, ensuring clear and consistent feedback under any abnormal circumstances and guaranteeing user experience. The state machine definition involves: card states are strictly defined, state transitions are triggered by specific events, and are uniformly scheduled by the state machine. The main states include: IDLE: Initial state, the card has not been requested or has been destroyed. REQUESTED: Rendering request received, ready to begin loading. LOADING: Loading the container and acquiring resource packages in parallel; the UI displays a placeholder loading animation. PARSING: Resources acquired, parsing resource package content. RENDERING: Parsing complete, executing rendering instructions. SUCCESS: The card has been successfully displayed on the screen. FAILED_DOWNLOAD: Resource package download failed. FAILED_PARSE: Resource package content corrupted or formatted incorrectly. FAILED_RUNTIME: A JS execution error occurred during rendering.

[0142] State transition and layered fallback handling: Normal process: IDLE -> (receive request) -> REQUESTED -> (start loading) -> LOADING -> (loading complete) -> PARSING -> (parsing complete) -> RENDERING -> (rendering complete) -> SUCCESS.

[0143] In the event of an anomaly during the loading process, this embodiment provides specific exception handling procedures and fallback UIs: In the LOADING state, if a network timeout occurs or the server returns a 5xx error, the state will transition to FAILED_DOWNLOAD. At this time, the state machine triggers a container-side exception fallback, rendering a preset error message in the SurfaceView, displaying an unstable network connection and requesting a retry later, along with a manual retry button. In the PARSING state, if the parser detects a corrupted file header or a JS syntax error, the state will transition to FAILED_PARSE. At this time, the state machine triggers a framework-side fallback, rendering a static interface indicating that content loading failed. In the RENDERING state, if a dual-layer protection mechanism catches a JS runtime exception, the state will transition to FAILED_RUNTIME. This dual-layer protection mechanism includes: a try...catch block in the JS layer as the first line of defense, and native layer capture of JS engine crashes as the second line of defense. Once an exception is caught, the JS execution environment of the affected card is immediately isolated to prevent it from affecting the main application. Subsequently, the state machine notifies the lightweight framework via a bridge communication mechanism. The framework then provides a fallback mechanism by rendering a message indicating an error, prompting users to click to reload the interface, and providing a one-click retry function.

[0144] To provide a better user experience, the state machine implements the following error reporting and automatic recovery mechanisms: When the state transitions to any FAILED_* state, an ErrorUpload Task is automatically triggered. This task collects key environmental information such as the current state, resource package ID, error type, detailed error stack trace, vehicle infotainment system model, system version, and network status, and reports it to the cloud-based log analysis system via the network. This facilitates remote and precise problem identification and resolution by developers. For certain temporary errors, such as FAILED_DOWNLOAD errors due to network fluctuations, the state machine can be configured with an automatic retry mechanism. For example, after transitioning to the FAILED_DOWNLOAD state, a 3-second wait is performed before automatically triggering a new process starting from the REQUESTED state. The maximum number of retries can be set, up to a maximum of 3 retries. This provides users with a seamless recovery experience.

[0145] The technical solution in this embodiment significantly improves card loading efficiency by parallel loading of containers and resource packages, breaking through the performance bottleneck of traditional serial loading. Real-world testing shows that in a 4G vehicle network environment, the average card loading time is reduced from the traditional 1.2 seconds to less than 300 milliseconds, a speed increase of over 75%, greatly enhancing the immediate feedback for user operations. Resource utilization is also highly optimized. Based on the LRU algorithm and dynamically configured intelligent cache management, the vehicle's storage space usage remains stable within a reasonable range, such as around 400MB, saving at least 30% of storage space compared to unordered caching methods, avoiding resource waste and duplicate downloads. Furthermore, system robustness is comprehensively enhanced. A state machine-based end-to-end anomaly handling mechanism, combined with dual-layer protection and error isolation, reduces the vehicle system crash rate caused by dynamic cards from 0.5% to below 0.01%, improving application stability by two orders of magnitude. Meanwhile, clear and user-friendly error messages and automatic recovery functions ensure that even in complex situations such as weak network conditions or code anomalies, users can still obtain a consistent, usable, and predictable interactive experience, greatly improving the reliability of the application and user satisfaction.

[0146] Example 10

[0147] In addition, as shown in Figure 8, Figure 8 This is a schematic diagram of the structure of a card display device provided in an embodiment of this application. This embodiment provides a card display device, which is a virtual device whose functional modules are implemented through software programs to execute the steps in the aforementioned method embodiments. Those skilled in the art will understand that this virtual device can be deployed on a server, cloud platform, or user terminal, such as a smartphone, tablet, or in-vehicle system, and performs its functions by calling corresponding hardware resources such as processors, memory, and network interfaces. (Refer to...) Figure 5 The card display device 100 in this embodiment includes a parallel processing module 110, configured to load the target container corresponding to the dynamic card in response to a dynamic card display request in a target scene, and simultaneously obtain the resource package associated with the dynamic card.

[0148] Furthermore, the parallel processing module 110 includes: a container loading unit configured to initialize and load a native view as the target container in the main thread in response to the display request; and a resource package acquisition unit configured to initiate a resource package acquisition process in a background thread in response to the display request.

[0149] Furthermore, the resource package acquisition unit includes: a status query subunit, configured to query the status of the resource packages associated with the dynamic card in the local storage space to determine the resource package storage status; a local read subunit, configured to read the resource package from the local storage when the resource package storage status is "existent"; and a cloud download subunit, configured to download the resource package from the cloud when the resource package storage status is "non-existent".

[0150] Furthermore, the system also includes: a storage management module 130, connected to the cloud download subunit, configured to check whether the local storage space has reached a preset threshold before downloading; when the preset threshold is reached, the storage space is cleaned up according to the least recently used principle until the cleaned storage space does not reach the preset threshold. The storage management module 130 is specifically configured to: maintain metadata information for all resource packages in the local storage space, including the last access time and storage time; and, based on the metadata information, identify and clean up one or more old resource packages that have exceeded a preset period of least recently used and / or storage time. This ensures the health and efficiency of the caching system. A parsing and rendering module 120, connected to the parallel processing module 110, is configured to parse the resource package after the target container has been loaded and the resource package has been acquired; and render the parsed resource package through the loaded target container to display the dynamic card in the target scene. An exception handling module 140 is connected to the parallel processing module 110 and the parsing and rendering module 120, and is configured to perform exception fallback processing when an exception occurs during loading, parsing or rendering.

[0151] Further, the exception handling module 140 includes: a download failure handling unit, configured to, in the event that the resource package download fails, obtain first preset rendering information, and render the first preset rendering information through the target container after the target container has been loaded; a parsing failure handling unit, configured to, in the event that the resource package parsing fails, obtain second preset rendering information, and render the second preset rendering information through the target container after the target container has been loaded; a request failure handling unit, configured to, in the event that the dynamic card display request response fails, obtain third preset rendering information, and render the third preset rendering information through the target container after the target container has been loaded; and a rendering exception handling unit, configured to, in the event that the resource package download is successful and parsing is successful but rendering execution is abnormal, perform advanced exception fallback processing.

[0152] Further, the rendering exception handling unit 144 includes: an error isolation subunit, configured to perform error isolation on the dynamic card where the rendering execution exception occurred in response to receiving a notification of a rendering execution exception via a bridge communication mechanism; a severity assessment subunit, configured to determine the severity of the execution exception when error isolation is performed; and a fallback rendering subunit, configured to obtain fourth preset rendering information and render the fourth preset rendering information using the loaded target container to obtain the fourth preset rendering information display.

[0153] Furthermore, the error isolation subunit is specifically configured as follows: based on a dual-layer protection mechanism, it captures the rendering execution exception; wherein, the dual-layer protection mechanism includes a JavaScript layer error handling system and a Native layer error handling system; in the case of capturing the dynamic card rendering execution exception, it stops the rendering of the abnormal dynamic card and isolates the execution environment of the abnormal dynamic card.

[0154] In this embodiment, the specific workflow is described as follows: When the card display device 100 is running, the modules work collaboratively: After the parallel processing module 110 receives a display request, its container loading unit and resource package acquisition unit immediately work in parallel. The status query subunit in the resource package acquisition unit first queries the local metadata index. If the cache is hit, the local reading subunit quickly acquires the resource package; if it is not hit, the cloud download subunit performs the download. Before downloading, the cloud download subunit notifies the storage management module 130 to perform storage space status checks and necessary LRU cleanup.

[0155] Once the parallel processing module 110 confirms that the target container and resource package are ready through internal coordination or event notification, it notifies the parsing and rendering module 120. The parsing and rendering module 120 then performs parsing and rendering operations. If an exception occurs at any stage of this process, detected internally by the module or discovered through a listener, control is transferred to the exception handling module 140. The exception handling module 140 assigns the appropriate processing unit to handle the exception based on its type. For example, if a rendering execution exception occurs, the rendering exception handling unit isolates the error, assesses its severity, and performs fallback rendering if deemed severe.

[0156] The state changes throughout the process can be tracked and managed by a central state machine (not shown in the figure, but can be considered part of device 100), ensuring that the logic of state transitions is clear and consistent. Through the above modular design, this virtual device embodiment fully implements all the technical solutions in the aforementioned method claims, achieving efficient and stable loading of dynamic cards.

[0157] It should be noted that the card display device provided in the above embodiments is only illustrated by the division of the above functional modules during rendering. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computer device can be divided into different functional modules to complete all or part of the functions described above. In addition, the card display method and the card display device embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0158] This application also provides a vehicle. Figure 6 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application.

[0159] Typically, vehicle 600 includes one or more processors 601 and one or more memories 602. Processor 601 may include one or more processing cores, such as a quad-core processor, a hexa-core processor, etc. Processor 601 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 601 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 601 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 601 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0160] The memory 602 may include one or more computer-readable storage media, which may be non-transitory. The memory 602 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 602 are used to store at least one computer program, which is executed by the processor 601 to implement the card display method provided in the method embodiments of this application.

[0161] Those skilled in the art will understand that Figure 6 The structure shown does not constitute a limitation on vehicle 600 and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0162] In addition, the device provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute a card display method provided in the above embodiments.

[0163] In this embodiment, the device or chip is used to execute the corresponding methods described above. Therefore, the beneficial effects it achieves can be referred to in the beneficial effects of the corresponding methods described above, and will not be repeated here. Through the description of the above embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0164] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

Claims

1. A card display method characterized by comprising: The method comprises: in response to a dynamic card display request in a target scene, loading a target container corresponding to the dynamic card, and simultaneously acquiring a resource package associated with the dynamic card; the loading of the target container corresponding to the dynamic card and the acquisition of the resource package associated with the dynamic card are performed in parallel; in the case where the target container is loaded and the resource package is acquired, processing the resource package; rendering the processed resource package through the loaded target container to display the dynamic card in the target scene; The method further comprises: in the case where the resource package is downloaded successfully and parsed successfully but the rendering execution is abnormal, in response to receiving a rendering execution abnormality through a bridge communication mechanism, performing error isolation on the dynamic card where the rendering execution abnormality occurs; in the case of performing error isolation, determining the severity of the execution abnormality; in the case where the degree of the execution abnormality is severe, acquiring fourth preset rendering information, the fourth preset rendering information being used to indicate that the dynamic card rendering execution is abnormal; rendering the fourth preset rendering information through the loaded target container to obtain fourth preset rendering information display; wherein the fourth preset rendering information display is used to indicate that the dynamic card is reloaded.

2. The method of claim 1, wherein, The acquisition of the resource package associated with the dynamic card comprises: in response to a dynamic card display request in a target scene, querying the state of a resource package associated with the dynamic card in a local storage space to determine the resource package storage state of the resource package; when the resource package storage state is present, reading the resource package; when the resource package storage state is not present, downloading the resource package from the cloud to acquire the resource package.

3. The method of claim 2, wherein, Before the resource package is downloaded from the cloud, the method further comprises: checking whether the local storage space reaches a preset threshold to determine a storage space state; when the storage space state reaches the preset threshold, cleaning the storage space according to the least recently used principle until the cleaned storage space does not reach the preset threshold; wherein the cleaned storage space is used to store the resource package downloaded from the cloud.

4. The method of claim 3, wherein, The cleaning of the local storage space according to the least recently used principle comprises: maintaining metadata information of all resource packages in the local storage space, the metadata information comprising last access time and storage time; according to the metadata information, identifying one or more old resource packages that are least recently used and / or whose storage time exceeds a preset period and cleaning the old resource packages.

5. The method of claim 2, wherein, The method further comprises: in the case where the resource package fails to be downloaded, acquiring first preset rendering information, the first preset rendering information being used to indicate that the resource package corresponding to the dynamic card display request fails to be downloaded; in the case where the target container is loaded, rendering the first preset rendering information through the target container.

6. The method of claim 1, wherein, The processing of the resource package in the case where the target container is loaded and the resource package is acquired comprises: The resource package is decompressed in a case that the target container loading is completed and the resource package acquisition is completed, and code files, layout files, style files and resource files in the resource package are obtained, wherein the code files are used to implement logic and dynamic behavior of the dynamic card; the layout files are used to define document layout of the dynamic card; the style files are used to define style rules of the dynamic card; and the resource files are used to define visual elements required by the dynamic card. A document object model and a cascading style sheet object model are generated based on the layout files and the style files. The document object model, the cascading style sheet object model, the code files and the resource files are taken as a processed resource package.

7. The method of claim 6, wherein, The processed resource package is rendered by the target container loaded completely, and the rendering includes: The code files are executed by the target container loaded completely based on the document object model and the cascading style sheet object model, and rendering instructions are generated. A user interface is drawn based on the rendering instructions and the resource files by the target container loaded completely, and the dynamic card in the target scene is displayed.

8. The method of claim 1, wherein, The method further includes: In a case that the resource package fails to be parsed, second preset rendering information is acquired, the second preset rendering information is used to indicate that the resource package corresponding to the dynamic card display request fails to be parsed; and in a case that the target container is loaded completely, the second preset rendering information is rendered by the target container. In a case that the dynamic card display request fails to be responded, third preset rendering information is acquired, the third preset rendering information is used to indicate that the dynamic card display request fails; and in a case that the target container is loaded completely, the third preset rendering information is rendered by the target container.

9. The method of claim 1, wherein, Error isolation is performed on the dynamic card in which the rendering execution exception occurs, and the error isolation includes: The rendering execution exception is captured based on a double-layer protection mechanism, wherein the double-layer protection mechanism includes a JavaScript layer error handling system and a Native layer error handling system. In a case that the dynamic card rendering execution exception is captured, rendering of the dynamic card in which the exception occurs is stopped, and an execution environment of the dynamic card in which the exception occurs is isolated.

Images