Cross-end service framework implementation method, device, electronic device and storage medium

Abstract

The present application provides a method, device, electronic device and storage medium for implementing a cross-end service framework. The method includes: dividing the business functions of an application into multiple plug-in business modules according to the business domain, and each business module carries a plug-in description file for identifying dependencies and version information; abstracting the preset system functions into a set of system service interfaces; establishing a service locator container, statically registering the core business module and the native implementation of the system service interface that matches the current operating platform; when it is detected that the business module to be called is not loaded, the plug-in manager downloads the corresponding plug-in package according to the plug-in description file; in the interface rendering stage, parsing the theme tag set based on the identifier and the system display mode, generating interface style data and providing it to the business module for interface rendering. The present application can achieve a unified system service interface abstraction, improve interface version consistency and type safety, and support on-demand downloading and hot-plug loading of business modules.

Description

Technical Field

[0001] The present application relates to the field of mobile terminal software technology, and in particular to a method, device, electronic device and storage medium for implementing a cross-terminal service framework. Background Art

[0002] With the rapid evolution of mobile, desktop, and web applications, enterprises often seek to deliver products of different brands or versions across multiple platforms, including Android, iOS, Windows, macOS, and browsers, using a unified codebase to shorten development cycles and reduce operational costs. Cross-platform rendering engines like Flutter and Dart are widely adopted for their "what you see is what you get" UI rendering capabilities. However, traditional approaches often compile all business logic and native adaptation code into a single package, using conditional imports at compile time to handle platform differences. While this monolithic architecture alleviates the problem of multi-platform code forking, it introduces new maintenance burdens such as bloated packages, coarse update granularity, and tightly coupled platform interfaces. Adding new features, replacing third-party SDKs, or customizing UIs for specific brands often requires repackaging and distributing the entire package, making it difficult to meet business needs for rapid iteration and targeted upgrades.

[0003] To improve flexibility, some existing solutions attempt to implement external strategies of "branching by platform" or "packaging by brand" through multi-package distribution or handwritten MethodChannel and JSBridge to encapsulate native capabilities. However, these solutions still scatter the logic of platform differences in the business layer and lack a unified system service interface abstraction. At the same time, the lack of reliable runtime plug-in management and dependency injection mechanisms makes it impossible to hot-swap business modules on demand, and it is difficult to ensure the consistency of interface versions and type safety. In addition, brand-level theme styles are usually solidified at compile time and cannot be dynamically switched according to the operating environment or user preferences. Plugins and hosts share the same process space, and permission granularity control is insufficient, posing a high potential security risk. These shortcomings have resulted in significant room for improvement in existing cross-end frameworks in terms of code reuse, package tailoring, runtime extensions, security isolation, and unified style management. Summary of the Invention

[0004] In view of this, the embodiments of the present application provide a cross-end service framework implementation method, device, electronic device and storage medium to solve the problems in the existing technology that lack a unified system service interface abstraction, it is difficult to ensure the consistency of interface version and type safety, and it is impossible to dynamically load and hot-swap business modules on demand.

[0005] In a first aspect, embodiments of the present application provide a method for implementing a cross-end service-oriented framework, which is applied to a terminal system including a cross-end rendering engine and a native service implementation layer. The method comprises: dividing the business functions of an application into multiple plug-in business modules according to business domains, each business module carrying a plug-in description file for identifying dependencies and version information; abstracting preset system functions into a set of system service interfaces, and making each business module dependent on the set of system service interfaces; obtaining information about the current operating platform when the cross-end rendering engine is started, establishing a service locator container, and statically registering core business modules and native implementations of system service interfaces that match the current operating platform; when a business module calls a system service interface, the service locator container injects the corresponding native implementation instance into the business module based on the current operating platform; when it is detected that the business module to be called is not loaded, the plug-in manager downloads the corresponding plug-in package based on the plug-in description file, verifies its integrity, and then loads it in an independent execution environment, registering the newly added business module and the corresponding service interface with the service locator container; connecting the native implementation to the cross-end rendering engine via a cross-end communication bridge, and parsing a theme tag set based on the identifier and the system display mode during the interface rendering phase to generate interface style data and provide it to the business module for interface rendering.

[0006] According to a second aspect of an embodiment of the present application, a cross-end service framework implementation device is provided, which is applied to a terminal system including a cross-end rendering engine and a native service implementation layer, including: a division module for dividing the business functions of an application into multiple plug-in business modules according to business domains, each business module carrying a plug-in description file for identifying dependencies and version information; an abstraction module for abstracting preset system functions into a set of system service interfaces, and making each business module dependent on the set of system service interfaces; an establishment module for obtaining the current operating platform information when the cross-end rendering engine is started, establishing a service locator container, and statically registering the core business module and the system service interface matching the current operating platform. native implementation; an injection module, which is used when the business module calls the system service interface, and the service locator container injects the corresponding native implementation instance into the business module according to the current operating platform; a loading module, which is used when it is detected that the business module to be called has not been loaded, and the plug-in manager downloads the corresponding plug-in package according to the plug-in description file, verifies the integrity and loads it in an independent execution environment, and registers the new business module and the corresponding service interface with the service locator container; a generation module, which is used to connect the native implementation with the cross-end rendering engine through a cross-end communication bridge, and parse the theme tag set based on the identifier and system display mode in the interface rendering stage, generate interface style data and provide it to the business module for interface rendering.

[0007] According to a third aspect of an embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the steps of the above method are implemented when the processor executes the computer program.

[0008] According to a fourth aspect of the embodiments of the present application, a computer-readable storage medium is provided, which stores a computer program. When the computer program is executed by a processor, the steps of the above method are implemented.

[0009] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects:

[0010] By dividing the business functions of the application into multiple plug-in business modules according to the business domain, each business module carries a plug-in description file for identifying dependencies and version information; abstracting the preset system functions into a set of system service interfaces, and making each business module dependent on the set of system service interfaces; obtaining the current operating platform information when the cross-end rendering engine is started, establishing a service locator container, statically registering the core business module and the native implementation of the system service interface that matches the current operating platform; when the business module calls the system service interface, the service locator container injects the corresponding native implementation instance into the business module based on the current operating platform; when it is detected that the business module to be called is not loaded, the plug-in manager downloads the corresponding plug-in package according to the plug-in description file, loads it in an independent execution environment after verifying its integrity, and registers the newly added business module and the corresponding service interface with the service locator container; connecting the native implementation to the cross-end rendering engine through a cross-end communication bridge, and parsing the theme tag set based on the identifier and system display mode in the interface rendering stage, generating interface style data and providing it to the business module for interface rendering. This application can achieve a unified system service interface abstraction, improve interface version consistency and type safety, and support on-demand downloading and hot-plug loading of business modules. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1 This is a flow chart of a method for implementing a cross-end service framework provided by an embodiment of the present application;

[0013] Figure 2 This is a schematic diagram of the structure of a device for implementing a cross-terminal service framework provided by an embodiment of the present application;

[0014] Figure 3 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0015] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0016] In order to solve the problem of multi-platform and multi-APP platformization technology and realize the problem of maintaining multiple APs on multiple platforms with one set of code, this application provides a technical solution based on the cross-end service framework of Flutter / Dart. The technical implementation ideas of this application's technical solution include:

[0017] Through platformization and service-oriented means, the same set of code programs can be presented in different product forms. The main technical contents include:

[0018] 1. Coarse-grained business code modularization.

[0019] 2. Implement different interface implementations for different platforms through dependency inversion.

[0020] 3. Implement multifaceted styles through Flutter's internal Provider Pattern mechanism, such as InheritedWidget.

[0021] The details of the technical solution of this application are as follows:

[0022] 1. Modular splitting of business code

[0023] 1.1 Granularity and method of module division

[0024] According to the business function modularization, it is encapsulated into different plug-in libraries.

[0025] Businesses communicate with each other through a unified service interface, mainly using dependency injection.

[0026] 1.2 Module registration and management mechanism

[0027] Different platforms and applications first statically register the core modules, and the remaining modules are loaded and updated on demand in the form of plug-ins.

[0028] 2. Specific implementation of dependency inversion

[0029] By abstracting different functions into various system service interfaces, including routing jumps, network requests, protocol execution, etc., each business module uses the service interface to execute corresponding functions.

[0030] 2.1 How to provide specific implementation for different platforms

[0031] Each platform implements its own system service interface and injects it into the global dependency container. It involves calling native code using MethodChannel and Dart FFI mechanism for native or system functions.

[0032] MethodChannel uses pigeon to define a unified type-safe interaction protocol.

[0033] Using the get_it dependency injection framework, how to inject corresponding service implementations based on relevant information of different platforms when Flutter starts.

[0034] 3. Specific implementation of multi-terminal UI adaptation

[0035] 3.1 How to manage UI component adaptation

[0036] Define your own style system protocol and adapt to different styles based on the Theme mechanism.

[0037] 3.2 Special optimization of Flutter multi-terminal UI rendering

[0038] Use adaptive layout on different platforms (Web / mobile).

[0039] On different platforms, relying on the Flutter rendering engine, it provides unified, cross-platform animation, gesture interaction, and screen adaptation.

[0040] Supports dynamic theme switching and can be customized for different brands of UI.

[0041] 4. Cross-end communication mechanism

[0042] For native or system functions, MethodChannel and Dart FFI are used to communicate with native functions, and EventChannel is used to listen for continuous native push information. On the web side, JS bridging is mainly used to interact with browser APIs.

[0043] The contents of the technical solution of this application are described in detail below with reference to the accompanying drawings and specific embodiments.

[0044] Figure 1 This is a flow chart of the cross-end service framework implementation method provided by the embodiment of this application. Figure 1As shown, the cross-end service framework implementation method is applied to a terminal system including a cross-end rendering engine and a native service implementation layer, and specifically may include:

[0045] S101, dividing the business functions of the application into multiple plug-in business modules according to business domains, each business module carries a plug-in description file for identifying dependency relationships and version information;

[0046] S102, abstracting the preset system functions into a set of system service interfaces, and making each business module dependent on the set of system service interfaces;

[0047] S103, when the cross-end rendering engine is started, the current operating platform information is obtained, a service locator container is established, and the core business module and the native implementation of the system service interface that matches the current operating platform are statically registered;

[0048] S104, when the business module calls the system service interface, the service locator container injects the corresponding native implementation instance into the business module based on the current operating platform;

[0049] S105, when it is detected that the service module to be called has not been loaded, the plug-in manager downloads the corresponding plug-in package according to the plug-in description file, verifies the integrity and loads it in the independent execution environment, and registers the newly added service module and the corresponding service interface with the service locator container;

[0050] S106, connect the native implementation with the cross-end rendering engine through a cross-end communication bridge, and parse the theme tag set based on the logo and system display mode in the interface rendering stage, generate interface style data and provide it to the business module for interface rendering.

[0051] In some embodiments, the business functions of an application are divided into multiple plug-in business modules according to business domains. Each business module carries a plug-in description file for identifying dependencies and version information, including:

[0052] Analyze the dependencies of the application source code based on the preset business domain division rules, determine the code boundaries of each business domain, and assign a unique business module identifier to each business domain;

[0053] Generate a plug-in project for each business domain according to the business module identifier, and encapsulate the corresponding business logic code, resource files and interface declarations into a plug-in business module;

[0054] Generate a corresponding plug-in description file for each plug-in business module, and package the plug-in business module together with the plug-in description file into an independent plug-in package and store it in the plug-in warehouse for the plug-in manager to perform download, verification and loading operations according to the plug-in description file.

[0055] Specifically, first, the platform predefines a set of business domain division rules. The rules use "functional responsibilities-data boundaries-interaction entrances" as the division dimensions, and divide all source code into several business domains such as account domain, product domain, transaction domain, message domain, and marketing domain. The static dependency analysis tool integrated in the project build pipeline will scan the import relationship, service call trajectory and resource reference list of the source file before compilation, determine the coupling strength between modules through graph algorithms, mark cross-domain references and output a "dependency matrix" report. In the dependency matrix, if a file accesses two types of core entities at the same time (such as reading order data and message data at the same time), it is marked as a "cross-domain call", requiring developers to split or refactor until only one-way dependencies are retained in the matrix, thereby locking the code boundaries of each business domain.

[0056] The system then automatically assigns a business module identifier to each business domain, using a combination of the company's top-level domain in reverse, the business domain abbreviation, and an ascending sequence, such as com.example.account.01. After generating the identifier, the build pipeline creates a separate plug-in project for that business domain. The build pipeline copies the domain's business logic files, static resources (images, fonts, layout declarations, etc.), and call declarations for system service interfaces to the plug-in project directory. An entry list is also generated in the project's root directory, declaring the plug-in initialization order, the main business entry class, and the service interfaces exposed to other plug-ins.

[0057] Next, the system generates a plugin description file for each plugin project. This file uses a key-value structure and contains at least the following fields: ① a business module identifier; ② a semantic version number, distinguishing between major, minor, and revision numbers; ③ a list of dependent business modules, each with a maximum and minimum compatible version; ④ a minimum core framework version number, indicating the minimum loading limit; ⑤ integrity check information, including the SHA-256 digest value of the plugin package; ⑥ an initialization priority, used by the plugin manager to determine the loading order during the cold start phase; and ⑦ a digital signature block, which uses the platform's private key to jointly sign the key fields and the digest value.

[0058] After the description file is completed, the plugin project and description file are packaged together into a standalone plugin package. The packaging process includes compressing the business code and resources, recalculating and writing the digest value, appending the signature block, and generating a distribution manifest. The generated plugin package is uploaded to the internal plugin repository using the "business module identifier / semantic version number" path. The repository indexes different versions of the same identifier, supporting retrieval and rollback by version range.

[0059] During runtime, when the host application needs to load a certain business domain function, the plug-in manager first queries the local plug-in cache; if there is no hit, it reads the corresponding business module identifier and expected version in the main manifest and initiates a download request to the plug-in repository. After the plug-in package is downloaded, the manager compares the SHA-256 digest, verifies the signature block, and checks the minimum core framework version number; after all checks are passed, the plug-in package is unpacked to the sandbox directory and the plug-in entry class is loaded in an independent execution environment (such as an isolated thread or an isolated virtual machine instance). When the plug-in is initialized, it will register the system service interface set according to the interface listed in the description file, and write the business service mapping relationship exported by itself back to the service locator container for subsequent plug-in or host calls.

[0060] Through the above embodiments, refined plug-in splitting of business functions, precise dependency declaration, version security verification and on-demand dynamic loading are achieved, providing a highly maintainable and highly scalable operating foundation for the cross-end service-oriented framework.

[0061] In some embodiments, the preset system functions are abstracted into a set of system service interfaces, and each business module is made dependent on the set of system service interfaces, including:

[0062] Based on the function list supported by the cross-end rendering engine, determine the system function category, and define the corresponding system service interface for each system function category using a preset interface description language;

[0063] Use the annotation processor to generate cross-end communication bridge stub code and a dependency declaration list that matches the system service interface for the system service interface during the business module compilation phase;

[0064] Inject the generated cross-end communication bridging stub code and dependency declaration list into the corresponding business module, so that the business module can call the native service implementation through the system service interface set;

[0065] When the service locator container is initialized, the dependency declaration list is parsed to establish a dependency mapping relationship between the business module and the system service interface.

[0066] Specifically, in this embodiment, using the "instant messaging + live broadcast" composite application as a scenario, the underlying capabilities such as camera access, file upload, location services, and payment calls are systematically abstracted to build a unified set of system service interfaces, and decouple the calling of business modules from native capabilities. The specific implementation process and technical means of this embodiment are as follows:

[0067] The platform maintains a Cross-Device Capabilities List, which lists the native capabilities accessible by the rendering engine on Android, iOS, web, and desktop. After product and architecture review, these capabilities are grouped into system functionality categories such as multimedia capture, file storage, network communication, location information, secure payment, and sensor input. Each category is assigned a unique capability code (e.g., MEDIA_CAPTURE, LOCATION_SERVICE).

[0068] To ensure cross-language type consistency, the platform pre-defines an interface description language, using a three-part text specification: "interface name + method signature + data structure." All type mapping rules are fixed in the runtime library. For example, the "payment interface" IDL declares the interface name IPaymentService, the method pay(Long orderId, String channel), and the return structure PayResult{String status, String message}. IDL files are stored in the repository's idl / directory and include a version number field to facilitate subsequent compatibility checks.

[0069] The platform integrates a self-developed annotation processor into the build chain. When the business module is compiled, the processor scans the @SystemService and @ServiceMethod annotation tags in its source code and reads the corresponding IDL description; then, based on the target end type:

[0070] Mobile: Generate a double-ended MethodChannel stub file, including the channel name, parameter serialization, and callback encapsulation logic, and write a checksum field bound to the interface version;

[0071] Desktop: Generate FFI header files and dynamic library loading wrapper classes, and map C structures and Dart byte buffers using unified data marshaling rules;

[0072] Web side: Generate a postMessage-based script bridge wrapper, automatically append the domain isolation prefix to avoid cross-site scripting conflicts.

[0073] At the same time, the processor automatically summarizes and generates a dependency declaration list (ServiceRequire.yaml) based on the dependencies of each system service interface, listing the interface name, target version, required platform capability flags and verification summary.

[0074] Furthermore, the generated cross-end communication bridge stub code, along with a dependency manifest, is packaged into the corresponding business module's artifact. To maintain consistent directories within the package, the build script consistently places the stub code in the generated / bridge / path and the dependency manifest in the META-INF / service / path. This allows the business module to access native capabilities directly through the system service interface set after compilation, without having to explicitly understand the differences between MethodChannel, FFI, or JS Bridge.

[0075] In some examples, during the cold start phase of an application, the service locator container first loads the framework-level PlatformManifest.yaml to determine the current running platform and rendering engine version; it then recursively scans the ServiceProvide.yaml (recording the native implementation class path) and ServiceRequire.yaml (recording the dependent interface and version) in all installed plug-in packages. For each system service interface, the container:

[0076] If the platform already has a native implementation class of the matching version, the "Interface → Implementation" entry is written to the mapping table and marked as "Ready";

[0077] If the implementation is missing or the version is incompatible, it will be marked as "pending" and wait for the implementation to be provided by subsequent plug-in packages or incremental patches.

[0078] After completion, the container exposes a unified resolve() interface. When a business module requests IPaymentService at runtime, the container returns instances of ApplePayImpl, GooglePayImpl, or WebPayImpl corresponding to the current platform based on the mapping table.

[0079] Furthermore, when initiating a cross-end call, the bridging stub code writes the interface version number and the parameter MD5 checksum value into the call frame header; after receiving it, the native side compares it with the version and type signature saved when the container was registered. Any inconsistency will return a "protocol version conflict" error and record a log, thereby avoiding crashes or data confusion caused by version drift during runtime.

[0080] Through the above embodiments, unified interface abstraction of system functions, automatic generation of cross-end bridging stubs, precise declaration of dependency lists, dynamic injection of runtime interfaces, and type safety verification are achieved. This enables each business module to call multi-end native capabilities imperceptibly while maintaining high reusability, providing scalable and evolvable underlying support for the cross-end service-oriented framework.

[0081] In some embodiments, when the cross-end rendering engine is started, the current operating platform information is obtained, a service locator container is established, and the core business modules and the native implementation of the system service interface that matches the current operating platform are statically registered, including:

[0082] Parse the preset runtime platform list, obtain the runtime platform identifier, instantiate the service locator container in memory based on the runtime platform identifier, and expose the global access entry;

[0083] Read the core business module list from the core module registry, and pre-register each core business module and the corresponding plug-in description file to the service locator container;

[0084] Load the corresponding native binding library according to the running platform identifier, parse the native implementation class of each system service interface in the system service interface set, and establish a mapping relationship between the system service interface and the native implementation class in the service locator container to obtain the interface implementation mapping table.

[0085] Specifically, in this embodiment, taking a "multi-terminal social-live broadcast aggregation application" as an example, it illustrates how to establish a service locator container, pre-register core business modules based on the operating platform identifier during the cold start process of the cross-terminal rendering engine, and complete the static mapping of the native implementation of the system service interface.

[0086] During the first rendering engine initialization callback after the application process is created, the framework reads the "Operation Platform Manifest" file delivered with the installation package. This manifest lists supported operating systems, processor architectures, rendering backends, and brand codes in a key-value format. The launcher matches each of the actual environment parameters returned by the system API to generate a unique platform identifier, such as android-arm64-opengles-brandA. If no exact match exists in the manifest, the launcher falls back to the nearest neighbor configuration and records the platform compatibility flag for reference in subsequent module loading strategies.

[0087] Furthermore, the framework allocates a contiguous cache area in the heap memory to store the core data structure of the service locator container (hereinafter referred to as "container"):

[0088] Module registration table: stores business module identifiers and references to corresponding instances;

[0089] Interface implementation mapping table: key-value pairs of storage system service interface identifiers and native implementation class references;

[0090] Thread-safe read-write lock: ensures consistency of concurrent access.

[0091] The container is published in singleton mode, globally exposing read-only access entries through the resolve (interface identifier) ​​and lookup (module identifier) ​​methods, and providing transactional write capabilities for batch registration during the startup phase.

[0092] Furthermore, the platform maintains a core module registry in advance. The registry consists of several records, each of which contains the business module identifier, the minimum compatible version number, and the storage path of the plug-in description file. During the cold start process, the launcher traverses the registry in sequence:

[0093] a) Parse the plugin description file to extract the module version, dependency list, and initialization priority;

[0094] b) Create lazy instance placeholders for each core module and write them to the module registry;

[0095] c) If the module has pre-dependencies and they have not been met, the "delayed initialization" status is recorded for subsequent wake-up.

[0096] Through the above steps, the core business module is pre-registered in a placeholder manner, ensuring that the subsequent business logic can resolve the module reference in the container, even if the module body has not yet been actually loaded.

[0097] Furthermore, based on the platform identifier, the launcher searches for the corresponding native binding library in the predefined path:

[0098] Android side retrieves lib / native_services_{arch}.so;

[0099] On iOS, search Frameworks / ServiceKit.framework.

[0100] The web side retrieves the compiled WASM module or JavaScript adaptation layer.

[0101] After successful loading, the framework uses runtime reflection (or export table parsing) to enumerate all implementation classes in the library, filter out classes marked with @ImplementsSystemService, and read the "interface identifier-version number" metadata declared in them. The container then establishes a one-to-one mapping between the system service interface identifier and the native implementation class reference, writing it to the interface implementation mapping table. If multiple versions of the same interface exist, the container retains the most compatible version according to the interface version negotiation rules, while recording the remaining implementations in a backup area for rollback purposes.

[0102] After completing the class scan, the container maintains a complete interface implementation mapping table. Each record in the table contains the interface identifier, implementation class reference, supported platform range, version number, and dependency level. The container serializes this table into a binary snapshot and caches it in the local sandbox directory. The snapshot file is then loaded first during the next cold start, shortening the class scan at startup.

[0103] Furthermore, once both the module registration table and the interface implementation mapping table are complete, the container switches to the "Ready" state and publishes a global access entry via a thread-safe flag. When upper-level services or plugins first resolve dependencies, they simply call the container's resolve method and pass in the interface identifier to retrieve a native implementation instance that matches the current platform. If the retrieval fails, the container returns to the "Unbound" state and triggers a fallback strategy (such as downloading an incremental implementation or falling back to the default implementation).

[0104] Through the above-mentioned method of this embodiment, this embodiment achieves platform awareness during startup, instant construction of the service locator container, placeholder registration of core business modules, and static mapping of system service interfaces to native implementations. This process not only ensures type consistency and version controllability of interface calls, but also provides a reliable service discovery foundation for subsequent dynamic loading of business modules at runtime.

[0105] In some embodiments, when a business module calls a system service interface, the service locator container injects the corresponding native implementation instance into the business module based on the current operating platform, including:

[0106] The business module calls the dependency resolution interface exposed by the service locator container and submits the interface identifier of the target system service interface;

[0107] The service locator container searches the interface implementation mapping table for a native implementation class that matches the interface identifier based on the current operating platform identifier.

[0108] If the corresponding native implementation class is retrieved and no cached instance is found, the native implementation class is instantiated through the platform-specific construction factory and the instance is cached in the service locator container;

[0109] The native implementation instance is returned to the business module in the form of a proxy object, so that the business module can complete the call to the system service interface through the proxy object.

[0110] Specifically, in this embodiment, taking the "Short Video-Live Broadcast" business module running on an Android mobile phone calling IShareService (one of the system service interfaces) as an example, it illustrates how the service locator container resolves dependencies, instantiates native implementations, and returns them to the business module in the form of proxy objects at runtime.

[0111] When a business module needs to share functionality, it obtains the global handle of the service locator container through the static method ServiceLocator.getInstance() and constructs the interface identifier IShareService@1.2.0 (interface name + semantic version number). It then calls the container's public resolve(interfaceKey) interface, submitting the interface identifier as the resolution parameter.

[0112] The service locator container maintains an interface implementation mapping table and an instance cache table internally.

[0113] First, read the running platform identifier android-arm64-opengles-brandA in the platform context as the search dimension;

[0114] Search the mapping table for an entry that fully matches IShareService@1.2.0 and declares support for the current platform identifier. The search result points to the native implementation class com.brandA.share.ImplShareService.

[0115] Furthermore, the container checks the instance cache table and finds that there is no instance cache for the implementation class, so it enters the instantiation process:

[0116] The platform-specific construction factory reads the library path, construction parameter template, initialization hook and other information recorded in the implementation entry;

[0117] Implement the parameterless constructor of the class through reflection call;

[0118] Execute the initialization hook: bind the MethodChannel channel name brandA_share_channel; set the UI thread Looper callback; inject the runtime tracking collector.

[0119] The successfully created implementation object is written to the instance cache table with the key IShareService@1.2.0|android-arm64-opengles-brandA and the last access timestamp is appended for use by the LRU eviction policy.

[0120] Furthermore, to facilitate unified interception, statistics, and exception fallback, the container uses a dynamic proxy generator to construct ShareServiceProxy:

[0121] The Proxy instance implements the same public methods as IShareService. Before each method call, the proxy records the call's starting time and parameter snapshot. After the call completes, it writes the time and result code back to the tracking channel. If the native implementation throws an exception, the proxy captures it, converts it into a framework-level ServiceError, and throws it to the caller. The generated ShareServiceProxy is then returned to the business module.

[0122] Furthermore, after the business module holds the proxy object, it can directly call payLoad=shareService.share(videoId, targetScene) to complete the sharing action:

[0123] The proxy internally packages the method name and serialized parameters and delivers them to the Java layer through MethodChannel. After the native implementation class completes processing, it returns the result through the same channel. The proxy unpacks the package and returns the structured result body ShareResult to the business module.

[0124] Furthermore, if there is no qualified implementation entry in the mapping table, the container immediately returns null and triggers the missing service listener in the background: reporting the missing interface identifier and the current platform identifier to the plug-in manager; the plug-in manager queries the remote repository for new implementation plug-ins, and if so, downloads, verifies, and loads them in an isolated environment; after loading is complete, the mapping table is updated and dependency resolution is retried, so that the business module can obtain the implementation without being aware of it.

[0125] Through the process of the above embodiment, this embodiment realizes runtime dependency resolution, platform difference instantiation, instance-level cache management, unified proxy interception and exception fallback under the cross-end service framework, ensuring that each business module can safely, efficiently and seamlessly call the system service interface on different operating platforms.

[0126] In some embodiments, when it is detected that the service module to be called is not loaded, the plug-in manager downloads the corresponding plug-in package according to the plug-in description file, verifies the integrity and then loads it in the independent execution environment, including:

[0127] Parse the plug-in description file to obtain the plug-in package download address, version number, target architecture, and integrity check value;

[0128] Download the plug-in package from the remote plug-in repository through the preset plug-in repository protocol and temporarily store it in the local cache directory;

[0129] Perform digital signature verification and digest comparison on the downloaded plug-in package based on the integrity check value. If verification passes, continue execution. If verification fails, abandon loading and log an exception.

[0130] Instantiate the plug-in running container in an independent execution environment, load the verified plug-in package, and parse the business logic code, resource files, and system service interface implementation within the plug-in;

[0131] Register the business modules defined in the plug-in package and the corresponding system service interface implementation to the service locator container, and update the interface implementation mapping table.

[0132] Specifically, in this embodiment, taking the first time a user triggers the "live broadcast and microphone connection" function as an example, it explains how the plug-in manager completes the download, verification, isolated operation and service registration of the plug-in package based on the plug-in description file when the host framework detects that the target business module has not yet been loaded.

[0133] First, the framework retrieves the target business module's plugin description file from its internal metadata directory. This description file contains the plugin package's acquisition path, target processor architecture, semantic version information, hash digest value, digital signature block, minimum compatible core framework version, and a list of module dependencies. The plugin manager first verifies that the minimum compatible core framework version meets the current runtime environment requirements and then extracts the acquisition path identifier as a download parameter.

[0134] The plugin manager then sends a download request to the remote plugin repository via a pre-defined plugin repository protocol (a RESTful interface over mutual TLS). The repository responds with a compressed package matching the target architecture based on the platform identifier included in the request, along with a server-generated hash digest in the response header. After downloading, the plugin package is temporarily stored in a local secure cache directory with a randomly generated temporary file name to avoid naming conflicts.

[0135] The plugin manager then calculates a hash digest for the temporary file and compares it to the reference value in the plugin description file. If they match, digital signature verification proceeds. This verification verifies the signature block using the host framework's built-in public key to confirm the plugin package's authenticity and that it has not been tampered with during transmission. If any step fails, the temporary file is deleted, the exception is logged, and the event is reported to the monitoring system.

[0136] In some examples, after verification, the plugin package is moved to a dedicated sandbox directory. The plugin manager creates an isolated runtime container for the package:

[0137] In the Android environment, the plug-in bytecode is loaded through an independent ClassLoader and runs in a separate Isolate thread group;

[0138] In iOS / macOS environments, use the dynamic library binder to load the plugin binary in the child runtime environment;

[0139] In a web environment, compile the bytecode into a separate Web Worker or WASM instance.

[0140] During the process, the static resources of the plug-in are mapped to the virtual resource table to prevent resource identification conflicts; the dependency list is parsed to confirm that the prerequisite module is ready, otherwise the dependent plug-in loading process is recursively triggered.

[0141] After loading, the plugin runtime container executes its entry initialization hook, registers the logging, tracking, and crash monitoring systems, and uses reflection to locate implementation classes marked with the "system service provider" tag. For each system service interface implementation, the plugin manager calls the service locator container's batch write interface, writes the "interface identifier → implementation class" relationship to the interface implementation mapping table, and simultaneously registers an instance reference to the "live broadcast and microphone connection" module in the business module registration table.

[0142] Furthermore, after mapping is complete, the service locator container wakes up all pending dependency resolution requests due to missing implementations. After retrying, the business logic can obtain the system service interface proxy object and successfully invoke the native live broadcast capability. If an exception occurs during plugin loading or initialization, the plugin manager triggers an atomic rollback: uninstalling the plugin, clearing the mapping table increments, restoring the previous stable version, and marking the plugin package as unavailable in the background to prevent repeated loading.

[0143] Through the process of the above embodiment, this embodiment demonstrates how the plug-in manager can realize online acquisition, double integrity verification, isolated operation, dependency resolution and dynamic service registration of plug-in packages without affecting the stability of the host process, providing a secure and scalable business function expansion mechanism for the cross-end service framework.

[0144] In some embodiments, in the interface rendering phase, parsing a theme tag set based on the identifier and the system display mode, generating interface style data, and providing the data to the business module for interface rendering includes:

[0145] Listen to the environment acquisition interface exposed by the cross-end rendering engine to obtain the current logo and system display mode;

[0146] Generate a topic request object based on the current identifier and system display mode, and call the topic resolver to retrieve the corresponding topic tag set from the topic resource repository;

[0147] Input the retrieved theme tag set into the theme parser to parse and obtain interface style data;

[0148] The interface style data is encapsulated as a theme provider object and injected into the root node of the interface rendering tree, so that the business module obtains the interface style data through the inherited context to complete the interface rendering.

[0149] Specifically, in this embodiment, taking the dual-brand release format of "Brand A" and "Brand B" on the same e-commerce platform as a scenario, it illustrates how the cross-end rendering engine parses the theme tag set based on the "brand logo-system display mode" combination during the interface rendering stage, generates interface style data, and injects it into the rendering tree.

[0150] In some examples, before entering the drawing pipeline, the cross-end rendering engine continuously listens for two types of environment change events through the preset EnvironmentService:

[0151] Brand ID: the current brand ID written by the login process;

[0152] System display mode: Light / dark mode changes broadcast by the operating system.

[0153] The listener triggers the theme refresh process immediately when it detects a change in any field, avoiding interface mismatch when switching brands or in night mode.

[0154] Furthermore, when the rendering engine prepares to build the root node of the widget tree, the theme manager reads the latest environment information and encapsulates the brand logo and system display mode into a ThemeRequest object. The brand logo is used to select the brand's primary color and logo form, and the system display mode determines the light / dark tone. This object contains the request timestamp and cache key to facilitate subsequent theme cache hits.

[0155] After receiving the ThemeRequest, the theme resolver first searches for the corresponding token set in the local LRU cache; if it misses, it initiates a query to the theme resource repository:

[0156] The warehouse stores ThemeToken in three levels: "brand level - system level - general level". Each level uses a unified JSON structure to describe colors, layouts, fillets, motion curves and other tags. If a tag is missing in the brand level, it will automatically fall back to the general level to ensure integrity.

[0157] The multi-level token lists retrieved by the parser will be overwritten and merged from top to bottom according to priority to form the final set of topic tags.

[0158] In some examples, the parser converts a theme tag set into interface style data (StyleData) through mapping rules:

[0159] Color palette: primary color, accent color, warning color, background color, text color;

[0160] Typesetting system: title-body text size, font weight, line height;

[0161] Layout spacing: padding, margins, grid width;

[0162] Rounded corners and shadows: control radius, shadow offset;

[0163] Animation curve: three types of curves: entry, exit, and emphasis.

[0164] The conversion process supports device DPI and font scaling factor correction to ensure consistent visual density on different screen sizes.

[0165] Furthermore, the generated StyleData is encapsulated as a ThemeProvider object and injected into the render tree root node as an InheritedWidget. The ThemeProvider also exposes a listener interface, allowing business modules to subscribe to "theme change" events. The rendering engine then begins to build the Widget tree from top to bottom, for example:

[0166] During the build process, each business module's widget obtains the ThemeProvider through the context. If the Provider version number is detected to be inconsistent with the last rendering, a local rebuild is triggered. Business widgets obtain color, layout, and other tokens by unpacking StyleData for style configuration, without having to perceive brand or system differences.

[0167] Furthermore, when the user switches brands in the settings page, or the system switches from light to dark, the EnvironmentService immediately emits an environment change event. The theme manager regenerates the ThemeProvider according to the aforementioned steps and uses a differential algorithm to calculate the set of changes compared to the old token. This triggers a rebuild only for the affected widgets, reducing the redrawing of irrelevant nodes and improving refresh efficiency.

[0168] Through the technical means of the above-mentioned embodiments, this embodiment realizes brand-system dual-dimensional theme analysis, dynamic injection of StyleData, and local differential redrawing during runtime, ensuring that multi-brand applications maintain a unified visual and interactive experience in different display modes, while reducing the impact of interface updates on performance.

[0169] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0170] Figure 2 This is a schematic diagram of the structure of the cross-end service framework implementation device provided by the embodiment of this application. Figure 2 As shown, the cross-end service framework implementation device is applied to a terminal system including a cross-end rendering engine and a native service implementation layer, including:

[0171] A division module 201 is used to divide the business functions of the application into multiple plug-in business modules according to business domains, and each business module carries a plug-in description file for identifying dependency relationships and version information;

[0172] Abstraction module 202, used to abstract the preset system functions into a set of system service interfaces and make each business module dependent on the set of system service interfaces;

[0173] Establishing module 203, which is used to obtain the current operating platform information when the cross-end rendering engine is started, establish a service locator container, statically register the core business module and the native implementation of the system service interface that matches the current operating platform;

[0174] Injection module 204, used for injecting the corresponding native implementation instance into the business module by the service locator container according to the current operating platform when the business module calls the system service interface;

[0175] The loading module 205 is used to, when it is detected that the service module to be called has not been loaded, download the corresponding plug-in package according to the plug-in description file, verify the integrity and load it in the independent execution environment, and register the newly added service module and the corresponding service interface with the service locator container;

[0176] The generation module 206 is used to connect the native implementation with the cross-end rendering engine through a cross-end communication bridge, and parse the theme tag set based on the logo and system display mode in the interface rendering stage, generate interface style data and provide it to the business module for interface rendering.

[0177] In some embodiments, Figure 2 The division module 201 performs dependency analysis on the application source code based on the preset business domain division rules, determines the code boundaries of each business domain, and assigns a unique business module identifier to each business domain; generates a plug-in project for each business domain according to the business module identifier, and encapsulates the corresponding business logic code, resource files and interface declarations into a plug-in business module; generates a corresponding plug-in description file for each plug-in business module, and packages the plug-in business module together with the plug-in description file into an independent plug-in package and stores it in the plug-in warehouse, so that the plug-in manager can perform downloading, verification and loading operations according to the plug-in description file.

[0178] In some embodiments, Figure 2The abstract module 202 determines the system function category based on the function list supported by the cross-end rendering engine, and defines the corresponding system service interface for each system function category using a preset interface description language; uses the annotation processor to generate cross-end communication bridging stub code and a dependency declaration list matching the system service interface for the system service interface during the business module compilation phase; injects the generated cross-end communication bridging stub code and the dependency declaration list into the corresponding business module, so that the business module calls the native service implementation through the system service interface set; parses the dependency declaration list when the service locator container is initialized, and establishes a dependency mapping relationship between the business module and the system service interface.

[0179] In some embodiments, Figure 2 The establishment module 203 parses the preset operating platform list, obtains the operating platform identifier, instantiates the service locator container in the memory based on the operating platform identifier, and exposes the global access entrance; reads the core business module list from the core module registry, and pre-registers each core business module and the corresponding plug-in description file to the service locator container; loads the corresponding native binding library according to the operating platform identifier, parses the native implementation class of each system service interface in the system service interface set, and establishes a mapping relationship between the system service interface and the native implementation class in the service locator container to obtain an interface implementation mapping table.

[0180] In some embodiments, Figure 2 The injection module 204 is used by the business module to call the dependency resolution interface exposed by the service locator container and submit the interface identifier of the target system service interface; the service locator container searches the interface implementation mapping table for a native implementation class that matches the interface identifier according to the current running platform identifier; if the corresponding native implementation class is retrieved and no cached instance is found, the native implementation class is instantiated through the platform-specific construction factory and the instance is cached in the service locator container; the native implementation instance is returned to the business module in the form of a proxy object, so that the business module completes the call to the system service interface through the proxy object.

[0181] In some embodiments, Figure 2 The loading module 205 parses the plug-in description file to obtain the plug-in package download address, version number, target architecture and integrity check value; downloads the plug-in package from the remote plug-in warehouse through the preset plug-in warehouse protocol and temporarily stores it in the local cache directory; performs digital signature verification and digest comparison on the downloaded plug-in package based on the integrity check value, continues execution after verification, and abandons loading and records an exception if verification fails; instantiates the plug-in running container in the independent execution environment, loads the verified plug-in package, parses the business logic code, resource files and system service interface implementation inside the plug-in; registers the business module defined in the plug-in package and the corresponding system service interface implementation to the service locator container, and updates the interface implementation mapping table.

[0182] In some embodiments, Figure 2 The generation module 206 monitors the environment acquisition interface exposed by the cross-end rendering engine to obtain the current identifier and the system display mode; generates a theme request object according to the current identifier and the system display mode, calls the theme parser to retrieve the corresponding theme tag set from the theme resource repository; inputs the retrieved theme tag set into the theme parser, and parses it to obtain interface style data; encapsulates the interface style data into a theme provider object and injects it into the root node of the interface rendering tree, so that the business module obtains the interface style data through the inherited context to complete the interface rendering.

[0183] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0184] Figure 3 Schematic diagram of the structure of the electronic device 3 provided in the embodiment of the present application. Figure 3 As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, the steps of the above-mentioned method embodiments are implemented. Alternatively, when the processor 301 executes the computer program 303, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0185] For example, computer program 303 may be divided into one or more modules / units, which are stored in memory 302 and executed by processor 301 to implement the present application. One or more modules / units may be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of computer program 303 in electronic device 3.

[0186] The electronic device 3 may be a desktop computer, a notebook, a PDA, a cloud server or other electronic device. The electronic device 3 may include but is not limited to a processor 301 and a memory 302. Those skilled in the art will understand that Figure 3 It is only an example of electronic device 3 and does not constitute a limitation of electronic device 3. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device may also include input and output devices, network access devices, buses, etc.

[0187] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0188] Memory 302 can be an internal storage unit of electronic device 3, such as a hard drive or memory of electronic device 3. Memory 302 can also be an external storage device of electronic device 3, such as a plug-in hard drive, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, etc. Furthermore, memory 302 can include both an internal storage unit of electronic device 3 and an external storage device. Memory 302 is used to store computer programs and other programs and data required by the electronic device. Memory 302 can also be used to temporarily store data that has been output or is about to be output.

[0189] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0190] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

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

[0192] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer equipment and methods can be implemented in other ways. For example, the apparatus / computer equipment embodiments described above are merely schematic. For example, the division of modules or units is merely a logical function division. In actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection of the apparatus or unit, which may be electrical, mechanical or other forms.

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

[0194] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0195] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application can implement all or part of the processes in the above-mentioned embodiment method by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of each of the above-mentioned method embodiments. The computer program may include computer program code, which may be in source code form, object code form, executable file, or some intermediate form. Computer-readable media may include: any entity or device capable of carrying computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium.

[0196] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the technical solutions of the present application are described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A method for implementing a cross-end service framework, characterized in that: Applicable to terminal systems including cross-end rendering engines and native service implementation layers, including: Divide the business functions of the application into multiple plug-in business modules according to the business domain. Each business module carries a plug-in description file for identifying dependencies and version information. Abstract the preset system functions into a set of system service interfaces, and make each business module dependent on the set of system service interfaces; When the cross-end rendering engine is started, the current operating platform information is obtained, a service locator container is established, and the core business modules and the native implementation of the system service interface that matches the current operating platform are statically registered; When a business module calls a system service interface, the service locator container injects the corresponding native implementation instance into the business module based on the current operating platform; When it is detected that the service module to be called has not been loaded, the plug-in manager downloads the corresponding plug-in package according to the plug-in description file, loads it in an independent execution environment after checking the integrity, and registers the newly added service module and the corresponding service interface with the service locator container; Connect the native implementation to the cross-end rendering engine through a cross-end communication bridge, and parse the theme tag set based on the logo and system display mode in the interface rendering phase, generate interface style data and provide it to the business module for interface rendering; The process of abstracting the preset system functions into a set of system service interfaces and making each business module dependent on the set of system service interfaces includes: Based on the function list supported by the cross-end rendering engine, determine the system function category, and define the corresponding system service interface for each system function category using a preset interface description language; Generate cross-end communication bridging stub code and a dependency declaration list matching the system service interface for the system service interface during the business module compilation phase using an annotation processor; Injecting the generated cross-end communication bridging stub code and dependency declaration list into the corresponding business module, so that the business module calls the native service implementation through the system service interface set; When the service locator container is initialized, the dependency declaration list is parsed to establish a dependency mapping relationship between the business module and the system service interface.

2. The method according to claim 1, characterized in that The business functions of the application are divided into multiple plug-in business modules according to the business domain. Each business module carries a plug-in description file for identifying dependency relationships and version information, including: Analyze the dependencies of the application source code based on the preset business domain division rules, determine the code boundaries of each business domain, and assign a unique business module identifier to each business domain; Generate a plug-in project for each business domain according to the business module identifier, and encapsulate the corresponding business logic code, resource files and interface declarations into a plug-in business module; A corresponding plug-in description file is generated for each plug-in service module, and the plug-in service module and the plug-in description file are packaged into an independent plug-in package and stored in the plug-in warehouse for the plug-in manager to perform downloading, verification and loading operations according to the plug-in description file.

3. The method according to claim 1, characterized in that The process of obtaining the current operating platform information when the cross-end rendering engine is started, establishing a service locator container, statically registering the core business module, and natively implementing the system service interface that matches the current operating platform includes: Parse the preset operating platform list, obtain the operating platform identifier, instantiate the service locator container in memory based on the operating platform identifier, and expose the global access entrance; Read the core business module list from the core module registry, and pre-register each core business module and the corresponding plug-in description file to the service locator container; Load the corresponding native binding library according to the operating platform identifier, parse the native implementation class of each system service interface in the system service interface set, and establish a mapping relationship between the system service interface and the native implementation class in the service locator container to obtain an interface implementation mapping table.

4. The method according to claim 3, characterized in that When the business module calls the system service interface, the service locator container injects the corresponding native implementation instance into the business module according to the current operating platform, including: The business module calls the dependency resolution interface exposed by the service locator container and submits the interface identifier of the target system service interface; The service locator container searches the interface implementation mapping table for a native implementation class that matches the interface identifier according to the current operating platform identifier; If the corresponding native implementation class is retrieved and no cached instance is found, the native implementation class is instantiated through the platform-specific construction factory and the instance is cached in the service locator container; The native implementation instance is returned to the business module in the form of a proxy object, so that the business module completes the call to the system service interface through the proxy object.

5. The method according to claim 1, wherein When it is detected that the service module to be called is not loaded, the plug-in manager downloads the corresponding plug-in package according to the plug-in description file, verifies the integrity and then loads it in the independent execution environment, including: Parse the plugin description file to obtain the plugin package download address, version number, target architecture, and integrity check value; Download the plug-in package from the remote plug-in repository through the preset plug-in repository protocol and temporarily store it in the local cache directory; Perform digital signature verification and digest comparison on the downloaded plug-in package based on the integrity check value, continue execution if verification passes, and abandon loading and record an exception if verification fails; Instantiate the plug-in running container in an independent execution environment, load the verified plug-in package, and parse the business logic code, resource files, and system service interface implementation within the plug-in; The business modules defined in the plug-in package and the corresponding system service interface implementations are registered to the service locator container, and the interface implementation mapping table is updated.

6. The method according to claim 1, characterized in that The interface rendering phase involves parsing a theme tag set based on the identifier and the system display mode, generating interface style data, and providing the data to the business module for interface rendering, including: Listen to the environment acquisition interface exposed by the cross-end rendering engine to obtain the current logo and system display mode; Generate a topic request object based on the current identifier and system display mode, and call the topic resolver to retrieve the corresponding topic tag set from the topic resource repository; Input the retrieved theme tag set into the theme parser to parse and obtain interface style data; The interface style data is encapsulated as a theme provider object and injected into the root node of the interface rendering tree, so that the business module obtains the interface style data through the inheritance context to complete the interface rendering.

7. A cross-end service framework implementation device, characterized in that: Applicable to terminal systems including cross-end rendering engines and native service implementation layers, including: A partitioning module is used to divide the business functions of an application into multiple plug-in business modules according to business domains. Each business module carries a plug-in description file for identifying dependencies and version information. An abstraction module is used to abstract the preset system functions into a set of system service interfaces and make each business module dependent on the set of system service interfaces; Establish a module for obtaining the current operating platform information when the cross-end rendering engine is started, establishing a service locator container, statically registering the core business module and the native implementation of the system service interface that matches the current operating platform; An injection module, configured to inject the corresponding native implementation instance into the business module by the service locator container according to the current operating platform when the business module calls the system service interface; A loading module is used to, when it is detected that the service module to be called has not been loaded, download the corresponding plug-in package according to the plug-in description file, load it in an independent execution environment after checking the integrity, and register the newly added service module and the corresponding service interface with the service locator container; A generation module is used to connect the native implementation with the cross-end rendering engine through a cross-end communication bridge, and to parse a theme tag set based on the identifier and the system display mode during the interface rendering phase, generate interface style data, and provide it to the business module for interface rendering; Among them, the abstract module is used to determine the system function category based on the function list supported by the cross-end rendering engine, and define the corresponding system service interface for each system function category using a preset interface description language; use the annotation processor to generate cross-end communication bridging stub code and a dependency declaration list matching the system service interface for the system service interface during the business module compilation phase; inject the generated cross-end communication bridging stub code and the dependency declaration list into the corresponding business module, so that the business module calls the native service implementation through the system service interface set; parse the dependency declaration list when the service locator container is initialized to establish a dependency mapping relationship between the business module and the system service interface.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images