Mobile terminal productization configuration method and system

Abstract

The invention relates to the technical field of computer software development and application deployment, and discloses a mobile terminal productization configuration method and system.The method comprises the steps that a cross-platform development framework and a front-end framework are selected and configured; common parts in page logic are extracted into independent modules, and differential requirements in different environments are met in a parameterization mode; loading a corresponding configuration file according to a target environment, wherein the target environment comprises a development environment and a production environment; defining a mapping relation between the input path and the output path, and dynamically synchronizing the function file under the input path to the output path in the construction process; and controlling the synchronization logic of the configuration file and the code file through the life cycle of the plug-in, wherein the synchronization logic comprises real-time monitoring in a development environment and one-time synchronization in a production environment. According to the method, the problem that customization and productization are difficult to consider in a traditional development mode is solved, and the development efficiency and the convenience of later maintenance are improved through a systematic technical means.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer software development and application deployment, in particular to a mobile terminal productization configuration method and system. BACKGROUND

[0002] With the rapid development of mobile Internet, more and more Internet service providers (ISPs) need to provide customized mobile application solutions for different customers or application scenarios. However, the traditional development mode often has contradictions between "productization" and "customization": on the one hand, in order to improve development efficiency and reduce maintenance cost, enterprises tend to adopt unified productization architecture; on the other hand, in the face of diversified customer demand, a large amount of customized development is inevitable, resulting in increased repetitive workload, rising version management complexity, and even affecting product stability and delivery cycle.

[0003] In the prior art, although there are development methods based on cross-platform frameworks (such as React Native, Uni-app) to realize code reuse, there are still deficiencies in dealing with multi-environment configuration, differentiated path mapping and construction process automation. In particular, during development, how to efficiently handle configuration switching, path synchronization and logic adaptation in different environments lacks systematic method support, resulting in low development efficiency, high error rate, and cumbersome deployment process.

[0004] Therefore, a mobile terminal productization configuration method and system are proposed. SUMMARY

[0005] In view of this, the present application proposes a mobile terminal productization configuration method and system, which not only solves the problem of difficulty in balancing customization and productization in the traditional development mode, but also improves development efficiency, construction quality and the convenience of later maintenance through systematic technical means, and has wide application prospect and practical value.

[0006] To achieve the above purpose, in a first aspect, the present application provides a mobile terminal productization configuration method, comprising:

[0007] selecting and configuring a cross-platform development framework and a front-end framework;

[0008] extracting common parts in page logic into independent modules, and adapting differentiated needs in different environments through parameterization, wherein the common parts include data loading and event handling;

[0009] loading corresponding configuration files according to target environments, wherein the target environments include development environments and production environments, and the configuration files include static resource paths, basic configuration items, style variables and output path mapping rules;

[0010] Define the mapping relationship between the input path codePath and the output path path, and dynamically synchronize the function files under the input path to the output path during the construction process.

[0011] Through the synchronization logic of the plug-in life cycle control configuration file and the code file, including real-time monitoring in the development environment and one-time synchronization in the production environment.

[0012] Preferably, the corresponding configuration file is loaded according to the target environment, specifically:

[0013] In the preset configuration directory, subdirectories are divided according to the environment, and each subdirectory contains environment-specific configuration files, including a static resource folder, a basic configuration file, a construction configuration file, a page configuration file, and a style configuration file.

[0014] The static resource folder is used to store environment-specific static resources, including images and fonts.

[0015] The basic configuration file is used to define environment-specific configuration items, including API addresses and theme colors.

[0016] The construction configuration file is used to specify construction parameters, including application names and icons.

[0017] The page configuration file is used to define page path mapping rules and output paths.

[0018] The style configuration file is used to store style variables to control UI presentation.

[0019] Through the construction parameters, the configuration file of the target environment is automatically selected and synchronized to the corresponding position of the code folder during the construction process.

[0020] Preferably, the mapping relationship between the input path codePath and the output path path is defined, and the function files under the input path are dynamically synchronized to the output path during the construction process, specifically:

[0021] In the page configuration file, define the input path codePath and the output path path fields, the codePath points to the function files under different environments, and the path is a unified output path.

[0022] Based on the two-way synchronization mechanism, the function files under the codePath path are dynamically synchronized to the path path according to the target environment.

[0023] Preferably, the bidirectional synchronization mechanism dynamically synchronizes the function files under the codePath path to the path path according to the target environment, in particular:

[0024] The bidirectional synchronization mechanism includes development environment synchronization and production environment synchronization.

[0025] The development environment synchronization listens to file changes under the codePath and path paths in the development environment through a file listener.

[0026] When the codePath file is updated, it is automatically synchronized to the path path and triggers a hot update.

[0027] When the path path file is manually modified, it is synchronized back to the codePath to ensure source file consistency.

[0028] The production environment synchronization synchronizes the codePath files to the path path once during build in the production environment to generate the final product.

[0029] Preferably, the synchronization logic of the configuration file and the code file through the plugin life cycle control includes real-time listening in the development environment and one-time synchronization in the production environment, in particular:

[0030] The plugin life cycle includes config life cycle, transform life cycle, and watchChange life cycle.

[0031] The configuration file synchronization logic is as follows:

[0032] In the config life cycle, determine the current environment. If the current environment is the development environment, start the listening logic and realize real-time reading and writing of the configuration file through a file operation tool.

[0033] If the current environment is the production environment, perform one-time synchronization.

[0034] The code file synchronization logic is as follows:

[0035] In the transform life cycle, detect file changes in the codePath and path paths and start listening through the addWatchFile method.

[0036] In the watchChange life cycle, perform file synchronization operations. The listener is automatically closed at the end of the build process.

[0037] Preferably, it also includes a security enhancement strategy, in particular:

[0038] Sensitive configuration items are encrypted and dynamically decrypted at runtime;

[0039] Access to the configuration directory is restricted by permissions, allowing only authorized users or devices with authorized IP addresses to modify the configuration files.

[0040] Preferably, it also includes a compatibility testing scheme, specifically:

[0041] Perform multi-platform compatibility testing for different operating systems, browsers, and device resolutions;

[0042] Verify UI consistency using real device debugging tools to ensure that functions under the output path operate normally in different environments.

[0043] Preferably, it also includes a feedback and iteration mechanism, specifically:

[0044] The application integrates seamless tracking to collect user behavior data, including click and crash events.

[0045] Provide a user feedback portal and dynamically adjust configuration files based on feedback data, including changing theme colors and adjusting layouts;

[0046] Hot update mechanisms quickly push out bug fixes, eliminating the need for users to reinstall the application.

[0047] Secondly, the present invention provides a mobile terminal product configuration system, comprising:

[0048] The framework configuration module is used to select and configure cross-platform development frameworks and front-end frameworks;

[0049] The logic layer module is used to extract the common parts of the page logic into independent modules, and adapt to the differentiated needs in different environments through parameterization. The common parts include data loading and event handling.

[0050] The adaptation module is used to load the corresponding configuration file according to the target environment, which includes development environment and production environment. The configuration file includes static resource path, basic configuration items, style variables and output path mapping rules.

[0051] The mapping and synchronization module is used to define the mapping relationship between the input path codePath and the output path path, and dynamically synchronizes the functional files under the input path to the output path during the construction process;

[0052] An integrated plugin module is used to control the synchronization logic between configuration files and code files through the plugin lifecycle, including real-time monitoring in the development environment and one-time synchronization in the production environment.

[0053] Preferably, the adaptation module, in particular:

[0054] Under the preset configuration directory, subdirectories are divided according to the environment, and each subdirectory contains environment-specific configuration files, including a static resource folder, a basic configuration file, a build configuration file, a page configuration file, and a style configuration file.

[0055] The static resource folder is used to store environment-specific static resources, including, for example, pictures and fonts.

[0056] The basic configuration file is used to define environment-specific configuration items, including API addresses and theme colors.

[0057] The build configuration file is used to specify build parameters, including application names and icons.

[0058] The page configuration file is used to define page path mapping rules and output paths.

[0059] The style configuration file is used to store style variables to control UI presentation.

[0060] By automatically selecting the configuration file of the target environment through the build parameters, the configuration file is synchronized to the corresponding location of the code folder during the build process.

[0061] The embodiments of the present application disclose a mobile terminal productization configuration method and system. The method can quickly adapt to differentiated needs in different environments by separating common parts in page logic into independent modules and using parameterized design, avoiding repeated coding and significantly improving development efficiency; at the same time, maintaining a unified front-end architecture is conducive to forming a standardized product system, facilitating subsequent maintenance and upgrading. According to the target environment (such as a development environment or a production environment), the corresponding configuration file is dynamically loaded to realize resource configuration isolation and on-demand loading in different scenarios; the configuration file structure is clear and easy to maintain, which helps to improve the configurability and portability of the system. By defining the mapping relationship between the input path (codePath) and the output path (path), combined with a bidirectional synchronization mechanism, the required build products can be automatically generated in different environments; real-time listening and hot updating are supported during the development phase, and one-time synchronization is performed during the production phase, balancing development efficiency and release stability. The synchronization logic of the configuration file and the code file is controlled by the plug-in life cycle (such as config, transform, and watchChange), making the entire build process more intelligent and automated; the plug-in mechanism has good extensibility, facilitating subsequent function expansion and process optimization. All configuration and path information is centrally managed, reducing version control difficulty; modular design and plug-in architecture also provide a good extension foundation for subsequent function iteration. Attached Figure Description

[0062] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0063] Figure 1 A flowchart illustrating a mobile terminal product configuration method provided in an embodiment of the present invention;

[0064] Figure 2 This is a schematic diagram of the structure of a mobile terminal product configuration system provided in an embodiment of the present invention. Detailed Implementation

[0065] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the disclosure to those skilled in the art. It should be noted that, unless otherwise specified, embodiments and features in the embodiments of the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0066] like Figure 1 As shown, in some embodiments of this application, this embodiment provides a mobile terminal product configuration method. Specifically, the method includes the following steps:

[0067] Step S101: Select and configure the cross-platform development framework and front-end framework.

[0068] As mentioned above, selecting and configuring the cross-platform development framework and the front-end framework are the basic steps of the entire mobile product configuration method. This step aims to determine the development tools and technology stack that the project will use to ensure that subsequent development work can proceed smoothly and meet the multi-end compatibility requirements. Selecting the appropriate cross-platform development framework and front-end framework not only helps to improve development efficiency, but also ensures the stability and consistency of the application on different operating systems (such as iOS, Android) and browsers. Cross-platform development frameworks allow developers to use a set of code libraries to build applications that run on multiple platforms, reducing the amount of repetitive development work. Uni-app is a popular cross-platform development framework that supports packaging Vue.js applications into various forms such as iOS, Android, and H5. Front-end frameworks are used to build user interface frameworks that provide component-based development patterns and data binding functions. Vue3 is a new generation of front-end framework that has a combination of APIs and better performance.

[0069] For example, assume that a mobile application is developed for an e-commerce platform that needs to support both iOS and Android operating systems, and also requires a web version so that users can access it directly through a browser. In this case, Uni-app can be chosen as the cross-platform development framework because it can seamlessly convert Vue.js applications into native mobile applications and web applications. For the front-end framework, Vue3 is adopted to simplify the UI development process using its single-file component feature and to achieve logic reuse and modular design through the combination of APIs. In actual operation, according to the specific requirements of the project, install the necessary dependency packages, set up the project structure, configure the routing, state management, and other basic functions to lay the foundation for subsequent development.

[0070] Step S102, abstract the common part in the page logic as an independent module, and adapt to the differentiated needs in different environments through parameterization, the common part includes data loading and event processing.

[0071] As mentioned above, abstract the parts of the page logic that remain consistent in different environments (such as data loading and event processing) as independent modules, and make them adaptable to different environmental requirements through parameterization. This process not only improves the reusability of the code, but also simplifies subsequent maintenance work, allowing the development team to focus on customizing requirements for specific environments.

[0072] The common part refers to those functional logics that will appear in all or most pages, such as data loading, state management, event listening and processing, etc. These logics usually have high universality and are suitable to be extracted to form independent modules. By encapsulating the common part into independent modules, logic reuse can be achieved, repeated coding can be reduced, and unified management and updating can be facilitated. The behavior of the module is controlled by defining parameters, so as to adapt to the specific needs in different environments. This way allows developers to adjust the functional performance without modifying the core logic, enhancing the flexibility and scalability of the system.

[0073] For example, suppose an application containing multiple pages is being developed, and each page needs to obtain user information from the server and display it. First, an independent data loading module is created, which is responsible for initiating network requests and returning user information. This module can accept parameters such as API endpoint address, request method type (GET / POST), and parameters to be passed. The event handling module can handle common interaction behaviors such as clicking the button to refresh data, automatically obtaining the latest data when the page is loaded, etc. Similarly, these event handling functions can also receive parameters to determine how to respond to user operations in different environments. In actual application, when debugging in the development environment is needed, different parameters can be set to simulate the data flow in the production environment; while in the production environment, real data sources can be used without changing any core logic.

[0074] It should be noted that in specific implementation scenarios, the above-mentioned solutions can be further adopted, such as component-based architecture, UI components (such as navigation bar, sidebar, etc.) can also be included in the modular system, each component can have its own configuration file to define its appearance style and interaction behavior, so that the required interface can be quickly assembled in different environments. Service layer separation scheme, which further abstracts business logic and service calls into independent service layers, to facilitate the replacement of specific implementation details in different scenarios, such as using mock services instead of real API calls in test environments, and switching back to actual service interfaces in production environments. Environment variable driven scheme, which uses environment variables to control the behavior of the module instead of hardcoding it inside the module, allowing developers to easily adjust the working mode of the module according to different deployment environments without modifying the source code. External configuration file scheme, which introduces external configuration files to store various environment-related settings such as API addresses, theme colors, etc. These configuration files can be dynamically loaded according to the current running environment to ensure that the application can run correctly in different contexts. The above optional solutions are within the scope of protection of the present application.

[0075] Step S103, load the corresponding configuration file according to the target environment, the target environment includes development environment and production environment, and the configuration file includes static resource path, basic configuration item, style variable and output path mapping rule.

[0076] As mentioned above, the corresponding configuration file is dynamically loaded according to different target environments (such as development environment and production environment). The configuration file contains key information such as static resource path, basic configuration item (such as API address, theme color), style variable and output path mapping rule, which is crucial to ensure the correct operation of the application in different environments. The static resource path specifies the storage location of static resources such as pictures and fonts, ensuring that these resources can be accessed correctly in different environments. The basic configuration item includes but is not limited to API address, database connection string, etc. These configuration items may differ depending on the environment. Style variables are used to define the visual properties of UI elements such as color and font size to adapt to different brand or design requirements. The output path mapping rule defines the mapping relationship between the input path (codePath) and the output path (path), ensuring that the function file can be correctly synchronized from one location to another during the build process. Through this process, seamless switching between development and production environments can be achieved, while ensuring that the configuration in each environment is accurately applied, reducing the risk of errors caused by manual intervention.

[0077] For example, assume that a release version is being prepared for a mobile application and needs to support two environments, including development environment and production environment. In the development environment: the static resource path points to the resources on the local server, which is convenient for developers to debug; the API address in the basic configuration item is set to the address of the test server, so as to simulate the real scene without affecting the actual user data; the style variable may be set to a brighter color scheme to facilitate problem identification and adjustment; the output path mapping rule allows developers to view the impact of code changes on the page in real time, supporting the hot update mechanism.

[0078] In the production environment: the static resource path is changed to the resource link on the CDN, improving resource loading speed; the API address in the basic configuration item points to the official server, using real data sources; the style variable adopts the official brand color scheme, providing consistent user experience; the output path mapping rule ensures that the final product can be correctly deployed to the production server, without any debugging information.

[0079] In this way, the development team can focus on function implementation and debugging during the development phase, and simply switch the configuration file to quickly enter the production state near the release time.

[0080] It should be noted that in a specific implementation scenario, on the basis of the above scheme, a pre-release environment scheme can also be adopted, that is, in addition to the development environment and the production environment, a pre-release environment can also be introduced as a transition stage for internal testing or open beta to a specific user group. The configuration file in this environment can be adjusted according to actual conditions, for example, using some real production data but limiting some sensitive operations. The CI / CD integration scheme is adopted, that is, combined with the continuous integration / continuous delivery (CI / CD) pipeline, the current environment is automatically detected and the corresponding configuration file is loaded. In this way, not only can the deployment process be simplified, but also the possibility of human error can be reduced. The version control scheme is adopted, that is, strict version management is implemented for the configuration file, and the history record of each modification is recorded to facilitate the tracking of the problem source. When a problem occurs, the previous stable version can be quickly rolled back. The above optional schemes all belong to the protection scope of the present application.

[0081] Step S104, define the mapping relationship between the input path codePath and the output path path, and dynamically synchronize the function files under the input path to the output path during the construction process.

[0082] As described above, during the project construction process, the mapping relationship between the input path (codePath) and the output path (path) is defined to realize the automatic synchronization of function files from the development environment to the production environment. This mapping relationship ensures the correct deployment of function files in different environments, while supporting real-time updates and debugging during development.

[0083] The input path (codePath) specifies the storage location of function files in the development environment or specific configuration, which usually includes specific business logic, page components, etc. The output path (path) is the storage location of the final generated product, used to store files after compilation and optimization, ready for deployment to the production environment. During the construction process, the system will automatically copy or move the files under codePath to path according to the pre-defined mapping rules, and perform corresponding processing (such as compression, obfuscation, etc.) as needed to ensure the consistency and integrity of the final product. This process not only simplifies the operation process of developers, but also improves the maintainability and extensibility of the project.

[0084] For example, an e-commerce application is being developed, which contains multiple page modules such as the home page, product detail page, shopping cart, etc. Each page has its own function files and resource files.

[0085] In the development environment: There may be multiple versions of the product detail page, corresponding to different test scenarios (such as views / product-detail-dev.vue, views / product-detail-test.vue, etc.), stored in the codePath directory. According to the needs of the current development stage, select one version as the default display page and map its path to the unified output path in the path directory (such as views / product-detail.vue).

[0086] In the build process: If you are currently in development mode, the system will listen to any changes in codePath (such as modifying a page's function file) and immediately synchronize the changes to the path directory so that developers can see the results immediately. When switching to production mode, the system will copy all selected function files from codePath to path directory at once and perform necessary optimization operations (such as code compression, image optimization, etc.) to prepare for final release.

[0087] In this way, whether in development or production environment, the correctness and consistency of function files can be ensured, reducing the risk of errors caused by manual intervention.

[0088] It should be noted that in specific implementation scenarios, on the basis of the above scheme, a multi-path synchronization scheme can also be adopted, that is, in addition to the basic input and output paths, more levels of path mapping can be supported, such as for some specific types of files (such as static resources), additional synchronization rules can be set to ensure that they can be correctly loaded in different environments. Real-time synchronization scheme in development environment, that is, not only supports one-way synchronization from codePath to path, but also can realize reverse synchronization, for example, when directly modifying files in the path directory, the system can automatically synchronize these changes back to codePath, maintaining the consistency of source files. The above optional schemes are within the scope of protection of the present application.

[0089] Step S105, synchronize the configuration file and the code file through the plug-in life cycle control, including real-time listening in the development environment and one-time synchronization in the production environment.

[0090] As mentioned above, the lifecycle mechanism of the plugin system is used to intelligently control the synchronization behavior between the configuration file and the code file during the build process. Plugin lifecycle management: Modern front-end build tools (such as Vite, Webpack, Rollup, etc.) usually provide a complete set of plugin lifecycle interfaces for intervention in the build process at different stages. This solution uses these lifecycle hooks reasonably to achieve precise control over synchronization logic. Real-time monitoring in development environment: In the development stage, the system starts a listener to continuously monitor changes in configuration files and code files, and automatically triggers synchronization operations after detecting changes. Combined with hot update technology, it improves development efficiency. One-time synchronization in production environment: When building and releasing the final version, only one-time file synchronization operation is performed to ensure that the final output product is stable, predictable, and does not contain unnecessary debugging information. Through this mechanism, differentiated synchronization strategies can be achieved in different build modes, meeting the flexibility of the development process and ensuring the stability and security of the production environment.

[0091] For example, take a mobile application project as an example. This project needs to support rapid iteration in the development stage and efficient packaging and deployment in the production environment.

[0092] In the development environment: When the developer modifies a page style variable or API address, the system will capture the changes through the plugin in a specific lifecycle (such as watchChange); then trigger the synchronization operation of the configuration file and the corresponding code file, and notify the browser to perform hot update, so that the changes take effect immediately; This can avoid manual page refresh or recompile the entire project, greatly improving development efficiency.

[0093] In the production environment: The build process enters a one-time build mode. After determining that it is a production environment in the config lifecycle, the listener function is no longer enabled. The plugin will perform a complete synchronization operation on all necessary configuration files and code files before the build starts. After synchronization is complete, continue with the compression, packaging, and optimization processes to generate stable products for release.

[0094] This approach achieves the organic unity between the efficient experience of "development as seen" and the safe delivery of "production as available".

[0095] It should be noted that in a specific implementation scenario, on the basis of the above scheme, a multi-stage life cycle cooperative control scheme can also be adopted, that is, not only the basic synchronization operation is limited, but also more complex task chains can be executed in different life cycle stages, for example: loading and verifying the configuration in the config stage; processing code conversion in the transform stage; performing cleaning or logging in the buildEnd stage. By combining multiple life cycle events, a complete automated build control system is formed. A dynamic environment sensing and strategy switching scheme is adopted, that is, the plug-in can automatically switch the synchronization strategy according to the current running environment (development / test / pre-release / production) without manual intervention; for example, in the test environment, part of the monitoring function is turned on to verify the problem; in the pre-release environment, the production synchronization logic is simulated to discover potential risks in advance. A cross-module linkage mechanism scheme is adopted, that is, the plug-in is not only responsible for the synchronization of a single path, but also can coordinate the dependency relationship between multiple modules to ensure that when a module changes, the related configuration and code can also be updated synchronously; for example, when a certain public component library is upgraded, all pages that reference the component are automatically triggered to update synchronously. The above optional schemes are within the protection scope of the present application.

[0096] In some embodiments of the present application, in order to realize the centralized management and environment isolation of the configuration, improve the maintainability and deployment efficiency of the system. According to the target environment, the corresponding configuration file is loaded, specifically:

[0097] Subdirectories are divided under the preset configuration directory according to the environment, and each subdirectory contains environment-specific configuration files, including a static resource folder, a basic configuration file, a build configuration file, a page configuration file, and a style configuration file;

[0098] The static resource folder is used to store environment-specific static resources, including, for example, pictures and fonts;

[0099] The basic configuration file is used to define environment-specific configuration items, including API addresses and theme colors;

[0100] The build configuration file is used to specify build parameters, including application names and icons;

[0101] The page configuration file is used to define page path mapping rules and output paths;

[0102] The style configuration file is used to store style variables to control UI presentation;

[0103] The configuration file of the target environment is automatically selected through the build parameter, and is synchronized to the corresponding position of the code folder during the build process.

[0104] As described above, according to the target environment, the corresponding configuration file is loaded, specifically including the following operations: a unified configuration directory is preset in the system, and different target running environments are divided under the directory, such as development environment, test environment, production environment, etc., and each environment corresponds to an independent subdirectory. Each subdirectory contains a set of configuration files that are exclusive to the environment, and these configuration files are used to define the basic parameters and resource information required by the application program in the current environment.

[0105] The configuration file includes: a static resource folder for storing static resource files related to the current environment, such as pictures, fonts, etc. The static resources under different environments may differ, for example, low-resolution pictures are used in the development environment for debugging, while high-resolution pictures are used in the production environment to ensure visual effects; a basic configuration file for defining core configuration items in the current environment, such as backend interface address (API address), theme color, whether to enable debugging mode, etc. These configuration items directly affect the function behavior and appearance of the application; a build configuration file for specifying the parameters required for project building in the current environment, such as application name, icon, start page settings, etc. These parameters usually affect the display form and platform adaptability of the final output product; a page configuration file for defining page path mapping rules and output path settings. Through this configuration file, the loading path of different page components in different environments can be controlled, and the consistency of the file structure during the building process can be ensured; a style configuration file for storing variable definitions related to interface style, such as color values, font sizes, spacing units, etc. Through this configuration file, unified management of the overall UI style of the application can be achieved, and flexible adjustment of visual presentation according to different environments can be supported.

[0106] In actual execution of the building process, the system automatically identifies the target environment according to the input building parameters, and loads the corresponding configuration file from the corresponding subdirectory. Then, the system synchronizes the content of these configuration files to the specified location in the code directory, so that subsequent compilation, packaging, etc. operations can correctly reference these configuration information. This way realizes the centralized management and environment isolation of the configuration, improves the maintainability and deployment efficiency of the system.

[0107] In some embodiments of the present application, in order to improve the building efficiency, simplify the deployment process, and enhance the flexibility and maintainability of the system, the mapping relationship between the input path codePath and the output path path is defined, and the function files under the input path are dynamically synchronized to the output path during the building process, specifically:

[0108] The input path codePath and the output path path field are defined in the page configuration file, the codePath points to the function files under different environments, and the path is a unified output path.

[0109] According to the target environment, the function file under the codePath path is dynamically synchronized to the path path based on a bidirectional synchronization mechanism.

[0110] As described above, defining the mapping relationship between the input path codePath and the output path path, and dynamically synchronizing the function file under the input path to the output path during the construction process, are important means to realize multi-environment adaptation and efficient construction process. In the system's page configuration file, two key fields are set, which are the input path codePath and the output path path. Among them, the input path codePath is used to point to the function file under different environments, such as the function file corresponding to the development environment, the version under the test environment or the production environment; the output path path represents the unified final output location, that is, the specific path where these function files should be placed after the construction is completed.

[0111] After the construction process is started, the system will identify and load the corresponding input path codePath according to the target environment it is currently in, and then automatically synchronize the function file under this path to the specified output path path through a bidirectional synchronization mechanism. The bidirectional synchronization mechanism means that in the development environment, the system not only supports forward synchronization from the input path to the output path, but also supports reverse synchronization of the modified file in the output path back to the input path to ensure the consistency of the source file. While in the production environment, only one-time forward synchronization operation is performed to ensure the stability and publishability of the final product.

[0112] In some embodiments of the present application, in order to meet the efficient iteration needs of the development stage while ensuring the construction quality and controllability in the production environment. According to the target environment, the function file under the codePath path is dynamically synchronized to the path path based on a bidirectional synchronization mechanism, specifically:

[0113] The bidirectional synchronization mechanism includes development environment synchronization and production environment synchronization;

[0114] The development environment synchronization, in the development environment, listens to the file changes under the codePath and the path paths through a file listener;

[0115] When the codePath file is updated, it is automatically synchronized to the path path and triggers a hot update;

[0116] When the path path file is manually modified, it is reversely synchronized to the codePath to ensure the consistency of the source file;

[0117] The production environment is synchronized, and the codePath file is synchronized to the path path at one time during the construction of the production environment to generate a final product.

[0118] As described above, based on the bidirectional synchronization mechanism, the function files under the input path codePath are dynamically synchronized to the output path path according to the target environment currently in, which is an important technical means to improve development efficiency and construction stability. The bidirectional synchronization mechanism includes two running modes: one is suitable for the development environment, and the other is suitable for the production environment.

[0119] In the development environment synchronization, the system continuously monitors the file changes in the input path codePath and the output path path through the deployment file listener. When detecting that a certain function file under the codePath path is updated, the system will immediately synchronize the file to the path path, and trigger the hot update mechanism at the same time, so that the developer can view the modification effect in real time without restarting the application. In addition, during the development process, if the user directly modifies the file under the path path, the system will also synchronize these changes back to the codePath path to ensure that the source file and the output file always remain consistent, avoiding version confusion or data loss caused by manual modification.

[0120] In the production environment synchronization, since the formal release stage emphasizes the stability and predictability of the construction results, a one-time synchronization strategy is adopted. At the beginning of the construction process, the system will synchronize all function files under the codePath path to the path path at one time, and on this basis, subsequent compilation, packaging and optimization operations are performed to finally generate stable products that can be used for release. This process does not enable file listening function, nor does it perform reverse synchronization, thereby ensuring the safety and consistency of the output content in the production environment.

[0121] In some embodiments of the present application, in order to realize differentiated processing strategies in different construction modes, while taking into account the flexibility of the development stage and the stability of the production stage. Through the synchronization logic of the plug-in life cycle control configuration file and the code file, including real-time monitoring in the development environment and one-time synchronization in the production environment, specifically:

[0122] The plug-in life cycle includes config life cycle, transform life cycle and watchChange life cycle;

[0123] The configuration file synchronization logic is specifically:

[0124] In the config life cycle, the current environment is determined. If the current environment is the development environment, the monitoring logic is started, and the real-time reading and writing of the configuration file are realized through the file operation tool.

[0125] If the current environment is the production environment, one-time synchronization is performed.

[0126] The code file synchronization logic is specifically:

[0127] In the transform life cycle, the file changes of the codePath and the path are detected, and the monitoring is started through the addWatchFile method.

[0128] In the watchChange life cycle, the file synchronization operation is performed, and the listener is automatically closed at the end of the build process.

[0129] As mentioned above, the synchronization logic between the configuration file and the code file is controlled through the plugin life cycle, which is an important mechanism to realize the automation of the build process and the differentiated management of the environment. According to the current target environment, the corresponding synchronization strategy is triggered in different stages to ensure real-time monitoring capability in the development environment and one-time stable synchronization in the production environment. The whole process relies on the multiple life cycle stages provided by the plugin system, mainly including: config life cycle, transform life cycle, and watchChange life cycle. These life cycles correspond to different processing stages in the build process, and are used to coordinate configuration loading, file conversion, and change monitoring behaviors.

[0130] In terms of configuration file synchronization logic, the system first determines the current running environment in the config life cycle. If the current environment is the development environment, the file monitoring logic is started, and the changes of the configuration file are continuously monitored through the file operation tool to ensure that the configuration information can be read and updated in real time to support dynamic debugging and hot reloading functions. If the current environment is the production environment, the monitoring mechanism is not enabled, and a one-time configuration file synchronization operation is directly performed to write the required configuration to the specified path, ensuring the stability of the final build product.

[0131] In terms of code file synchronization logic, the system detects the file status under the input path codePath and the output path path in the transform life cycle. In this stage, the system calls the addWatchFile method to add a listener for the relevant file, so that it can respond in a timely manner when a modification occurs. When the actual file change is detected, the watchChange life cycle is entered, and the specific file synchronization operation is performed in this stage to update the changed content from the source path to the target path. In addition, the listener will automatically close at the end of the entire build process, without the need for manual intervention, thereby avoiding resource leaks or residual listening problems. This mechanism not only improves development efficiency, but also ensures the safety and controllability of the build process.

[0132] In some embodiments of the present application, in order to improve the overall security of the system while ensuring configuration flexibility, prevent data leakage, service interruption and other security risks caused by configuration file leakage or illegal modification. It also includes security enhancement strategies, specifically:

[0133] Sensitive configuration items are encrypted and decrypted dynamically at runtime;

[0134] Access permissions to the configuration directory are restricted, allowing only authorized users or devices from authorized IP addresses to modify configuration files.

[0135] As mentioned above, in order to improve the data security and access control capability in the configuration management process, the system encrypts the configuration items in the configuration file that involve sensitive information. These sensitive configuration items include but are not limited to API keys, database connection strings, third-party service credentials, etc. Encryption operations are completed during configuration file generation or storage, ensuring that these information will not be exposed in plaintext. During the application running process, the system dynamically decrypts these encrypted configuration items as needed for normal invocation and use. The decryption process is triggered only when necessary and completed in memory, avoiding the risk of long-term residence or leakage of sensitive information.

[0136] In addition, the system also restricts access to the configuration directory through a permission control mechanism. Only authorized users or devices from authorized IP address ranges are allowed to view or modify configuration file content. This permission control mechanism can be implemented based on identity verification, access tokens, IP whitelists, etc., effectively preventing unauthorized access, tampering or stealing of configuration information.

[0137] In some embodiments of the present application, in order to improve the cross-platform adaptability of the product, ensure its stable operation in a variety of terminal environments, and enhance the consistency of user experience and the deployability of the system. It also includes compatibility testing schemes, specifically:

[0138] Perform multi-platform compatibility testing for different operating systems, browsers, and device resolutions;

[0139] Verify UI consistency using real device debugging tools to ensure that functions under the output path operate normally in different environments.

[0140] As mentioned above, to ensure that the built application or page functionality maintains good compatibility and consistency in various operating environments, the compatibility testing plan specifically includes two aspects:

[0141] First, after the system is built, it performs multi-platform compatibility tests for different target operating environments. These tests cover multiple operating systems (such as iOS, Android, Windows, etc.), mainstream browsers (such as Chrome, Safari, Firefox, Edge, etc.), and devices with different resolutions (such as mobile phones, tablets, desktop monitors, etc.). Through simulation or actual deployment, the system verifies whether the usability, response speed, and interaction performance of the functional modules under the output path meet expectations in various environments, thereby identifying and fixing potential adaptation issues.

[0142] Secondly, to further ensure consistent UI presentation across different devices and platforms, the system also incorporates real-device debugging tools for practical verification. These tools connect to real devices and perform real-time monitoring and adjustments to the application's layout, style, and interaction logic, ensuring that the final output interface maintains visual and operational consistency and avoids issues such as misalignment, distortion, or functional abnormalities due to device differences.

[0143] In some embodiments of this application, to enhance the intelligent operation and maintenance capabilities of the system and improve product iteration efficiency and user experience quality, a feedback and iteration mechanism is also included, specifically:

[0144] The application integrates seamless tracking to collect user behavior data, including click and crash events.

[0145] Provide a user feedback portal and dynamically adjust configuration files based on feedback data, including changing theme colors and adjusting layouts;

[0146] Hot update mechanisms quickly push out bug fixes, eliminating the need for users to reinstall the application.

[0147] As mentioned above, in order to achieve the continuous optimization and quick response ability after the release of the application, the feedback and iteration mechanism first collects user operation behavior data by integrating the non-intrusive tracking technology in the application. The collected user behavior data includes but is not limited to page clicks, button interactions, page jump paths, and application crash events, and other key information. These data can be automatically reported to the background system without affecting the user experience, providing the basis for subsequent product analysis, function optimization and problem positioning.

[0148] Secondly, the system also provides a user feedback entry, allowing end users to submit opinions or problem descriptions during use. Combined with the behavior data obtained by non-intrusive tracking and the information actively fed back by users, the system can more comprehensively understand the performance of the current version of the application, and dynamically adjust the related configuration files accordingly. For example, the interface theme color can be changed according to user preferences, or the page layout can be optimized according to actual use, thereby improving user satisfaction and product adaptability.

[0149] Further, in order to realize the quick repair of problems and the instant update of functions, the system also integrates a hot update mechanism. When detecting defects that need to be repaired or new functions that need to be online, the system can replace local resources or load new modules by issuing an update package, without forcing users to reinstall the application. This mechanism not only improves the maintainability of the application, but also effectively reduces the interference caused by version updates to users.

[0150] Compared with the prior art, the embodiment of the application discloses a mobile terminal productization configuration method, which can quickly adapt to differentiated needs in different environments, avoid repeated coding, and significantly improve development efficiency by separating common parts in page logic into independent modules and adopting parameterized design; meanwhile, a unified front-end architecture is maintained, which is beneficial to forming a standardized product system and facilitating subsequent maintenance and upgrading. According to target environments (such as development environments and production environments), corresponding configuration files are dynamically loaded to realize resource configuration isolation and on-demand loading in different scenarios; the configuration file structure is clear and easy to maintain, which helps to improve the configurability and portability of the system. By defining the mapping relationship between the input path (codePath) and the output path (path) and combining a bidirectional synchronization mechanism, the required build products can be automatically generated in different environments; real-time monitoring and hot updating are supported in the development stage, and one-time synchronization is performed in the production stage, which balances development efficiency and release stability. The synchronization logic of the configuration file and the code file is controlled by using the plug-in life cycle (such as config, transform, and watchChange), so that the entire build process is more intelligent and automated; the plug-in mechanism has good extensibility, which facilitates subsequent function expansion and process optimization. All configuration and path information is centrally managed, which reduces the version control difficulty; the modular design and plug-in architecture also provide a good extension foundation for subsequent function iteration.

[0151] Based on the same inventive concept as the above method, the embodiment of the application also proposes a mobile terminal productization configuration system, as shown in Figure 2 , which is a structural schematic diagram of a mobile terminal productization configuration system, the system comprising:

[0152] a framework configuration module for selecting and configuring a cross-platform development framework and a front-end framework;

[0153] a logic layer module for separating common parts in page logic into independent modules and adapting differentiated needs in different environments through parameterization, wherein the common parts include data loading and event processing;

[0154] an adaptation module for loading corresponding configuration files according to target environments, wherein the target environments include development environments and production environments, and the configuration files include static resource paths, basic configuration items, style variables, and output path mapping rules;

[0155] a mapping and synchronization module for defining the mapping relationship between the input path (codePath) and the output path (path), and dynamically synchronizing the function files under the input path to the output path during the build process;

[0156] The integrated plug-in module is used for synchronizing the configuration file and the code file through the plug-in life cycle control configuration file and the code file, including real-time monitoring in the development environment and one-time synchronization in the production environment.

[0157] Preferably, the adaptation module, in particular:

[0158] Each subdirectory contains environment-specific configuration files, including a static resource folder, a basic configuration file, a build configuration file, a page configuration file, and a style configuration file.

[0159] The static resource folder is used to store environment-specific static resources, including, for example, pictures and fonts.

[0160] The basic configuration file is used to define environment-specific configuration items, including API addresses and theme colors.

[0161] The build configuration file is used to specify build parameters, including application names and icons.

[0162] The page configuration file is used to define page path mapping rules and output paths.

[0163] The style configuration file is used to store style variables to control UI presentation.

[0164] The configuration file of the target environment is automatically selected through the build parameters, and is synchronized to the corresponding position of the code folder during the build process.

[0165] Those skilled in the art will appreciate that embodiments of the present application can be provided as methods, systems or computer program products. Therefore, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) containing computer usable program code.

[0166] The present application is described with reference to flowcharts and / or block diagrams according to the method, device (system) and computer program product of the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as the combination of the flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to produce a machine, so that the instructions executed by the computer or other programmable data processing devices produce a device that implements the functions described in the flowcharts and / or block diagrams. Figure 1 one flow or multiple flows and / or blocksFigure 1 means for performing the function specified in the block or blocks.

[0167] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the flow Figure 1 flow or flows and / or blocks Figure 1 means for performing the function specified in the block or blocks.

[0168] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the flow Figure 1 flow or flows and / or blocks Figure 1 steps for performing the function specified in the block or blocks.

[0169] Finally, it should be noted that the above-mentioned embodiments are merely intended to illustrate the technical solutions of the present application, rather than limit the same. Even though the present application has been described in detail with reference to the above-mentioned embodiments, those skilled in the art should understand that the specific embodiments of the present application can be modified or replaced equivalently without departing from the spirit and scope of the present application, and any modification or replacement without departing from the spirit and scope of the present application should be included in the protection scope of the claims of the present application.

Claims

1. A method for configuring mobile terminal products, characterized in that, include: Select and configure cross-platform development frameworks and front-end frameworks; The common parts of the page logic are extracted into independent modules, and the parameters are used to adapt to the different needs in different environments. The common parts include data loading and event handling. Load the corresponding configuration file according to the target environment, which includes development environment and production environment. The configuration file includes static resource path, basic configuration items, style variables and output path mapping rules. Define the mapping relationship between the input path codePath and the output path path, and dynamically synchronize the functional files under the input path to the output path during the construction process; The synchronization logic between configuration files and code files is controlled through the plugin lifecycle, including real-time monitoring in the development environment and one-time synchronization in the production environment.

2. The method as described in claim 1, characterized in that, The step of loading the corresponding configuration file according to the target environment is as follows: The preset configuration directory is divided into subdirectories according to the environment. Each subdirectory contains environment-specific configuration files, including static resource folders, basic configuration files, build configuration files, page configuration files, and style configuration files. The static resource folder is used to store environment-specific static resources, including images and fonts. The basic configuration file is used to define environment-specific configuration items, including API address and theme color; The build configuration file is used to specify build parameters, which include the application name and icon; The page configuration file is used to define page path mapping rules and output paths; The style configuration file is used to store style variables to control UI presentation; The configuration file for the target environment is automatically selected based on the build parameters, and it is synchronized to the corresponding location in the code folder during the build process.

3. The method as described in claim 2, characterized in that, The definition of the mapping relationship between the input path codePath and the output path path involves dynamically synchronizing the functional files under the input path to the output path during the construction process. Specifically: The page configuration file defines the input path codePath and the output path path fields. The codePath points to the functional files in different environments, and the path is a unified output path. Based on a two-way synchronization mechanism, the functional files under the codePath are dynamically synchronized to the path according to the target environment.

4. The method as described in claim 3, characterized in that, The bidirectional synchronization mechanism dynamically synchronizes the functional files under the codePath path to the path path according to the target environment, specifically as follows: The bidirectional synchronization mechanism includes development environment synchronization and production environment synchronization; The development environment is synchronized, and a file listener is used in the development environment to monitor changes in files under the codePath and the path. When the codePath file is updated, it is automatically synchronized to the path and a hot update is triggered. When the path file is manually modified, it is reverse-synchronized to the codePath to ensure the consistency of the source file. The production environment synchronization involves synchronizing the codePath file to the path path during the build process to generate the final product.

5. The method as described in claim 1, characterized in that, The synchronization logic between the configuration file and code file controlled through the plugin lifecycle includes real-time monitoring in the development environment and one-time synchronization in the production environment, specifically as follows: The plugin lifecycle includes the config lifecycle, the transform lifecycle, and the watchChange lifecycle; The configuration file synchronization logic is as follows: During the config lifecycle, the current environment is determined. If the current environment is the development environment, the listening logic is started, and the configuration file is read and written in real time through file operation tools. If the current environment is the production environment, then a one-time synchronization is performed; The code file synchronization logic is as follows: During the transform lifecycle, detect file changes between the codePath and the path, and start listening using the addWatchFile method; File synchronization is performed during the watchChange lifecycle, and the listener is automatically shut down when the build process ends.

6. The method as described in claim 1, characterized in that, It also includes security enhancement strategies, specifically: Sensitive configuration items are encrypted and dynamically decrypted at runtime; Access to the configuration directory is restricted by permissions, allowing only authorized users or devices with authorized IP addresses to modify the configuration files.

7. The method as described in claim 1, characterized in that, It also includes a compatibility testing plan, specifically: Perform multi-platform compatibility testing for different operating systems, browsers, and device resolutions; Verify UI consistency using real device debugging tools to ensure that functions under the output path operate normally in different environments.

8. The method as described in claim 1, characterized in that, It also includes feedback and iteration mechanisms, specifically: The application integrates seamless tracking to collect user behavior data, including click and crash events. Provide a user feedback portal and dynamically adjust configuration files based on feedback data, including changing theme colors and adjusting layouts; Hot update mechanisms quickly push out bug fixes, eliminating the need for users to reinstall the application.

9. A mobile terminal product configuration system, characterized in that, include: The framework configuration module is used to select and configure cross-platform development frameworks and front-end frameworks; The logic layer module is used to extract the common parts of the page logic into independent modules and adapt to the differentiated needs in different environments through parameterization. The common parts include data loading and event handling. An adaptation module is used to load the corresponding configuration file according to the target environment, which includes development environment and production environment. The configuration file includes static resource path, basic configuration items, style variables and output path mapping rules. The mapping and synchronization module is used to define the mapping relationship between the input path codePath and the output path path, and dynamically synchronizes the functional files under the input path to the output path during the construction process; An integrated plugin module is used to control the synchronization logic between configuration files and code files through the plugin lifecycle, including real-time monitoring in the development environment and one-time synchronization in the production environment.

10. The system as described in claim 9, characterized in that, The adaptation module specifically includes: The preset configuration directory is divided into subdirectories according to the environment. Each subdirectory contains environment-specific configuration files, including static resource folders, basic configuration files, build configuration files, page configuration files, and style configuration files. The static resource folder is used to store environment-specific static resources, including images and fonts. The basic configuration file is used to define environment-specific configuration items, including API address and theme color; The build configuration file is used to specify build parameters, which include the application name and icon; The page configuration file is used to define page path mapping rules and output paths; The style configuration file is used to store style variables to control UI presentation; The configuration file for the target environment is automatically selected based on the build parameters, and it is synchronized to the corresponding location in the code folder during the build process.

Images