Method of operating a functional assembly and related device

Abstract

This application discloses a method for operating a functional component and related equipment. The method may include: receiving a call request for a target function initiated by the functional component; obtaining the operating environment information of the electronic device; determining whether the electronic device has an interface module file corresponding to the target function and matching the operating environment information; if the electronic device does not have an interface module file, sending a download request to a server; the download request includes a target native bridging packet identifier corresponding to the target function and the operating environment information; receiving a download response from the server; the download response includes an interface module file matching the target native bridging packet identifier corresponding to the target function and the operating environment information; and loading and registering the interface module file by a container running the functional component, so that the functional component can call the target function through the interface module file. This application can effectively save storage space resources of electronic devices.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for operating a functional component and related equipment. Background Technology

[0002] With the rapid development of artificial intelligence (AI) technology, desktop widgets generated through AI dialogue are emerging as an application model. Currently, the React Native framework is typically used as the foundation for code generation and execution. Its cross-platform capabilities allow generated desktop widgets to adapt to different platforms, thereby reducing multi-platform development costs. React Native is a cross-platform mobile application development framework based on JavaScript (a scripting programming language). It uses JavaScript code to call native components to achieve interface rendering and functional interaction. Its core principle is to achieve communication between JavaScript and the native system through the JS Bridge (JavaScript bridging layer).

[0003] In actual operation, when desktop widgets need to access hardware sensors or call specific system application programming interfaces (APIs), the JavaScript layer of the React Native framework relies on native bridging packages pre-integrated in the platform application to complete the interaction with the native system. To support diverse application scenarios, platform applications often need to pre-integrate a large number of native bridging packages to handle unknown functional requirements. However, pre-integrating a large number of native bridging packages leads to a continuous increase in the size of the platform application's installation package, occupying valuable storage space on the user's device and causing inconvenience. Summary of the Invention

[0004] This application provides a method for operating a functional component and related equipment, which can effectively save storage space resources of electronic devices.

[0005] In a first aspect, embodiments of this application provide a method for operating a functional component, applied to an electronic device. The method includes: receiving a call request initiated by the functional component for a target function; obtaining operating environment information of the electronic device; determining whether the electronic device possesses an interface module file corresponding to the target function and matching the operating environment information; if the electronic device does not possess an interface module file, sending a download request to a server; the download request includes a target native bridging packet identifier corresponding to the target function and operating environment information; receiving a download response from the server; the download response includes an interface module file matching the target native bridging packet identifier corresponding to the target function and the operating environment information; and loading and registering the interface module file by a container running the functional component, so that the functional component can call the target function through the interface module file.

[0006] As can be seen, by receiving call requests from functional components, checking for the existence of matching interface module files locally, and dynamically downloading and loading them from the server when missing, on-demand acquisition and dynamic integration of native interface functions are achieved. This avoids unnecessary expansion of the platform application size and significantly saves storage space on electronic devices.

[0007] In one possible implementation, the above method further includes: extracting the module name corresponding to the target function from the import statement in the component code file of the functional component; and determining the target native bridging package identifier corresponding to the module name based on a preset mapping relationship.

[0008] As can be seen, by automatically extracting the module name from the import statement of the component code and determining the corresponding native bridging package identifier based on the mapping relationship, the accurate identification of missing functions is achieved.

[0009] In one possible implementation, the aforementioned functional component is a desktop widget; the aforementioned container is a widget container for managing desktop widgets; the method further includes: receiving user requirement description information; generating a widget installation package based on the requirement description information using artificial intelligence; and applying the widget installation package to the widget container to obtain a desktop widget.

[0010] It is evident that by combining AI with the ability to generate desktop widgets, users can obtain personalized widgets simply by describing them in natural language.

[0011] In one possible implementation, the method further includes: receiving a test call request for a test function initiated by a functional component; obtaining the operating environment information of the electronic device; sending a test download request to a server; the test download request includes the target native bridging packet identifier corresponding to the test function and the operating environment information; receiving a test download response from the server; the test download response includes a test interface module file that matches the target native bridging packet identifier and the operating environment information corresponding to the test function; and having the container running the functional component load and register the test interface module file so that the functional component can call the test function through the test interface module file.

[0012] As can be seen, functional components can be verified by downloading test interface module files before actual use. This helps to identify compatibility or missing functionality issues in advance, avoids call failures in real-world use cases, and improves the operational stability of functional components and user experience.

[0013] In one possible implementation, the above method further includes: upon receiving a download failure notification from the server, generating an automatic interface module file corresponding to the target function based on the call request and runtime environment information of the target function using artificial intelligence; the download failure notification is used to indicate that there is no target native bridging package corresponding to the target function; the container running the functional component loads and registers the automatic interface module file so that the functional component calls the target function through the automatic interface module file.

[0014] As can be seen, even when the corresponding native bridging package is not available on the server side, AI can be used to automatically generate interface module files. This avoids the problem of functional unavailability caused by the lack of a native bridging package, and significantly enhances the adaptability and functional coverage of functional components.

[0015] In one possible implementation, the method further includes: receiving a call request for the dot matrix screen initiated by a functional component; obtaining the operating environment information of the electronic device; generating a corresponding interface module file for the dot matrix screen based on the call request and operating environment information of the dot matrix screen using artificial intelligence; and having the container running the functional component load and register the interface module file so that the functional component can call the dot matrix screen through the interface module file.

[0016] As can be seen, for special hardware scenarios such as dot matrix screens, AI can be used to dynamically generate adapter module files, enabling instant adaptation to non-standard or emerging hardware devices.

[0017] In one possible implementation, the method further includes: receiving a call request from a functional component for multiple target functions; obtaining the operating environment information of the electronic device; determining multiple target native bridging packet identifiers corresponding to the multiple target functions; based on the multiple target native bridging packet identifiers and the operating environment information, obtaining multiple interface module files corresponding to the multiple target functions respectively, and determining the loading order of the multiple interface module files; performing verification processing on the multiple interface module files; and, if the multiple interface module files pass the verification processing, loading and registering the multiple interface module files by the container running the functional component in the loading order, so that the functional component can call the multiple target functions through the multiple interface module files respectively.

[0018] As can be seen, by batch acquisition, sequential loading, and unified verification of multiple interface module files, the dependencies of multiple target function calls can be ensured to be correct and the loading process to be orderly.

[0019] Secondly, embodiments of this application provide another method for operating a functional component, applied to a server. The method includes: receiving a download request from an electronic device; the download request includes a target native bridging packet identifier corresponding to the target function and runtime environment information; extracting the target native bridging packet corresponding to the target function based on the target native bridging packet identifier and runtime environment information; compiling the target native bridging packet corresponding to the target function to obtain an interface module file corresponding to the target function; and sending a download response to the electronic device; the download response includes an interface module file that matches the target native bridging packet identifier and runtime environment information corresponding to the target function.

[0020] As can be seen, a precise extraction, compilation, and distribution mechanism based on request parameters (native bridging package identifier + runtime environment information) is implemented on the server side. By pre-compiling the native bridging package into platform-adapted interface module files, the server can efficiently respond to clients' on-demand download requests, ensuring the functional integrity and platform compatibility of the distributed files.

[0021] Thirdly, embodiments of this application provide an operating apparatus for a functional component, which includes a transceiver unit and a processing unit. The transceiver unit is used to receive a call request initiated by the functional component for a target function. The processing unit is used to obtain the operating environment information of the electronic device and determine whether the electronic device has an interface module file corresponding to the target function and matching the operating environment information. The transceiver unit is further used to send a download request to a server when the electronic device does not have an interface module file; the download request includes a target native bridging packet identifier corresponding to the target function and the operating environment information; and to receive a download response from the server; the download response includes an interface module file matching the target native bridging packet identifier corresponding to the target function and the operating environment information. The processing unit is further used to load and register the interface module file by a container running the functional component, so that the functional component can call the target function through the interface module file.

[0022] In one possible implementation, the processing unit is further configured to extract the module name corresponding to the target function from the import statement in the component code file of the functional component; and determine the target native bridging package identifier corresponding to the module name based on a preset mapping relationship.

[0023] In one possible implementation, the aforementioned functional component is a desktop widget; the aforementioned container is a widget container used to manage the desktop widget. The transceiver unit is further configured to receive user request description information. The processing unit is further configured to generate a widget installation package based on the request description information using artificial intelligence, and apply the widget installation package to the widget container to obtain the desktop widget.

[0024] In one possible implementation, the transceiver unit is further configured to receive test call requests for test functions initiated by functional components. The processing unit is further configured to obtain the operating environment information of the electronic device. The transceiver unit is further configured to send a test download request to the server; the test download request includes the target native bridging packet identifier corresponding to the test function and the operating environment information; and receive a test download response from the server; the test download response includes a test interface module file that matches the target native bridging packet identifier and the operating environment information corresponding to the test function. The processing unit is further configured to load and register the test interface module file by the container running the functional component, so that the functional component can call the test function through the test interface module file.

[0025] In one possible implementation, the processing unit is further configured to, upon receiving a download failure notification from the server, generate an automatic interface module file corresponding to the target function based on the call request for the target function and runtime environment information using artificial intelligence; the download failure notification is used to indicate that there is no target native bridging package corresponding to the target function; the automatic interface module file is loaded and registered by the container running the functional component, so that the functional component can call the target function through the automatic interface module file.

[0026] In one possible implementation, the transceiver unit is further configured to receive a call request for the dot matrix screen initiated by a functional component. The processing unit is further configured to obtain the operating environment information of the electronic device; generate a corresponding interface module file for the dot matrix screen based on the call request and operating environment information using artificial intelligence; and load and register the interface module file by the container running the functional component, so that the functional component can call the dot matrix screen through the interface module file.

[0027] In one possible implementation, the transceiver unit is further configured to receive call requests for multiple target functions initiated by functional components. The processing unit is further configured to: acquire the operating environment information of the electronic device; determine multiple target native bridging packet identifiers corresponding to the multiple target functions; based on the multiple target native bridging packet identifiers and the operating environment information, acquire multiple interface module files corresponding to the multiple target functions, and determine the loading order of the multiple interface module files; perform verification processing on the multiple interface module files; and, if all multiple interface module files pass the verification processing, load and register the multiple interface module files in the loading order by the container running the functional components, so that the functional components can call the multiple target functions through the multiple interface module files respectively.

[0028] Fourthly, embodiments of this application provide another operating apparatus for a functional component, which includes a transceiver unit and a processing unit. The transceiver unit is used to receive a download request from an electronic device; the download request includes a target native bridging packet identifier corresponding to the target function and runtime environment information. The processing unit is further used to extract the target native bridging packet corresponding to the target function based on the target native bridging packet identifier and runtime environment information; and to compile the target native bridging packet to obtain an interface module file corresponding to the target function. The transceiver unit is used to send a download response to the electronic device; the download response includes an interface module file that matches the target native bridging packet identifier and runtime environment information corresponding to the target function.

[0029] Fifthly, embodiments of this application provide a computer device, the computer device comprising: a memory for storing a program; and a processor for executing the program stored in the memory. When the program is executed by the processor, the processor executes a method as described in the first aspect and any possible implementation of the first aspect, or executes a method as described in the second aspect and any possible implementation of the second aspect.

[0030] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, allow the processor to perform a method as described in the first aspect and any possible implementation thereof, or to perform a method as described in the second aspect and any possible implementation thereof. Attached Figure Description

[0031] Figure 1 A schematic diagram of a system architecture provided for an embodiment of this application; Figure 2 A flowchart illustrating a method for operating a functional component according to an embodiment of this application; Figure 3 A schematic diagram of the structure of a functional component operating device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0032] The embodiments of this application will now be described with reference to the accompanying drawings.

[0033] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0034] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0035] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0036] As used in this specification, the terms "component," "module," "system," etc., are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process and / or an execution thread, and components may be located on a single computer and / or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0037] With the rapid development of artificial intelligence technology, the application scenarios of AI-generated desktop widgets are becoming increasingly widespread. Among them, desktop widgets (also known as desktop components or desktop widgets) are lightweight platform application components that run on the desktop or negative one screen of electronic devices, providing users with convenient information display and quick operation access without requiring users to open the full platform application.

[0038] In related technologies, AI-generated desktop widgets are typically implemented using React Native technology. This involves interacting with AI on a webpage, where the AI ​​uses React Native to write corresponding code, thereby generating the desired desktop widget. This approach relies to some extent on the cross-platform capabilities of the React Native framework, but it has inherent limitations in native function calls and system-level interactions.

[0039] For example, when a user needs a desktop widget to access the hardware sensors of an electronic device (such as a camera, gyroscope, accelerometer, etc.) or to call specific system APIs (such as notification permission management, background task scheduling, Bluetooth communication, etc.), the JavaScript layer of the React Native framework needs to communicate with the underlying native system using native bridging packages. To support the infinitely rich application scenarios of desktop widgets, platform applications need to pre-integrate a large number of native bridging packages to cover all kinds of native functions that may be called.

[0040] However, an excessive number of native bridging packages can cause platform applications to continuously expand in size, consuming valuable storage space on user devices. Furthermore, in real-world usage scenarios, users may only utilize the functions corresponding to one or two native bridging packages, leaving a large number of pre-built native bridging packages unused, resulting in ineffective use of storage resources. Additionally, when a user generates a new desktop widget using AI, and this widget requires access to a system capability that the platform application does not yet have a pre-built native bridging package for, the widget will fail to function properly due to the lack of necessary native interfaces. Users must wait for the platform application to release a new version and complete an update before gaining support for this native capability, a process that often takes weeks or even longer, severely impacting user experience and the immediate availability of desktop widgets.

[0041] In view of this, embodiments of this application provide a method for operating a functional component and related equipment. The code of the native bridging package is extracted from the platform application, compiled into a platform-adapted interface module file, and stored on the server. During operation, the platform application dynamically requests the download from the server only when the functional component actually needs to call a native function and the corresponding interface module is not yet available locally. The interface module is then integrated into the runtime environment using plug-in loading technology, thereby achieving real-time expansion of native interface functionality.

[0042] The following describes a system architecture applicable to the embodiments of this application.

[0043] Please see Figure 1 , Figure 1 This is a schematic diagram of a system architecture provided for an embodiment of this application. (For example...) Figure 1 As shown, the system architecture includes an electronic device 110 and a server 120. The electronic device 110 and the server 120 can communicate via wired or wireless means. The electronic device 110 runs an operating system, which can be Android, Apple mobile OS (iOS), or other types of operating systems; this application embodiment does not impose any limitations on this.

[0044] Electronic device 110 includes platform application 111. Taking platform application 111 as containing N functional components as an example, where N is a positive integer, platform application 111 includes functional component 1, functional component 2, ..., functional component N. Functional components can be desktop widgets, mini-program components, quick app components, or other functional units that need to call the device's native functions. During operation, functional components may need to call various native functions of electronic device 110, such as camera capture, gyroscope data acquisition, notification push, Bluetooth communication, etc. Platform application 111 provides a runtime environment for functional components through its internal container and is responsible for managing the interaction with the native system.

[0045] Electronic device 110 may include, but is not limited to: smartphones, tablets, smart wearable devices, smart voice interaction devices, smart home appliances, personal computers, in-vehicle terminals, smart cameras, virtual reality devices (such as augmented reality (AR) devices), etc., and this application does not limit them.

[0046] Server 120 is used to store interface module files, which are generated by extracting and compiling code from the native bridging package. Based on the download request sent by electronic device 110, server 120 returns an interface module file to electronic device 110 that matches the target function and operating environment information.

[0047] The server can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0048] The following describes the operation method of the functional components provided in the embodiments of this application.

[0049] Please see Figure 2 , Figure 2 This is a flowchart illustrating a method for operating a functional component according to an embodiment of this application. Figure 2 As shown, the operation method of this functional component may include, but is not limited to, the following steps: S201, The electronic device receives a call request for a target function initiated by a functional component.

[0050] Among them, functional components refer to program modules that run within the platform application and have independent functional units.

[0051] In one possible implementation, the functional component is a desktop widget, which is hosted and managed by a widget container. The electronic device receives a user's request description, generates a widget installation package based on this description using artificial intelligence, and applies the installation package to the widget container to obtain the desktop widget. This desktop widget can be used to implement specific functions, such as QR code payment, weather inquiries, and device status monitoring.

[0052] Optionally, functional components can also be mini-program components, quick app components, or other lightweight functional modules embedded in the platform application.

[0053] The target function refers to the hardware capabilities or system services provided by the native system of the electronic device that the functional component needs to invoke. Hardware capabilities include, but are not limited to: camera photography, flash control, gyroscope data acquisition, accelerometer sensing, Global Positioning System (GPS) positioning, Bluetooth communication, Near Field Communication (NFC), fingerprint recognition, and dot matrix screen display. System services include, but are not limited to: push notifications, background task scheduling, permission management, clipboard reading and writing, and database access.

[0054] In one possible implementation, the electronic device receives a call request for a target function initiated by a functional component at any time: when the functional component is created, when the functional component responds to a user operation, or when the functional component is automatically triggered according to preset logic. For example, when a user clicks the "Scan QR Code" button on a desktop widget, the widget immediately initiates a call request for the camera function. Accordingly, the electronic device receives the call request for the camera function initiated by the desktop widget. Similarly, when the desktop widget automatically refreshes data in the background, it may initiate a call request for network communication functions. Accordingly, the electronic device receives the call request for network communication functions initiated by the desktop widget.

[0055] S202, Obtain operating environment information of electronic devices.

[0056] In this embodiment of the application, after receiving a call request for a target function initiated by a functional component, the electronic device obtains its own operating environment information.

[0057] The runtime environment information refers to data describing the current operating status and system configuration of the electronic device. Accurately obtaining the runtime environment information ensures that the subsequently downloaded interface module files are compatible with the current electronic device environment.

[0058] The runtime environment information may include at least one of the following: operating system type information, operating system version information, hardware architecture information, device model information, or screen type information.

[0059] Operating system type information identifies the type of operating system running on the electronic device. For example, Android, iOS, or other types of operating systems. Operating system version information identifies the specific version number of the operating system running on the electronic device. For example, for Android, version information may include Android 12, Android 13, Android 14, etc.; for iOS, version information may include iOS 15, iOS 16, iOS 17, etc. Hardware architecture information identifies the type of processor architecture used by the electronic device. Device model information identifies the specific model of the electronic device. Screen type information identifies the screen characteristics of the electronic device, such as whether it has a dot matrix screen, foldable screen, curved screen, or standard flat screen.

[0060] In one possible implementation, the electronic device can obtain the aforementioned runtime environment information by calling the system interface provided by the operating system. Optionally, the electronic device can also pre-collect the runtime environment information when the platform application starts and cache it in local memory, reading it directly from the cache when needed to improve processing efficiency.

[0061] S203, Determine whether the electronic device has an interface module file that corresponds to the target function and matches the operating environment information.

[0062] In this embodiment of the application, after receiving a call request for a target function initiated by a functional component and obtaining the operating environment information of the electronic device, the electronic device determines whether there is an interface module file that corresponds to the target function and matches the operating environment information locally.

[0063] In one possible implementation, the electronic device can determine the corresponding function identifier based on the target function. The electronic device can extract the module name corresponding to the target function from the import statements in the component code file of the functional component, and then determine the function identifier corresponding to that module name based on a pre-defined mapping relationship between module names and function identifiers. For example, when the functional component code contains "import com.example.camera.Camera API", the electronic device extracts the module name "Camera API" from it, and determines the function identifier corresponding to this module name as "camera_capture" through the mapping relationship. The electronic device then determines whether an interface module file corresponding to the function identifier and matching the runtime environment information exists locally.

[0064] If a matching interface module file exists locally that corresponds to the function identifier and matches the runtime environment information, the process can proceed to step S208, whereby the functional component can directly call the target function through this interface module file. If no matching interface module file exists locally that corresponds to the function identifier and matches the runtime environment information, step S204 is executed to initiate a download request to the server. This ensures the reusability of the interface module file, avoids repeated downloads, and saves network traffic and loading time.

[0065] S204: If the electronic device does not have the interface module file, the electronic device sends a download request to the server. Correspondingly, the server receives the download request from the electronic device.

[0066] In this embodiment, when the electronic device confirms that there is no interface module file matching the target function and operating environment information locally, the electronic device sends a download request to the server via the network. This download request includes at least the target native bridging packet identifier corresponding to the target function and the aforementioned obtained operating environment information.

[0067] In one possible implementation, the module name corresponding to the target function can be extracted from the import statement in the component code file of the functional component; then, based on the preset mapping relationship between the module name and the native bridging package identifier, the target native bridging package identifier corresponding to the module name can be determined. For example, if the functional component code contains the import statement import com.example.camera.Camera API, the electronic device extracts the module name "Camera API" from it and determines the corresponding target native bridging package identifier (such as "camera_bridge_v2") according to the preset mapping relationship.

[0068] After receiving the download request, the server parses the download request to obtain the target native bridging packet identifier and runtime environment information carried in it.

[0069] S205, the server extracts the target native bridging packet corresponding to the target function based on the target native bridging packet identifier and the runtime environment information.

[0070] In this embodiment of the application, after receiving a download request sent by an electronic device and parsing it to obtain the target native bridging packet identifier and runtime environment information, the server extracts the target native bridging packet corresponding to the target function from the repository based on the above information.

[0071] The native bridging package refers to the code collection used to connect the React Native framework and the native system interfaces. It typically includes native modules written in Java (the native programming language for Android) or Objective-C / Swift (the native programming language for iOS), as well as corresponding JavaScript interface definitions, used to enable JavaScript layer calls to native functions. In this embodiment, the native bridging package is not pre-integrated into the platform application, but is stored on the server side as a resource unit distributed on demand.

[0072] In the server repository, the native bridging package can be stored in source code or pre-compiled intermediate form. Optionally, the server can also store both source code and pre-compiled intermediate forms simultaneously, selecting the most appropriate processing path based on the runtime environment information sent by the electronic device. For example, when the operating system version in the runtime environment information matches the compatibility range of the pre-compiled intermediate form, the server can directly use the pre-compiled intermediate form; when they do not match or require customized compilation, the server recompiles using the source code.

[0073] After obtaining the target native bridging package identifier and runtime environment information carried in the download request, the server first locates the corresponding target native bridging package in the repository based on the target native bridging package identifier in the download request. The target native bridging package identifier is the identification information used to uniquely identify the target native bridging package. After locating the target native bridging package, the server further extracts the core code portion that matches the current electronic device environment from the target native bridging package based on the runtime environment information. At the same time, the server scans the source code directory of the target native bridging package using automated scripts, identifying core files containing native interface definitions, method implementations, and resource dependencies, while excluding test code, redundant configurations, and unnecessary dependencies, ensuring that the extracted code is concise and functionally complete.

[0074] In one possible implementation, after receiving a download request from an electronic device, the server can first search its repository for a target native bridging packet or interface module file that matches the target native bridging packet identifier and the runtime environment information carried in the download request.

[0075] If a target native bridging package or interface module file matching the target native bridging package identifier and the runtime environment information already exists in the server repository, the server can directly perform subsequent extraction, compilation, or return operations. If no target native bridging package or interface module file matching the target native bridging package identifier and the runtime environment information exists in the server repository, the server can perform external retrieval processing to obtain candidate bridging package resources corresponding to the target function from external resources. In this way, it is not necessary to pre-store a large number of native bridging packages on the server side; the corresponding resources can be obtained on demand when the target function is actually called, thereby reducing server storage pressure and improving the coverage of the target function.

[0076] External resources may include code repositories, bridging package distribution platforms, component resource libraries, native bridging package resource libraries maintained by developers, or other network services that provide native bridging package code resources.

[0077] The server can construct a retrieval request based on the target native bridging packet identifier and send the retrieval request to the external resource.

[0078] In one possible implementation, the retrieval request may further include runtime environment information to obtain candidate bridging package resources from external resources that are compatible with the current runtime environment of the electronic device. For example, when the runtime environment information indicates that the electronic device is an Android platform and the operating system version is a specific version, the server may prioritize obtaining candidate bridging package resources that are applicable to the Android platform and compatible with that operating system version; when the runtime environment information indicates that the electronic device is an iOS platform, the server may prioritize obtaining candidate bridging package resources that are applicable to the iOS platform.

[0079] In one possible implementation, after receiving candidate bridging package resources returned by external resources, the server can filter the candidate bridging package resources based on preset filtering rules to obtain the target native bridging package corresponding to the target function. The preset filtering rules may include at least one of the following: name matching rules, module name matching rules, interface definition matching rules, platform compatibility rules, dependency rules, and code integrity rules.

[0080] Optionally, the server can also determine whether a candidate bridging package resource meets the subsequent compilation conditions based on whether it contains native interface definitions, method implementations, resource dependencies, or configuration files corresponding to the target function. If a candidate bridging package resource does not meet the preset filtering rules, the server can discard it and continue filtering other candidate bridging package resources. This filtering process can prevent bridging package resources that are unrelated to the target function, incompatible with the runtime environment, or have incomplete code from being introduced into the subsequent processing flow.

[0081] In one possible implementation, after determining the target native bridging package, the server can also perform preprocessing on it. This preprocessing may include: removing test code, sample code, redundant configuration files, irrelevant resource files, or unnecessary dependencies; supplementing compilation configurations corresponding to the runtime environment information; and uniformly processing the directory structure, naming rules, and interface exposure methods in the target native bridging package. Through this preprocessing, the interface module files generated by subsequent compilation can be more streamlined, reducing their size, improving network transmission efficiency, and increasing loading efficiency on the electronic device side.

[0082] In one possible implementation, if the server fails to find a suitable candidate bridging package resource in external resources, or if the retrieved candidate bridging package resources, after screening, do not meet the preset requirements, the server can return a download failure notification to the electronic device. The download failure notification can indicate that: there is no target native bridging package or interface module file in the server repository that matches the target native bridging package identifier and runtime environment information, and there are no suitable candidate bridging package resources in external resources either. Upon receiving the download failure notification, the electronic device can execute the automatic interface module file generation process described in other embodiments of this application, that is, using artificial intelligence to generate an automatic interface module file corresponding to the target function based on the call request and runtime environment information of the target function. Thus, the server can form a hierarchical processing path: prioritizing the reuse of existing resources in the server repository; performing external search processing when existing resources are unavailable; and performing automatic interface module file generation processing only when external search still fails, thereby improving the success rate of target function calls.

[0083] S206, the server compiles the target native bridging package corresponding to the target function to obtain the interface module file corresponding to the target function.

[0084] In this embodiment of the application, after the server extracts the target native bridging packet, it compiles the extracted code to generate an interface module file that corresponds to the target function and matches the operating environment of the electronic device.

[0085] In one possible implementation, the compilation process can invoke the corresponding compilation toolchain based on the target platform indicated by the electronic device's runtime environment information, generating platform-compatible interface module files. For example, when the runtime environment information indicates that the electronic device is an Android platform, the server invokes Android compilation tools (such as the dx tool or d8 compiler) to compile the extracted Java code into a dex format file. The dex format file is a unique executable file format specific to the Android platform, short for Dalvik Executable, used to store compiled Java bytecode, and is one of the core file types for running Android applications.

[0086] When the runtime environment information indicates that the electronic device is an iOS platform, the server calls the Xcode compilation toolchain to compile the extracted Objective-C or Swift code into a framework dynamic library format.

[0087] During the compilation process, the server can also optimize the independently loadable binary files generated by the compilation based on preset compilation parameters and dependency library configurations, and clean up the intermediate files generated during the compilation process to reduce the size of the final interface module file, which facilitates network transmission and local storage.

[0088] S207, the server sends a download response to the electronic device. Correspondingly, the electronic device receives the download response from the server.

[0089] In this embodiment, after compiling and preparing the interface module file, the server encapsulates the generated interface module file in a download response and sends it to the electronic device. This download response includes the target native bridging packet identifier corresponding to the target function and the interface module file matching the runtime environment information.

[0090] In one possible implementation, the download response may also include version information, checksum, and expiration information of the interface module file. Upon receiving the download response, the electronic device can perform an integrity check on the interface module file to ensure it has not been tampered with or corrupted, and then store the interface module file in a designated local directory for later reuse.

[0091] S208, the container running the functional components loads and registers the interface module file so that the functional components can call the target function through the interface module file.

[0092] In this embodiment, after the electronic device receives the interface module file, the container running the functional component uses plug-in loading technology to dynamically load and register the interface module file, so that the functional component can call the target function through the interface module file.

[0093] Among them, plug-in loading technology is a technology for dynamically loading external code modules. By passing the path of external files to a custom class loader, external files can be loaded into the platform application, realizing on-demand loading and runtime expansion of functional modules without modifying the main program of the platform application or restarting the platform application.

[0094] Depending on the operating system running the electronic device, the specific implementation of plug-in loading technology varies.

[0095] For example, when an electronic device runs the Android system, the interface module files are in dex format. The container can use a custom class loader (such as DexClassLoader) to pass the path to an external dex file, loading the classes from that file into the application process. After loading, the container instantiates the corresponding interface class using reflection and registers it with its internal function dispatch center. Subsequently, when a functional component initiates a call to the target function again, the container can route the call to the registered interface implementation, thus successfully completing the call to the target function.

[0096] When an electronic device runs the iOS system, the interface module files are dynamic libraries in framework format. Containers can load framework-format dynamic libraries through NSBundle and leverage Objective-C's runtime features to dynamically register classes and exchange methods, thereby enabling dynamic integration of native interfaces.

[0097] Through the above loading and registration mechanism, functional components can obtain the required native interface capabilities in real time without the need for a pre-built native bridging package, thus realizing the on-demand dynamic expansion of functions.

[0098] In one possible implementation, after the electronic device sends a download request to the server, the server returns a download failure notification indicating that the target native bridging package corresponding to the target function does not exist in the server's repository. The download failure notification may include the error code "ERR_BRIDGE_NOT_FOUND" or other error messages used to identify "no matching bridging package found".

[0099] After an electronic device receives a download failure notification, it can use artificial intelligence to generate an automatic interface module file corresponding to the target function based on the call request of the target function and the runtime environment information.

[0100] For example, an electronic device may have a lightweight AI model integrated locally, which has code generation capabilities. The electronic device collects the input information needed to generate the automatic interface module file, including a call request for the target function, runtime environment information, and function description text. The call request for the target function includes information such as a function description, expected input / output parameters, and the calling method. Runtime environment information includes the operating system type, operating system version, hardware architecture, and device model. The function description text can be a natural language description extracted from the function component's call request, or the user's initial requirement description information when generating the function component through AI dialogue.

[0101] The electronic device inputs the above information as a prompt to the local artificial intelligence model. After reasoning, the artificial intelligence model generates an automatic interface module file corresponding to the target function.

[0102] After receiving the automatic interface module file, the electronic device uses a plug-in loading technique to dynamically load and register the automatic interface module file, enabling the functional components to call the target function through the automatic interface module file. The specific implementation details of loading and registration can be found in step S208 and will not be elaborated here.

[0103] In one possible implementation, the server can also centrally store and manage all extracted and compiled interface module files. The electronic device does not need to download and store these files; instead, when a functional component initiates a call request for a target function, the electronic device sends the call request and runtime environment information to the server. Based on the received call request information, the server loads the corresponding interface module file in the cloud environment, and through remote procedure calls or inter-process communication mechanisms, proxies the electronic device to complete the call to the target function, returning the call result to the electronic device.

[0104] Therefore, electronic devices do not need to perform download, storage, loading, and registration operations of interface module files, further reducing the storage burden and computing overhead of electronic devices.

[0105] In one possible implementation, the ability of a functional component to call the target function can be verified and tested before the functional component is officially put into use or during operation.

[0106] The electronic device can receive test call requests for test functions initiated by functional components and obtain the electronic device's operating environment information. After obtaining the operating environment information, it sends a test download request to the server. The test download request may include the target native bridging packet identifier corresponding to the test function and the operating environment information. Optionally, the test download request may also carry a test identifier to inform the server that this request is a test request, so that the server returns a version of the interface module file specifically for testing, such as a debug version with additional log output or a test version that supports simulation mode.

[0107] After receiving a test download request, the server retrieves or compiles the corresponding test interface module file from the repository in real time based on the test identifier and target native bridging package identifier in the download request. Upon completion, the server sends a test download response to the electronic device. The electronic device receives the server's test download response, which includes the target native bridging package identifier corresponding to the test function and the test interface module file matching the runtime environment information. Optionally, the test download response may also include information such as test case sets, expected results, or test timeout periods to guide the electronic device in performing specific test verifications.

[0108] The container running the functional components loads and registers the test interface module files, enabling the functional components to call test functions through these files. Optionally, when loading and registering the test interface module files, the container can isolate them from the production version's interface module files. For example, the test interface module files can be stored in a different directory than the production version, or a separate DexClassLoader instance can be used on the Android platform, and a separate NSBundle instance can be used on the iOS platform. This isolation mechanism prevents the test version from interfering with the production environment, ensuring that debug logs, mock data, or abnormal states generated during testing do not affect the normal operation of the production version's interface module files.

[0109] After a functional component calls a test function through the test interface module file, the results of the test call are verified. Verification includes one or more of the following: functional correctness verification, performance verification, and exception handling verification. Upon completion of the test, a test report is generated. This report includes one or more of the following information: test function identifier, test time, test results, performance data, and error logs.

[0110] In one possible implementation, a functional component may call multiple target functions during operation, rather than just a single target function. For example, in a utility expense reimbursement assistant widget, when the functional component is used to implement complex business functions such as QR code recognition, image upload, location verification, and notification reminders, the functional component may need to simultaneously call camera functions, album read / write functions, location functions, and notification push functions. Compared to a scenario where a single target function corresponds to a single interface module file, multiple target functions often correspond to multiple target native bridging package identifiers and multiple interface module files. If multiple interface module files are downloaded, loaded, and registered separately, problems such as improper loading order, dependency mismatch, and partial loading success but overall call failure can easily occur.

[0111] Therefore, the container can perform scheduling, verification, and rollback processes on the multiple interface module files before they are officially loaded and registered.

[0112] Specifically, after receiving a call request from a functional component for multiple target functions, or after identifying multiple module names while parsing the component code file of a functional component, the electronic device can determine the multiple target native bridging package identifiers corresponding to the functional component. The container can generate a set of interface module files to be processed based on the multiple target native bridging package identifiers and runtime environment information. For each interface module file in this set, the container can determine whether an interface module file exists locally on the electronic device that matches the corresponding target native bridging package identifier and runtime environment information. For interface module files that already exist locally, they can be directly added to the loading set; for interface module files that do not exist locally, a corresponding download request can be sent to the server, and a corresponding download response can be received to complete the interface module file set. In this way, when a functional component needs to call multiple target functions, the container can first obtain the set of interface module files corresponding to the multiple target functions, rather than processing them one by one during runtime, thereby improving the overall operational stability.

[0113] In one possible implementation, the container can perform scheduling based on the dependencies between multiple interface module files to determine their loading order. This dependency can be determined based on at least one of the following: the order of import statements in the component code files, pre-defined dependencies between module names, pre-defined dependencies between target native bridging package identifiers, or information about other interface module files that the interface module file depends on during registration. For example, when the first interface module file needs to call capabilities provided by the second interface module file at runtime, the container can load and register the second interface module file first, and then load and register the first interface module file. This approach reduces the probability of interface call failures, registration failures, or runtime exceptions due to improper loading order.

[0114] In one possible implementation, before formally registering multiple interface module files into the container, the container can perform verification processing on these files. This verification process may include at least one of the following: compatibility verification, integrity verification, test call verification, or result consistency verification. Compatibility verification verifies whether the interface module files match the current runtime environment information; integrity verification verifies whether the interface module files have been completely downloaded and are not corrupted; test call verification verifies whether functional components can normally call the corresponding target functions through the corresponding test interface module files; and result consistency verification verifies whether multiple interface module files meet the preset calling relationships when running together. Through this verification process, incompatible, incomplete, or uncallable interface module files can be identified before formal execution, preventing these interface module files from entering the formal runtime environment.

[0115] In one possible implementation, after multiple interface module files have passed verification, the container can perform formal loading and registration of these files according to the loading order described above. This formal loading and registration may include: loading the class files from the multiple interface module files sequentially, instantiating the interface classes, registering the interface classes with the container's internal function scheduling center, and establishing a mapping relationship between the target function and the corresponding interface module file. After formal loading and registration are completed, functional components can collaboratively call multiple target functions through the multiple interface module files. Through unified scheduling and unified registration, the container can avoid the inconsistency issues caused by loading and registering multiple interface module files separately.

[0116] In one possible implementation, if an exception occurs during the scheduling, verification, loading, or registration of multiple interface module files, the container can perform a rollback. This rollback can include at least one of the following: canceling currently unregistered interface module files, unloading temporarily loaded but not yet officially enabled interface module files, restoring to a previously verified version of the interface module files, or returning a failure message to the functional component. If a target function is a critical function of the functional component, the container can directly prevent the functional component from entering the official running state if the corresponding interface module file fails verification. If a target function is a non-critical function, the container can also simply disable the non-critical function, allowing the functional component to continue running even without it. Through rollback, the basic availability of the functional component can be maintained as much as possible while ensuring its stability.

[0117] Furthermore, during the execution of the scheduling, verification, formal loading, formal registration, and rollback processes, the container can also generate corresponding log information. This log information may include one or more of the following: target native bridging packet identifier, interface module file identifier, download time, loading time, registration result, test result, failure reason, or rollback result. The log information can be stored locally on the electronic device and uploaded to the server when a functional component call fails, so that the server can continue to perform bridging packet updates, external searches, or automatic interface module file generation based on the log information. Considering that mobile terminal users typically do not have the ability to directly modify code, retaining and uploading log information on the electronic device side can improve the efficiency of subsequent problem location and automatic repair without relying on manual troubleshooting by users.

[0118] Through the above implementation methods, when a functional component requires only a single target function, the single-module download, loading, and registration process in the existing implementation methods of this application can be used; when a functional component requires multiple target functions, an interface module file set can be formed based on multiple target native bridging package identifiers, scheduling and verification processes can be performed first, followed by formal loading and formal registration, and rollback processing can be performed when necessary. In this way, it can adapt to both simple and complex functional scenarios, thereby improving the stable operation capability of the functional component on the electronic device and the success rate of target function invocation.

[0119] In one possible implementation, when a functional component needs to call the dot matrix screen of an electronic device to display content, an interface module file adapted to the dot matrix screen can be dynamically generated through artificial intelligence technology to achieve efficient communication between the functional component and the dot matrix screen.

[0120] Among them, a dot matrix screen is a display device composed of regularly arranged light-emitting units (such as light-emitting diodes (LEDs)). Each light-emitting unit can be independently controlled to turn on or off or to adjust its grayscale level. By combining light-emitting units in different positions, text, graphics, or animation information can be displayed.

[0121] Electronic devices can receive call requests for dot matrix screens initiated by functional components. These requests can include display content, display parameters, dot matrix screen identifiers, etc. After receiving the call request, the electronic device needs to obtain its current operating environment information. Then, using artificial intelligence, it generates a corresponding interface module file for the dot matrix screen based on the call request and operating environment information. This interface module file is a special type of interface module file whose function is to convert general display requests (such as displaying the text "Hello World") issued by functional components into a sequence of driver instructions that the specific dot matrix screen can understand. The core function of the interface module file is to realize the conversion between the "general display abstraction layer" and the "specific hardware driver layer," including dot matrix screen identifiers, etc.

[0122] After receiving the interface module file, the electronic device uses a plug-in loading technology to dynamically load and register the interface module file, enabling the functional components to call the dot matrix screen through the interface module file. The specific implementation details of loading and registration can be found in step S208, and will not be elaborated here.

[0123] This application's embodiments decouple the native bridging package code from the platform application, replacing it with an on-demand download and dynamic loading method. This eliminates the need for the platform application to pre-install all potentially used native bridging packages during the initial installation phase. This significantly reduces the initial size of the platform application, effectively saving storage space on user devices and reducing network traffic consumption during application download and installation. Furthermore, the dynamic download and plug-in loading mechanism allows functional components to retrieve the corresponding interface module file from the server and complete loading and registration in real time when they need to call a native function not yet supported by the platform application. This entire process does not require waiting for platform application version updates, greatly improving the timeliness of feature expansion.

[0124] The following describes the operating apparatus of the functional components provided in the embodiments of this application.

[0125] Please refer to Figure 3 , Figure 3 This is a schematic diagram of the structure of an operating device for a functional component provided in an embodiment of this application. The operating device for the functional component may include a transceiver unit 310 and a processing unit 320. The transceiver unit 310 may be a device that has signal input (receive) or output (transmit) for transmitting signals to other devices or other components in a device.

[0126] The processing unit 320 can be a device with processing capabilities, and may include one or more processors. The processor can be a general-purpose processor or a dedicated processor. The processor can be a baseband processor or a central processing unit (CPU). The baseband processor can be used to process communication protocols and communication data, while the CPU can be used to control the device (e.g., a host node, relay node, or chip), execute software programs, and process data from the software programs.

[0127] The device that operates the functional component can be an electronic device or a server, or it can be a device used to implement the functions of the electronic device or server, such as a chip.

[0128] When the operating device of the functional component is an electronic device, the operating device of the functional component includes: The transceiver unit 310 is used to receive call requests initiated by functional components for a target function.

[0129] The processing unit 320 is used to acquire the operating environment information of the electronic device and determine whether the electronic device has an interface module file that corresponds to the target function and matches the operating environment information.

[0130] The transceiver unit 310 is also used to send a download request to the server when the electronic device does not have an interface module file; the download request includes the target native bridging packet identifier corresponding to the target function and the operating environment information; and to receive the download response from the server; the download response includes an interface module file that matches the target native bridging packet identifier and the operating environment information corresponding to the target function.

[0131] The processing unit 320 is also configured to load and register the interface module file by the container running the functional component, so that the functional component can call the target function through the interface module file.

[0132] In one possible implementation, the processing unit 320 is further configured to extract the module name corresponding to the target function from the import statement in the component code file of the functional component; and determine the target native bridging package identifier corresponding to the module name based on a preset mapping relationship.

[0133] In one possible implementation, the aforementioned functional component is a desktop widget; the aforementioned container is a widget container used to manage the desktop widget. The transceiver unit 310 is further configured to receive user requirement description information. The processing unit 320 is further configured to generate a widget installation package based on the requirement description information using artificial intelligence, and apply the widget installation package to the widget container to obtain the desktop widget.

[0134] In one possible implementation, the transceiver unit 310 is further configured to receive a test call request for a test function initiated by a functional component. The processing unit 320 is further configured to obtain the operating environment information of the electronic device. The transceiver unit 310 is further configured to send a test download request to the server; the test download request includes the target native bridging packet identifier corresponding to the test function and the operating environment information; and receive a test download response from the server; the test download response includes a test interface module file that matches the target native bridging packet identifier and the operating environment information corresponding to the test function. The processing unit 320 is further configured to load and register the test interface module file by the container running the functional component, so that the functional component can call the test function through the test interface module file.

[0135] In one possible implementation, the processing unit 320 is further configured to, upon receiving a download failure notification from the server, generate an automatic interface module file corresponding to the target function based on the call request for the target function and runtime environment information using artificial intelligence; the download failure notification is used to indicate that there is no target native bridging package corresponding to the target function; the automatic interface module file is loaded and registered by the container running the functional component, so that the functional component can call the target function through the automatic interface module file.

[0136] In one possible implementation, the transceiver unit 310 is further configured to receive a call request for the dot matrix screen initiated by a functional component. The processing unit 320 is further configured to obtain the operating environment information of the electronic device; generate a corresponding interface module file for the dot matrix screen based on the call request and operating environment information of the dot matrix screen using artificial intelligence; and load and register the interface module file by the container running the functional component, so that the functional component can call the dot matrix screen through the interface module file.

[0137] In one possible implementation, the transceiver unit 310 is further configured to receive call requests for multiple target functions initiated by the functional component. The processing unit 320 is further configured to obtain the operating environment information of the electronic device; determine multiple target native bridging packet identifiers corresponding to the multiple target functions; based on the multiple target native bridging packet identifiers and the operating environment information, obtain multiple interface module files corresponding to the multiple target functions respectively, and determine the loading order of the multiple interface module files; perform verification processing on the multiple interface module files; if the multiple interface module files all pass the verification processing, the container running the functional component loads and registers the multiple interface module files in the loading order, so that the functional component can call the multiple target functions through the multiple interface module files respectively.

[0138] Alternatively, when the operating device of the functional component is a server, the operating device of the functional component includes: The transceiver unit 310 is used to receive download requests from electronic devices; the download request includes the target native bridging packet identifier corresponding to the target function and the operating environment information.

[0139] The processing unit 320 is also used to extract the target native bridging package corresponding to the target function based on the target native bridging package identifier and runtime environment information; and to compile the target native bridging package corresponding to the target function to obtain the interface module file corresponding to the target function.

[0140] The transceiver unit 310 is used to send a download response to the electronic device; the download response includes a target native bridging packet identifier corresponding to the target function and an interface module file that matches the operating environment information.

[0141] For a description of the operating device of the functional components and the technical effects brought about by any possible implementation thereof, please refer to the description of the technical effects of the foregoing method embodiments, which will not be repeated here.

[0142] According to the embodiments of this application, Figure 3The various units in the operating device of the functional components shown can be individually or entirely merged into one or more other units, or one or more of the units can be further divided into multiple functionally smaller units. This can achieve the same operation without affecting the technical effect of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can also be implemented by multiple units, or the function of multiple units can be implemented by one unit.

[0143] This application also provides a computer device; please refer to [link / reference]. Figure 4 , Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application.

[0144] like Figure 4 As shown, the computer device 400 may include one or more processors 410, one or more memories 430, one or more communication interfaces 420, and a bus 440, wherein the processors 410, memories 430, and communication interfaces 420 are connected via the bus 440. The computer device may be an operating device for the functional components described above.

[0145] The memory 430 is used to store a program; the processor 410 is used to execute the program stored in the memory. When the program is executed, the processor 410 executes the method in any possible implementation of the operation method of the functional components described above.

[0146] It should be understood that, in the embodiments of this application, the memory 430 mentioned above includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CDROM), as well as external memory other than computer memory and processor cache. A portion of the memory 430 may also include non-volatile random access memory. For example, the memory 430 may also store device type information.

[0147] The processor 410 described above can be one or more Central Processing Units (CPUs). If the processor 410 is a CPU, it can be a single-core CPU or a multi-core CPU. The processor 410 can also be 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. A general-purpose processor can be a microprocessor or any conventional processor.

[0148] The steps performed in the foregoing embodiments can be based on the above. Figure 4 The computer device 400 shown is implemented in a way that the processor 410 can execute any of the optional implementations of the operating method of the functional components provided in the embodiments of this application, or it can execute the implementation of the operating device of the functional components described in the embodiments of this application. Specifically, the processor 410 can implement... Figure 3 The processing unit 320 in the operating device of the functional component shown in the figure has the function of [function name missing]. The communication interface 420 can implement the function of the transceiver unit 310 in the operating device of the functional component shown in the figure. The memory 430 can provide a cache when the processor 410 executes the implementation of the operating device of the functional component described in the embodiments of this application, and can also store the computer programs required by the processor 410 to execute the implementation of the operating device of the functional component described in the embodiments of this application.

[0149] This application also provides a computer storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, enable the processor to implement the above-mentioned functions. Figure 2 The method shown.

[0150] This application also provides a computer program product, which includes: instructions or a computer program; when the instructions or the computer program are executed, the above-mentioned functions can be achieved. Figure 2 The method shown.

[0151] This application also provides a chip, which includes a processor. The processor executes instructions, enabling the chip to achieve the aforementioned... Figure 2The method shown is described above. Optionally, the chip also includes a communication interface for receiving or transmitting signals.

[0152] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by hardware related to computer programs. The computer programs can be stored in computer storage media, and when executed, they can implement the processes of the above method embodiments. The aforementioned computer storage media include various media capable of storing computer program code, such as read-only memory (ROM) or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for operating a functional component, characterized in that, Applied to electronic devices, the method includes: Receive the call request for the target function initiated by the functional component; Obtain the operating environment information of the electronic device; Determine whether the electronic device has an interface module file that corresponds to the target function and matches the operating environment information; If the interface module file is not present in the electronic device, a download request is sent to the server; the download request includes the target native bridging package identifier corresponding to the target function and the operating environment information; Receive the download response from the server; the download response includes the target native bridging packet identifier corresponding to the target function and the interface module file that matches the runtime environment information; The interface module file is loaded and registered by the container running the functional component, so that the functional component can call the target function through the interface module file.

2. The method as described in claim 1, characterized in that, The method further includes: Extract the module name corresponding to the target function from the import statement in the component code file of the functional component; Based on the preset mapping relationship, the target native bridging packet identifier corresponding to the module name is determined.

3. The method as described in claim 1, characterized in that, The functional component is a desktop widget; the container is a widget container used to manage the desktop widget. The method further includes: Receive user's request description information; The widget installation package is generated based on the requirement description information using artificial intelligence, and then applied to the widget container to obtain the desktop widget.

4. The method as described in claim 1, characterized in that, The method further includes: Receive test call requests for the test functions initiated by the functional components; Obtain the operating environment information of the electronic device; Send a test download request to the server; the test download request includes the target native bridging packet identifier corresponding to the test function and the runtime environment information; Receive the test download response from the server; the test download response includes the target native bridging packet identifier corresponding to the test function and the test interface module file that matches the runtime environment information; The test interface module file is loaded and registered by the container running the functional component, so that the functional component can call the test function through the test interface module file.

5. The method as described in claim 1, characterized in that, The method further includes: Upon receiving a download failure notification from the server, an automatic interface module file corresponding to the target function is generated using artificial intelligence based on the call request for the target function and the runtime environment information; the download failure notification is used to indicate that the target native bridging package corresponding to the target function does not exist. The container running the functional component loads and registers the automatic interface module file, so that the functional component can call the target function through the automatic interface module file.

6. The method as described in claim 1, characterized in that, The method further includes: Receive the call request for the dot matrix screen initiated by the functional component; Obtain the operating environment information of the electronic device; Based on the call request of the dot matrix screen and the operating environment information, artificial intelligence is used to generate the corresponding interface module file for the dot matrix screen. The container running the functional component loads and registers the interface module file, so that the functional component can call the dot matrix screen through the interface module file.

7. The method as described in claim 1, characterized in that, The method further includes: Receive the invocation requests initiated by the functional components for multiple target functions; Obtain the operating environment information of the electronic device; Determine the target native bridging packet identifiers corresponding to the multiple target functions; Based on the multiple target native bridging package identifiers and the runtime environment information, multiple interface module files corresponding to the multiple target functions are obtained respectively, and the loading order of the multiple interface module files is determined. Perform verification processing on the multiple interface module files; If all the interface module files pass the verification process, the container running the functional component loads and registers the multiple interface module files in the loading order, so that the functional component can call the multiple target functions through the multiple interface module files respectively.

8. A method for operating a functional component, characterized in that, Applied to a server, the method includes: Receive a download request from an electronic device; the download request includes the target native bridging package identifier corresponding to the target function and the operating environment information; Based on the target native bridging packet identifier corresponding to the target function and the runtime environment information, extract the target native bridging packet corresponding to the target function; Compile the target native bridging package corresponding to the target function to obtain the interface module file corresponding to the target function; Send a download response to the electronic device; the download response includes a target native bridging packet identifier corresponding to the target function and an interface module file that matches the operating environment information.

9. A device for operating a functional component, characterized in that, The operating device of the functional component includes a unit for implementing the method as described in any one of claims 1-7, or includes a unit for implementing the method as described in claim 8.

10. A computer device, characterized in that, include: Memory, processor; where: The memory is used to store computer programs, the computer programs including program instructions; The processor is configured to invoke the program instructions to cause the computer device to perform the method as described in any one of claims 1-7, or to perform the method as described in claim 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1-7, or performs the method as described in claim 8.

Images