A mobile terminal hybrid modular operation and multi-tenant dynamic distribution method and system

Abstract

The application relates to the technical field of multi-tenant software distribution and management, and provides a mobile terminal hybrid modular operation and multi-tenant dynamic distribution method, which comprises the following steps of S1, triggering a CI / CD process to perform standardized construction, dynamically injecting a configuration according to an environment variable, simultaneously outputting online resources and offline resource package dual-state products in one construction, registering the dual-state products and metadata thereof to an application management center and forming a standard product version record; S2, under a SaaS scenario, issuing a specified version of a sub-application configuration to a target tenant, and under a private deployment scenario, triggering automatic binding to bind the latest product to a private tenant; S3, requesting the latest application configuration of a current tenant when a native App is started, comparing version numbers on the terminal side to determine whether to download and decompress offline resource packages to a local sandbox; when the sub-application is started, a container instance is obtained from a Web view reuse pool and local resources are preferentially loaded, and a bridge layer is used to synchronize a native side state to a Web side, and a business request is initiated after the Web side state management library is updated.

Description

Technical Field

[0001] This invention relates to the technical field of multi-tenant software distribution and management, and in particular to a method and system for mobile terminal hybrid modular operation and multi-tenant dynamic distribution. Background Technology

[0002] In modern enterprise-level SaaS (Software as a Service) applications (such as retail, supply chain, and ERP), mobile products exhibit complex characteristics including multi-module collaboration, multi-team parallel operation, multi-tenant isolation, and multiple deployment models (SaaS / private). To ensure development efficiency while providing an exceptional user experience, systems typically adopt an architecture of "Native Host + H5 (HTML5, Hypertext Markup Language 5) / hybrid sub-applications." This architecture uses a native container to host the web view, leveraging native capabilities to ensure basic performance while utilizing the dynamism of web technologies for rapid iteration, making it the mainstream choice for current enterprise-level mobile applications.

[0003] However, to support such a massive ecosystem, simply addressing "endpoint performance" is insufficient; a closed-loop lifecycle encompassing "code building → asset management → tenant distribution → endpoint operation" must be constructed. Only by seamlessly integrating the data and control flows across these stages can precise version control, on-demand resource delivery, and dynamic runtime adaptation be achieved in a multi-tenant environment, thereby truly meeting the dual requirements of stability and agility for enterprise applications.

[0004] Analysis reveals that existing technologies suffer from multiple shortcomings in achieving the aforementioned closed loop. Besides issues such as fragmented outputs in the engineering and distribution chain (dispersed build products lacking unified management), chaotic multi-tenant version management (different tenants cannot independently select versions, leading to widespread upgrade impact), inconsistent private and SaaS delivery chains (private deployments often require recompilation and packaging, resulting in long delivery cycles), and disconnect between client-side updates and containers (separation of update strategies and container loading logic, leading to resource inconsistencies), running containers on the client side itself also has serious technical flaws, specifically manifested as follows: (1) Performance bottlenecks of pure cross-platform frameworks: In scenarios with high requirements for performance and response speed, such as industrial equipment (e.g., PDAs (Personal Digital Assistants)), apps packaged using pure cross-platform frameworks (e.g., uni-app) face serious performance problems, including slow startup (cold start takes several seconds), memory jitter (frequent allocation and release causing UI lag), and frequent GC (Garbage Collection) (causing the main thread to pause), which seriously affects the operator's work efficiency. These performance bottlenecks stem from the intermediate layer interpretation and bridging overhead of cross-platform frameworks, making it difficult to meet the real-time response requirements on low-end industrial terminals.

[0005] (2) State fragmentation and bridging chaos: The Native and H5 sides maintain their states independently (such as user information, language settings, tenant identifiers, etc.), lacking a unified state synchronization mechanism, resulting in inconsistent data between the two sides. For example, after a user switches tenants, the H5 side still uses the old token, causing authentication failure. At the same time, the JSBridge (JavaScript Bridge) capability is fragmented and open, with different modules arbitrarily registering bridging methods. There is a lack of a unified registry center and lifecycle management (such as not unbinding when the page is destroyed), which can easily lead to bridging conflicts (method overriding or duplicate registration), memory leaks, and call timeouts, seriously reducing communication reliability.

[0006] (3) Distribution chain defects: The H5 sub-application is configured statically during compilation (such as backend service domain name and environment variables are hard-coded during construction), which makes it impossible to achieve version control and canary release based on the tenant dimension. This results in difficulty in version rollback and extremely high risk of new feature verification. Once a release fails, it will affect all tenants. In addition, private deployment lacks an agile channel. Each update requires manual packaging and file replacement, which cannot take advantage of the canary release strategy on the SaaS side, resulting in low delivery efficiency and easy errors.

[0007] In summary, existing technologies urgently need a mobile hybrid modular system that can uniformly solve the problems of the entire build-distribution-running chain. It should simultaneously meet the following requirements: standardized CI / CD dual-state build capability, fine-grained canary release capability in multi-tenant dimension, interface-driven intelligent hot update capability on the client side, and a runtime platform that is deeply integrated with high-performance containers, so as to achieve a unified balance between R&D efficiency, delivery flexibility and client-side user experience in complex enterprise-level SaaS scenarios. Summary of the Invention

[0008] To address the aforementioned issues, the present invention aims to provide a method and system for mobile terminal hybrid modular operation and multi-tenant dynamic distribution. By constructing a unified end-to-end closed-loop technical solution from code construction, asset management, tenant distribution to terminal operation, and combining standardized CI / CD dual-state artifact output, multi-tenant fine-grained canary release, interface-driven intelligent hot update arbitration, and deep integration with a high-performance WebView container pool, this invention effectively solves problems such as artifact fragmentation, chaotic version management, low efficiency of private delivery, terminal performance bottlenecks, and the separation of Native and H5 states in existing technologies. This significantly improves the development efficiency, delivery flexibility, system stability, and terminal user experience of enterprise-level SaaS mobile applications in complex multi-tenant scenarios.

[0009] The above-mentioned objective of this invention is achieved through the following technical solutions: A method for hybrid modular operation and multi-tenant dynamic distribution on mobile devices includes the following steps: S1: At the build layer, trigger the continuous integration (CI) / continuous deployment (CD) process to execute a standardized build, dynamically inject configuration according to environment variables, and output dual-state artifacts of online resources and offline resource packages in one build. The dual-state artifacts and their metadata are registered to the application management center and form a standard artifact version record. S2: At the release scheduling layer, based on the collaboration between the application management center and the portal management system, the specified version of the sub-application configuration is issued to the target tenant in the SaaS scenario, and automatic binding is triggered in the private deployment scenario to bind the latest artifact to the private tenant. S3: On the client-side runtime layer, when the native App starts, it requests the latest application configuration of the current tenant. The client side compares the version number to determine whether to download and decompress the offline resource package to the local sandbox. When the sub-application starts, it obtains a container instance from the Web view reuse pool and loads local resources first. At the same time, it synchronizes the native side state to the Web side through the bridging layer. After the Web side state management library updates, it initiates business requests.

[0010] Further, step S1 specifically includes: Step S11: Trigger Continuous Integration (CI) / Continuous Deployment (CD) build and environment variable injection. When the sub-application code is merged, trigger the Continuous Integration (CI) / Continuous Deployment (CD) process and inject context variables including environment variable VUE_APP_ENV, domain name, and source version fromVersion. Step S12: Dynamically generate the application description file Manifest and package it in two states. In the post-compilation processing stage, execute an automated script to extract the Git commit count as the version number versionCode, read package.json to get the version name versionName, dynamically concatenate and generate an online H5 link h5Url suitable for the current environment, and generate the application description file manifest.json. The compiled output is packaged into an online H5 deployment directory and a WGT offline resource compressed package. The online H5 deployment directory is available for web access or downgrade use, and the WGT offline resource compressed package is available for download by the App to achieve instant opening. Step S13: Application Management Center BOP Input and Version Record Generation. The WGT offline resource compressed package, the generated application description file manifest.json, and metadata are registered to the Application Management Center BOP through the application programming interface (API) to form a standard artifact version record.

[0011] Further, step S2 specifically includes: Step S21: In the Software as a Service (SaaS) scenario, the Portal management system synchronizes the standard artifact library of the Application Management Center (BOP) in real time to achieve data integration; on the Portal management system, operations and maintenance personnel or tenant administrators upgrade the sub-application from version 1 to version 2 for a specific tenant marked with the Tenant ID, and support fine-grained gray-scale distribution by store or by user role. Step S22: In a private deployment scenario, a lightweight channel is provided for private deployment environments without a complex BOP system: after the sub-application build artifacts are sent to the private server, the system automatically triggers a webhook to directly bind the latest version to the private tenant, ensuring agile interaction.

[0012] Further, step S3 specifically includes: Step S31: After the native App starts, it sends an authentication request to the portal management system Portal through the gateway. The portal management system Portal returns the latest list of sub-applications authorized by the currently logged-in user and module information moduleInfo based on the tenant ID of the tenant. Step S32: The App's local module manager ModuleManager compares the issued version number versionCode with the locally cached version number. If an update is needed, it triggers a silent background download of wgtUrl and decompresses it to the dist directory of the local application sandbox. If the download fails or the network is weak, it automatically downgrades to use h5Url as the entry point. Step S33: When the user clicks the sub-application entry, the system obtains a single-instance Web view from the WebView reuse pool, intercepts network requests through the Web view client, and maps static resources to the locally decompressed dist directory that was just hot-updated to achieve instant first-screen loading; when the Web view loads, the system natively serializes the serviceUrl, tenant information tenantInfo, and token information tokenInfo through JsBridge and pushes them to the H5. The Vuex state management library on the H5 side automatically refreshes and uses the latest serviceUrl to initiate business requests, completely completing the closed loop from cloud to end.

[0013] Furthermore, in step S31, the module information moduleInfo returned by the portal management system Portal is a JSON structure, which contains at least the following fields: The application's unique identifier is appId, the backend service routing address (serviceUrl) to which the H5 client's business request points, the numeric version number (versionCode) used for client-side version comparison, the download address (wgtUrl) for the offline resource package, and the online access address (h5Url) for downgrading when the network is weak or the download fails.

[0014] Furthermore, in step S32, the logic for version arbitration performed by the App's local module manager, ModuleManager, is as follows: The system compares the issued versionCode with the local cached version number. If the issued version number is greater than the local version number, it is determined that an update is needed, triggering a silent background download of the offline resource package pointed to by wgtUrl. After the download is complete, the integrity of the package is verified and it is decompressed to the dist directory of the local application sandbox. After successful decompression, the local module version number is updated. If the issued version number is not greater than the local version number, the update is skipped. When the download fails or the system is in a weak network environment, the system automatically uses h5Url as the downgrade entry point.

[0015] Furthermore, in step S33, the WebView reuse pool is a pre-created single-instance WebView reuse pool, which avoids the overhead of repeated creation through container reuse; the JsBridge adopts a registry-style unified management, which has lifecycle binding and unbinding functions to realize bidirectional communication between native and H5; the state management library on the H5 side achieves state consistency between the native and H5 sides through global state broadcasting, and the business request carries the latest serviceUrl and token information to initiate to the backend service.

[0016] A mobile hybrid modular operation and multi-tenant dynamic distribution system for executing the mobile hybrid modular operation and multi-tenant dynamic distribution method as described above includes: The build layer is used to trigger the execution of standardized builds in the continuous integration (CI) / continuous deployment (CD) process. Configurations are dynamically injected according to environment variables. A single build outputs dual-state artifacts, including online and offline resource packages. The dual-state artifacts and their metadata are registered to the application management center and form a standard artifact version record. The release scheduling layer is used to distribute the specified version of the sub-application configuration to the target tenant in the SaaS scenario based on the collaboration between the application management center and the portal management system, and to trigger automatic binding to bind the latest artifact to the private tenant in the private deployment scenario. The client-side runtime layer is used to request the latest application configuration of the current tenant when the native app starts. The client side compares the version number to determine whether to download and decompress the offline resource package to the local sandbox. When starting the sub-application, it obtains a container instance from the Web view reuse pool and loads local resources first. At the same time, it synchronizes the native side state to the Web side through the bridging layer. After the Web side state management library updates, it initiates business requests.

[0017] A computer device, characterized in that it includes a memory and one or more processors, wherein the memory stores computer code, and when the computer code is executed by the one or more processors, causes the one or more processors to perform the method as described above.

[0018] A computer-readable storage medium, characterized in that the computer-readable storage medium stores computer code, which, when executed, is performed as described above.

[0019] Compared with the prior art, the present invention has at least one of the following beneficial effects: (1) Establish a closed-loop automation system across the entire supply chain to significantly improve delivery efficiency. It automates the entire process from code building, asset management, tenant distribution to client-side hot updates, eliminating manual intervention and information silos between each stage, and significantly shortening the delivery cycle from the completion of development to the effective date of the new version on the tenant side.

[0020] (2) Supports fine-grained canary releases for multi-tenants, significantly reducing release risks. It supports fine-grained canary rollout based on individual tenants, stores, or user roles, allowing new features to be verified in a small area first and gradually rolled out, avoiding the impact of full rollout failures on all tenants and greatly reducing the risk of version upgrades.

[0021] (3) Achieve instant opening of the first screen on the client side and unified status, solving both performance and stability issues. The WebView reuse pool and local resource interception achieve instant first-screen loading, solving the performance bottleneck of cross-platform frameworks on industrial equipment; at the same time, the registry-style JsBridge and global state broadcasting ensure real-time consistency between Native and H5 states, avoiding authentication failures and data inconsistencies, thus balancing client-side performance and system stability. Attached Figure Description

[0022] Figure 1 This is an overall flowchart of the mobile terminal hybrid modular operation and multi-tenant dynamic distribution method of the present invention; Figure 2 This is the overall architecture diagram of the mobile terminal hybrid modular operation and multi-tenant dynamic distribution method of the present invention; Figure 3 This is a flowchart illustrating the dynamic interaction process of the endpoint runtime layer of this invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0025] This invention proposes a complete closed-loop system from "cloud-based build and distribution" to "high-performance execution on the client side," aiming to solve various problems mentioned in the background technology, such as fragmented artifacts, chaotic multi-tenant version management, inconsistent private and SaaS delivery links, disconnect between client-side updates and containers, and performance bottlenecks of pure cross-platform frameworks. This system achieves standardized, automated, and intelligent management of the entire link from code submission to client-side user use through a collaborative three-layer architecture of build layer, release scheduling layer, and client-side execution layer. The core improvements are as follows: (1) Standardized CI / CD dynamic construction and dual-state product output By introducing automated build scripts (such as generateH5Manifest.sh), configurations are dynamically injected based on environment variables during the CI / CD (Continuous Integration / Continuous Deployment) phase. A single build outputs both an "online H5 link" and an "offline WGT static resource package" as dual-state artifacts, which are then uniformly submitted to the BOP (Business Operation Platform). This standardized build process ensures that every code change is traceable and rollbackable, while providing a unified source of artifacts for subsequent multi-tenant distribution and client-side hot updates.

[0026] (2) Multi-tenant canary release system based on BOP and Portal collaboration By integrating the BOP asset repository with the Portal tenant management system, tenant administrators can flexibly select standard artifacts from the BOP for tenant-level canary releases via the Portal. Simultaneously, for private deployment scenarios, an agile "release upon artifact submission" process is provided, enabling private deployment environments to quickly obtain the latest artifacts without complex release approvals, significantly shortening the delivery cycle.

[0027] (3) Interface-driven end-side hot update and version arbitration mechanism When the native app starts or activates, it requests the latest application configuration (moduleInfo) for the current tenant from the Portal via an API. The client compares the versionCode and intelligently decides whether to download and unzip the latest WGT package or downgrade to use an H5 online link. This mechanism ensures that the client always runs sub-application resources consistent with the tenant's authorized version, while also guaranteeing business continuity in weak network environments through degradation strategies.

[0028] 4. A runtime platform deeply integrated with high-performance single-instance WebView pools Once the hot update of the sub-application resources is complete, they are seamlessly mounted to the native WebViewPool (a high-performance web view reuse pool) for execution. Combined with a registry-based JSBridge (JavaScript Bridge) and Vuex (Vue.js state management library) for global state broadcasting, it achieves extreme loading speed and state consistency, ensuring real-time synchronization of state between the Native and H5 sides and avoiding authentication failures and data inconsistencies.

[0029] The technical solution of the present invention will be explained below through specific embodiments: First Embodiment like Figure 1 and2 As shown, this embodiment provides a method for mobile terminal hybrid modular operation and multi-tenant dynamic distribution, characterized by the following steps: S1: At the build layer, trigger the continuous integration (CI) / continuous deployment (CD) process to execute a standardized build, dynamically inject configurations according to environment variables, and output dual-state artifacts of online resources and offline resource packages in one build. Register the dual-state artifacts and their metadata to the application management center and form a standard artifact version record.

[0030] In this embodiment, step S1 specifically includes: Step S11: Trigger Continuous Integration (CI) / Continuous Deployment (CD) build and environment variable injection. When the sub-application code is merged, trigger the Continuous Integration (CI) / Continuous Deployment (CD) process and inject context variables including environment variable VUE_APP_ENV, domain name, and source version fromVersion. When the source code of a sub-application (such as a store assistant or a procurement assistant) is merged into a specific branch of the version repository (such as the main branch or a release branch), the system automatically triggers the CI / CD pipeline. During the build startup phase, the pipeline script dynamically injects a series of context variables based on the deployment target (such as development environment, testing environment, pre-release environment, or production environment) corresponding to the current build task. These variables include, but are not limited to: VUE_APP_ENV (to identify the deployment environment type corresponding to the current build), domain (to specify the domain names that all external access depends on in the current environment, including the access domain names of H5 online pages and the domain names of API interface requests), and fromVersion (to identify the upstream version source on which this build is based, facilitating subsequent version tracing and change difference analysis). Through the dynamic injection of these environment variables, the same set of source code can adapt to different deployment environments without modifying any configuration files, achieving the standardized build goal of "build once, adapt to multiple environments."

[0031] Step S12: Dynamically generate the application description file Manifest and package it in two states. In the post-compilation processing stage, execute an automated script to extract the Git commit count as the version number versionCode, read package.json to get the version name versionName, dynamically concatenate and generate an online H5 link h5Url suitable for the current environment, and generate the application description file manifest.json. The compiled output is packaged into an online H5 deployment directory and a WGT offline resource compressed package. The online H5 deployment directory is available for web access or downgrade use, and the WGT offline resource compressed package is available for download by the App to achieve instant opening. After compilation and building, the system enters the post-processing stage, executing a pre-configured automated script (e.g., generateH5Manifest.sh). This script first extracts the Commit Count of the current code commit as the version code using Git commands. Since the Commit Count monotonically increases with each commit, it naturally ensures the incrementality of the version number, suitable for determining version status. Simultaneously, it reads the package.json file in the project root directory to obtain the version name (e.g., "1.0.1"), a readable version identifier displayed to the user. Subsequently, based on the environment variables injected in step S11 (especially domain and VUE_APP_ENV), the script dynamically constructs an h5Url (online H5 link) suitable for the current environment. For example, it combines the domain name and environment identifier into a complete URL path, ensuring that the H5 client correctly points to the deployment address of the current environment in both downgraded and online access scenarios. Finally, the script summarizes the key information such as versionCode, versionName, and h5Url to generate a manifest.json application description file. This file serves as the "metadata tag" of the current build artifact, carrying core descriptive data such as version information, resource entry points, and deployment environment.

[0032] Based on this, the system packages the compiled static resource artifacts into two formats simultaneously: Online H5 deployment catalog: This is the traditional web application deployment package, which contains complete HTML, CSS, JavaScript and static resource files such as images. It can be deployed to a web server for browsers or WebViews embedded in apps to access online via standard HTTP / HTTPS protocols. It also serves as a fallback solution when offline resources on the client side are unavailable. WGT Offline Resource Compressed Package: This is an offline resource package file that has been packaged and compressed. It is designed specifically for the App side. After the client side downloads it, it is decompressed to the local sandbox directory. Then, WebView directly loads it by intercepting local file protocols (such as file: / / ), thereby achieving a "second-open" experience that does not rely on the network. It is especially suitable for weak network or offline operation scenarios such as industrial PDAs.

[0033] Step S13: Application Management Center BOP Input and Version Record Generation. The WGT offline resource compressed package, the generated application description file manifest.json, and metadata are registered to the Application Management Center BOP through the application programming interface (API) to form a standard artifact version record.

[0034] The aforementioned WGT offline resource compressed package, manifest.json application description file, and other relevant metadata generated during the build process (such as build time, build trigger, code branch information, commit ID, etc.) are registered and reported by calling the standard API (Application Programming Interface) exposed by the Application Management Center (BOP). After receiving the reported data, BOP manages the storage of the WGT package and generates an independent "standard artifact version record" for this build, such as "v1.0.0", "v1.0.1", etc., using versionCode and versionName in manifest.json as the core index. This version record not only contains the storage address and version information of the artifact file, but also associates and binds it with the appId of the sub-application, thus forming a standardized artifact asset library within BOP with "application as the dimension and version as the granularity". Subsequently, whether it is a multi-tenant canary release in a SaaS scenario or an agile delivery in a private scenario, the version selection and distribution can be uniformly selected and scheduled based on the standard artifact version records in the asset library, ensuring that all links from the source to the end use trusted artifacts that have been built through the same standardized process and have complete version traceability capabilities.

[0035] S2: At the release scheduling layer, based on the collaboration between the application management center and the portal management system, the specified version of the sub-application configuration is issued to the target tenant in the SaaS scenario, and automatic binding is triggered in the private deployment scenario to bind the latest artifact to the private tenant.

[0036] In this embodiment, step S2 specifically includes: Step S21: In the Software as a Service (SaaS) scenario, the Portal management system synchronizes the standard artifact library of the Application Management Center (BOP) in real time to achieve data integration; on the Portal management system, operations and maintenance personnel or tenant administrators upgrade the sub-application from version 1 to version 2 for a specific tenant marked with the Tenant ID, and support fine-grained gray-scale distribution by store or by user role. Specifically, the Portal (portal management system), serving as a unified operational entry point for operations personnel and tenant administrators, maintains a complete mapping table between tenants and sub-application versions. This mapping table retrieves the latest standard artifact version records from the BOP (Browser Object Program) through a periodic or real-time synchronization mechanism, ensuring that the list of available versions displayed on the Portal is always consistent with the artifact versions already submitted in the BOP. When operations personnel or tenant administrators with appropriate permissions log in to the Portal, the system automatically filters the manageable tenant range based on their identity. Administrators can select the target tenant (uniquely identified by a Tenant ID) on the interface, choose the target sub-application to be upgraded from the list of currently authorized sub-applications for that tenant, and then select the desired upgrade version (e.g., from v1.0.0 to v1.0.1) from the list of available versions synchronized from the BOP, performing the version binding operation.

[0037] At the canary release level, Portal supports more granular canary release strategy configurations than "full tenant release". Specifically, when upgrading a version, administrators can set the release scope through Portal's canary release strategy management module, including but not limited to: by store (only effective for users under tenants within a specific region or store ID range) and by user role (only effective for users with specific role identifiers, such as store manager, purchasing agent, warehouse manager, etc.). Through the above granular canary release strategies, the new version can be verified on a small scale (e.g., only for store manager roles in a single store), and the canary release scope can be gradually expanded until full release after successful verification, effectively reducing the risk of global failures caused by defects introduced by the new version.

[0038] Step S22: In a private deployment scenario, a lightweight channel is provided for private deployment environments without a complex BOP system: after the sub-application build artifacts are sent to the private server, the system automatically triggers a webhook to directly bind the latest version to the private tenant, ensuring agile interaction.

[0039] Specifically, in private deployment scenarios, each private client typically has an independently deployed server environment, and due to security compliance or network isolation factors, these environments often cannot directly access the BOP (Application Programming Center) of the cloud-based SaaS environment. Therefore, this invention designs a lightweight release channel specifically for private deployment scenarios. In this channel, a lightweight local version management service is pre-deployed within the private server, exposing standard artifact receiving interfaces and webhook callback interfaces.

[0040] Once the sub-application completes its CI / CD standardized build and outputs bi-state artifacts in the cloud, the system pushes the build artifacts (including WGT offline resource packages, manifest.json, and metadata) to the artifact receiving endpoint on the corresponding private server according to the pre-configured private deployment goals. After the artifact is submitted, the local version management service on the private server automatically triggers a pre-configured webhook callback. The execution logic of this webhook is as follows: it reads the version information carried in the manifest.json of the submitted artifact, directly binds the latest version to the version mapping table of the private tenant, and completes the agile delivery process of "submission equals release". The entire process does not require manual login to the server to replace files, does not require restarting the service, and does not require additional release approval processes, which greatly shortens the delivery cycle from code submission to version effectiveness in private scenarios, enabling private customers to obtain the latest product features and security patches at a near-SaaS agile pace.

[0041] Steps S21 and S22 described above together constitute the complete implementation of the release scheduling layer in this invention. Both design differentiated release scheduling mechanisms for SaaS multi-tenant scenarios and private single-tenant scenarios, but share the same set of build artifact sources (i.e., the BOP standard artifact produced in step S1), thereby unifying the SaaS and private delivery links at the underlying level and avoiding the additional overhead of maintaining multiple build and release processes for the two deployment models. Through the processing of this release scheduling layer, each tenant (whether a SaaS tenant or a private tenant) ultimately obtains a clear sub-application version configuration that matches its own authorization policy, providing accurate configuration input for the next step of version arbitration and hot update in the end-side runtime layer.

[0042] S3: On the client-side runtime layer, when the native App starts, it requests the latest application configuration of the current tenant. The client side compares the version number to determine whether to download and decompress the offline resource package to the local sandbox. When the sub-application starts, it obtains a container instance from the Web view reuse pool and loads local resources first. At the same time, it synchronizes the native side state to the Web side through the bridging layer. After the Web side state management library updates, it initiates business requests.

[0043] In this embodiment, as Figure 3 As shown, step S3 specifically involves: Step S31: After the native App starts, it sends an authentication request to the portal management system Portal through the gateway. The portal management system Portal returns the latest list of sub-applications authorized by the currently logged-in user and module information moduleInfo based on the tenant ID of the tenant. In step S31, the module information moduleInfo returned by the portal management system Portal is a JSON structure, which contains at least the following fields: The application's unique identifier is appId, the backend service routing address (serviceUrl) to which the H5 client's business request points, the numeric version number (versionCode) used for client-side version comparison, the download address (wgtUrl) for the offline resource package, and the online access address (h5Url) for downgrading when the network is weak or the download fails.

[0044] Specifically, after successful user login authentication, the native app enters the client-side initialization phase. At this time, the configuration management module embedded in the app sends an authentication request to the Portal through the network gateway. This request carries the identity credentials (such as a token) of the currently logged-in user and the tenant ID. After receiving the request, the Portal first verifies the validity of the user's credentials, and then queries the list of authorized sub-applications of that tenant and their corresponding version configuration information using the tenant ID as an index. The sub-application list covers all mobile modules ordered by the tenant in the SaaS scenario, such as Store Assistant, Procurement Assistant, and Store Inspection Assistant. The version configuration information for each sub-application is carried by a `moduleInfo` structure in JSON format, containing at least the following fields: `appId` (a unique application identifier used by the client to distinguish different sub-applications), `serviceUrl` (the backend service routing address to which all business requests from the H5 client point, ensuring that API requests initiated by the H5 page can be correctly routed to the corresponding backend microservice), `versionCode` (a numeric version number used by the client to compare versions), `wgtUrl` (the CDN download address for offline resource packages, used by the client to download when updates are needed), and `h5Url` (the online access address, used as a fallback entry point in weak network environments or when offline package downloads fail). The Portal returns the above `moduleInfo` list to the client at once. The client configuration management module receives this and caches it in local memory for subsequent steps. Through this mechanism, each tenant's client-side App does not need to pre-build any version information; it can dynamically obtain the latest application configuration that precisely matches its own authorization policy upon startup.

[0045] Step S32: The App's local module manager ModuleManager compares the issued version number versionCode with the locally cached version number. If an update is needed, it triggers a silent background download of wgtUrl and decompresses it to the dist directory of the local application sandbox. If the download fails or the network is weak, it automatically downgrades to use h5Url as the entry point. In step S32, the logic for version arbitration performed by the App's local module manager, ModuleManager, is as follows: The system compares the issued versionCode with the local cached version number. If the issued version number is greater than the local version number, it is determined that an update is needed, triggering a silent background download of the offline resource package pointed to by wgtUrl. After the download is complete, the integrity of the package is verified and it is decompressed to the dist directory of the local application sandbox. After successful decompression, the local module version number is updated. If the issued version number is not greater than the local version number, the update is skipped. When the download fails or the system is in a weak network environment, the system automatically uses h5Url as the downgrade entry point.

[0046] Specifically, after receiving the moduleInfo returned in step S31, the module manager on the client side executes the version arbitration logic for each sub-application. For each sub-application, the module manager first reads the cached local version number of the sub-application from the client-side local persistent storage (such as SharedPreferences or a local database), and then compares the latest versionCode issued with the locally cached version number. When the released version number is greater than the locally cached version number, ModuleManager determines that an update is available for the current sub-application. At this point, ModuleManager immediately starts a silent background download task, downloading the offline resource package from the CDN address pointed to by wgtUrl via a system-level download service (such as DownloadManager in Android or URLSession in iOS). This download process is executed in a background thread and does not affect the user's normal operation of other functions of the app. After the download is complete, ModuleManager performs integrity verification on the WGT package (such as MD5 or SHA verification). If the verification passes, it is decompressed to the dist directory of the local application sandbox (e.g., / data / data / {packageName} / files / modules / {appId} / dist / ). After successful decompression, the local cached version number of the sub-application is updated to the latest released versionCode and persistently stored. When the released version number is not greater than the local cache version number, ModuleManager determines that no update is needed at present, skips the download process of the sub-application, and directly uses the existing offline resources locally; If the download of wgtUrl fails at any of the above stages due to network anomalies, CDN service unavailability, or timeouts, or if the client-side network status detection determines that the current network environment is weak (such as 2G / 3G network, high latency connection), ModuleManager will automatically mark the h5Url as the entry address of the current sub-application. Subsequent users will access the sub-application directly via online H5, ensuring that service is not interrupted due to offline resource acquisition failures. This degradation strategy is re-evaluated at each startup. Once the client-side network status recovers and a new version of the WGT package is available, ModuleManager will re-trigger the download update in the next configuration fetch cycle.

[0047] Through the aforementioned version arbitration and hot update mechanism, the client side can always run application resources consistent with the tenant's authorized version with minimal network overhead and optimal loading strategy, while also having automatic recovery capabilities in abnormal scenarios.

[0048] Step S33: When the user clicks the sub-application entry, the system obtains a single-instance Web view from the WebView reuse pool, intercepts network requests through the Web view client, and maps static resources to the locally decompressed dist directory that was just hot-updated to achieve instant first-screen loading; when the Web view loads, the system natively serializes the serviceUrl, tenant information tenantInfo, and token information tokenInfo through JsBridge and pushes them to the H5. The Vuex state management library on the H5 side automatically refreshes and uses the latest serviceUrl to initiate business requests, completely completing the closed loop from cloud to end.

[0049] In step S33, the WebView reuse pool is a pre-created single-instance WebView reuse pool, which avoids the overhead of repeated creation through container reuse; the JsBridge adopts a registry-style unified management, which has lifecycle binding and unbinding functions to realize bidirectional communication between native and H5; the state management library on the H5 side realizes the consistency of state between the native and H5 sides through global state broadcasting, and the business request carries the latest serviceUrl and token information to initiate to the backend service.

[0050] Specifically, when a user clicks on a sub-application entry icon in the App's main interface, the client-side container management module executes the following loading process: First, the container management module retrieves a pre-created single-instance WebView from the WebView reuse pool (WebViewPool). The WebView reuse pool completes the pre-creation and initialization of several WebView instances (including kernel loading, basic settings, etc.) during the app startup phase or before the first use. These instances remain alive throughout the app's lifecycle, being retrieved as needed and returned after use. This avoids the time-consuming overhead of repeatedly creating WebViews and initializing the kernel each time a sub-application is launched, fundamentally solving the slow startup and memory jitter problems caused by frequent WebView creation in traditional solutions.

[0051] Secondly, the container management module sets a custom WebViewClient for the obtained WebView instance. When the WebView starts loading sub-application resources, this WebViewClient intercepts all network requests (such as http: / / or https: / / requests) for static resources (HTML, CSS, JavaScript, images, etc.). The interception logic matches and maps the requested URL path with the file path in the local dist directory: if the corresponding resource file exists in the local dist directory, the request is directly redirected to the local file protocol (such as file: / / path), and the WebView loads the local file; if the corresponding resource does not exist locally or loading the local file fails, it falls back to the original network request and obtains the resource from the CDN or web server. Through this interception and mapping mechanism, all static resources are loaded locally, completely avoiding network round-trip time, thus achieving the ultimate "instant opening" experience for the first screen.

[0052] Meanwhile, during the WebView page loading process, the native side actively initiates communication with the H5 side through the registered JsBridge channel. Specifically, the native side calls the pre-registered handleGetAppInfo method in JsBridge to serialize key state data such as the current user's serviceUrl (backend service routing address), tenantInfo (tenant information, including tenant ID, tenant name, etc.), and tokenInfo (user identity token) into a JSON string, which is then injected and passed to the H5 side through the WebView's evaluateJavascript method.

[0053] After receiving the JSON configuration from the native push notification, the H5 side submits the data to the Vuex state management library, triggering a synchronous update of relevant states in the Store (such as serviceUrl, tenant, token, etc.). Because Vuex employs a reactive design, all components and modules that depend on these states automatically receive the latest values ​​after the state update. Subsequently, the H5 side's business code (such as the API request layer) reads the latest state from Vuex, carries the serviceUrl and token information, and initiates a data request to the backend business service to complete the retrieval of business data and page rendering.

[0054] Thus, a complete closed loop from cloud-based build and distribution to high-performance operation on the edge is fully established: the build layer produces standard artifacts and incorporates them into the BOP (Browser Object Programming) → the scheduling layer authorizes and distributes version configurations according to tenant dimensions → the runtime layer dynamically acquires configurations, intelligently arbitrates versions, performs silent hot updates, loads high-performance containers, synchronizes states across platforms, and executes business requests in a closed loop. Throughout this process, the layers interact through standardized interfaces and protocols, achieving a highly cohesive and loosely coupled architecture design. This enables the invention to possess high scalability, maintainability, and operational reliability in mobile hybrid modular operation and multi-tenant dynamic distribution scenarios.

[0055] Second Embodiment This embodiment provides a mobile terminal hybrid modular operation and multi-tenant dynamic distribution system for executing the mobile terminal hybrid modular operation and multi-tenant dynamic distribution method as described in the first embodiment, including: The build layer is used to trigger the execution of standardized builds in the continuous integration (CI) / continuous deployment (CD) process. Configurations are dynamically injected according to environment variables. A single build outputs dual-state artifacts, including online and offline resource packages. The dual-state artifacts and their metadata are registered to the application management center and form a standard artifact version record. The release scheduling layer is used to distribute the specified version of the sub-application configuration to the target tenant in the SaaS scenario based on the collaboration between the application management center and the portal management system, and to trigger automatic binding to bind the latest artifact to the private tenant in the private deployment scenario. The client-side runtime layer is used to request the latest application configuration of the current tenant when the native app starts. The client side compares the version number to determine whether to download and decompress the offline resource package to the local sandbox. When starting the sub-application, it obtains a container instance from the Web view reuse pool and loads local resources first. At the same time, it synchronizes the native side state to the Web side through the bridging layer. After the Web side state management library updates, it initiates business requests.

[0056] A computer-readable storage medium stores computer code that, when executed, performs the methods described above. Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. This program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0057] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

[0058] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0059] It should be noted that the above embodiments can be freely combined as needed. The above description is only a preferred embodiment of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for hybrid modular operation and multi-tenant dynamic distribution on mobile terminals, characterized in that, Includes the following steps: S1: At the build layer, trigger the continuous integration (CI) / continuous deployment (CD) process to execute a standardized build, dynamically inject configuration according to environment variables, and output dual-state artifacts of online resources and offline resource packages in one build. The dual-state artifacts and their metadata are registered to the application management center and form a standard artifact version record. S2: At the release scheduling layer, based on the collaboration between the application management center and the portal management system, the specified version of the sub-application configuration is issued to the target tenant in the SaaS scenario, and automatic binding is triggered in the private deployment scenario to bind the latest artifact to the private tenant. S3: On the client-side runtime layer, when the native App starts, it requests the latest application configuration of the current tenant. The client side compares the version number to determine whether to download and decompress the offline resource package to the local sandbox. When the sub-application starts, it obtains a container instance from the Web view reuse pool and loads local resources first. At the same time, it synchronizes the native side state to the Web side through the bridging layer. After the Web side state management library updates, it initiates business requests.

2. The mobile terminal hybrid modular operation and multi-tenant dynamic distribution method according to claim 1, characterized in that, Step S1 is as follows: Step S11: Trigger Continuous Integration (CI) / Continuous Deployment (CD) build and environment variable injection. When the sub-application code is merged, trigger the Continuous Integration (CI) / Continuous Deployment (CD) process and inject context variables including environment variable VUE_APP_ENV, domain name, and source version fromVersion. Step S12: Dynamically generate the application description file Manifest and package it in two states. In the post-compilation processing stage, execute an automated script to extract the Git commit count as the version number versionCode, read package.json to get the version name versionName, dynamically concatenate and generate an online H5 link h5Url suitable for the current environment, and generate the application description file manifest.json. The compiled output is packaged into an online H5 deployment directory and a WGT offline resource compressed package. The online H5 deployment directory is available for web access or downgrade use, and the WGT offline resource compressed package is available for download by the App to achieve instant opening. Step S13: Application Management Center BOP Input and Version Record Generation. The WGT offline resource compressed package, the generated application description file manifest.json, and metadata are registered to the Application Management Center BOP through the application programming interface (API) to form a standard artifact version record.

3. The mobile terminal hybrid modular operation and multi-tenant dynamic distribution method according to claim 1, characterized in that, Step S2, specifically: Step S21: In the Software as a Service (SaaS) scenario, the Portal management system synchronizes the standard artifact library of the Application Management Center (BOP) in real time to achieve data integration; on the Portal management system, operations and maintenance personnel or tenant administrators upgrade the sub-application from version 1 to version 2 for a specific tenant marked with the Tenant ID, and support fine-grained gray-scale distribution by store or by user role. Step S22: In a private deployment scenario, a lightweight channel is provided for private deployment environments without a complex BOP system: after the sub-application build artifacts are sent to the private server, the system automatically triggers a webhook to directly bind the latest version to the private tenant, ensuring agile interaction.

4. The mobile terminal hybrid modular operation and multi-tenant dynamic distribution method according to claim 1, characterized in that, Step S3 is as follows: Step S31: After the native App starts, it sends an authentication request to the portal management system Portal through the gateway. The portal management system Portal returns the latest list of sub-applications authorized by the currently logged-in user and module information moduleInfo based on the tenant ID of the tenant. Step S32: The App's local module manager ModuleManager compares the issued version number versionCode with the locally cached version number. If an update is needed, it triggers a silent background download of wgtUrl and decompresses it to the dist directory of the local application sandbox. If the download fails or the network is weak, it automatically downgrades to use h5Url as the entry point. Step S33: When the user clicks the sub-application entry, the system obtains a single-instance Web view from the WebView reuse pool, intercepts network requests through the Web view client, and maps static resources to the locally decompressed dist directory that was just hot-updated to achieve instant first-screen loading; when the Web view loads, the system natively serializes the serviceUrl, tenant information tenantInfo, and token information tokenInfo through JsBridge and pushes them to the H5. The Vuex state management library on the H5 side automatically refreshes and uses the latest serviceUrl to initiate business requests, completely completing the closed loop from cloud to end.

5. The mobile terminal hybrid modular operation and multi-tenant dynamic distribution method according to claim 4, characterized in that, In step S31, the module information moduleInfo returned by the portal management system Portal is a JSON structure, which contains at least the following fields: The application's unique identifier is appId, the backend service routing address (serviceUrl) to which the H5 client's business request points, the numeric version number (versionCode) used for client-side version comparison, the download address (wgtUrl) for the offline resource package, and the online access address (h5Url) for downgrading when the network is weak or the download fails.

6. The mobile terminal hybrid modular operation and multi-tenant dynamic distribution method according to claim 4, characterized in that, In step S32, the logic for version arbitration performed by the App's local module manager, ModuleManager, is as follows: The system compares the issued versionCode with the local cached version number. If the issued version number is greater than the local version number, it is determined that an update is needed, triggering a silent background download of the offline resource package pointed to by wgtUrl. After the download is complete, the integrity of the package is verified and it is decompressed to the dist directory of the local application sandbox. After successful decompression, the local module version number is updated. If the issued version number is not greater than the local version number, the update is skipped. When the download fails or the system is in a weak network environment, the system automatically uses h5Url as the downgrade entry point.

7. The mobile terminal hybrid modular operation and multi-tenant dynamic distribution method according to claim 4, characterized in that, In step S33, the WebView reuse pool is a pre-created single-instance WebView reuse pool, which avoids the overhead of repeated creation through container reuse; the JsBridge adopts a registry-style unified management, which has lifecycle binding and unbinding functions to realize bidirectional communication between native and H5; the state management library on the H5 side realizes the consistency of state between the native and H5 sides through global state broadcasting, and the business request carries the latest serviceUrl and token information to initiate to the backend service.

8. A mobile terminal hybrid modular operation and multi-tenant dynamic distribution system for executing the mobile terminal hybrid modular operation and multi-tenant dynamic distribution method as described in any one of claims 1-7, characterized in that, include: The build layer is used to trigger the execution of standardized builds in the continuous integration (CI) / continuous deployment (CD) process. Configurations are dynamically injected according to environment variables. A single build outputs dual-state artifacts, including online and offline resource packages. The dual-state artifacts and their metadata are registered to the application management center and form a standard artifact version record. The release scheduling layer is used to distribute the specified version of the sub-application configuration to the target tenant in the SaaS scenario based on the collaboration between the application management center and the portal management system, and to trigger automatic binding to bind the latest artifact to the private tenant in the private deployment scenario. The client-side runtime layer is used to request the latest application configuration of the current tenant when the native app starts. The client side compares the version number to determine whether to download and decompress the offline resource package to the local sandbox. When starting the sub-application, it obtains a container instance from the Web view reuse pool and loads local resources first. At the same time, it synchronizes the native side state to the Web side through the bridging layer. After the Web side state management library updates, it initiates business requests.

9. A computer device, characterized in that, The device includes a memory and one or more processors, wherein the memory stores computer code that, when executed by the one or more processors, causes the one or more processors to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer code, and when the computer code is executed, the method as described in any one of claims 1 to 7 is performed.

Images