Mobile terminal unified technology base system

Abstract

The invention belongs to the technical field of mobile application development, and discloses a mobile terminal unified technology base system. The method comprises the following steps: a modularization architecture layer provides a standardized basic technical component; the packaging and publishing platform uninterruptedly integrates and deploys the source code of the integrated standardized basic technology component to generate an application package capable of running at the iOS end, the Android end and the HarmonyOS end; the dynamic configuration platform dynamically issues configuration parameters to the distributed mobile terminal applications so as to control behaviors of the mobile terminal applications during operation; and the operation and maintenance monitoring platform collects and analyzes performance, crash and log data of the application, and provides a hot repair capability. According to the mode, a modularized and platformized technical system in which all parts are deeply coordinated is constructed, and the problems of efficiency, quality and stability of mobile terminal development with relevance in a framework, delivery, operation and maintenance whole link are uniformly solved by utilizing a systematic technical framework.

Description

Technical Field

[0001] This invention relates to the field of mobile application development technology, and in particular to a unified technology foundation system for mobile terminals. Background Technology

[0002] With the rapid development of enterprise mobile businesses, it is often necessary to maintain multiple independent mobile applications. Under traditional development models, these applications often face the following technical challenges: Technology stack fragmentation: Different applications and operating systems (iOS, Android, HarmonyOS) use different technology stacks, which leads to the need to repeatedly develop multiple sets of code for the same business functions, resulting in high R&D costs and inconsistent implementation effects.

[0003] Low delivery efficiency: Reliance on local packaging by developers, non-standard processes, low level of automation, resulting in long testing and release cycles and high risks.

[0004] Online operations and maintenance are difficult: there is a lack of effective monitoring tools, making it impossible to quickly detect and locate online crashes and performance issues; at the same time, there is a lack of dynamic methods, and online problems can only be fixed by releasing new versions, resulting in slow response times and poor user experience.

[0005] Difficulty in architectural evolution: As business iterates, code coupling increases and technical debt accumulates, making the system architecture prone to decay and difficult to maintain and upgrade.

[0006] Existing technologies are mostly point-based solutions to single problems, lacking a systematic technical framework to address the aforementioned interconnected issues.

[0007] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0008] The main objective of this invention is to provide a unified technology foundation system for mobile terminals, aiming to systematically address the issues of efficiency, quality, and stability in the entire chain of mobile terminal development, including architecture, delivery, and operation and maintenance.

[0009] To achieve the above objectives, the present invention provides a unified mobile technology platform system, characterized in that the unified mobile technology platform system is used to support at least two independent mobile applications, the system comprising: The component-based architecture layer is used to provide standardized basic technology components. These standardized basic technology components are reusable and follow a unified design paradigm, serving as a unified technical interface for upper-layer business development. A platform-based tool layer, integrated with the standardized basic technology components, is used for building, configuring, and maintaining applications. The platform-based tool layer includes: A packaging and distribution platform is used to continuously integrate and deploy the source code of the standardized basic technology components, generating application packages that can run on iOS, Android, and HarmonyOS. The dynamic configuration platform communicates with the configuration retrieval component integrated within the client to dynamically distribute configuration parameters to the mobile application to control the behavior of the mobile application during runtime. The operation and maintenance monitoring platform communicates with the data acquisition SDK integrated within the client to collect and analyze application performance, crash and log data, and provides hot-repair capabilities. The componentized architecture layer, packaging and release platform, dynamic configuration platform and operation and maintenance monitoring platform work together to provide unified technical support for the at least two independent mobile applications, enabling cross-application reuse of business functions and consistent operation and maintenance management.

[0010] In one embodiment, the core architectural principles followed by the componentized architecture layer include the Single Responsibility Principle, the Protocol-Oriented Programming Principle, the Dependency Inversion Principle, and the Dependency Inversion Principle. The Single Responsibility Principle focuses each component on a specific domain problem; the Protocol-Oriented Programming Principle defines the capabilities exposed by the component through protocols; the Dependency Inversion Principle injects dependencies through constructors; and the Interface Segregation Principle avoids creating large protocols that contain multiple unrelated capabilities.

[0011] In one embodiment, the standardized basic technology components follow at least one of the following standardized paradigms: utility classes or static service components, using the singleton pattern or static method class; configuration classes or injectable service components, injecting configuration objects through a constructor; and UI components, using the builder pattern or view pattern, which are prohibited from containing business logic.

[0012] In one embodiment, the packaging and release platform supports at least one of the following capabilities: unified multi-platform builds through integration with Xcode, Gradle, and HarmonyOS command-line tools via Jenkins; iOS certificates managed using Match, and code compression and obfuscation performed using R8 / Proguard; and multi-environment builds, including development, R&D, and production environments.

[0013] In one embodiment, the dynamic configuration platform is implemented based on Nacos and supports at least one of the following capabilities: real-time distribution and dynamic updating of configuration parameters; support for canary release strategies, including canary release by user ID, device ID, or version number; and provision of emergency downgrade capabilities, including function switch switching and backup interface activation.

[0014] In one embodiment, the dynamic configuration platform includes a client and a server. When the client starts up, it initiates a configuration request through the configuration manager. The configuration request includes the application name and the operating system platform identifier. If the request fails, the client executes a delayed retry mechanism at least once until the preset retry limit is reached or the request succeeds. After receiving a client request, the server queries the Nacos configuration center based on the application name and operating system platform identifier, obtains the corresponding configuration, converts it into JSON format, adds version number, timestamp, and data signature metadata to the response, and then returns it to the client.

[0015] In one embodiment, the operation and maintenance monitoring platform includes at least one of the following functions: automatic collection of client crash data, symbol table parsing and multi-dimensional statistical analysis; monitoring and analysis of performance indicators such as cold start performance and lag rate; support for remotely pulling client logs by user ID or device ID; and integrated hot-fix capability, supporting gray-scale, full release and rollback of patches.

[0016] Furthermore, to achieve the above objectives, this invention also proposes a mobile application development and operation method based on a unified technology platform. This method is applied to the mobile unified technology platform system described above, and includes: The component-based architecture layer provides standardized basic technology components, which are reusable and follow a unified design paradigm, serving as a unified technical interface for upper-layer business development. The platform-based tool layer is used for building, configuring, and maintaining applications. This platform-based tool layer includes: The packaging and distribution platform continuously integrates and deploys the source code that integrates the standardized basic technology components, generating application packages that can run on iOS, Android, and HarmonyOS. The dynamic configuration platform dynamically sends configuration parameters to the distributed mobile applications to control the behavior of the mobile applications during runtime. The operation and maintenance monitoring platform collects and analyzes application performance, crash and log data, and provides hot-repair capabilities.

[0017] In one embodiment, the core architectural principles followed by the componentized architecture layer include the Single Responsibility Principle, the Protocol-Oriented Programming Principle, the Dependency Inversion Principle, and the Dependency Inversion Principle. The Single Responsibility Principle focuses each component on a specific domain problem; the Protocol-Oriented Programming Principle defines the capabilities exposed by the component through protocols; the Dependency Inversion Principle injects dependencies through constructors; and the Interface Segregation Principle avoids creating large protocols that contain multiple unrelated capabilities.

[0018] Furthermore, to achieve the above objectives, the present invention also proposes a mobile application development and operation and maintenance device based on a unified technology foundation. The mobile application development and operation and maintenance device based on a unified technology foundation includes: a memory, a processor, and a mobile application development and operation and maintenance program based on a unified technology foundation stored on the memory and executable on the processor. The mobile application development and operation and maintenance program based on a unified technology foundation is configured to implement the steps of the mobile application development and operation and maintenance method based on a unified technology foundation as described above.

[0019] Furthermore, to achieve the above objectives, the present invention also proposes a storage medium storing a mobile application development and maintenance program based on a unified technology platform. When the mobile application development and maintenance program based on the unified technology platform is executed by a processor, it implements the steps of the mobile application development and maintenance method based on the unified technology platform described above.

[0020] In this invention, the component-based architecture layer provides standardized basic technical components; the packaging and deployment platform continuously integrates and deploys the source code of these standardized basic technical components, generating application packages that can run on iOS, Android, and HarmonyOS; the dynamic configuration platform dynamically distributes configuration parameters to the distributed mobile applications to control their runtime behavior; and the operation and maintenance monitoring platform collects and analyzes application performance, crash, and log data, and provides hot-repair capabilities. This approach constructs a component-based, platform-based technical system with deep collaboration among its components, using a systematic technical framework to uniformly solve the efficiency, quality, and stability issues of related mobile development across the entire chain of architecture, delivery, and operation and maintenance. Attached Figure Description

[0021] Figure 1 This is a structural block diagram of the first embodiment of the mobile terminal unified technology base system of the present invention; Figure 2 This is a schematic diagram of the overall process of configuring the platform in the unified technology base system for mobile terminals of the present invention; Figure 3 This is a schematic diagram of the configuration platform client-side process in the mobile terminal unified technology base system of the present invention; Figure 4 This is a schematic diagram of the configuration platform server-side process in the mobile terminal unified technology base system of the present invention; Figure 5 This is a flowchart illustrating the first embodiment of the mobile application development and maintenance method based on a unified technology platform according to the present invention.

[0022] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0024] This invention provides a unified technology foundation system for mobile terminals, as described in the embodiments of the present invention. Figure 1 , Figure 1 This is a structural block diagram of a first embodiment of a unified mobile terminal technology base system according to the present invention.

[0025] In its implementation, this embodiment uses a unified mobile technology foundation system to support at least two independent mobile applications. The system primarily comprises two layers: a component-based architecture layer 100 and a platform-based tool layer 200. The component-based architecture layer is the cornerstone of the technology foundation. Through abstraction and encapsulation, it provides a series of standardized basic technology components prefixed with "SK," such as SKHttp (network), SKWebView (webpage container), SKToastView (lightweight notifications), and SKLocation (location services). These components provide a unified API interface externally, while internally they are secondary encapsulations of native implementations or excellent open-source libraries (such as Moya and Kingfisher) for iOS (Swift / SwiftUI), Android (Kotlin / Compose), and Harmony (ArkTS / ArkUI). Business developers do not need to concern themselves with the underlying differences; they can directly call these components to quickly implement functions, thereby decoupling business logic from basic technologies and enabling "cross-application reuse of business functions." For example, an enterprise application (APP) and an OleApp can both rely on the same SKHttp component library for network requests.

[0026] Platform Tool Layer: This layer comprises three automated platforms integrated with the component-based architecture layer, responsible for the application's "birth, aging, illness, and death." Packaging and Deployment Platform: Built on CI / CD tools like Jenkins, this platform automatically pulls business code integrating the aforementioned basic technology components through a configured pipeline. It then calls Xcode, Gradle, and HarmonyOS command-line tools to compile, sign, harden (e.g., R8 / Proguard), and package the application, ultimately generating distributable application packages such as .ipa, .apk, or .app. This automates and standardizes the build process. Dynamic Configuration Platform: This platform is built on Nacos. A configuration retrieval component (SDK) is integrated within the mobile application, requesting the latest configuration parameters from this platform upon startup or at regular intervals. Configurations issued by the platform (such as feature switches, interface addresses, and UI text) can be read and applied by the client's basic technology components, thereby enabling "control over their runtime behavior." For example, by issuing a configuration of disable_feature_A=true, the A feature loaded in SKWebView can be remotely disabled. Operations and Maintenance Monitoring Platform: This platform integrates SaaS monitoring services. The mobile application integrates a data collection SDK responsible for collecting and reporting data such as crashes, performance (startup time, lag rate), and network requests. The platform provides a visual interface for "collecting and analyzing" this data. Simultaneously, the platform integrates hot-fix capabilities, allowing for the distribution of patch packages to fix native code defects online.

[0027] In this embodiment, collaborative work is illustrated by the following scenario: The operations and maintenance monitoring platform detects a spike in the crash rate of the SKHttp component on a certain API request. Monitoring and Location (Operations and Maintenance Platform): The platform issues an alert, and developers locate the root cause of the problem through crash analysis and remote logs. Emergency Degradation (Dynamic Configuration Platform): To prevent the impact from escalating, the dynamic configuration platform immediately issues a configuration to switch requests to an alternative interface, achieving rapid stabilization. Repair and Release (Component Layer + Packaging Platform): Developers repair the SKHttp component code and submit it to the code repository. The packaging and release platform automatically triggers a build, generating a new application version. Verification and Closed Loop (Operations and Maintenance Platform): After the new version is released in a canary phase, the operations and maintenance monitoring platform continuously monitors the crash rate metric to verify the repair effect.

[0028] Furthermore, regarding the aforementioned unified mobile technology platform system, it should be noted that the integration scope of the unified mobile technology platform system in this embodiment is to be integrated into the enterprise application APP and OleApp after development. The system scope includes: iOS and Android business layer integration scope: marketing and sales guidance domain, transaction settlement domain, content interaction domain, marketing interaction domain, business middleware, etc., within the client business layer. Mobile platform tool performance requirements include: 1. Support for high availability and horizontal scaling; 2. Support for ≥4000 concurrent users; 3. Response time for ordinary page operations not exceeding 1 second, and response time for report-type pages not exceeding 5 seconds; 4. External interface TPS ≥300. Customized mobile platform module performance requirements include: 1. Code optimization conforming to Wanjia code writing standards; 2. APP support for optional app store or silent background download and installation, with APP updates not affecting user usage; 3. Support for feature gray-scale deployment, with new features being gray-scale deployed through the client. Customized mobile platform module localization requirements include: 1. The application software used conforms to the version requirements of the enterprise's technical roadmap, specifically referring to the technical roadmap version. The security requirements for customized modules on mobile terminals include: 1. Residual information protection (applicable to systems with Level 3 or higher security standards), ensuring that the storage space containing user authentication information, files, directories, database records, and other resources of the system and database is completely erased before being released or reallocated (regardless of whether the data is on the hard drive or in memory). 2. Secure access requirements: The program must use the HTTPS access protocol to provide user access. 3. Communication integrity and confidentiality: The program must prevent information from being damaged, modified, lost, or altered without authorization during transmission, exchange, storage, and processing. The program uses secure communication protocols and other information encryption technologies to prevent illegal information leakage. 4. Non-repudiation: The program must resolve disputes regarding whether an event or action has occurred or not by generating, collecting, maintaining, utilizing, and verifying evidence of the generated event or action. 5. Security assessment and scanning requirements: A security assessment and scanning must be performed after system resource application and application deployment (requiring the patching of medium- and high-risk vulnerabilities). 6. Code auditing requirements: A code audit plan must be incorporated into relevant stages of the development process to analyze the source code and identify program errors, security vulnerabilities, and other risks. 7. Penetration Testing Requirements: Applications exposed to the external network must pass system penetration testing and complete the remediation of risks identified during the penetration test before going live. 8. Operational Security Requirements: The system must support normal operation after being upgraded with security devices such as firewalls and patches. 9. Data Security Requirements: 10. Clear Data Security Classification Requirements: Sensitivity identification must be performed on metadata, and security classification content must be improved and submitted for review. 11. Data Security Gateway Must Be Deployed Simultaneously During Product Deployment: If business data contains sensitive data, a data security gateway must be deployed at the data storage end for data security review.12. Data Security Gateway Access Requirements: Applications accessing sensitive data must install the specified data security driver, and data access must be conducted through the data security gateway according to specified requirements. 13. Sensitive Data Collection, Processing, and Usage Requirements: During data processing, the program should employ technologies such as digests, message authentication codes, digital signatures, and anti-crawler measures to ensure data integrity and security. Historical cached sensitive data should be cleared after processing. 14. Traceability Requirements: The program should implement security measures such as logging and watermarking during data access to ensure traceability of sensitive data access. 15. Development Environment Management Requirements: Sensitive data migrated from the production environment to the SIT / UAT environment must undergo de-identification processing. 16. Data Access Requirements: In accordance with data security management standards (data confidentiality levels follow commercial confidentiality management standards and the Personal Information Protection Law), sensitive data should be protected using encrypted storage, static de-identification, and dynamic de-identification techniques to ensure secure data access.

[0029] Furthermore, the core architectural principles followed by the component-based architecture layer include the Single Responsibility Principle, the Protocol-Oriented Programming Principle, the Dependency Inversion Principle, and the Interface Segregation Principle. The Single Responsibility Principle focuses each component on a specific domain problem; the Protocol-Oriented Programming Principle defines the capabilities exposed by a component through a protocol; the Dependency Inversion Principle injects dependencies through the constructor; and the Interface Segregation Principle avoids creating large protocols that contain multiple unrelated capabilities.

[0030] It's important to note that the Single Responsibility Principle (SRP) defines a component or class as having only one reason to change. Specifically, each fundamental component must focus on solving a clear and independent domain problem. A counterexample is an SKNetworkManager that is responsible for both initiating network requests and displaying a global loading animation at the start of a request; this violates the SRP because the network logic and UI logic are coupled together. A positive example is to separate them into two components: SKNetworkClient, which handles only the core logic of network communication; and SKLoadingIndicator, which is only responsible for showing and hiding the loading animation.

[0031] Protocol-oriented programming is defined as relying on abstractions (protocols) rather than concrete implementations. Specifically, all capabilities exposed by components must be defined through a protocol. The internal implementation details of components should be hidden, interacting with the outside world only through the protocol. This is crucial for achieving component substitutability and testability. A counterexample is directly depending on concrete classes, such as... 1classUserViewModel{ 2 / / Hard-coded dependency, cannot be replaced, difficult to test 3privateletlogger=SKLogger() 4} Positive examples, depending on protocols, such as: 1 protocol Logging { 2func log(message: String, level: LogLevel) 3} 4 5 class UserViewModel { 6. private let logger: Logging / / Depends on abstract protocol 7. 8 / / Pass in the concrete implementation via dependency injection 9init(logger: Logging) { 10self.logger = logger 11} 12} The Dependency Inversion Principle states that high-level modules should not depend on low-level modules; both should depend on abstractions. The primary way to implement this principle is dependency injection. Specifically, components must not hard-code their dependencies. All external dependencies must be injected through the constructor (Initializer). This ensures that component dependencies are explicit and that mock objects can be easily injected during testing. Example: Counterexample, creating dependencies internally, such as: 1 final class SKHttpService { 2private let session: URLSession 3init() { 4. Dependencies are hard-coded internally and cannot be controlled or replaced externally. 5self.session = URLSession(configuration: .default) 6} 7} A good example is dependency injection via the constructor, such as: 1. Protocol URLSessionProtocol { / * ... An abstraction of URLSession... * / } 2. `extension URLSession: URLSessionProtocol {}` / / Makes the native URLSession conform to the protocol. 4 final class SKHttpService { 5private let session: URLSessionProtocol 6 7. Dependencies are injected from outside, which is clear, controllable, and testable. 8init(session: URLSessionProtocol) { 9self.session = session 10} 11} The Interface Segregation Principle states that clients should not be forced to depend on methods they do not use. Specifically, this means that the protocols exposed by a component should be as small and specialized as possible. Avoid creating large protocols that contain many unrelated capabilities. Large protocols should be broken down into smaller, more specific protocols.

[0032] Example: Counterexample, a massive caching protocol: 1 protocol CacheService { 2func save(data: Data, forKey: String) 3func read(forKey: String) ->Data? 4func clearAll() 5func trimToSize(_ size: Int) 6} Even a client that only needs to read from the cache is forced to learn methods like save and clearAll, which it doesn't actually need.

[0033] A good example is breaking it down into smaller agreements with more clearly defined responsibilities, such as: 1 protocol ReadableCache { 2func read(forKey: String) ->Data? 3} 4 protocol WritableCache { 5func save(data: Data, forKey: String) 6func clearAll() 7func trimToSize(_ size: Int) 8} 9 / / A component can implement multiple protocols simultaneously. 10 class SKDiskCache: ReadableCache, WritableCache { / * ... * / } In one embodiment, the standardized basic technology components provided by the componentized architecture layer follow at least one of the following standardized paradigms: utility classes or static service components, using the singleton pattern or static method class; configuration classes or injectable service components, injecting configuration objects through the constructor; and UI components, using the builder pattern or view pattern, which are prohibited from containing business logic.

[0034] It's important to note that utility / static service components are suitable for providing pure functions or a single global function, and are stateless or have globally shared state. Examples include SKToastManager, SKCryptoUtil, and device information services. The core pattern is singleton or static method class. Class names end with Manager, Util, Service, or Helper, and all public APIs must be thread-safe. State management and configuration components are suitable for components that need to be instantiated, manage their own state, and whose behavior depends on external configuration. Examples include SKHttpClient, SKDatabaseHandler, and SKImageCache. The core pattern is Dependency Injection (DI) + Configuration Object. Names should directly use the component's core responsibilities, such as SKHttpClient. UI components are suitable for reusable UI elements, such as custom pop-ups, loading animations, and placeholder views. The core pattern is Builder or ViewModifier / View. Names end with UI-related terms such as View, Alert, or Indicator.

[0035] In one embodiment, several different basic components are described in detail. Component 1: SKToastView. SKToastView, as a commonly used lightweight notification component on mobile devices, is mainly used to display short-term information to users (such as operation results, loading status, etc.). Its design focuses on simplicity, ease of use, customizability, and cross-platform consistency, specifically including: Singleton management mode: The display / hiding of the pop-up is uniformly controlled through the SKToastManager.share singleton, avoiding conflicts between multiple instances and simplifying the call chain. Automated lifecycle: The pop-up automatically times after it is displayed, disappears with an animation after expiration, and releases resources without requiring manual management by the caller. Low-intrusion interaction: User interaction is disabled in the pop-up view (isUserInteractionEnabled=false) to avoid interfering with the underlying interface operation. Adaptive layout: The width of the pop-up is limited to the screen width minus 30, supports automatic text wrapping, and adapts to notification content of different lengths.

[0036] Component 2: SKWebView Web Container. SKWebView is a high-performance, highly scalable mobile web content display component. Its design revolves around core functionality, layered architecture, security mechanisms, and cross-platform consistency, providing reliable web container support for hybrid development. The detailed design framework includes: Flexible content loading: Supports three content sources: URL, URLString, and HTMLString, meeting the webpage loading needs of different scenarios. JS-Native bidirectional communication: Message handlers are registered through WKUserContentController, enabling bidirectional interaction between JS calls to native code (via message names such as jsToOcWithPrams and exit) and native interception of URL protocols (such as custom schemes). Configurable behavior and styles: Provides configuration options such as sliding control, content height monitoring, and additional JS injection to adapt to diverse business scenarios. Complete lifecycle management: WebView creation, updating, and destruction are implemented through makeUIView, updateUIView, and dismantleUIView, ensuring resource release (such as removing message handlers and undelegating).

[0037] Component 3: SKAppLogger. SKAppLogger is designed to meet logging needs in development, debugging, and testing scenarios. It supports log hierarchy and multi-dimensional filtering. As a lightweight logging tool, its core focuses on environment adaptability, ease of use, and performance optimization. Specific design elements are as follows: Environment Differentiation Strategy: By differentiating between DEBUG and RELEASE environments, dynamic adjustments to logging are achieved. Detailed logs are retained for debugging during development, while logs are streamlined during production to reduce resource consumption and sensitive information exposure, balancing debugging efficiency and production stability. Hierarchical and Categorized Management: A two-tiered management mechanism is designed based on log importance (level) and business module (category). This filters redundant information through levels (e.g., ignoring low-priority logs in the DEBUG environment) and enables rapid problem location by module through categorization, improving log analysis efficiency. Native Dependency Optimization: The underlying log output is implemented based on the system-level os.log framework. Leveraging its low performance overhead and high system integration, it avoids the redundant development of complex logging systems while ensuring log recording stability.

[0038] Component 4: SKHttp Network Library. SKHttp, as the core component for mobile network requests, aims to provide high-performance, highly reliable, and easily scalable HTTP / HTTPS communication capabilities, supporting businesses to quickly implement network request functions. SKHttp is a network implementation library based on frameworks (iOS: Moya + Alamofire; Android: Retrofit + OKHttp). It can serve as the foundation framework for different mobile business layers. 1. Request Entry Stage: Developers initiate network requests through SKHttpRequestMoya, configuring request parameters (headers, timeout, target). It merges global and local HttpHeaders. 2. Request Processing Stage: MoyaProvider acts as the core request provider. Request endpoints are configured through EndpointClosure. Specific request details are configured through RequestClosure. The Session (based on Alamofire) sends the actual HTTP request. 3. Response Processing Stage: The response is divided into two paths based on the request result: success and failure. Success Path: Data Processing → JSON Parsing → Model Conversion → Success Callback. Failure Path: Error Handling → Information Encapsulation → Failure Callback. 4. Auxiliary Functions: Network status monitoring is a separate module.

[0039] Component 5: SKLocation Positioning Component. SKLocation, as a core component of mobile location services, aims to provide efficient, accurate, and low-power positioning capabilities, supporting functions such as acquiring user location information, monitoring location changes, and geocoding. It is based on Amap (Gaode Maps) and has different processing logic in different environments (emulators and real devices). It provides the function of obtaining the device's current geographical location (latitude and longitude).

[0040] Component 6: SKVideoPlayer Video Player. SKVideoPlayer is a wrapper based on open-source third-party libraries (iOS: VideoPlayer, Android: ExoPlayer). As a core component for mobile video playback, it aims to provide high-performance, multi-functional, and low-power video playback capabilities, supporting playback needs in various scenarios such as local videos, network streams, and live broadcasts. It features a fully customizable UI, a built-in caching mechanism, multi-video preloading, support for specifying playback position, and a simple and easy-to-use API. Customizable UI. Ability to play local media or stream remote media via HTTP / HTTPS. Built-in caching mechanism supports playback while downloading. Multiple videos can be preloaded at any time. Support for specifying playback position. Simple API.

[0041] Component 7: SKReachability Network Status Monitoring Tool. SKReachability, as a mobile network reachability detection component, aims to provide real-time and accurate network status monitoring capabilities, helping businesses adjust their behavior based on network type (e.g., Wi-Fi / cellular) and connection status, thereby improving user experience. The following is its outline design framework: Singleton pattern dominant: A globally unique instance is enforced through `public static let shared = SKReachability()`, avoiding state conflicts caused by multiple instances listening simultaneously (e.g., duplicate state updates, resource waste), ensuring network status consistency within the application. Responsive state management: Based on the ObservableObject protocol, the core state property `isReachable` is marked with `@Published`, enabling network status changes to be automatically perceived by the view and trigger UI updates, simplifying the interaction logic between the view and the state. Dependence on mature frameworks: Reusing Alamofire's `NetworkReachabilityManager` to implement underlying network listening avoids redundant development of complex network status detection logic (e.g., system network interface calls, state transition handling), improving the stability of the utility class. Function minimization principle: Only core functions such as network connection status judgment, connection type differentiation (cellular / Wi-Fi) and monitoring start / stop are retained to reduce integration costs while ensuring scalability (if new status types are needed, they can be extended based on the existing architecture).

[0042] Component 8: SKKingfisher Image Downloader. SKKingfisher is a secondary wrapper based on third-party open-source libraries (iOS: Kingfisher, Android: Coil). As a mobile image loading and caching component, it aims to provide efficient, easy-to-use, and scalable image processing capabilities. It supports loading, caching, and displaying network and local images, and also features enhanced image processing functions such as cropping and rounded corners. Covered scenarios: network image loading (HTTP / HTTPS), local image (resource file / sandbox file) loading, image caching (memory / disk), image preprocessing (scaling, cropping, rounded corners), progressive loading (blur to sharp); Supported formats: JPEG, PNG, WebP, GIF (static / animated).

[0043] Component 9: SKRoute SKRoute is a secondary wrapper based on third-party open-source libraries (iOS: LinkNavigator, Android: TheRouter). As a mobile page routing component, it aims to provide a unified and flexible mechanism for page navigation and parameter passing, supporting module decoupling, route interception, and fallback processing capabilities. Suitable for page navigation management in large applications, it helps developers easily navigate between different pages. The library provides an intuitive syntax, supports page navigation via URL-like expressions, supports deep linking, and allows parameter injection during page transitions. The core LinkNavigator is not only suitable for unidirectional architectures (such as the MVI design pattern or pointfreeco's TheComposableArchitecture) but can also be used for other architectures.

[0044] Component 10: SKServiceLocator. SKServiceLocator, as a mobile service locator component, aims to provide a loosely coupled service registration and retrieval mechanism, enabling dependency injection and decoupling between components. It is suitable for service calls and collaboration between modules in large applications. Its core goal is to enable modules to obtain the required services through a "registration-resolution" mechanism, without directly referencing the specific implementations of other modules, using a unified service container (SKServiceLocator). The underlying logic of this design includes: Abstract dependencies: relying on service interfaces (protocols) rather than specific implementations, reducing coupling between modules; Centralized management: managing service registration and retrieval through a unified container, simplifying dependency maintenance; Flexible expansion: supporting dynamic service replacement (e.g., replacing with simulated services during testing), improving system adaptability.

[0045] Component 11: SKInermc Inter-module Communication. SKInermc (Inter-module communication) is a framework designed to achieve efficient communication between independent modules. It solves problems such as module decoupling, message passing controllability, and dynamic interaction by encapsulating three core communication modes (notification center, message center, and publish-subscribe). The core goal of the framework is to provide flexible, manageable, and low-intrusion communication capabilities while ensuring module independence. SKInermc's design revolves around three core principles: "decoupling," "scenario adaptation," and "manageability." Module decoupling is prioritized: Intermediate layers (such as NotificationManager and SKMessageCenter) isolate the communicating parties, avoiding direct module dependencies and reducing coupling. For example, in the notification center mode, the sender and receiver do not need to know of each other's existence; they interact indirectly only through the "notification name." Scenario-differentiated adaptation: Dedicated modes are designed for different communication needs: Simple broadcast scenarios (such as status change notifications): The notification center mode is used, pursuing lightweight and convenient operation; Centralized management scenarios (such as multiple modules listening for the same type of message): The message center mode is used, simplifying many-to-many communication through centralized management. Dynamic interaction scenarios (e.g., on-demand subscription / cancellation of messages): A publish-subscribe pattern is adopted, and message filtering and dynamic management are achieved through "tags". Lifecycle controllability: The lifecycle management of communication relationships is strictly regulated (e.g., registration / deregistration and subscription / cancellation must occur in pairs during initialization / destruction) to avoid memory leaks (e.g., circular references, invalid listeners).

[0046] Furthermore, the platform tool layer 20 includes a packaging and release platform that supports at least one of the following capabilities: unified multi-platform builds through integration with Xcode, Gradle, and HarmonyOS command-line tools via Jenkins; iOS certificate management using Match and code compression and obfuscation using R8 / Proguard; and support for multi-environment builds, including development, R&D, and production environments.

[0047] It should be noted that the pipeline execution process of the packaging and release platform includes: 1. Code retrieval; 2. Dependency installation; 3. Static code scanning (SonarQube / MobSF); 4. Build artifacts (APK / IPA / HAP / APP); 5. Security hardening (Proguard / R8) with specific hardening steps; 6. Distribution testing (TestFlight / Dandelion / internal platform), uploading to the app store (App Store); 7. Result notification (RunWorkbot). The multi-environment management design includes: Android: using BuildVariants to differentiate between dev / staging / prod; iOS: using debug and release environments; HarmonyOS: controlling build parameters through environment variable configuration files.

[0048] Furthermore, the platform tool layer 20 includes a dynamic configuration platform based on Nacos, which supports at least one of the following capabilities: real-time distribution and dynamic updating of configuration parameters; support for canary release strategies, including canary release by user ID, device ID, or version number; and provision of emergency degradation capabilities, including function switch switching and backup interface activation.

[0049] It should be noted that the core features of the dynamic configuration platform are: a. Support for near real-time online configuration distribution: Configurations are dynamically distributed via the server, and clients can pull the latest configurations upon startup, enabling changes to function states and policy parameters without requiring a new release. b. Enhanced degradation and canary deployment capabilities: In case of anomalies or emergencies, certain functions can be quickly disabled, backup interfaces can be switched, and timeout parameters can be adjusted, significantly improving fault response capabilities. c. Improved R&D efficiency and operational flexibility: Product and operations teams can directly control policies through the configuration platform, without frequently relying on client releases, shortening the change cycle. d. Unified configuration management across multiple platforms: Supports configuration management by App name, platform (iOS / Android / HarmonyOS), etc., ensuring consistent behavior across multiple platforms while allowing for differentiated control. The dynamic configuration platform's process on the client side is as follows: 1. Startup: The process is triggered when the client starts. Initialize the configuration manager (ConfigManager). 2. Request configuration: Carrying key parameters: appName (application name), osPlatform (operating system platform). 3. Request result processing: If the request succeeds, parse the JSON data in an asynchronous thread, convert the parsed result into a structure / class model, and mark it as [Configuration initialization complete, model ready]. If the request fails: check the number of retries: less than 3: re-initiate the request after a delay (return to step 1) 3: record the failure log and mark it as [Configuration initialization complete] (no valid model). 4. Success branch: parse the JSON response in a background thread, convert the data into a program model (Struct / Class), and mark it as [Configuration initialization complete, model ready]. 5. Failure branch: less than the retry limit: re-request after a delay. retry limit reached: record the error log. Mark it as [Configuration initialization complete] (no valid model). The core design of this process is a fault tolerance mechanism with 3 retries, asynchronous parsing ensures the smoothness of the main thread, and the final state is unified as [Configuration initialization complete]. When successful, the usable data model is output. The process on the server side is the request processing flow: 1. Receive request. Listen for client configuration requests. Receive parameters: appName (application identifier), osPlatform (operating system type). 2. Parameter validation. 1. Check if required parameters are complete. Verify parameter format validity. Return an error response immediately for invalid parameters. 2. Nacos query. Use appName+osPlatform as the configuration ID. Access the Nacos configuration center to retrieve the latest configuration. Return an empty configuration response if the configuration does not exist. 3. Data conversion. Convert the original configuration to standard JSON format. Add metadata: version: configuration version number; timestamp: effective time; signature: data signature. 4. Response return, set the HTTP status code (200 for success), add the cache control header (max-age=300), and return a JSON format response body.

[0050] The overall process for configuring the platform can be referenced. Figure 2 As shown, this configuration platform includes a client and a server. The client's process can be further referenced. Figure 3 As shown, the specific process includes: 1. Startup: The process and initialization of the configuration manager (ConfigManager) are triggered when the client starts. 2. Configuration Request: A configuration request is sent to the server, carrying key parameters: appName (application name), osPlatform (operating system platform). 3. Request Result Processing: If the request is successful: → Parse the JSON data in an asynchronous thread → Convert the parsed result into a struct / class model → Mark "Configuration initialization complete, model ready" If the request fails: Check the retry count: Less than 3 times: Resend the request after a delay (return to step 1). 3 times: Record the failure log → Mark "Configuration initialization complete" (no valid model). 4. Success branch: Parse the JSON response in a background thread, convert the data into a program model (Struct / Class) and mark "Configuration initialization complete, model ready". 5. Failure branch: Less than the retry limit: Resend the request after a delay. Retry limit reached: Record the error log and mark "Configuration initialization complete" (no valid model).

[0051] The server-side process can be further referenced. Figure 4 As shown, 1. Request processing flow, including (1) Receiving requests: Listening for client configuration requests. Receiving parameters: appName (application identifier), osPlatform (operating system type). (2) Parameter verification: Checking whether the required parameters are complete, verifying the validity of the parameter format, and invalid parameters → immediately returning an error response. (3) Nacos query: Using appName+osPlatform as the configuration ID, accessing the Nacos configuration center to obtain the latest configuration, if the configuration does not exist → returning an empty configuration response. (4) Data conversion: Converting the original configuration to standard JSON format, adding metadata: version: configuration version number, timestamp: effective time, signature: data signature. (5) Response return: Setting the HTTP status code (200 success), adding the cache control header (max-age=300), and returning the JSON format response body.

[0052] Configuration management process: 1. Administrator operation: Log in to the Nacos console. Select the target configuration set by namespace. 2. Configuration editing: Supports two operation modes: Add: Create a new configuration item; Modify: Update an existing configuration value. Supports multiple editing formats: form mode (key-value pairs), text mode (JSON / YAML / Properties). 3. Version control: Automatically generates version numbers. Supports comparison with historical versions and configuration rollback. 4. Configuration publishing: Perform small-batch verification, and publish to the Nacos storage center after confirmation. Trigger configuration change notifications; new requests take effect immediately. Nacos platform roles include: unified storage (centralized management of all application configurations), real-time synchronization (second-level push to all service nodes), access control (namespace isolation and access management), and monitoring and auditing (recording all configuration changes and tracking operation logs).

[0053] Furthermore, the operation and maintenance monitoring platform includes at least one of the following functions: automatic collection of client crash data, symbol table parsing, and multi-dimensional statistical analysis; monitoring and analysis of performance indicators such as cold start performance and lag rate; support for remotely pulling client logs by user ID or device ID; and integrated hot-fix capabilities, supporting gray-scale, full release, and rollback of patches.

[0054] It's important to note that the purpose of the operations and maintenance monitoring platform is to improve the timeliness of fault detection, reduce troubleshooting time, enable seamless updates for users, and improve user experience (in the past, due to the App Store review mechanism, the release cycle generally took about 2 days). The Wanjia mobile platform requires a full lifecycle solution for enterprise-level mobile applications, integrating core capabilities for development, testing, release, and operations to help quickly and efficiently build and manage mobile applications. The platform integrates the EMAS tool to achieve the following capabilities: EMAS (Enterprise Mobile Application Platform) is a full lifecycle solution for enterprise-level mobile applications, integrating core capabilities for development, testing, release, and operations to help enterprises quickly and efficiently build and manage mobile applications. Its core functions can be summarized into four categories: "development efficiency improvement, quality monitoring, and operational support." The problems it addresses are: 1. Full-link performance monitoring, real-time collection of metrics such as startup time, page rendering time, memory usage, and CPU utilization; monitoring network requests: tracking API response time and error rate to locate slow interfaces and server-side problems; improving detection timeliness and ensuring timely reception by configuring various alarm policies, alarm channels, and alarm scopes. 2. Mobile Testing: Addresses the issue of limited testing devices and insufficient system and version coverage for all user groups through cloud-based real device testing. 3. Anomaly Tracking and Analysis: Automatically captures crashes and ANRs (Application Not Responding), recording complete stack information and device environment; supports custom anomaly reporting for quick identification of business logic errors (e.g., payment process failures). 4. User Experience Analysis: Tracking and behavioral analysis: Records user clicks, page navigation, and other behaviors to analyze feature usage and retention rates; lag monitoring: Detects UI thread blocking, generates main thread stack logs, and optimizes smoothness. 5. Hotfix and Dynamic Updates: No app store approval required; real-time bug fixing via patch packages (supports Java, Kotlin, and Objective-C); dynamically updates configurations (e.g., switches, parameters) for rapid adjustment of business strategies.

[0055] In this embodiment, the component-based architecture layer provides standardized basic technology components; the packaging and deployment platform continuously integrates and deploys the source code of the standardized basic technology components, generating application packages that can run on iOS, Android, and HarmonyOS; the dynamic configuration platform dynamically distributes configuration parameters to the distributed mobile applications to control their runtime behavior; and the operation and maintenance monitoring platform collects and analyzes application performance, crash, and log data, and provides hot-repair capabilities. This approach constructs a component-based, platform-based technical system with deep collaboration among its components, using a systematic technical framework to uniformly solve the efficiency, quality, and stability issues of related mobile development across the entire chain of architecture, delivery, and operation and maintenance.

[0056] Furthermore, this embodiment of the invention also proposes a storage medium storing a mobile application development and maintenance program based on a unified technology platform. When the mobile application development and maintenance program based on the unified technology platform is executed by a processor, it implements the steps of the mobile application development and maintenance method based on the unified technology platform described above.

[0057] Reference Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the mobile application development and operation method based on a unified technology platform according to the present invention.

[0058] like Figure 2 As shown in the embodiments of the present invention, the mobile application development and operation method based on a unified technology platform includes: Step S10: The component-based architecture layer provides standardized basic technology components, which are reusable and follow a unified design paradigm, serving as a unified technical interface for upper-layer business development.

[0059] Step S20: The packaging and distribution platform continuously integrates and deploys the source code of the standardized basic technology components to generate an application package that can run on iOS, Android, and HarmonyOS.

[0060] Step S30: The dynamic configuration platform dynamically sends configuration parameters to the distributed mobile applications to control the behavior of the mobile applications during runtime.

[0061] Step S40: The operation and maintenance monitoring platform collects and analyzes the application's performance, crash and log data, and provides hot-repair capabilities.

[0062] In this embodiment, the component-based architecture layer provides standardized basic technology components; the packaging and deployment platform continuously integrates and deploys the source code of the standardized basic technology components, generating application packages that can run on iOS, Android, and HarmonyOS; the dynamic configuration platform dynamically distributes configuration parameters to the distributed mobile applications to control their runtime behavior; and the operation and maintenance monitoring platform collects and analyzes application performance, crash, and log data, and provides hot-repair capabilities. This approach constructs a component-based, platform-based technical system with deep collaboration among its components, using a systematic technical framework to uniformly solve the efficiency, quality, and stability issues of related mobile development across the entire chain of architecture, delivery, and operation and maintenance.

[0063] This application also provides a mobile application development and maintenance device based on a unified technology platform, including a processor, a communication interface, a memory, and a communication bus. The processor, communication interface, and memory communicate with each other through the communication bus. The memory is used to store mobile application development and maintenance programs based on the unified technology platform. When the processor executes the programs stored in the memory, it implements the aforementioned mobile application development and maintenance method based on the unified technology platform.

[0064] The communication bus mentioned in the aforementioned mobile application development and maintenance equipment based on a unified technology platform can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc.

[0065] The communication interface is used for communication between the aforementioned mobile application development and maintenance equipment based on a unified technology platform and other devices.

[0066] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0067] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0068] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0069] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0070] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

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

[0072] It should be understood that the above are merely illustrative examples and do not constitute any limitation on the technical solutions of the present invention. In specific applications, those skilled in the art can make settings as needed, and the present invention does not impose any restrictions on this.

[0073] It should be noted that the workflow described above is merely illustrative and does not limit the scope of protection of this invention. In practical applications, those skilled in the art can select some or all of the workflow to achieve the purpose of this embodiment according to actual needs, and no restrictions are imposed here.

[0074] In addition, for technical details not described in detail in this embodiment, please refer to the mobile application development and operation method based on a unified technology platform provided in any embodiment of the present invention, which will not be repeated here.

[0075] Furthermore, it should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0076] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0077] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0078] The above are merely preferred embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

[0079] It is understood that the system provided in the embodiments of the present invention corresponds to the method provided in the embodiments of the present invention, and the explanation, examples and beneficial effects of the relevant content can be referred to the corresponding parts of the above methods.

Claims

1. A unified technology platform system for mobile terminals, characterized in that, The unified mobile technology platform system is used to support at least two independent mobile applications. The system includes: The component-based architecture layer is used to provide standardized basic technology components. These standardized basic technology components are reusable and follow a unified design paradigm, serving as a unified technical interface for upper-layer business development. The platform tool layer, integrated with the standardized basic technology components, is used for building, configuring, and operating applications. The platform tool layer includes a packaging and release platform, a dynamic configuration platform, and an operation and maintenance monitoring platform. The packaging and distribution platform is used to continuously integrate and deploy the source code that integrates the standardized basic technology components, generating application packages that can run on iOS, Android and HarmonyOS. The dynamic configuration platform communicates with the configuration retrieval component integrated within the client to dynamically send configuration parameters to the distributed mobile applications in order to control the behavior of the mobile applications during runtime. The operation and maintenance monitoring platform communicates with the data acquisition SDK integrated in the client to collect and analyze application performance, crash and log data, and provide hot repair capabilities. The componentized architecture layer, packaging and release platform, dynamic configuration platform and operation and maintenance monitoring platform work together to provide unified technical support for the at least two independent mobile applications, enabling cross-application reuse of business functions and consistent operation and maintenance management.

2. The mobile terminal unified technology foundation system as described in claim 1, characterized in that, The core architectural principles followed by the component-based architecture layer include the Single Responsibility Principle, Protocol-Oriented Programming Principle, Dependency Inversion Principle, and Interface Segregation Principle. The Single Responsibility Principle focuses each component on a specific domain problem; the Protocol-Oriented Programming Principle defines the capabilities exposed by a component through a protocol; the Dependency Inversion Principle injects dependencies through the constructor; and the Interface Segregation Principle avoids creating large protocols that contain multiple unrelated capabilities.

3. The mobile terminal unified technology foundation system as described in claim 1, characterized in that, The standardized basic technology components follow at least one of the following standardized paradigms: utility classes or static service components, using the singleton pattern or static method class; configuration classes or injectable service components, injecting configuration objects through the constructor; UI components, using the builder pattern or view pattern, and are prohibited from containing business logic.

4. The mobile terminal unified technology foundation system as described in claim 1, characterized in that, The packaging and release platform supports at least one of the following capabilities: unified multi-platform build through Jenkins integration with Xcode, Gradle, and HarmonyOS command-line tools; iOS certificate management using Match; and code compression and obfuscation using R8 / Proguard. It supports building multiple environments, including development, R&D, and production environments.

5. The mobile terminal unified technology base system as described in claim 1, characterized in that, The dynamic configuration platform is based on Nacos and supports at least one of the following capabilities: real-time distribution and dynamic updating of configuration parameters; and support for canary release strategies, including canary release by user ID, device ID, or version number. Provides emergency degradation capabilities, including function switch switching and backup interface activation.

6. The mobile terminal unified technology foundation system as described in claim 1, characterized in that, The dynamic configuration platform includes a client and a server. When the client starts up, it initiates a configuration request through the configuration manager. The configuration request includes the application name and the operating system platform identifier. If the request fails, the client executes a delayed retry mechanism at least once until the preset retry limit is reached or the request succeeds. After receiving a client request, the server queries the Nacos configuration center based on the application name and operating system platform identifier, obtains the corresponding configuration, converts it into JSON format, adds version number, timestamp, and data signature metadata to the response, and then returns it to the client.

7. The mobile terminal unified technology foundation system as described in claim 1, characterized in that, The operation and maintenance monitoring platform includes at least one of the following functions: automatic collection of client crash data, symbol table parsing and multi-dimensional statistical analysis; monitoring and analysis of performance indicators such as cold start performance and lag rate; support for remotely pulling client logs by user ID or device ID; and integrated hot-fix capability, supporting gray-scale, full release and rollback of patches.

8. A method for developing and maintaining mobile applications based on a unified technology platform, characterized in that, The mobile application development and operation method based on a unified technology platform is applied to the mobile unified technology platform system as described in any one of claims 1 to 7, and the method includes: The component-based architecture layer provides standardized basic technology components, which are reusable and follow a unified design paradigm, serving as a unified technical interface for upper-layer business development. The packaging and distribution platform continuously integrates and deploys the source code that integrates the standardized basic technology components, generating application packages that can run on iOS, Android, and HarmonyOS. The dynamic configuration platform dynamically sends configuration parameters to the distributed mobile applications to control the behavior of the mobile applications during runtime. The operation and maintenance monitoring platform collects and analyzes application performance, crash and log data, and provides hot-repair capabilities.

9. A mobile application development and maintenance device based on a unified technology platform, characterized in that, The mobile application development and maintenance device based on a unified technology platform includes: a memory, a processor, and a mobile application development and maintenance program based on a unified technology platform stored on the memory and capable of running on the processor. The mobile application development and maintenance program based on a unified technology platform is configured to implement the steps of the mobile application development and maintenance method based on a unified technology platform as described in claim 8.

10. A storage medium, characterized in that, The storage medium stores a mobile application development and operation program based on a unified technology platform. When the mobile application development and operation program based on the unified technology platform is executed by the processor, it implements the steps of the mobile application development and operation method based on a unified technology platform as described in claim 8.

Images