Page generation method and electronic equipment

Abstract

The invention provides a page generation method and electronic equipment, and relates to the technical field of intelligent interaction. The method comprises the steps of obtaining a function control instruction, and obtaining corresponding page content according to the function control instruction; creating an initial page, obtaining a preset bridging script, and injecting the bridging script into the page content; loading the page content injected with the bridging script to the initial page to obtain a loaded page; and obtaining current equipment function data, generating a function execution page based on the loaded page and the equipment function data, and performing visual display. According to the embodiment, the bridging script is injected into the page content, so that communication between the function execution page and the equipment function module is realized, a bridging code does not need to be written manually, and the stability and reliability of communication between the function execution page and a native code are improved. And meanwhile, the page content is dynamically generated according to the function control instruction, so that the flexibility of function control and the scene adaptation capability are improved.

Description

Technical Field

[0001] This application relates to the field of intelligent interactive technology, and in particular to a page generation method and an electronic device. Background Technology

[0002] With the rapid development of artificial intelligence (AI) technology, various intelligent interactive systems have been widely used in computer software, mobile terminals, smart devices and other fields. As a key carrier for user-device interaction, these intelligent interactive systems undertake functions such as function control and information display. Their ease of interaction and page adaptability directly affect the user experience.

[0003] In various intelligent interaction scenarios, users increasingly rely on convenient interaction methods such as voice to issue function control commands. Therefore, there is an urgent need for a technology that can understand user intentions through voice interaction and dynamically generate adapted interactive pages to realize function control and display of relevant information. Summary of the Invention

[0004] This application provides a page generation method and an electronic device for generating an interactive page that can adapt to user intent, enabling function control and display of relevant information.

[0005] In a first aspect, embodiments of this application provide a page generation method, including: Obtain function control commands, and retrieve the corresponding page content based on the function control commands; Create an initial page and obtain a preset bridging script, then inject the bridging script into the page content; The page content injected into the bridge script is loaded onto the initial page, resulting in the loaded page; Obtain current device function data, and based on the loaded page and device function data, generate a function execution page and display it visually.

[0006] Based on the above technical content, this application embodiment, after obtaining the function control instruction, can obtain the corresponding page content according to the function control instruction, without the need for a fixed static template. This improves the adaptability between the function execution page and the function control instruction, which is beneficial to meeting the diverse needs of users in controlling device functions and enhancing the flexibility and scenario adaptability of device control. After generating the page content, an initial page is created, and a preset bridging script is obtained. The bridging script is injected into the page content so that the initial page can stably load the bridging script, realizing communication between the function execution page and the native code, i.e., the device function module. There is no need to manually write bridging code, thus effectively reducing development difficulty and workload, reducing development costs and maintenance difficulty, while also reducing code redundancy and effectively avoiding logical loopholes that may occur when manually writing bridging code, improving the stability and reliability of communication between the function execution page and the native code. Then, the page content injected with the bridging script is loaded onto the initial page to obtain the loaded page. The system acquires current device function data and generates a function execution page based on the loaded page and device function data. This visualization integrates page content with current device function data, allowing users to intuitively perceive the device's operating status through the visualized function execution page. This provides data support for users to accurately control device functions in the future, ensuring the accuracy and security of device function control.

[0007] In one possible implementation, obtaining current device function data includes: Based on the bridging script, create an interaction global object; the interaction global object contains data request methods for obtaining device function data; Call the data request method in the global interaction object to send a data acquisition request to the corresponding device function module and obtain the current device function data.

[0008] In this embodiment, the current device function data can be obtained by calling the unified data request method provided by the interactive global object. This unifies the calling rules for data acquisition, realizes the standardization and unification of data requests, eliminates the need to manually write data acquisition code, and reduces the difficulty of page development and maintenance costs.

[0009] In one possible implementation, the data request method carries a device-defined application programming interface (API). Call the data request method in the global interaction object to send a data acquisition request to the corresponding device function module and obtain the current device function data, including: Verify the operation permissions corresponding to the device function application programming interface; If the verification passes, the device function application programming interface is called to initiate a data acquisition request to the corresponding device function module to obtain the current device function data.

[0010] Here, the operation permissions of the device function application programming interface carried by the data request method are verified to prevent data leakage and improve security. Additionally, it avoids sending unauthorized data acquisition requests to the device function module, reducing system resource consumption and improving system response speed.

[0011] In one possible implementation, an interaction global object is created based on the bridge script, including: Inject the bridging script again into the page after it has loaded; Create an interactive global object using the re-injected bridge script.

[0012] In this regard, the bridging script is injected again into the page after loading to ensure that the bridging function is available, which solves the problem of bridging script failure and improves stability.

[0013] In one possible implementation, after generating and visually displaying the function execution page based on the loaded page and device function data, the following steps are also included: Check if there are any device control operations on the function execution page; If a device control operation is detected on the function execution page, the corresponding functional logic is executed, and the displayed content of the function execution page is updated.

[0014] In this embodiment of the application, when a device control operation is detected on the function execution page, the function logic corresponding to the device control operation can be automatically executed based on the function execution page, and the device function data after the operation is executed can be updated and displayed synchronously, thereby improving the user interaction experience.

[0015] In one possible implementation, the interactive global object also contains execution operation methods for performing device control operations, and the execution operation methods carry the device function application programming interface; Execute the functional logic corresponding to the equipment control operations, including: Perform multiple verifications on the device's functional application programming interface; the multiple verifications include at least one of the following: permission verification, parameter range verification, operation step size limit verification, and dangerous operation confirmation verification. If the verification passes, the device function application programming interface is invoked to send an execution operation request to the corresponding device function module, so that the device function module executes the functional logic corresponding to the device control operation.

[0016] Based on the above technical content, when executing the functional logic corresponding to device control operations, permission verification and parameter range verification are performed on the device function application programming interface (API). This prevents invalid operation commands from entering the backend device function modules, reducing the processing pressure on the device function modules and improving their operational stability. Simultaneously, it also improves the compliance of the function execution page when calling the device function API via a bridge. Furthermore, by performing operation step size limit verification and dangerous operation confirmation verification on the device function API, it effectively avoids device function failures or security failures caused by misoperation, improving operational safety and reliability.

[0017] In one possible implementation, the corresponding page content is obtained based on the function control instructions, including: Determine the corresponding control intent based on the function control instructions; Based on the control intent, the corresponding device functional architecture and data interaction specifications are obtained from the preset knowledge base; the knowledge base stores the device functional architecture and data interaction specifications corresponding to different control intents. Generate page content based on the corresponding device functional architecture and data interaction specifications.

[0018] In this embodiment, page content is automatically generated based on function control instructions and a preset knowledge base, which improves the matching accuracy between page content and function control instructions, and also enables personalized display.

[0019] In one possible implementation, the method further includes, before injecting the bridging script into the page content: Obtain vehicle hardware information; Inject hardware information into the bridging script.

[0020] Here, in the in-vehicle intelligent cockpit scenario, since different vehicle models have different hardware capabilities, the vehicle's hardware information is dynamically detected and injected into the bridging script, giving the bridging script hardware awareness capabilities. It can adjust the functions and interaction logic of the function execution page according to the actual hardware information of the vehicle, thus realizing the dynamic adaptation between the function execution page and the vehicle's hardware capabilities.

[0021] In one possible implementation, the method further includes: Configure bridging, set up bidirectional communication, manage callbacks, and manage the lifecycle of bridging scripts; The bridging configuration includes permission whitelist configuration, security constraint level configuration, and hardware capability mapping configuration.

[0022] Specifically, by configuring the bridging scripts, the rules for function call permissions and security control are further refined, improving the security and reliability of the bridging configuration. Furthermore, bidirectional communication settings enable two-way communication between the function execution page and the device's functional modules. By managing callbacks and lifecycles of the bridging scripts, memory leaks and invalid callbacks are avoided, improving the stability and performance of the bridging scripts and reducing system resource overhead.

[0023] Secondly, embodiments of this application provide a page generation apparatus, including: The processing module is used to obtain function control instructions and, based on these instructions, to obtain the corresponding page content. The processing module is also used to create the initial page, obtain the preset bridging script, and inject the bridging script into the page content; The processing module is also used to load the page content injected with the bridge script onto the initial page to obtain the loaded page; The processing module is also used to obtain the current device function data, and based on the loaded page and device function data, generate a function execution page and display it visually.

[0024] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor. The memory stores a computer program that can run on the processor, and when the processor executes the computer program, it implements a page generation method as described in any of the first aspects.

[0025] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements a page generation method as described in any of the first aspects.

[0026] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here.

[0027] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

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

[0029] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application; Figure 2 This is a schematic flowchart of a page generation method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating a page generation method provided in another embodiment of this application; Figure 4 This is a schematic diagram of the structure of a page generation apparatus provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] The present application will be described more clearly below with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the function of the present application, but do not limit the present application in any way. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the present application. These all fall within the protection scope of the present application.

[0031] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0032] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0033] In the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0034] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0035] Furthermore, the term "multiple" mentioned in the embodiments of this application should be interpreted as two or more.

[0036] First, the terms used in the embodiments of this application will be explained: AI-Generated Web Page Protocol: A protocol that describes the content of World Wide Web (Web) pages in JSON format. The AI ​​system directly generates JSON data that conforms to this protocol, which contains the htmlContent field to store the complete HTML document. After local parsing, the complete web page can be rendered in WebView.

[0037] JavaScript Bridge (JSBridge): A mechanism to enable bidirectional communication between web pages and Android native code. It exposes native methods to JavaScript through the @JavascriptInterface annotation and calls JavaScript methods from native code through the evaluateJavascript method, thus bridging the gap between web pages and device functionality.

[0038] In various intelligent interaction scenarios, users are increasingly relying on convenient interaction methods such as voice to issue function control commands. For example, in the scenario of in-vehicle intelligent cockpit, users need to quickly generate vehicle control pages through voice commands to perform operations such as air conditioning adjustment and navigation settings; in the scenario of smart home, users expect voice commands to trigger home device status display pages to complete the linkage control of lights and curtains; in the scenario of desktop terminal, users also need to dynamically generate office software function pages based on voice commands to improve operating efficiency.

[0039] Therefore, there is an urgent need for a system that can understand user intent through voice interaction and dynamically generate an adapted interactive page. This interactive page can then be used to control functions and display relevant information, thereby meeting users' needs for the portability of intelligent interaction.

[0040] Here, due to the flexibility and wide adaptability of web page development, web pages can be used to host pages for function control and information display. However, research has found that there are certain limitations in the technologies related to intelligent interaction based on web pages, specifically as follows: In one related technology, an AI system can generate corresponding web pages based on static HTML templates. However, since static templates fix the page content and structure, they cannot meet the diverse needs of users to control device functions.

[0041] Another related technology can generate web pages by loading external Uniform Resource Locators (URLs). However, loading external URLs requires a network connection and cannot be used offline. In intelligent interaction scenarios, such as in-vehicle intelligent cockpits, offline use is often required. Therefore, generating web pages by loading external URLs cannot meet the needs of intelligent interaction. In addition, there are security risks introduced by external resources.

[0042] Furthermore, the generated web pages cannot directly operate device functions, requiring complex API calls and permission management, resulting in high integration costs. Additionally, communication between the generated web pages and device function modules requires developers to manually write JavaScript code, hindering automated function integration and reducing development efficiency.

[0043] Secondly, in intelligent interaction scenarios, the generated interactive pages need to be able to directly operate device functions, such as opening news lists, dashboard displays, and air conditioning adjustments. However, device functions need to be bound to the underlying device function application programming interface (API), which usually requires manually writing the integration logic with the device functions.

[0044] On the other hand, common web bridging solutions (such as Cordova, React Native WebView bridging, etc.) only provide a simple mechanism for JavaScript to call native methods. In intelligent interaction scenarios, corresponding bridging code needs to be written for each device function module, which results in high integration costs and difficult maintenance.

[0045] The applicant has discovered that, in order to generate interactive pages that adapt to user intent in intelligent interaction scenarios to control device functions and display relevant information, it is necessary to consider a new method for generating pages.

[0046] To enhance the adaptation of pages to user intent and to enable functional control and information display through pages, the embodiments of this application, upon obtaining a functional control instruction, generate corresponding page content based on that instruction. This eliminates the need for fixed static templates, improving the adaptation between the functional execution page and the functional control instruction. This facilitates meeting diverse user needs for device control and enhances the flexibility and scenario adaptability of device control. After generating page content, an initial page is created, and a preset bridging script is obtained. This bridging script is injected into the page content, enabling the initial page to stably load the bridging script. This facilitates communication between the functional execution page and the native code (device functional modules) without the need for manually writing bridging code. This effectively reduces development difficulty and workload, lowers development costs and maintenance complexity, reduces code redundancy, and avoids logical vulnerabilities that may arise from manually writing bridging code. This improves the stability and reliability of communication between the functional execution page and the native code. Finally, the page content injected with the bridging script is loaded onto the initial page, resulting in the loaded page. The system acquires current device function data and generates a function execution page based on the loaded page and device function data, then displays it visually. This integrates page content with device function data, allowing users to intuitively perceive the operating status of device functions through the visual function execution page. This provides data support for users to accurately control device functions in the future, ensuring the accuracy and security of device function control.

[0047] First refer to Figure 1 , Figure 1 The illustration shows an application scenario provided according to an embodiment of this application, which involves a page content generation layer, a rendering engine layer, a bridge manager, an atom manager, and a device function module.

[0048] The page generation layer generates corresponding page content based on function control instructions and sends the page content to the rendering engine layer. The rendering engine layer creates an initial page and then generates a function execution page based on the initial page, the bridging script, and the page content. The function execution page contains the current device function data, which is obtained by calling the device function API through the device function interaction interface and the atomic manager based on the bridging script.

[0049] The following is combined with Figure 1 Application scenarios, refer to Figures 2-3 This application describes a page generation method provided according to exemplary embodiments. It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way. Rather, the embodiments of this application can be applied to any applicable scenario.

[0050] It should be noted that the implementation methods of this application can be executed by different devices for different intelligent interaction scenarios.

[0051] In the context of in-vehicle smart cockpits, the implementation methods of this application can be applied to vehicles, which can be servers or vehicle hosts, and the page generation method provided by the exemplary implementation methods of this application can be executed on servers or vehicle hosts.

[0052] The server can be a monolithic server or a distributed server spanning multiple computers or computer data centers. Servers can also be of various categories, such as, but not limited to, web servers, application servers, database servers, or proxy servers.

[0053] Optionally, a server may include hardware, software, or embedded logic components for performing suitable functions supported or implemented by the server, or a combination of two or more such components. For example, a server may be a blade server, a cloud server, or a server group consisting of multiple servers, which may include one or more of the above-mentioned categories of servers, etc.

[0054] In smart home scenarios, the implementation methods of this application can be applied to smart home gateways or smart terminals, etc.

[0055] In desktop terminal interaction scenarios, the embodiments of this application can be applied to desktop computers, or processors of laptops, etc.

[0056] It should be noted that the page generation method provided according to the exemplary embodiments of this application can be executed on the same device or on different devices.

[0057] refer to Figure 2 , Figure 2 This is a schematic flowchart of a page generation method provided in an embodiment of this application. Figure 2 As shown, the method in the embodiments of this application may include: Step 201: Obtain function control instructions and get the corresponding page content based on the function control instructions.

[0058] In this system, function control commands are triggered by the user. In one implementation scenario, these commands are user voice commands. For example, in a smart in-vehicle cockpit, commands might include opening a news list, opening the front left window, or adjusting the driver's seat. In a smart home scenario, commands might include opening curtains or turning off lights. In a desktop terminal interaction scenario, commands might include opening a screenshot tool shortcut or opening a music playlist.

[0059] Page content is a collection of descriptive information used to construct subsequent functional execution pages. It defines the structure, style, interaction, and functional relationship logic of the functional execution pages. For example, if the functional execution page is a web page, then the page content is Hyper Text Markup Language (HTML) content.

[0060] Step 202: Create the initial page and obtain the preset bridging script, then inject the bridging script into the page content.

[0061] Taking a web page as the initial page as an example, web pages can be created using WebCardStrategy. After creating the initial page, you can also make corresponding settings, including but not limited to enabling JavaScript, setting the viewport, disabling zoom, etc. You can also set WebViewClient and WebChromeClient to handle page load events.

[0062] A bridging script is a pre-written, standardized script used to enable communication between a function execution page and native code, i.e., device function modules. Optionally, a bridging script may include logic for waiting for the native interface to be ready, code for creating interactive global objects, automatic initialization trigger mechanisms, etc.

[0063] The code for creating an interactive global object can be used to create such an object, which can provide functions such as `requestData` and `executeAction`. `requestData` is the data request method; calling `requestData` retrieves device function data. `executeAction` is the execution operation method for performing device control operations; calling `executeAction` executes these operations.

[0064] Taking the initial page as a web page as an example, a bridge script can be injected before or at the beginning of the HTML content using the injectBridgeScript method. This ensures that the interactive global object can be correctly initialized when the web page loads, enabling communication with the native code.

[0065] Step 203: Load the page content injected with the bridging script onto the initial page to obtain the loaded page.

[0066] Continuing with the example of an initial web page, optionally, the HTML content injected with the bridging script can be loaded onto the initial page using the loadDataWithBaseURL method, and the rendering process can be started to obtain the loaded page. Here, the loaded page can also be displayed visually.

[0067] Step 204: Obtain the current device function data, and based on the loaded page and device function data, generate a function execution page and display it visually.

[0068] Optionally, device function data can be obtained based on the requestData provided by the global interaction object. Device function data refers to the real-time status data of the device. Taking an in-vehicle smart cockpit scenario as an example, device function data includes window height, seat position, news list data, etc.

[0069] Optionally, after obtaining the device function data, the Document Object Model (DOM) of the loaded page can be automatically updated, the device function data rendered, and the page display automatically updated to obtain the final function execution page. The function execution page is an interactive page that can perform device control operations and display the current device functions.

[0070] Continuing with the example of an in-vehicle smart cockpit, the function execution page can be displayed through the vehicle's infotainment system. After displaying the function execution page, the user can interact with it to trigger corresponding device control operations, such as clicking the button to adjust the driver's seat forward. This will then execute the corresponding functional logic, enabling cockpit control. After the control is completed, the device function data can be retrieved to update the displayed content of the function execution page.

[0071] Here, the functional logic corresponding to the device control operation can be implemented based on the executeAction method provided by the aforementioned global interactive object.

[0072] In this embodiment, after obtaining the function control command, the corresponding page content can be obtained according to the function control command, without the need for a fixed static template. This improves the adaptability between the function execution page and the function control command, which is beneficial for meeting the diverse needs of users in controlling device functions and enhancing the flexibility and scenario adaptability of device control. After generating the page content, an initial page is created, and a preset bridging script is obtained. The bridging script is injected into the page content so that the initial page can stably load the bridging script, realizing communication between the function execution page and the native code, i.e., the device function module. There is no need to manually write bridging code, thus effectively reducing development difficulty and workload, reducing development costs and maintenance difficulty, while also reducing code redundancy and effectively avoiding logical loopholes that may occur when manually writing bridging code, improving the stability and reliability of communication between the function execution page and the native code. Then, the page content injected with the bridging script is loaded onto the initial page to obtain the loaded page. The system acquires current device function data and generates a function execution page based on the loaded page and the current device function data. This process integrates page content with device function data, allowing users to intuitively perceive the operating status of device functions through the visualized function execution page. This provides data support for users to accurately control device functions in the future, ensuring the accuracy and security of device function control.

[0073] In addition, this application embodiment injects the bridging script into the page content. It is also necessary to consider how to realize the communication between the function execution page and the device function module based on the bridging script. Furthermore, it is also necessary to consider how to execute the functional logic corresponding to the device control operation after the user triggers the device control operation based on the function execution page, so as to realize the device function control. Figure 3 This is a flowchart illustrating a page generation method provided in another embodiment of this application, such as... Figure 3 As shown, the method includes: Step 301: Obtain function control instructions; determine the corresponding control intent based on the function control instructions; obtain the corresponding device functional architecture and data interaction specifications from the preset knowledge base based on the control intent; wherein, the knowledge base stores the device functional architecture and data interaction specifications corresponding to different control intents; generate page content based on the corresponding device functional architecture and data interaction specifications.

[0074] Here, the knowledge base stores the device functional architecture and data interaction specifications corresponding to different control intentions. The device functional architecture includes, but is not limited to, the names of device functional modules and the Uniform Resource Identifier (URI) of device functional APIs. The data interaction specifications include, but are not limited to, parameter structures, return value formats, and field descriptions.

[0075] Taking the in-vehicle intelligent cockpit scenario as an example, the equipment functional modules include, but are not limited to, window control modules, seat adjustment modules, and air conditioning control modules.

[0076] The URI of a device function API, also known as an atomic capability URI, is used to represent the device function API that needs to be called. Its format can be packageName / interfaceName, for example, com.gwm.app.aicard / get_news_list. Here, since the API interfaces, calling methods, parameter structures, etc. of different device function modules are different, this embodiment bridges heterogeneous device function APIs through a unified URI format, eliminating the need to write different bridging code for each device function module.

[0077] The parameter structure refers to the parameter information required to call the device's function API. Taking the news list API as an example, its parameter structure includes, but is not limited to, the page number of the pagination and the starting data position.

[0078] The return value format refers to the format of the data returned after the device function API is called, including the field structure of the return value. For example, the field structure of the return value of the news list API interface is [{id, title, picUrl, source, url,ctime}].

[0079] Field descriptions are explanatory descriptions of fields, including but not limited to the meaning and purpose of each field.

[0080] Optionally, an AI system can determine the corresponding control intent based on the user's function control commands, and automatically query the knowledge base for matching device function modules based on the control intent, thereby obtaining the device function architecture and data interaction specifications of that module. The AI ​​system can then automatically generate corresponding page content based on this device function architecture and data interaction specifications. At this point, the fields displayed in the page content match the return value format of the device function module, avoiding display errors caused by field mismatches. The AI ​​system can then assemble the page content into the corresponding fields of the JSON data to form complete page protocol data.

[0081] Taking a web page as an example, the generated page content is HTML content. Based on the defined standardized AI-generated web page protocol, the AI ​​system can concatenate the HTML content into the htmlContent field of JSON data to form web page protocol data, i.e., JSON data, which contains a complete HTML document structure.

[0082] The complete HTML document structure includes DOCTYPE, html, head, and body tags. The AI-generated Web page protocol refers to describing Web page content in JSON format, including the complete HTML content stored in the htmlContent field, supporting the type: web identifier for Web type cards, and the description field for describing card functions.

[0083] The AI ​​system automatically includes JavaScript bridging code during page content generation. This code uses the `AICard.requestData(uri, callbackName)` method to call the device function API and the `AICard.executeAction(uri)` method to perform device control operations. Here, `uri` is the URI of the device function API, and `callbackName` is the name of the JavaScript callback function.

[0084] Furthermore, in related technologies, HTML fragments generated based on external resources cannot be run directly. However, this embodiment replaces static templates with a standardized AI-generated web page protocol, enabling the HTML content generated by the AI ​​system to contain the htmlContent field of a complete HTM document structure. Simultaneously, it includes inline Cascading Style Sheets (CSS) and JavaScript. After local parsing, the complete page can be rendered without relying on external resources, ensuring normal operation even in offline environments. This achieves dynamic rendering and real-time response, reducing response time from seconds to milliseconds, effectively improving the efficiency of web page generation and enabling real-time generation and updating of web pages.

[0085] In this embodiment, page content is automatically generated based on function control instructions and a preset knowledge base, which improves the matching accuracy between page content and function control instructions, and also enables personalized display.

[0086] Step 302: Create an initial page and obtain a preset bridging script, then inject the bridging script into the page content.

[0087] Taking a web page as an example, optionally, after the AI ​​system generates JSON data, it can send the JSON data to WebCardStrategy.createCard. After receiving the JSON data, WebCardStrategy.createCard parses the htmlContent field to obtain the HTML content.

[0088] In one implementation scenario, after the initial page is created, bridging can be initialized through the bridging manager, adding the device function interaction interface to the JavaScript interface of the initial page. This device function interaction interface serves as the entry point for subsequent function execution pages to call native device functions, and includes features such as data requests, operation execution, and logging.

[0089] Taking a web page as the initial page as an example, the bridge manager can initialize a JavaScript bridge using `webBridgeManager.initialize(cardContext)` to add the `WebAppInterface` to the JavaScript interface of the web page. `WebAppInterface` is the device function interaction interface, which can implement methods annotated with `@JavascriptInterface`, serving as the entry point for JavaScript to call native functions.

[0090] In some embodiments, for in-vehicle smart cockpit scenarios, before injecting the bridging script into the page content, the vehicle's hardware information can also be obtained and injected into the bridging script.

[0091] The vehicle's hardware information includes the current vehicle's hardware configuration data, such as the number of windows, screen size, whether it has rear seat heating, whether it supports a panoramic sunroof, whether it supports seat memory, and whether it supports dual-zone climate control.

[0092] In one implementation scenario, during bridging initialization, the current vehicle's hardware information can be queried via VehicleHardwareCapability.

[0093] Here, in the in-vehicle intelligent cockpit scenario, due to the different hardware capabilities of different vehicle models, the vehicle's hardware information is dynamically detected through a bridging mechanism and injected into the bridging script. This gives the bridging script hardware awareness capabilities, allowing it to adjust the functions and interaction logic of the function execution page according to the actual hardware information of the vehicle, thus achieving dynamic adaptation between the function execution page and the vehicle's hardware capabilities.

[0094] In some embodiments, the page generation method further includes: bridging configuration, bidirectional communication settings, callback management, and lifecycle management of the bridging script; wherein, the bridging configuration includes permission whitelist configuration, security constraint level configuration, and hardware capability mapping configuration.

[0095] The permission whitelist configuration configures a list of atomic capability URIs that are allowed to be invoked via bridging. If an invocation is made to a URI that is not in the permission whitelist, it will be rejected.

[0096] The security constraint level configuration is used to configure the bridged security constraint level. For example, the security constraint level can include strict or lenient. In strict mode, each operation needs to be checked for permissions and parameter range. In lenient mode, only dangerous operations can be checked.

[0097] Hardware capability mapping configuration configures the mapping relationship between hardware information and atomic capability URIs. When the hardware does not support a certain function, the corresponding URI call is automatically disabled.

[0098] Optionally, the bridging configuration may also include settings such as the native interface name, the name of the global interaction object, whether to enable automatic initialization, and whether to enable logging. The native interface name can default to AICardNative, and the global interaction object name can default to AICard. It should be noted that the bridging configuration can be customized according to actual needs.

[0099] Two-way communication configuration enables bidirectional communication between the function execution page and native code. Taking a web page as an example, this configuration supports JavaScript calling native methods (via @JavascriptInterface) and native code calling JavaScript methods (via evaluateJavascript) to achieve two-way communication.

[0100] In one implementation scenario, a proactive push mechanism for device status changes can be set up. When the device status changes, the native code can proactively call the status update function of the function execution page through `evaluateJavascript`. The function execution page can respond to device status changes in real time, achieving real-time synchronization of device status. This eliminates the need to manually write status listening and page update code, improving development efficiency and accuracy. Taking an in-vehicle smart cockpit scenario as an example, device status includes, but is not limited to, vehicle speed, engine speed, and window position.

[0101] Callback management refers to supporting JavaScript method calls with callbacks. The bridge manager manages the mapping relationship between callback IDs and callback interfaces through a callbackMap, ensuring that callbacks execute correctly. In one implementation scenario, a callback timeout mechanism can be set. When a callback exceeds a preset callback time threshold, the callback mapping can be automatically cleaned up to prevent memory leaks. The callback time threshold can be set according to actual needs, such as 5 seconds.

[0102] Lifecycle management refers to monitoring the device's lifecycle. Taking the in-vehicle smart cockpit scenario as an example, when the cockpit enters sleep mode or the vehicle is turned off, the bridge manager can automatically pause bridging communication to prevent device control operations from being performed when the vehicle is not running. Additionally, the bridge manager can automatically clean up bridging resources when a function execution page is destroyed to prevent memory leaks. Function execution page destruction can be achieved by simply closing the function execution page.

[0103] Here, a bridging manager enables unified management of bridging, including but not limited to JavaScript bridging initialization, bridging configuration, bidirectional communication settings, callback management, lifecycle management, and proactive push mechanisms for device status changes. Furthermore, the device function interaction interface serves as the entry point for JavaScript to call native functions, and a unified atomic capability URI mechanism bridges heterogeneous device function APIs, achieving automated bridging between function execution pages and device function modules, allowing operation of device functions without writing additional integration code.

[0104] Furthermore, by configuring the bridging scripts, the rules for function call permissions and security control are further refined, improving the security and reliability of the bridging configuration. In addition, bidirectional communication settings enable two-way communication between the function execution page and the device's functional modules. By managing callbacks and lifecycles of the bridging scripts, memory leaks and invalid callbacks are avoided, improving the stability and performance of the bridging scripts and reducing system resource overhead.

[0105] Step 303: Load the page content injected with the bridging script onto the initial page to obtain the loaded page.

[0106] For the implementation of step 303, please refer to [link / reference]. Figure 2 The relevant descriptions in the embodiments will not be repeated here.

[0107] Step 304: Based on the bridging script, create an interactive global object; the interactive global object contains data request methods for obtaining device function data.

[0108] The bridging script can contain code that creates an interactive global object. In one implementation scenario, the bridging script can automatically detect whether the native interface AICardNative is available. If it is available, it creates an interactive global object. The interactive global object can provide various methods such as requestData, executeAction, showToast, log, and openLargeCard for JavaScript bridging call code to call.

[0109] Here, requestData is the data request method, and executeAction is the operation execution method. The specific calling process of the two can be seen below, and will not be elaborated here.

[0110] The `showToast` method refers to the atomic manager displaying a Toast notification in native code upon receiving a message from the JavaScript bridge call. In one implementation scenario, the display duration and position of the Toast notification can be optimized to prevent it from obscuring important information.

[0111] The `log` method refers to the atomic manager recording logs in the native code upon receiving logs passed from the JavaScript bridge call code. In one implementation scenario, for in-vehicle smart cockpits, an operation audit log can be added to record device control operations performed through the bridge, facilitating problem tracing.

[0112] The `openLargeCard` method triggers the opening of a large card, implemented through the `CardContext` callback interface. In one implementation scenario, specifically for in-vehicle smart cockpits, it supports full-screen display of the large card and hardware button adaptation.

[0113] Optionally, the bridging script can support an automatic initialization trigger mechanism. Taking a web page as an example, if the `window.onAICardReady` function is defined in the HTML content, the bridging script will automatically call this function after the interactive global object is created, triggering the page initialization logic to obtain the current device function data and automatically render it, without the need to manually write code to obtain the data.

[0114] In another implementation scenario, if the window.onAICardReady function is not triggered within a preset time period, the page initialization logic is also executed once in a normal browser environment to ensure that the preview function in the non-bridging environment can display the current device function data.

[0115] In some embodiments, creating an interaction global object based on a bridging script includes: re-injecting the bridging script into the loaded page; and using the re-injected bridging script to create the interaction global object.

[0116] Optionally, in the onPageFinished callback, the bridge script can be injected again using the injectBridgeScriptAfterPageLoad method to ensure that the bridging function is available. An interactive global object is then created based on the re-injected bridge script. After the interactive global object is created, the window.onAICardReady function is called to trigger the page initialization logic. The specific process can be referred to the above, and will not be elaborated here.

[0117] Here, the bridging script is injected again into the page after loading to ensure that the bridging function is available, which solves the problem of bridging script failure and improves stability.

[0118] Step 305: Call the data request method in the interactive global object to send a data acquisition request to the corresponding device function module and obtain the current device function data.

[0119] Optionally, the JavaScript bridging code within the page content can call the `requestData` method, i.e., `AICard.requestData(uri, callbackName)`, to send a data retrieval request to the device function interaction interface. This request carries the URI of the device function API and the callback function name. The device function interaction interface then sends the data retrieval request to the AtomicManager, which can call `AtomicManager.addRequestListData` to retrieve the corresponding device function data.

[0120] In this embodiment, the current device function data can be obtained by calling the unified data request method provided by the interactive global object. This unifies the calling rules for data acquisition, realizes the standardization and unification of data requests, eliminates the need to manually write data acquisition code, and reduces the difficulty of page development and maintenance costs.

[0121] In one possible implementation, the data request method carries a device function application programming interface (API); it calls the data request method in the interaction global object to initiate a data acquisition request to the corresponding device function module to obtain the current device function data, including: verifying the operation permission corresponding to the device function API; if the verification passes, it calls the device function API to initiate a data acquisition request to the corresponding device function module to obtain the current device function data.

[0122] Here, before the AtomicManager calls AtomicManager.addRequestListData, the BridgeSecurityValidator can be used to verify the permissions corresponding to the device function API URI in the received data acquisition request, such as vehicle.read.WINDOW.

[0123] Optionally, when performing permission verification on a URI, it can be based on a permission whitelist. Specifically, if the URI is in the permission whitelist, the call is allowed, and the permission verification passes. If the URI is not in the permission whitelist, the call is denied, and the permission verification fails.

[0124] In one implementation scenario, once the URI's authorization is verified, device function data can be requested. After the device function data is returned, a JavaScript callback function can be invoked via `evaluateJavascript` to pass the data to the loaded page for automatic page updates. The data passed to the loaded page can be in JSON array format.

[0125] In another implementation scenario, if the URI permission verification fails, an error message is returned via a callback function, and the page automatically displays an insufficient permission message after loading. Alternatively, if a device function data request fails or returns empty data, the JavaScript bridge call code can automatically display an error message or an empty status to improve the user experience.

[0126] Here, the operation permissions of the device function application programming interface carried by the data request method are verified to prevent data leakage and improve security. In addition, it also avoids sending unauthorized data acquisition requests to the device function module, reducing system resource consumption and improving system response speed.

[0127] Step 306: Based on the loaded page and the current device function data, generate a function execution page and display it visually.

[0128] For the implementation of step 306, please refer to [link / reference]. Figure 2 The relevant descriptions in the embodiments will not be repeated here.

[0129] Step 307: Detect whether there is a device control operation on the function execution page; if a device control operation is detected on the function execution page, execute the functional logic corresponding to the device control operation and update the display content of the function execution page.

[0130] In this context, device control operations can be triggered by user interactions such as clicking and inputting on the function execution page. Taking an in-vehicle smart cockpit scenario as an example, the function execution page corresponds to seat adjustment. Before the user triggers a device control operation, the function execution page displays the current seat angle. After the user clicks the seat adjustment button, the current seat angle can be adjusted based on the function execution page, and the adjusted seat angle is updated on the function execution page after the adjustment is complete.

[0131] Here, in this embodiment of the application, when a device control operation is detected on the function execution page, the function logic corresponding to the device control operation can be automatically executed based on the function execution page, and the device function data after the operation is executed can be updated and displayed synchronously, thereby improving the user interaction experience.

[0132] In some embodiments, the interactive global object further includes an execution operation method for performing device control operations. The execution operation method carries a device function application programming interface (API). Executing the functional logic corresponding to the device control operation includes: performing multiple verifications on the device function API; the multiple verifications include at least one of permission verification, parameter range verification, operation step size limit verification, and dangerous operation confirmation verification; if the verification passes, the device function API is invoked to send an execution operation request to the corresponding device function module, so that the device function module executes the functional logic corresponding to the device control operation.

[0133] Specifically, the JavaScript bridge call code invokes the `AICard.executeAction(uri)` method in the global interaction object to send an execution operation request to the device function interaction interface. This execution operation request carries the URI of the device function API. The device function interaction interface then sends the execution operation request to the Atomic Manager. After receiving the execution operation request, the Atomic Manager can perform multiple validations on the URI carried by the execution operation request through `BridgeSecurityValidator`.

[0134] The JavaScript bridging call code can construct an atomic capability URI with parameters using the buildAtomicUri function, and supports the concatenation of multiple parameters, such as com.gwm.app.aicard / read_news_detail?url=xxx, where xxx represents the parameters concatenated in the URI.

[0135] In one implementation scenario, if multiple checks pass, the Atomic Manager can call `AtomicManager.doActionCall` to cause the corresponding device function module to perform the appropriate operation. Here, by using the execution operation method in the global interaction object, when a device control operation is detected on the function execution page, the corresponding device function API can be automatically called to perform the corresponding operation, thus automating the interaction operation without the need to manually write the execution operation code.

[0136] In some embodiments, after an operation is performed, operation feedback can be displayed via AICard.showToast, and operation logs can be recorded via AICard.log.

[0137] In some embodiments, the large card can also be opened via AICard.openLargeCard to enable page navigation.

[0138] Here, multiple verifications are performed on the device function API, that is, the URI of the device function API is verified. These multiple verifications include at least one of the following: permission verification, parameter range verification, operation step size limit verification, and dangerous operation confirmation verification.

[0139] Permission verification checks the permissions corresponding to a URI. If the URI has the appropriate permissions, the corresponding operation is executed. For example, controlling car windows requires the `vehicle.control.WINDOW` permission. In one implementation scenario, the current device status can be obtained to determine whether the URI has the corresponding permissions under that device status.

[0140] Parameter range validation refers to checking whether the operation parameters carried by the URI are within a preset range based on the URI type. For example, the preset range for the window position value is 0-100, and the preset range for the seat angle is -30°-30°. If the operation parameter exceeds the preset range, the operation will be rejected.

[0141] Operation step size limit verification is used for continuous operations to verify the step size of a single operation. For example, for adjusting a car window, the maximum change step size is less than or equal to 5%, thereby preventing rapid changes caused by accidental operation.

[0142] Dangerous operation confirmation verification refers to checking whether prior confirmation is required in the URI configuration for dangerous operations. If confirmation is required, a confirmation dialog box will pop up through CardContext. After the user confirms, the corresponding operation can be executed without returning a value. Dangerous operations include, but are not limited to, child lock unlocking and emergency braking.

[0143] Based on the above technical content, when executing the functional logic corresponding to device control operations, permission verification and parameter range verification are performed on the device function application programming interface (API). This prevents invalid operation commands from entering the backend device function module, reduces the processing pressure on the device function module, and helps improve the operational stability of the device function module. Simultaneously, it also improves the compliance of the function execution page when calling the device function API through bridging. Furthermore, operation step size limit verification and dangerous operation confirmation verification are performed on the device function application programming interface (API), effectively preventing device function failures or security failures caused by misoperation, thus improving the safety and reliability of operations.

[0144] In this embodiment, the knowledge base stores the device functional architecture and data interaction specifications corresponding to different control intentions. When generating page content, the knowledge base can be automatically queried to obtain the corresponding device functional architecture and data interaction specifications. Based on these specifications, page content is automatically generated, eliminating the need for fixed static templates and improving the matching accuracy between page content and functional control instructions. Personalized display is also achieved. Then, an initial page is created, and a preset bridging script is obtained. The bridging script is automatically injected into the page content to ensure that the interactive global object is correctly initialized when the initial page loads, enabling communication with the native code. This eliminates the need for manually writing bridging code, effectively reducing development difficulty and workload, lowering development costs and maintenance complexity, reducing code redundancy, and effectively avoiding logical vulnerabilities that may occur with manually written bridging code. This improves the stability and reliability of communication between the function execution page and the native code. Next, the page content injected with the bridging script is loaded onto the initial page, resulting in the loaded page. Based on the bridging script, an interactive global object is created. The current device functional data is obtained using the data request method provided by the interactive global object. Based on the loaded page and the current device functional data, a function execution page is generated and displayed visually. When a device control operation is detected on the function execution page, the corresponding functional logic is executed to control the device and update the displayed content of the function execution page, thus improving the user's interactive experience.

[0145] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0146] Figure 4 This is a schematic diagram of the structure of a page generation apparatus provided in an embodiment of this application. For example... Figure 4 As shown, the page generation device provided in this embodiment may include: a processing module 401.

[0147] The processing module 401 is used to obtain function control instructions and get the corresponding page content according to the function control instructions. The processing module 401 is also used to create an initial page, obtain a preset bridging script, and inject the bridging script into the page content; Processing module 401 is also used to load the page content injected with the bridging script onto the initial page to obtain the loaded page; The processing module 401 is also used to obtain the current device function data, and based on the loaded page and device function data, generate a function execution page and display it visually.

[0148] In one possible implementation, processing module 401 is specifically used for: Based on the bridging script, create an interaction global object; the interaction global object contains data request methods for obtaining device function data; Call the data request method in the global interaction object to send a data acquisition request to the corresponding device function module and obtain the current device function data.

[0149] In one possible implementation, the data request method carries a device functionality application programming interface; the processing module 401 is specifically used for: Verify the operation permissions corresponding to the device function application programming interface; If the verification passes, the device function application programming interface is called to initiate a data acquisition request to the corresponding device function module to obtain the current device function data.

[0150] In one possible implementation, processing module 401 is specifically used for: Inject the bridging script again into the page after it has loaded; Create an interactive global object using the re-injected bridge script.

[0151] In one possible implementation, processing module 401 is further configured to: Check if there are any device control operations on the function execution page; If a device control operation is detected on the function execution page, the corresponding functional logic is executed, and the displayed content of the function execution page is updated.

[0152] In one possible implementation, the interactive global object also includes execution operation methods for performing device control operations, and these execution operation methods carry device function application programming interfaces; the processing module 401 is specifically used for: Perform multiple verifications on the device's functional application programming interface; the multiple verifications include at least one of the following: permission verification, parameter range verification, operation step size limit verification, and dangerous operation confirmation verification. If the verification passes, the device function application programming interface is invoked to send an execution operation request to the corresponding device function module, so that the device function module executes the functional logic corresponding to the device control operation.

[0153] In one possible implementation, processing module 401 is specifically used for: Determine the corresponding control intent based on the function control instructions; Based on the control intent, the corresponding device functional architecture and data interaction specifications are obtained from the preset knowledge base; the knowledge base stores the device functional architecture and data interaction specifications corresponding to different control intents. Generate page content based on the corresponding device functional architecture and data interaction specifications.

[0154] In one possible implementation, processing module 401 is further configured to: Obtain vehicle hardware information; Inject hardware information into the bridging script.

[0155] In one possible implementation, processing module 401 is further configured to: Configure bridging, set up bidirectional communication, manage callbacks, and manage the lifecycle of bridging scripts; The bridging configuration includes permission whitelist configuration, security constraint level configuration, and hardware capability mapping configuration.

[0156] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0157] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 5 As shown, the electronic device 500 of this embodiment includes a processor 510 and a memory 520, wherein the memory 520 stores a computer program 521 that can run on the processor 510. When the processor 510 executes the computer program 521, it implements the steps in any of the above-described method embodiments, for example... Figure 2 Steps 201 to 204 are shown. Alternatively, when processor 510 executes computer program 521, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 4 The function of module 401 shown.

[0158] For example, computer program 521 may be divided into one or more modules / units, one or more of which are stored in memory 520 and executed by processor 510 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 521 in electronic device 500.

[0159] Those skilled in the art will understand that Figure 5 This is merely an example of an electronic device and does not constitute a limitation on the electronic device. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, buses, etc.

[0160] The processor 510 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0161] The memory 520 can be an internal storage unit of the electronic device, such as a hard drive or memory, or an external storage device, such as a plug-in hard drive, SmartMedia Card (SMC), Secure Digital (SD) card, or Flash Card. The memory 520 can also include both internal and external storage units. The memory 520 is used to store computer programs and other programs and data required by the electronic device. The memory 520 can also be used to temporarily store data that has been output or will be output.

[0162] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0163] An embodiment of this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the page generation method described above.

[0164] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0165] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0166] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device 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 system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0167] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0168] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0169] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0170] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A page generation method, characterized in that, include: Obtain function control instructions, and obtain the corresponding page content based on the function control instructions; Create an initial page and obtain a preset bridging script, then inject the bridging script into the page content; The page content injected into the bridging script is loaded onto the initial page to obtain the loaded page; Obtain the current device function data, and based on the loaded page and the device function data, generate a function execution page and display it visually.

2. The page generation method according to claim 1, characterized in that, The process of obtaining current device function data includes: Based on the bridging script, an interaction global object is created; the interaction global object contains data request methods for obtaining device function data; The data request method in the global interaction object is invoked to send a data acquisition request to the corresponding device function module and obtain the current device function data.

3. The page generation method according to claim 2, characterized in that, The data request method carries a device function application programming interface; The step of invoking the data request method in the global interaction object to initiate a data acquisition request to the corresponding device function module and obtain the current device function data includes: Verify the operation permissions corresponding to the application programming interface of the device function; If the verification passes, the device function application programming interface is invoked to send a data acquisition request to the corresponding device function module to obtain the current device function data.

4. The page generation method according to claim 2, characterized in that, The creation of an interactive global object based on the bridging script includes: The bridging script is injected again into the loaded page; The interactive global object is created using the re-injected bridging script.

5. The page generation method according to any one of claims 2 to 4, characterized in that, After generating and visually displaying the function execution page based on the loaded page and the device function data, the method further includes: Detect whether there is a device control operation on the function execution page; If a device control operation is detected on the function execution page, the functional logic corresponding to the device control operation is executed, and the display content of the function execution page is updated.

6. The page generation method according to claim 5, characterized in that, The interactive global object also includes execution operation methods for performing device control operations, and the execution operation methods carry device function application programming interfaces; The execution of the functional logic corresponding to the device control operation includes: The device's functional application programming interface is subjected to multiple verifications; the multiple verifications include at least one of permission verification, parameter range verification, operation step size limit verification, and dangerous operation confirmation verification. If the verification passes, the device function application programming interface is invoked to send an execution operation request to the corresponding device function module, so that the device function module executes the functional logic corresponding to the device control operation.

7. The page generation method according to any one of claims 1 to 4, characterized in that, The step of obtaining the corresponding page content according to the function control instruction includes: Based on the function control instructions, determine the corresponding control intent; Based on the control intent, the corresponding device functional architecture and data interaction specifications are obtained from a preset knowledge base; wherein, the knowledge base stores the device functional architecture and data interaction specifications corresponding to different control intents; The page content is generated based on the corresponding device functional architecture and data interaction specifications.

8. The page generation method according to any one of claims 1 to 4, characterized in that, Before injecting the bridging script into the page content, the method further includes: Obtain vehicle hardware information; The hardware information is injected into the bridging script.

9. The page generation method according to claim 8, characterized in that, The method further includes: The bridging script is configured for bridging, bidirectional communication is set up, callbacks are managed, and its lifecycle is managed. The bridging configuration includes permission whitelist configuration, security constraint level configuration, and hardware capability mapping configuration.

10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the page generation method as described in any one of claims 1 to 9.

Images