A UniApp universal native function bridging plug-in system and plug-in calling method

Abstract

The application discloses a UniApp general native function bridging plug-in system and a plug-in calling method, and belongs to the technical field of mobile application cross-platform development. In order to solve the technical problems of redundancy, inefficiency and complex configuration of native module bridging in UniApp development, a centralized plug-in registry is constructed to uniformly manage plug-in metadata, and a native layer dynamic router is designed. After receiving a calling request of a front-end general SDK, the router executes a dynamic routing algorithm based on multi-factor weighting, intelligently selects an optimal plug-in instance from the registry to perform proxy execution, and uniformly manages the life cycle of the plug-in. The application can realize automation, intelligentization and uniformization of native plug-in management, greatly improving development efficiency, application flexibility and running performance.

Description

Technical Field

[0001] This invention belongs to the field of cross-platform development technology for mobile applications, specifically relating to a UniApp universal native function bridging plugin system and plugin invocation method. Background Technology

[0002] With the rapid development of the mobile internet, in order to cope with the coexistence of iOS, Android and HarmonyOS Next platforms, cross-platform development technologies have become increasingly popular due to their ability to build multi-platform applications using a single codebase (Reference: Li, Y., Li, Z., & Zhang, M. A survey of cross-platform development frameworks for mobile applications[J]. Journal of Software: Evolution and Process, 2023, 35(5): e2456.). Among them, UniApp, as a full-platform development framework based on Vue.js syntax, provides rich cross-platform APIs through its built-in uni objects, which greatly improves development efficiency (Refer to DCloud.UniApp official documentation. https: / / uniapp.dcloud.net.cn / , 2024.). However, UniApp still has significant limitations when handling complex or platform-specific native functions. When an application needs to call functions not covered by the official API, such as custom hardware interaction, deep system integration, or third-party SDKs, developers must write native plugins (see Apple Inc. Apple Developer Documentation: WebKit JavaScript Environment. https: / / developer.apple.com / documentation / , 2024.).

[0003] Traditional UniApp native plugin development suffers from several pain points. First, regarding redundancy and duplication, each native function needs to be implemented separately on Android, iOS, and HarmonyOS Next, requiring corresponding calling modules to be written in the front end. This process is cumbersome and prone to generating a large amount of repetitive glue code. Second, plugin configuration is complex, requiring registration and configuration within the native project, involving numerous steps and prone to errors, hindering dynamic updates and hot-swapping of plugins. Furthermore, the lack of a unified governance mechanism is a significant problem. As the number of plugins grows, the project lacks a centralized system for plugin discovery, status monitoring, version compatibility, and exception handling, leading to high maintenance costs. Finally, in terms of performance, traditional synchronous calls and simple asynchronous callbacks may introduce additional performance overhead and context switching when handling a large number or continuous native calls, impacting operational efficiency.

[0004] To address the aforementioned issues, existing optimization solutions largely focus on encapsulating more official APIs or establishing a plugin marketplace. However, these methods do not fundamentally resolve the bottleneck of plugin communication at the architectural level. They still rely on static, pre-configured bridging methods, making it difficult to achieve true "plug-and-play" and dynamic intelligent routing (Reference: Qiao B, Li L, Zhang X, et al. Taskweaver: A code-first agent framework[J]. arXiv preprint arXiv:2311.17541, 2023.). Summary of the Invention

[0005] The purpose of this invention is to propose a UniApp universal native function bridging plugin system and plugin invocation method to solve the technical problems of redundancy, inefficiency, complex configuration, and the need for developers to write cumbersome native module and configuration code in the existing UniApp development. It aims to automatically discover, orchestrate, and invoke the platform's native capabilities, and achieve the goal of automating, intelligentizing, and unifying the management of native plugins.

[0006] To achieve the above objectives, the present invention adopts the following technical solution.

[0007] A bridging plugin system based on UniApp's universal native functions includes: A front-end general bridging SDK is used to generate and send API call requests containing function identifiers and platform types, and to perform parameter serialization and signature verification on the requests. A centralized plugin registry is used to store metadata information of each plugin instance, and when a query request is received, it returns an initial set of candidate plugin instances that support the function identifier. The native layer dynamic router is used to receive the API call request, query the centralized plugin registry according to the function identifier to retrieve the initial candidate plugin instance set, apply a filter chain to process the initial candidate plugin instance set to obtain a filtered candidate plugin instance set; it is also used to apply a scorer chain to calculate the comprehensive weight score of each plugin instance in the filtered candidate plugin instance set, select the plugin instance with the highest score as the optimal plugin instance according to the comprehensive weight score, execute the API call request through the optimal plugin instance and return the execution result.

[0008] Furthermore, the establishment of the centralized plugin registry includes embedding the registry in the application resource directory or deploying it on a remote server, and supporting dynamic updates and hot-swapping.

[0009] Furthermore, the front-end general bridging SDK also includes parameter validation, call encapsulation, bridging call and callback management functions.

[0010] Furthermore, the plugin instance metadata stored in the centralized plugin registry includes the plugin's unique identifier, a list of functional methods, version number, and performance cost metrics.

[0011] Furthermore, the centralized plugin registry is a JSON configuration file built into the application resource directory, or it is deployed on a remote server and pulled over the network.

[0012] Furthermore, the filter chain includes at least a platform filter, which is used to remove plugin instances whose platform attributes do not match the platform type of the API call request.

[0013] Furthermore, the filter chain also includes version filters, dependency filters, and state filters, which are used to remove the corresponding plugin instance when the plugin instance version is incompatible, the dependency is missing, or the state is abnormal.

[0014] Furthermore, it also includes a native layer unified entry module, which is used to receive front-end requests and forward the requests to the native layer dynamic router for processing; the native layer unified entry module inherits UniModule on the Android side and exposes methods using annotations, and inherits DCUniModule on the iOS side and exposes methods using macro definitions.

[0015] Furthermore, the scoring chain includes a performance cost factor, an instance status factor, and a version compatibility factor, and obtains a comprehensive score for candidate plugin instances through weighted calculation.

[0016] Furthermore, the native layer dynamic router manages the lifecycle of plugin instances, including loading, initialization, caching, and destruction, and optimizes memory usage using reference counting or least recently used strategies.

[0017] A plugin invocation method based on the system includes the following steps: 1) The native layer dynamic router receives API call requests sent by the front end, and the API call requests include function identifiers and platform types; 2) The native layer dynamic router queries the centralized plugin registry based on the function identifier to retrieve an initial set of candidate plugin instances that support the function identifier; 3) Apply a filter chain to the initial candidate plugin instance set. The filter chain includes at least a platform filter to remove plugins whose platform attributes do not match the platform type of the API call request, thus obtaining a filtered candidate plugin instance set. 4) Apply a scorer chain to each plugin instance in the filtered candidate plugin instance set to calculate a comprehensive weight score; 5) Select the plugin instance with the highest score from the filtered candidate plugin instance set based on the comprehensive weight score as the optimal plugin instance; 6) Execute the API call request through the optimal plugin instance and return the execution result to the front end.

[0018] Furthermore, the API call request mentioned in step 1) is generated by the front-end general bridging SDK. This front-end general bridging SDK encapsulates a unified invoke method, receives the function identifier, parameters and callback function, and sends the API call request to the native layer dynamic router through the UniApp bridging mechanism.

[0019] Furthermore, step 4) involves calculating the overall weighted score, which includes: Obtain multiple preset evaluation factors and their corresponding weights, including performance cost factors, instance status factors, and version compatibility factors; Calculate the evaluation factor values ​​for each plugin instance in the filtered candidate plugin instance set; The comprehensive weight score is obtained by multiplying each factor value of each plugin instance by its corresponding weight and then summing the results.

[0020] Furthermore, the steps for calculating the values ​​of each evaluation factor include: Calculate the performance cost factor: Obtain the historical average execution cost of the plugin instance and calculate the factor value based on the historical average execution cost; Calculate instance state factors: Query the plugin instance pool to get the current state of the plugin instance, and assign discrete score values ​​according to the current state. The current states are loaded and initialized, loaded only, and not loaded, and the values ​​are assigned in descending order. Calculate the version compatibility factor: Obtain the current application version number and the plugin instance version number, calculate the absolute difference between the two, and the factor value is inversely proportional to the absolute difference.

[0021] Furthermore, in step 5), if multiple plugin instances have the same highest overall weight score, a tie-breaking strategy is adopted, prioritizing the plugin instance with the lowest performance cost.

[0022] Furthermore, if the optimal plugin instance fails to execute in step 6), it is downgraded or removed from the candidate set, and a second-best plugin instance is selected from the set for retry.

[0023] Furthermore, after receiving the API call request, the native layer dynamic router further performs instance state factor calculation, which is used to correct the comprehensive weight score of the candidate plugin based on the plugin loading state and initialization state.

[0024] The present invention has achieved the following beneficial effects.

[0025] 1. This invention provides a unified front-end general bridging SDK and a centralized plugin registry, allowing developers to focus only on business logic and function implementation without writing redundant bridging code and complex configurations, thus achieving "define once, call in multiple places" and greatly improving development efficiency.

[0026] 2. This invention utilizes a centralized registration and dynamic routing mechanism to achieve complete decoupling between front-end calls and native plugin implementation; native plugins can be developed, updated, and even hot-fixed independently, significantly improving the flexibility and maintainability of the application.

[0027] 3. The core dynamic routing algorithm of this invention is based on a weighted scoring of multiple factors (such as performance cost, instance status, and version compatibility), which can intelligently select the optimal execution path and avoid unnecessary performance overhead. At the same time, through a unified plugin instance pool and lifecycle management (such as LRU strategy), the consumption of repeated initialization is reduced and the application performance is improved.

[0028] 4. The dynamic routing algorithm of this invention has built-in degradation and retry mechanisms to ensure the availability and fault tolerance of function calls; at the same time, the factor model of the algorithm has good scalability, allowing new factors (such as network latency and power consumption) to be integrated into the decision-making process in the future, so that the system has continuous optimization space. Attached Figure Description

[0029] Figure 1 This is an architecture diagram of a UniApp universal native function bridging plugin system according to the present invention.

[0030] Figure 2 This is a flowchart of the dynamic routing decision-making process of the present invention.

[0031] Figure 3 This is a timing diagram for retrieving battery information in the embodiment. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in further detail below.

[0033] This invention proposes a UniApp universal native function bridging plugin system, which includes three core modules: a front-end universal bridging SDK (JavaScript SDK), a native layer dynamic router, and a centralized plugin registry (PluginRegistry), such as... Figure 1 As shown.

[0034] like Figure 1 As shown, the system comprises a front-end layer, a bridging layer, and a native layer. The front-end layer includes a front-end JavaScript SDK; the bridging layer includes the UniApp bridging mechanism; and the native layer includes a native layer dynamic router, a centralized plugin registry, and a plugin instance pool. The front-end layer sends API calls to the native layer through the bridging layer, which forwards the requests to the native layer. The native layer dynamic router sends plugin information query requests to the plugin registry, which returns the corresponding plugin configuration information. Simultaneously, the native layer dynamic router sends plugin management instructions to the plugin instance pool, which provides the corresponding functional services. The native layer processes the results and returns them to the bridging layer, which then returns them to the front-end layer, thus completing a full functional call process.

[0035] 1. General-purpose bridging SDK for front-end.

[0036] Front-end developers no longer need to write separate calling code for different platforms. They only need to call the invoke method provided by the general bridging SDK and pass in the target function identifier (action) and calling parameters (params). This SDK is responsible for interacting with the bridging layer to implement a unified calling interface across platforms.

[0037] 2. Centralized plugin registry.

[0038] All native functional modules (including pre-built plugins and dynamically loaded plugins) must be registered in a centralized plugin registry. This registry can be deployed locally on the application or on a remote server for unified management of plugin information. Registration information includes: a unique plugin identifier (pluginId), a list of functional methods (methodList), version number, required permissions, performance cost metrics, and other metadata. Through this registry, the system can dynamically discover, retrieve, and load corresponding plugins at runtime, ensuring the consistency and scalability of function calls.

[0039] 3. Native layer dynamic router.

[0040] The native layer dynamic router and its internal dynamic routing algorithm constitute the core innovation of this invention.

[0041] (1) Dynamic routing decision mechanism.

[0042] When a frontend request is passed from the bridging layer to the native layer, the native layer's dynamic router does not simply forward the request. Instead, it executes a dynamic decision-making algorithm based on multiple factors and weights to determine the optimal execution path.

[0043] This algorithm takes into account the following factors: Functionality Availability: Determines whether a plugin capable of executing the target action exists on the current platform based on the plugin registry; Performance cost: Evaluate the execution cost of different plugins (such as time consumption, energy consumption, etc.); Version compatibility: Prioritize the plugin version that is most compatible with the current application version; Link status: Prioritize using currently loaded plugin instances that do not require re-initialization to reduce latency; Proxy execution and result return: Based on the decision result, the native layer dynamic router dynamically creates the target plugin instance and executes the corresponding method using Java reflection (Android) or Runtime API (iOS). The execution result or exception information is uniformly encapsulated by the router and returned to the front end through the UniApp bridging mechanism.

[0044] (2) Multi-factor weighted selection algorithm.

[0045] The native layer dynamic router employs a multi-factor weighted dynamic selection algorithm to select the optimal plugin instance from multiple candidate plugins that implement the same function (action). To execute request R. The following is a formal description of the algorithm.

[0046] Given a route request R, which includes a function identifier (action), platform type (platform), and parameters (params), consider the following set of candidate plugins. Each of the plugins Both declare support for requesting action R.

[0047] The goal is to find a plugin. This results in its overall weight score. Maximum, that is: The formula for calculating the overall score is as follows: in, For the overall score; The weight of the k-th evaluation factor satisfies The weights can be configured according to application requirements (such as performance priority, stability priority, or security priority); For the k-th evaluation factor in the plugin The normalized score under request R has a value range in the interval [0,1]. The higher the value, the better the performance of the factor.

[0048] If a plugin fails to execute, the system can reduce the plugin's weight or remove it based on feedback, and select the next best plugin to retry, thereby improving the system's fault tolerance and stability.

[0049] (3) Plugin lifecycle management.

[0050] The system also provides unified plugin lifecycle management, including plugin loading, initialization, caching, and destruction. It manages the lifecycle of plugin instances using reference counting and the LRU (Least Recently Used) strategy, achieving optimized memory usage and efficient resource utilization.

[0051] The specific implementation process of this system is described below.

[0052] 1. Preparation phase: System environment setup and basic configuration.

[0053] This system relies on the standard UniApp development environment and the corresponding native development environment.

[0054] (1) UniApp Project Creation and Configuration: Create a new UniApp project using HBuilder X or CLI commands (vue create-pdcloudio / uni-preset-vue) and correctly configure App module permissions in the manifest.json file. This system requires enabling JS Native capabilities in the module configuration to serve as a channel for interaction between the front-end and native code. Create a dedicated directory (such as universal-bridge) in the project to store the system's front-end SDK code.

[0055] (2) Native development environment preparation: For Android, use Android Studio to open the nativeplugins directory under the UniApp project (or create it as needed) to carry out native plugin development and ensure that the Android SDK and Gradle build tool versions are compatible; for iOS, use Xcode to open the iOS project in the nativeplugins directory and configure a valid developer certificate and description file.

[0056] (3) Establishment of the plugin registry: The system needs to build a centralized plugin registry, which can be implemented in two ways: built-in and remote.

[0057] Built-in: The registry is packaged directly into the App resource directory as a predefined JSON configuration file (such as plugins-manifest.json), and the file records the metadata of all pre-built plugins.

[0058] Remote: The registry is deployed to the server, and the latest data is pulled from a specified URL when the app starts or periodically to support dynamic updates and hot-swapping of plugins.

[0059] 2. Planning Phase (Step 1): Implementation of the front-end general bridging SDK.

[0060] The front-end SDK is a unified interface that developers call, and its design goal is simplicity and consistency.

[0061] SDK Design and Packaging: Create a JavaScript module named UniversalBridge, which provides the main invoke method. This method accepts a configuration object as a parameter, which must contain an action field and optionally include callback functions such as params, success, fail, and complete.

[0062] Within the SDK, this method does not depend on a specific native implementation, and its core responsibilities include: (1) Parameter validation: Validate the validity of required fields such as action; (2) Call encapsulation: Encapsulate the call request and callback function into a standardized message format; (3) Bridge call: Send the message to the native unified bridge entry module through the uni.requireNativePlugin or uni.sendNativeEvent methods provided by UniApp; (4) Callback management: Receive the results or error information returned by the native layer and trigger the corresponding front-end callback function.

[0063] In addition, the SDK should have a unified error handling mechanism to deal with network errors, missing modules, parameter parsing failures, etc., and should provide TypeScript type definition files (.d.ts) to enhance the type hints and code completion experience.

[0064] 3. Planning Phase (Second Step): Implementation of the unified entry module for the native layer.

[0065] The native layer unified entry module is responsible for connecting front-end calls and core logic.

[0066] Android Implementation: Create a class in the Android project that inherits from `io.dcloud.feature.uniapp.bridge.UniModule`, and expose methods for front-end calls using the `@UniJSMethod` annotation. The `invoke` method receives SDK call requests, parses parameters, and forwards them to the native layer dynamic router for processing. The running thread should be set to a non-UI thread (`uiThread = false`) to prevent blocking the interface. Finally, the execution result is sent back to the front-end via `UniJSCallback`.

[0067] iOS implementation: Create a class that inherits from DCUniModule in the iOS project, and expose methods to the front end using the macro UNI_EXPORT_METHOD. Its internal logic is the same as that of the Android side: parse parameters, call the router, and return the result through callback.

[0068] HarmonyOS Next implementation: In the HarmonyOS Next project, create a class that inherits from com.example.uniappbridge.UniModule, and expose methods using the @UniJSMethod annotation as the entry point for the front-end SDK. In the invoke method, parse the parameters and forward the request to the native layer dynamic router for processing. Specify that it runs on a non-UI thread using thread scheduling parameters. Finally, use UniJSCallback to return the execution result to the front-end, completing a full front-end and back-end interaction.

[0069] 4. Execution phase: Implementation of the native layer dynamic router.

[0070] The native layer dynamic router is the core decision-making center of the system, responsible for plugin selection, invocation, and distribution.

[0071] (1) Registry loading and parsing: When the router starts, it loads and parses the JSON configuration file from the built-in resources or remote server, caches its contents as a memory hash map (HashMap / Dictionary), and uses the action as the key and the corresponding plugin metadata list as the value to achieve fast retrieval.

[0072] (2) Implementation of multi-factor weighted routing algorithm.

[0073] Performance cost factor: The initial value is obtained from the performanceCost field of the plugin metadata, and the average execution cost of each plugin can be dynamically updated through runtime monitoring to improve the accuracy of decision-making.

[0074] Instance status factor: Interacts with the plugin instance pool to obtain the loading, active, or cached status of plugin instances in real time.

[0075] Version compatibility factor: The compatibility score is evaluated by comparing the versionCode in the plugin metadata with the current App version number (which can be written during the compilation stage or read from the configuration file).

[0076] Based on the above system, a plugin invocation method is implemented. The core mechanism of this method lies in the decision-making and execution of the native layer dynamic router. For example... Figure 2 As shown, the overall process of this method includes four steps: candidate set retrieval, filter chain processing, scorer chain and weighted synthesis, and decision output. The diagram illustrates the complete logic from candidate plugin retrieval to filtering, scoring, and decision-making: the process terminates when the platform filter fails; if it passes, it sequentially enters the scorer chain, where weighted scoring is performed using performance cost factors, instance status factors, and version compatibility factors. If a plugin with the highest score exists, it is selected; otherwise, cases with the same score are handled according to preset rules. The specific processing steps of this method are described below.

[0077] Step 1: Candidate set retrieval.

[0078] When the native layer dynamic router receives a call request R, it first uses the action field in the request as the key to retrieve the corresponding set of plugins from the plugin registry index cached in memory, thus obtaining an initial candidate set. Each of the plugins The metadata of all components declares support for this action. This step performs an initial screening based on functional compatibility to ensure that subsequent calculations are performed only on relevant plugins, thereby improving execution efficiency.

[0079] Step 2: Filter chain processing.

[0080] This step aims to quickly eliminate unqualified plugins based on hard constraints, thereby reducing the size of the candidate set.

[0081] Each candidate plugin P is checked using the platform filter. i Does the `platform` attribute match the `platform` attribute in request R? For example, when the request originates from the iOS platform, all Android plugins need to be filtered out. The filtered result is the candidate set. .like If the value is empty, the algorithm terminates immediately and returns a "No plugin available" error message.

[0082] Step 3: Scorer chain and weighted summation.

[0083] This step involves filtering the candidate plugins. Each plugin in A multi-dimensional quantitative assessment is conducted, and a comprehensive fitness score is calculated. This includes two parts: factor calculation and weighted summation.

[0084] 1. Factor calculation.

[0085] Each evaluation factor can be calculated in parallel or sequentially, and each factor is defined as a function. The output value is normalized to the interval [0,1], where 1 represents the best and 0 represents the worst.

[0086] (1) Performance-cost factor : in, For plugins The historical average execution cost (in milliseconds); λ is the decay coefficient used to control the degree of influence of cost on the score. The higher the execution cost, the lower the score.

[0087] (2) Instance state factor : The instance status factor is a discrete scoring index based on the plugin's running status, and its calculation method is as follows: When the plugin is in a loaded and initialized state, record ; When the plugin is only loaded but not yet initialized, record... ; When the plugin is neither loaded nor initialized, record .

[0088] (3) Version compatibility factor : in, Indicates the current application version. This indicates the plugin version; the smaller the absolute difference between the two, the closer the score is to 1, indicating better compatibility.

[0089] 2. Weighted summation.

[0090] The plugin is obtained by multiplying the scores of each factor by their corresponding weights and then summing the results. Overall score: in, This indicates the overall score; Each weight is a key configuration parameter of the system, determining the algorithm's bias. For example, if performance is a priority, it can be set... .

[0091] Step 4: Decision-making and output.

[0092] Traversing the candidate set Select the plugin with the highest overall score. If multiple plugins have the same score, a tie-breaking strategy will be used to select the winner. Common tie-breaking strategies include: ① prioritizing plugins with lower performance costs; ② prioritizing plugins with newer versions; ③ randomly selecting a plugin. This embodiment uses the strategy of prioritizing plugins with lower performance costs to optimize the overall user experience.

[0093] Finally, select the plugin The metadata is returned to the caller (usually a unified entry module), completing a full dynamic routing decision process.

[0094] The following provides a specific embodiment that details the complete process occurring internally within the system when a user calls the device.getBatteryInfo function, thereby illustrating the implementation of the present invention. Figure 3 As shown.

[0095] 1. Prerequisites.

[0096] Two Android plugins supporting device.getBatteryInfo have been registered in the registry: BatteryPluginV1 (high operating cost) and BatteryPluginV2 (low operating cost). An instance of BatteryPluginV2 has been created and cached in the plugin instance pool, with a status of loaded / cached.

[0097] 2. Processing flow.

[0098] Step 1 (Front-end call): The developer writes the code UniversalBridge.invoke({action: 'device.getBatteryInfo', success: (res) => { ...}}) in the front-end Vue component.

[0099] Step 2 (Bridge Communication): The front-end SDK passes this call to the Android native module UniversalBridgeModule through the UniApp framework's JS-Native bridging mechanism.

[0100] Step 3 (Triggering Routing): The invoke method of UniversalBridgeModule is called, which parses action='device.getBatteryInfo' and platform information. Then, a RouteRequest object is created and DynamicRouter.selectOptimalPlugin is called to trigger dynamic routing decisions.

[0101] Step 4 (Decision Process): The native layer dynamic router queries the registry to retrieve the candidate plugin set, obtaining two candidates: BatteryPluginV1 and BatteryPluginV2. Then, platform filtering is performed (both are eligible), selecting usable plugins. Next, a weighted score is applied to both: BatteryPluginV2 has a significantly higher overall score than BatteryPluginV1 due to its lower performance cost (85.0 < 120.5), better instance status (cached), and the same version compatibility. Therefore, the router selects BatteryPluginV2 as the preferred plugin. .

[0102] Step 5 (Obtaining an Instance): The router requests an instance of BatteryPluginV2 from the PluginInstancePool. The instance pool finds an existing cached instance and directly returns that instance (incrementing its reference count by 1), avoiding the overhead of reflection-based creation.

[0103] Step 6 (Native Execution): The router calls the execute method of the BatteryPluginV2 instance. Internally, the plugin uses Android's BatteryManager API to obtain the current battery percentage information.

[0104] Step 7 (Result Return): After obtaining the power data, BatteryPluginV2 returns the result to the router via IPluginCallback.onSuccess, then to UniversalBridgeModule, and finally encapsulates the result via UniJSCallback and returns it to the front-end layer.

[0105] Step 8 (State Update): After execution, the instance pool calls `releaseInstance`, decrementing the instance's reference count by 1. Since its count is not zero, the instance is returned to the cached state, awaiting the next call.

[0106] Step 9 (Front-end Response): The front-end SDK receives a success response, triggers the success callback function defined by the developer, and the UI is updated to display battery information.

[0107] Through the detailed description of the above embodiments, it can be seen that the present invention provides a complete and implementable technical solution. The system of the present invention effectively solves the pain points of native function extension in UniApp development through three core innovations: dynamic routing algorithm, unified lifecycle management, and centralized plugin registry. It achieves automated and intelligent plugin management and invocation, significantly improving development efficiency and runtime performance.

[0108] To further verify the superiority of the technical solution of this invention, the system performance was quantitatively evaluated through multi-dimensional experimental testing. The test environment was based on mainstream hardware devices (Xiaomi 13 Ultra (Snapdragon 8 Gen2, 12GB RAM) for Android, iPhone 14 Pro (A16 chip, 6GB RAM) for iOS, and Huawei nova 13 Pro (model MIS-AL00, 12GB RAM) for HarmonyOS Next). 1000 high-frequency native function calls were used as test cases. The key performance indicators of the traditional UniApp native plugin development mode and the solution of this invention were compared. The test results are as follows.

[0109] 1. Development efficiency: The solution of this invention does not require writing redundant cross-platform bridging code and complex configurations. The development and integration cycle of a single native function is shortened by an average of 68%, with configuration steps reduced by 82% on Android, 75% on iOS, and 78% on HarmonyOS Next.

[0110] 2. Call efficiency: The average response time of a single API call is reduced by 42% compared to the traditional mode. On Android, it is optimized from 18.6ms to 10.7ms, on iOS, it is optimized from 15.3ms to 8.9ms, and on HarmonyOS Next, it is optimized from 16.8ms to 9.7ms. There is no significant performance degradation after 1000 consecutive calls.

[0111] 3. Resource consumption: The plugin instance pool optimizes memory usage through the LRU strategy, reducing memory consumption by 35% for the same number of plugins. The average memory usage on Android has decreased from 28.5MB to 18.5MB, on iOS from 22.3MB to 14.5MB, and on HarmonyOS Next from 25.7MB to 16.7MB. The average CPU utilization has decreased by 23%.

[0112] 4. Compatibility: Supports all versions of iOS 12.0+, Android 8.0+, and HarmonyOS Next 4.0+, with a plugin version compatibility accuracy of 99.2% and no cases of call failure due to version conflicts.

[0113] 5. Robustness: In simulated abnormal scenarios such as plugin execution failure, network interruption, and missing dependencies, the system automatically downgrades and retryes with a success rate of 98.5%, without any crashes, and the response time for exception handling is controlled within 5ms.

[0114] Hot update efficiency: After the remote plugin registry is updated, the plugin hot-plugging takes an average of only 2.3ms. Plugin replacement can be completed without restarting the application, which is more than 99% more efficient than the traditional application reinstallation and update mode.

[0115] The experimental data above fully demonstrates that the solution of the present invention is significantly superior to the traditional solution in terms of development efficiency, running performance, resource consumption, compatibility and robustness. It can effectively solve the core pain points of UniApp native function bridging and has extremely high practical application value.

[0116] Although the present invention has been disclosed above with reference to embodiments, it is not intended to limit the present invention. Appropriate modifications or equivalent substitutions made by those skilled in the art to the technical solutions of the present invention should be covered within the protection scope of the present invention, which is defined by the claims.

Claims

1. A bridging plugin system based on UniApp universal native functions, characterized in that, include: A front-end general bridging SDK is used to generate and send API call requests containing function identifiers and platform types, and to perform parameter serialization and signature verification on the requests. A centralized plugin registry is used to store metadata information of each plugin instance, and when a query request is received, it returns an initial set of candidate plugin instances that support the function identifier. A native layer dynamic router is used to receive the API call request, query the centralized plugin registry according to the function identifier to retrieve the initial candidate plugin instance set, and apply a filter chain to process the initial candidate plugin instance set to obtain a filtered candidate plugin instance set. It is also used to calculate the comprehensive weight score of each plugin instance in the filtered candidate plugin instance set using a scorer chain, and select the plugin instance with the highest score as the optimal plugin instance based on the comprehensive weight score, execute the API call request through the optimal plugin instance and return the execution result.

2. The system as described in claim 1, characterized in that, The front-end general bridging SDK also includes parameter validation, call encapsulation, bridging call and callback management functions.

3. The system as described in claim 1, characterized in that, The establishment of the centralized plugin registry includes embedding the registry in the application resource directory or deploying it on a remote server, and supporting dynamic updates and hot-swapping; the plugin instance metadata stored in the centralized plugin registry includes the plugin's unique identifier, a list of functional methods, version number, and performance cost indicators; the centralized plugin registry is a JSON configuration file embedded in the application resource directory, or deployed on a remote server and retrieved over the network.

4. The system as described in claim 1, characterized in that, The filter chain includes at least a platform filter, which is used to remove plugin instances whose platform attributes do not match the platform type of the API call request; the filter chain also includes a version filter, a dependency filter, and a state filter, which are used to remove the corresponding plugin instances when the plugin instance version is incompatible, the dependency is missing, or the state is abnormal.

5. The system as described in claim 1, characterized in that, It also includes a native layer unified entry module, which is used to receive front-end requests and forward the requests to the native layer dynamic router for processing; the native layer unified entry module inherits UniModule on the Android side and exposes methods using annotations, and inherits DCUniModule on the iOS side and exposes methods using macro definitions.

6. The system as described in claim 1, characterized in that, The scoring chain includes performance cost factors, instance status factors, and version compatibility factors, and obtains a comprehensive score for candidate plugin instances through weighted calculation; the native layer dynamic router manages the lifecycle of plugin instances, including loading, initialization, caching, and destruction, and optimizes memory usage using reference counting or least recently used strategies.

7. A plug-in invocation method based on the system according to any one of claims 1-6, characterized in that, Includes the following steps: 1) The native layer dynamic router receives API call requests sent by the front end, and the API call requests include function identifiers and platform types; 2) The native layer dynamic router queries the centralized plugin registry based on the function identifier to retrieve an initial set of candidate plugin instances that support the function identifier; 3) Apply a filter chain to the initial candidate plugin instance set. The filter chain includes at least a platform filter to remove plugins whose platform attributes do not match the platform type of the API call request, thus obtaining a filtered candidate plugin instance set. 4) Apply a scorer chain to each plugin instance in the filtered candidate plugin instance set to calculate a comprehensive weight score; 5) Select the plugin instance with the highest score from the filtered candidate plugin instance set based on the comprehensive weight score as the optimal plugin instance; 6) Execute the API call request through the optimal plugin instance and return the execution result to the front end.

8. The method as described in claim 7, characterized in that, The API call request mentioned in step 1) is generated by the front-end general bridging SDK. This front-end general bridging SDK encapsulates a unified invoke method, receives the function identifier, parameters and callback function, and sends the API call request to the native layer dynamic router through the UniApp bridging mechanism.

9. The method as described in claim 7, characterized in that, Step 4) involves calculating the overall weighted score, which includes: Obtain multiple preset evaluation factors and their corresponding weights, including performance cost factors, instance status factors, and version compatibility factors; Calculate the evaluation factor values ​​for each plugin instance in the filtered candidate plugin instance set; The comprehensive weight score is obtained by multiplying each factor value of each plugin instance by its corresponding weight and then summing the results. The steps for calculating the values ​​of each evaluation factor mentioned above include: Calculate the performance cost factor: Obtain the historical average execution cost of the plugin instance and calculate the factor value based on the historical average execution cost; Calculate instance state factors: Query the plugin instance pool to get the current state of the plugin instance, and assign discrete score values ​​according to the current state. The current states are loaded and initialized, loaded only, and not loaded, and the values ​​are assigned in descending order. Calculate the version compatibility factor: Obtain the current application version number and the plugin instance version number, calculate the absolute difference between the two, and the factor value is inversely proportional to the absolute difference.

10. The method as described in claim 7, characterized in that, If multiple plugin instances have the same highest comprehensive weight score in step 5), a tie-breaking strategy is adopted, prioritizing the plugin instance with the lowest performance cost; if the optimal plugin instance fails to execute in step 6), it is downgraded or removed from the candidate set, and the second-best plugin instance is selected from the set for retry; after receiving the API call request, the native layer dynamic router further performs instance state factor calculation, which is used to correct the comprehensive weight score of the candidate plugins according to the plugin loading state and initialization state.

Images