On-demand compilation and dynamic subpackage method and system based on modular packer

Abstract

The invention discloses an on-demand compilation and dynamic subpackage method and system based on a modular packager, belongs to the technical field of software development, and aims to solve the technical problems of slow loading and resource waste caused by large volume of a modularly packaged file. Comprising the following steps: dynamically identifying a currently required code module, and triggering compiling and loading of the code module; dividing the code module into a plurality of code block files according to a pre-configured subpackage strategy, and dynamically loading the corresponding code block files as required; the user-defined packer plug-in or extension is integrated with the adaptive modular packer; defining a preloading strategy based on a user behavior analysis result, and integrating the preloading strategy with a modular packer; when a new code module is loaded, the dependency and version of the code module are managed and maintained; for resource types needing to be lazy loaded in the application, placeholders are defined for resources or components needing to be lazy loaded, and the placeholders are used in the loading process to improve the user experience.

Description

Technical Field

[0001] The present invention relates to the technical field of software development, and in particular to an on-demand compilation and dynamic subpackaging method and system based on a modular packager. Background Art

[0002] In modern front-end application development, code is typically organized in a modular fashion. Modular bundlers (such as Webpack, Rollup, and Parcel) are used to package these modules and their dependencies into files that can be executed by browsers. However, as applications scale, the size of these bundled files also increases. This causes users to download large amounts of unnecessary code when they first load the application, resulting in slow loading times and a poor user experience.

[0003] While existing optimization methods, such as code splitting, can break code into smaller chunks, these splitting strategies are typically predefined at build time and cannot fully optimize based on actual user usage during app runtime. Furthermore, some modules may not be used throughout the app's lifecycle, yet they are still packaged and loaded, resulting in wasted resources.

[0004] In front-end application development, the large file size after modular packaging leads to slow loading and waste of resources, which is a technical problem that needs to be solved. Summary of the Invention

[0005] The technical task of the present invention is to address the above shortcomings and provide an on-demand compilation and dynamic subpackaging method and system based on a modular packager to solve the technical problems that the file size after modular packaging is large, resulting in slow loading and waste of resources.

[0006] In a first aspect, the present invention provides an on-demand compilation and dynamic subpackaging method based on a modular packager, comprising the following steps:

[0007] On-demand compilation: Monitors application status in real time. When the application status changes, it dynamically identifies the currently required code modules and triggers the compilation and loading of the code modules.

[0008] Dynamic subpackaging: When the application is running, the dependencies between code modules are analyzed, and the code modules are divided into multiple code block files according to the pre-configured subpackaging strategy. The corresponding code block files are dynamically loaded on demand.

[0009] Integrated packager: Select an appropriate modular packager based on development requirements, develop custom packager plug-ins or extensions based on on-demand compilation and dynamic subpackaging requirements, and integrate the custom packager plug-ins or extensions with the appropriate modular packager;

[0010] Preloading and precompilation performance optimization: Analyze user behavior based on historical user data, define preloading strategies based on the results of user behavior analysis, integrate preloading strategies with modular packagers, and generate resource links or codes required for preloading during packaging;

[0011] Module dependency management and version control: During application startup or packaging, a global module dependency registry is built. Dependencies and version requirements are declared in the metadata or configuration files of each code module. When loading new code modules, the dependencies and versions of the code modules are managed and maintained.

[0012] Resource lazy loading and placeholder rendering: For resource types that require lazy loading in the application, define placeholders for the resources or components that need to be lazy loaded, and use placeholders to improve the user experience during the loading process.

[0013] Preferably, on-demand compilation includes the following steps:

[0014] Application state monitoring: When the application starts, a state management system is initialized to monitor the application state, including monitoring router navigation events, specific user operations, and state variables that control whether components or modules need to be rendered.

[0015] Pattern requirement identification: When the application state changes, the system determines whether a specific code module needs to be loaded based on pre-configured rules or dynamic analysis results. This is done by maintaining a mapping table between routes and modules, and between components and modules.

[0016] Dynamic compilation trigger: triggers the dynamic compilation process of the code module that needs to be loaded;

[0017] Module compilation and loading: After receiving a dynamic compilation request, the modular packager compiles the code according to the dependencies of the code module and generates the corresponding code block. After the compilation is completed, the modular packager provides a loading mechanism. After the code block is loaded, the code in it is executed to initialize and register the code module.

[0018] Compilation result cache: Stores compiled code modules and corresponding code blocks in local cache or memory.

[0019] Preferably, dynamic subpackaging includes the following steps:

[0020] Dependency analysis: During the application construction or operation phase, the dependencies between code modules are analyzed and a dependency graph is constructed.

[0021] Define a dynamic subpackaging strategy: package the components corresponding to each route and their dependencies into a separate chunk, package independent code modules or large components and their dependencies into a single chunk, and extract dependencies shared by multiple code modules into separate chunks.

[0022] Dynamic subpackaging: Configure the corresponding subpackaging strategy in the module packager configuration;

[0023] Code management and loading: When the application is running, for the code modules that need to be loaded, the corresponding code block files are dynamically loaded according to the chunk information where the code modules are located. The application's performance data and module usage are regularly analyzed to optimize the subpackaging strategy.

[0024] Preferably, the integrated packager includes the following steps:

[0025] Select a packager: Choose a suitable modular packager based on project requirements and the team's technology stack;

[0026] Select packager extension: Select the plug-in or extension required by the modular packager;

[0027] Develop custom plug-ins or extensions: Develop custom packager plug-ins or extensions based on on-demand compilation and dynamic subpackaging requirements;

[0028] Configure the packager: In the modular packager configuration file, introduce and configure custom plug-ins or extensions, and adjust other configuration items of the modular packager as needed, including the entry file, output path, and code optimization options;

[0029] Testing and debugging: Test the integration effect in actual projects to verify whether on-demand compilation and dynamic subpackaging work as expected. Use the debugging tools provided by the modular packager or browser developer tools to debug and resolve any problems.

[0030] Preferably, the preloading and precompiling performance optimization includes the following steps:

[0031] User behavior prediction: Collect historical user data, analyze user behavior patterns based on this data using statistical methods or machine learning models, and predict the code modules or functions that users will need at a predetermined time in the future to obtain user behavior analysis results.

[0032] Define preloading strategy: Define preloading strategy based on user behavior analysis results;

[0033] Preloading implementation: Use HTML tags to load resources when the browser is idle, or dynamically create tags through JavaScript code to load preloaded code blocks;

[0034] Performance monitoring and optimization: Monitor the performance of preloading and adjust the preloading strategy based on the actual results.

[0035] Preferably, module dependency management and version control include the following steps:

[0036] Build a dependency registry: When the application starts or during packaging, build a global module dependency registry to record the version information of all code modules and their dependencies.

[0037] Dependency version declaration: declare the dependencies and their version requirements in the metadata or configuration files of each code module;

[0038] Dependency loading check: When a new code module needs to be loaded, check whether its dependencies have been registered in the module dependency registry. If the dependencies have not been loaded, load the specified version of the dependencies. If the dependencies have been loaded, check whether the loaded version meets the requirements of the current module.

[0039] Version conflict handling: If a version conflict is found, relevant operations are performed according to the predetermined version conflict strategy. The version conflict strategy includes parallel loading, on-demand upgrade / downgrade, and error prompts. Parallel loading involves loading dependencies of different versions and isolating them using namespaces or other mechanisms to avoid conflicts. On-demand upgrade / downgrade involves upgrading or downgrading loaded dependencies to compatible versions if conditions permit. Error prompts: If the version conflict cannot be resolved, the error is reported to the developer or user.

[0040] Dependency update and cleanup: When a code module is uninstalled or the application status changes, the module dependency registry is updated, and unnecessary dependencies are cleaned up to release resources.

[0041] Preferably, resource lazy loading and placeholder rendering include the following steps:

[0042] Resource type identification: Identify the types of resources that need to be lazy loaded in the application, including images, videos, fonts, components or modules;

[0043] Lazy loading strategy implementation: The lazy loading strategy for images is to use the lazy attribute of the img tag or use the IntersectionObserverAPI to monitor whether the image enters the visible area and dynamically set the src attribute. The lazy loading strategy for videos is the same as that for images, or the video resource is loaded when the user clicks the play button. The lazy loading strategy for fonts is to use the FontLoadingAPI or CSSFontLoadingModule to control the loading timing of fonts. The lazy loading strategy for components or modules is to render a placeholder for components or modules that need to be loaded dynamically until they are loaded.

[0044] Placeholder rendering: define placeholders for resources or components that need to be lazy loaded;

[0045] Synchronize with code loading: synchronize lazy loading of resources with on-demand loading and dynamic subpackaging of code.

[0046] In a second aspect, the present invention provides an on-demand compilation and dynamic subpackaging system based on a modular packager, which is used to implement on-demand compilation and dynamic subpackaging of code through an on-demand compilation and dynamic subpackaging method based on a modular packager as described in any one of the first aspects, wherein the system includes an on-demand compilation module, a dynamic subpackaging module, an integrated packager module, a preloading and precompilation performance optimization module, a module dependency management and version control module, and a resource lazy loading and placeholder rendering module;

[0047] The on-demand compilation module is used to perform the following tasks: monitor the application status in real time, dynamically identify the currently required code modules when the application status changes, and trigger the compilation and loading of the code modules;

[0048] The dynamic subpackaging module is used to perform the following: when the application is running, it analyzes the dependencies between code modules, divides the code modules into multiple code block files according to the pre-configured subpackaging strategy, and dynamically loads the corresponding code block files on demand;

[0049] The integrated packager module is used to perform the following: select an adapted modular packager based on development requirements, develop a custom packager plug-in or extension based on on-demand compilation and dynamic subpackaging requirements, and integrate the custom packager plug-in or extension with the adapted modular packager;

[0050] The preloading and precompilation performance optimization module is used to perform the following: analyze user behavior based on historical user data, define preloading strategies based on the user behavior analysis results, integrate the preloading strategies with the modular packager, and generate resource links or codes required for preloading during packaging;

[0051] The module dependency management and version control module is used to perform the following tasks: During application startup or packaging, it builds a global module dependency registry, declares dependencies and version requirements for each code module in its metadata or configuration file, and manages and maintains the dependencies and versions of code modules when loading new ones.

[0052] The resource lazy loading and placeholder rendering module is used to perform the following: For resource types that need to be lazy loaded in the application, define placeholders for the resources or components that need to be lazy loaded, and use placeholders to improve the user experience during the loading process.

[0053] The modular packager-based on-demand compilation and dynamic subpackaging method and system of the present invention have the following advantages:

[0054] 1. Loading only necessary code and resources at the initial stage can significantly reduce the initial loading time of the application, thereby reducing the consumption of client resources (such as memory and CPU);

[0055] 2. Provides optional predictive preloading function, which provides faster loading speed and smoother interaction, improving user experience;

[0056] 3. By avoiding loading unused code and resources, resource utilization is optimized, and combined with a higher degree of modularity, it promotes more flexible management and deployment of application code;

[0057] 4. Fine-grained dependency tracking and on-demand compilation reduce redundant code and shrink package size. At the same time, unified module dependencies and version control can prevent dependency conflicts to enhance application stability. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0059] The present invention will be further described below with reference to the accompanying drawings.

[0060] Figure 1 This is a flowchart of an on-demand compilation and dynamic subpackaging method based on a modular packager in Example 1. DETAILED DESCRIPTION

[0061] The present invention will be further described below with reference to the accompanying drawings and specific embodiments so that those skilled in the art can better understand the present invention and implement it. However, the embodiments given are not intended to limit the present invention. Unless there is a conflict, the embodiments of the present invention and the technical features in the embodiments may be combined with each other.

[0062] The embodiment of the present invention provides an on-demand compilation and dynamic subpackaging method and system based on a modular packager, which is used to solve the technical problem that the file size after modular packaging is large, resulting in slow loading and waste of resources.

[0063] Example 1:

[0064] The present invention provides an on-demand compilation and dynamic subpackaging method based on a modular packager, which includes six steps: on-demand compilation, dynamic subpackaging, packager integration, preloading and precompilation performance optimization, module dependency management and version control, and resource lazy loading and placeholder rendering.

[0065] Step S100 is on-demand compilation: real-time monitoring of the application state, and when the application state changes, dynamic identification of the currently required code module, and triggering the compilation and loading of the code module.

[0066] As a specific implementation of on-demand compilation, this step includes the following operations:

[0067] (1) Application state monitoring: When the application starts, a state management system is initialized (for example, based on a routing manager or a custom event mechanism). The state management system monitors the application state, including monitoring the navigation events of the router (such as hashchange, popstate, or routing hooks of a specific framework), specific user operations (such as clicking a button, expanding a component, etc., which may trigger the demand for a specific module), and state variables that control whether a component or module needs to be rendered;

[0068] (2) Pattern requirement identification: When the application state changes, it determines whether a specific code module needs to be loaded based on pre-configured rules or the results of dynamic analysis. This determination is made by maintaining a mapping table between routes and modules, and a mapping table between components and modules. For example, when the route switches to / user / profile, it is determined that the UserProfileModule needs to be loaded.

[0069] (3) Dynamic compilation triggering: For code modules that need to be loaded, the dynamic compilation process of the code modules is triggered. This may involve interaction with modular bundlers. For example, dynamic import can be achieved through the import() syntax, and Webpack will automatically handle code segmentation and on-demand loading. You can customize Webpack plug-ins to more finely control the compilation process. In addition, bundlers such as Rollup / Parcel also provide dynamic import functions and can be integrated similarly. For more complex scenarios, you may need to customize the compilation process, such as calling the bundler's API or using a dedicated dynamic module loading library;

[0070] (4) Module compilation and loading: After receiving the dynamic compilation request, the modular packager compiles the code module according to its dependencies and generates the corresponding code chunk. After the compilation is completed, the modular packager provides a loading mechanism (for example, loading the generated JavaScript file through a network request). After the code chunk is loaded, the code in it is executed to initialize and register the code module.

[0071] (5) Compilation result cache: Store the compiled code modules and corresponding code blocks in local cache or memory.

[0072] To avoid repeatedly compiling the same module, a compilation result caching mechanism is needed. The compiled module and its corresponding code block are stored in a local cache (e.g., browser LocalStorage or IndexedDB) or in memory. The next time the same module needs to be loaded, it is first checked to see if it exists in the cache. If so, it is used directly without recompiling.

[0073] Step S200: Dynamic subpackaging: When the application is running, the dependencies between code modules are analyzed, and the code modules are divided into multiple code block files according to the pre-configured subpackaging strategy, and the corresponding code block files are dynamically loaded on demand.

[0074] As a specific implementation of dynamic subpackaging, this step includes the following operations:

[0075] (1) Dependency analysis: During the application construction or operation phase, the dependencies between code modules are analyzed and a dependency graph is constructed. This can be accomplished using the API provided by the modular packager or custom code analysis tools.

[0076] (2) Define a dynamic subpackaging strategy: Package the components corresponding to each route and their dependencies into a separate chunk, package independent code modules or large components and their dependencies into a chunk, and extract dependencies shared by multiple code modules into separate chunks to avoid repeated loading. Use specific syntax (for example, Webpack's import()) to mark the code that needs to be dynamically loaded. Analyze the frequency of module usage, package infrequently used modules separately, and load them on demand.

[0077] (3) Dynamic subpackaging: Configure the corresponding subpackaging strategy in the module bundler configuration. For example, you can use the splitChunks plug-in in Webpack for configuration. For more complex dynamic subpackaging requirements, you may need to write a custom bundler plug-in or script to dynamically adjust the subpackaging strategy based on runtime information.

[0078] (4) Code management and loading: When the application is running, for the code modules that need to be loaded, the corresponding code block files are dynamically loaded according to the chunk information where the code module is located. This operation is usually automatically handled by the runtime code provided by the packager. For example, Webpack will insert <script>标签来加载chunk文件；

[0079] (5)优化分包策略：定期分析应用的性能数据和模块使用情况，优化分包策略，以达到最佳的加载性能，具体操作时，可以利用打包器的分析工具(例如，WebpackBundleAnalyzer)来可视化代码块的构成和大小，帮助进行优化。

[0080] 步骤S300集成打包器：根据开发需求选择适配的模块化打包器，根据按需编译和动态分包需求、开发自定义的打包器插件或扩展，将自定义的打包器插件或扩展与适配的模块化打包器集成。

[0081] 作为集成打包器的具体实施，该步骤包括如下操作：

[0082] (1)选取打包器：根据项目需求和团队的技术栈，选择合适的模块化打包器(例如，Webpack、Rollup、Parcel)；

[0083] (2)选定打包器扩展：选定模块化打包器需要的插件或扩展，例如：Webpack:中的插件(Plugins)、加载器(Loaders)、钩子(Hooks)等，Rollup:中的插件(Plugins)以及Parcel通常通过配置文件进行扩展；

[0084] (3)开发自定义插件或扩展：根据按需编译和动态分包的需求，开发自定义的打包器插件或扩展，根据按需编译和动态分包的需求，开发自定义的打包器插件或扩展，例如，可以开发一个Webpack插件，用于监听路由变化，识别需要动态编译的模块，并触发相应的编译流程，插件需要能够访问打包器的内部API，以便控制编译过程、管理代码块、注入运行时代码等；

[0085] (4)配置打包器：在模块化打包器的配置文件中，引入并配置自定义的插件或扩展，根据需要调整模块化打包器的其他配置项，其他配置项包括入口文件、输出路径以及代码优化选项等；

[0086] (5)测试与调试：在实际项目中测试集成效果，验证按需编译和动态分包是否按预期工作，并通过模块化打包器提供的调试工具或浏览器开发者工具进行调试，解决出现的问题。

[0087] 步骤S400预加载与预编译性能优化：基于历史用户数据分析用户行为，基于用户行为分析结果定义预加载策略，将预加载策略与模块化打包器集成，打包时生成预加载所需的资源链接或代码。

[0088] 作为预加载与预编译性能优化的具体实施，该步骤包括如下操作：

[0089] (1)用户行为预测：收集历史用户数据，基于历史用户数据、通过统计方法或机器学习模型分析用户行为模式，预测用户未来预定时间需要的代码模块或功能，得到用户行为分析结果；

[0090] (2)定义预加载策略：根据用户行为分析结果定义预加载策略，例如在用户鼠标悬停在某个链接上时，预加载该链接对应的页面模块。在用户完成某个操作后，预加载下一个可能需要的模块，在应用空闲时，预加载一些常用的模块；

[0091] (3)预加载实现：使用HTML标签在浏览器空闲时加载资源，或者通过JavaScript代码动态创建标签加载预加载的代码块，具体操作时，可以使用<linkrel＝"prefetch">或<linkrel＝"preload">等HTML标签在浏览器空闲时加载资源。也可以通过JavaScript代码动态创建<script>标签来加载预编译的代码块；

[0092] (4)性能监控与优化：监控预加载的性能，例如是否增加了不必要的带宽消耗，根据实际效果调整预加载策略，避免过度预加载。

[0093] 步骤S500模块依赖管理与版本控制：应用启动或打包过程中，构建一个全局的模块依赖注册表，在每个代码模块的元数据或配置文件中声明其依赖以及版本要求，加载新的代码模块时，对代码模块的依赖和版本进行管理维护。

[0094] 作为模块依赖管理与版本控制的具体实施，该步骤包括如下操作：

[0095] (1)构建依赖注册表：在应用启动时或打包过程中，构建一个全局的模块依赖注册表，通过模块依赖注册表记录所有代码模块及其依赖的版本信息，可以使用Map或类似的数据结构来存储这些信息；

[0096] (2)依赖版本声明：在每个代码模块的元数据或配置文件中声明其依赖及其版本要求(例如，使用语义化版本控制)；

[0097] (3)依赖加载检查：当需要加载一个新的代码模块时，检查其依赖是否已经注册到模块依赖注册表中，如果依赖尚未加载，加载依赖指定的版本，如果依赖已经加载，检查已加载的版本是否满足当前模块的要求；

[0098] (4)版本冲突处理：如果发现版本冲突(例如，需要的版本与已加载的版本不兼容)，按照预定的版本冲突策略执行相关操作，其中，版本冲突策略包括并行加载、按需升级 / 降级以及错误提示，并行加载内容为：加载不同版本的依赖，并使用命名空间或其他机制进行隔离，以避免冲突；按需升级 / 降级内容为：如果条件允许，升级或降级已加载的依赖至兼容的版本；错误提示：如果无法解决版本冲突，向开发者或用户报告错误；

[0099] (5)依赖更新与清理：当代码模块卸载或应用状态改变时，更新模块依赖注册表，并清理不需要的依赖，释放资源。

[0100] 步骤S600资源懒加载与占位渲染：对于应用中需要懒加载的资源类型，为需要懒加载的资源或组件定义占位符，在加载过程中使用占位符提升用户体验。

[0101] 作为资源懒加载与占位渲染的具体实施，该步骤包括如下操作：

[0102] (1)资源类型识别：在应用中识别需要进行懒加载的资源类型，资源类型包括图片、视频、字体以及组件或模块；

[0103] (2)懒加载策略实现：图片的懒加载策略为通过标签的loading＝"lazy"属性或使用IntersectionObserverAPI监听图片是否进入可视区域，并动态设置src属性，视频的懒加载策略与图片的懒加载策略相同，或者在用户点击播放按钮时加载视频资源，字体的懒加载策略为使用FontLoadingAPI或CSSFontLoadingModule控制字体的加载时机，组件或模块的懒加载策略为对于需要动态加载的组件或模块，在其加载完成之前渲染一个占位符；

[0104] (3)占位符渲染：对需要懒加载的资源或组件定义占位符，对于图片，可以使用低分辨率的模糊图片作为占位符，对于组件，可以使用骨架屏(SkeletonScreen)或其他简单的UI元素作为占位符。在资源或组件加载完成后，替换掉占位符；

[0105] (4)与代码加载同步：将资源懒加载与代码的按需加载和动态分包同步进行，例如，当一个动态加载的组件需要特定的图片资源时，只有在该组件的代码加载完成后，才开始懒加载相关的图片。

[0106] 本实施例的方法通过在应用运行时根据实际需求动态地编译和加载代码模块，并结合灵活的动态分包策略、统一的依赖管理、可选的性能优化手段(如预加载和资源懒加载)，有效地减少了初始加载时间，提升了用户体验，并优化了资源利用率。本实施例的方法可与现有的主流模块化打包器集成，为构建高性能应用提供了一种高效且灵活的解决方案。

[0107] 实施例2：

[0108] 本发明一种基于模块化打包器的按需编译与动态分包系统，包括按需编译模块、动态分包模块、集成打包器模块、预加载与预编译性能优化模块、模块依赖管理与版本控制模块以及资源懒加载与占位渲染模块。

[0109] 按需编译模块用于执行如下：实时监控应用状态，当应用状态发生变化时，动态识别当前所需的代码模块，并触发代码模块的编译和加载。

[0110] 作为按需编译模块的具体实施，该模块用于执行如下操作：

[0111] (1)应用状态监控：应用启动时，初始化一个状态管理系统(例如，基于路由管理器或自定义事件机制)，通过状态管理系统监听应用状态，包括监听路由器的导航事件(例如hashchange、popstate或特定框架的路由钩子)、特定的用户操作(例如点击某个按钮、展开某个组件等，这些操作可能触发对特定模块的需求)以及控制组件或模块是否需要渲染的状态变量；

[0112] (2)模式需求识别：当应用状态发生变化时，根据预先配置的规则或动态分析的结果，判断是否需要加载特定的代码模块，判断方式为通过维护一个路由与模块的映射表、组件与模块的映射表的方式进行识别，例如当路由切换到 / user / profile时，识别出需要加载UserProfileModule；

[0113] (3)动态编译触发：对于需要加载的代码模块，触发代码模块的动态编译过程，这可能涉及到与模块化打包器的交互，例如：可以通过import()语法实现动态导入，Webpack会自动处理代码分割和按需加载。可以自定义Webpack插件来更精细地控制编译过程，另外Rollup / Parcel这些打包器也提供了动态导入的功能，可以类似地进行集成，对于更复杂的场景，可能需要自定义编译流程，例如调用打包器的API或使用专门的动态模块加载库；

[0114] (4)模块编译与加载：模块化打包器接收到动态编译的请求后，根据代码模块的依赖关系进行编译，生成对应的代码块(chunk)，编译完成后，模块化打包器提供加载机制(例如，通过网络请求加载生成的JavaScript文件)，代码块加载后，执行其中的代码实现代码模块的初始化和注册；

[0115] (5)编译结果缓存：将已编译的代码模块以及对应的代码块存储在本地缓存或内存中。

[0116] 为了避免重复编译相同的模块，需要实现编译结果的缓存机制。将已编译的模块及其对应的代码块存储在本地缓存(例如，浏览器LocalStorage或IndexedDB)或内存中。在下次需要加载相同的模块时，首先检查缓存中是否存在，如果存在则直接使用，无需重新编译。

[0117] 动态分包模块用于执行如下：在应用运行时，分析代码模块之间的依赖关系，根据预配置的分包策略将代码模块划分为多个代码块文件，按需动态加载对应的代码块文件。

[0118] 作为动态分包模块的具体实施，该模块用于执行如下操作：

[0119] (1)依赖关系分析：在应用构建阶段或运行阶段，分析代码模块之间的依赖关系，构建依赖图谱，可以利用模块化打包器提供的API或自定义代码分析工具来完成；

[0120] (2)定义动态的分包策略：将每个路由对应的组件及其依赖关系打包为一个独立的chunk，将独立的代码模块或大型组件及其依关系打包为一个chunk，将多个代码模块共享的依赖提取成单独的chunk，避免重复加载。通过特定的语法(例如，Webpack的import())标记需要动态加载的代码。分析模块的使用频率，将不常用的模块进行单独打包，按需加载；

[0121] (3)动态分包：在模块打包器的配置中，配置相应的分包策略，例如，在Webpack中可以使用splitChunks插件进行配置，对于更复杂的动态分包需求，可能需要编写自定义的打包器插件或脚本，根据运行时的信息动态地调整分包策略；

[0122] (4)代码管理与加载：应用运行时，对于需要加载的代码模块，根据代码模块所在chunk信息，动态加载对应的代码块文件，该操作通常由打包器提供的运行时代码自动处理，例如，Webpack会在需要时插入<script>标签来加载chunk文件；

[0123] (5)优化分包策略：定期分析应用的性能数据和模块使用情况，优化分包策略，以达到最佳的加载性能，具体操作时，可以利用打包器的分析工具(例如，WebpackBundleAnalyzer)来可视化代码块的构成和大小，帮助进行优化。

[0124] 集成打包器模块用于执行如下：根据开发需求选择适配的模块化打包器，根据按需编译和动态分包需求、开发自定义的打包器插件或扩展，将自定义的打包器插件或扩展与适配的模块化打包器集成。

[0125] 作为集成打包器模块的具体实施，该模块用于执行如下操作：

[0126] (1)选取打包器：根据项目需求和团队的技术栈，选择合适的模块化打包器(例如，Webpack、Rollup、Parcel)；

[0127] (2)选定打包器扩展：选定模块化打包器需要的插件或扩展，例如：Webpack:中的插件(Plugins)、加载器(Loaders)、钩子(Hooks)等，Rollup:中的插件(Plugins)以及Parcel通常通过配置文件进行扩展；

[0128] (3)开发自定义插件或扩展：根据按需编译和动态分包的需求，开发自定义的打包器插件或扩展，根据按需编译和动态分包的需求，开发自定义的打包器插件或扩展，例如，可以开发一个Webpack插件，用于监听路由变化，识别需要动态编译的模块，并触发相应的编译流程，插件需要能够访问打包器的内部API，以便控制编译过程、管理代码块、注入运行时代码等；

[0129] (4)配置打包器：在模块化打包器的配置文件中，引入并配置自定义的插件或扩展，根据需要调整模块化打包器的其他配置项，其他配置项包括入口文件、输出路径以及代码优化选项等；

[0130] (5)测试与调试：在实际项目中测试集成效果，验证按需编译和动态分包是否按预期工作，并通过模块化打包器提供的调试工具或浏览器开发者工具进行调试，解决出现的问题。

[0131] 预加载与预编译性能优化模块用于执行如下：基于历史用户数据分析用户行为，基于用户行为分析结果定义预加载策略，将预加载策略与模块化打包器集成，打包时生成预加载所需的资源链接或代码。

[0132] 作为预加载与预编译性能优化模块的具体实施，该模块用于执行如下操作：

[0133] (1)用户行为预测：收集历史用户数据，基于历史用户数据、通过统计方法或机器学习模型分析用户行为模式，预测用户未来预定时间需要的代码模块或功能，得到用户行为分析结果；

[0134] (2)定义预加载策略：根据用户行为分析结果定义预加载策略，例如在用户鼠标悬停在某个链接上时，预加载该链接对应的页面模块。在用户完成某个操作后，预加载下一个可能需要的模块，在应用空闲时，预加载一些常用的模块；

[0135] (3)预加载实现：使用HTML标签在浏览器空闲时加载资源，或者通过JavaScript代码动态创建标签加载预加载的代码块，具体操作时，可以使用<linkrel＝"prefetch">或<linkrel＝"preload">等HTML标签在浏览器空闲时加载资源。也可以通过JavaScript代码动态创建<script>标签来加载预编译的代码块；

[0136] (4)性能监控与优化：监控预加载的性能，例如是否增加了不必要的带宽消耗，根据实际效果调整预加载策略，避免过度预加载。

[0137] 模块依赖管理与版本控制模块用于执行如下：应用启动或打包过程中，构建一个全局的模块依赖注册表，在每个代码模块的元数据或配置文件中声明其依赖以及版本要求，加载新的代码模块时，对代码模块的依赖和版本进行管理维护。

[0138] 作为模块依赖管理与版本控制模块的具体实施，该模块用于执行如下操作：

[0139] (1)构建依赖注册表：在应用启动时或打包过程中，构建一个全局的模块依赖注册表，通过模块依赖注册表记录所有代码模块及其依赖的版本信息，可以使用Map或类似的数据结构来存储这些信息；

[0140] (2)依赖版本声明：在每个代码模块的元数据或配置文件中声明其依赖及其版本要求(例如，使用语义化版本控制)；

[0141] (3)依赖加载检查：当需要加载一个新的代码模块时，检查其依赖是否已经注册到模块依赖注册表中，如果依赖尚未加载，加载依赖指定的版本，如果依赖已经加载，检查已加载的版本是否满足当前模块的要求；

[0142] (4)版本冲突处理：如果发现版本冲突(例如，需要的版本与已加载的版本不兼容)，按照预定的版本冲突策略执行相关操作，其中，版本冲突策略包括并行加载、按需升级 / 降级以及错误提示，并行加载内容为：加载不同版本的依赖，并使用命名空间或其他机制进行隔离，以避免冲突；按需升级 / 降级内容为：如果条件允许，升级或降级已加载的依赖至兼容的版本；错误提示：如果无法解决版本冲突，向开发者或用户报告错误；

[0143] (5)依赖更新与清理：当代码模块卸载或应用状态改变时，更新模块依赖注册表，并清理不需要的依赖，释放资源。

[0144] 资源懒加载与占位渲染模块用于执行如下：对于应用中需要懒加载的资源类型，为需要懒加载的资源或组件定义占位符，在加载过程中使用占位符提升用户体验。

[0145] 作为资源懒加载与占位渲染模块的具体实施，该模块用于执行如下操作：

[0146] (1)资源类型识别：在应用中识别需要进行懒加载的资源类型，资源类型包括图片、视频、字体以及组件或模块；

[0147] (2)懒加载策略实现：图片的懒加载策略为通过标签的loading＝"lazy"属性或使用IntersectionObserverAPI监听图片是否进入可视区域，并动态设置src属性，视频的懒加载策略与图片的懒加载策略相同，或者在用户点击播放按钮时加载视频资源，字体的懒加载策略为使用FontLoadingAPI或CSSFontLoadingModule控制字体的加载时机，组件或模块的懒加载策略为对于需要动态加载的组件或模块，在其加载完成之前渲染一个占位符；

[0148] (3)占位符渲染：对需要懒加载的资源或组件定义占位符，对于图片，可以使用低分辨率的模糊图片作为占位符，对于组件，可以使用骨架屏(SkeletonScreen)或其他简单的UI元素作为占位符。在资源或组件加载完成后，替换掉占位符；

[0149] (4)与代码加载同步：将资源懒加载与代码的按需加载和动态分包同步进行，例如，当一个动态加载的组件需要特定的图片资源时，只有在该组件的代码加载完成后，才开始懒加载相关的图片。

[0150] 以上对本发明所提供的基于模块化打包器的按需编译与动态分包方法及系统进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。< / script>

Claims

1. A modular packager-based on-demand compilation and dynamic subpackaging method, characterized in that: The steps include: On-demand compilation: Monitors application status in real time. When the application status changes, it dynamically identifies the currently required code modules and triggers the compilation and loading of the code modules. Dynamic subpackaging: When the application is running, the dependencies between code modules are analyzed, and the code modules are divided into multiple code block files according to the pre-configured subpackaging strategy. The corresponding code block files are dynamically loaded on demand. Integrated packager: Select an appropriate modular packager based on development requirements, develop custom packager plug-ins or extensions based on on-demand compilation and dynamic subpackaging requirements, and integrate the custom packager plug-ins or extensions with the appropriate modular packager; Preloading and precompilation performance optimization: Analyze user behavior based on historical user data, define preloading strategies based on the results of user behavior analysis, integrate preloading strategies with modular packagers, and generate resource links or codes required for preloading during packaging; Module dependency management and version control: During application startup or packaging, a global module dependency registry is built. Dependencies and version requirements are declared in the metadata or configuration files of each code module. When loading new code modules, the dependencies and versions of the code modules are managed and maintained. Resource lazy loading and placeholder rendering: For resource types that require lazy loading in the application, define placeholders for the resources or components that need to be lazy loaded, and use placeholders to improve the user experience during the loading process.

2. The on-demand compilation and dynamic subpackaging method based on modular packager according to claim 1 is characterized in that: On-demand compilation includes the following steps: Application state monitoring: When the application starts, a state management system is initialized to monitor the application state, including monitoring router navigation events, specific user operations, and state variables that control whether components or modules need to be rendered. Pattern requirement identification: When the application state changes, the system determines whether a specific code module needs to be loaded based on pre-configured rules or dynamic analysis results. This is done by maintaining a mapping table between routes and modules, and between components and modules. Dynamic compilation trigger: triggers the dynamic compilation process of the code module that needs to be loaded; Module compilation and loading: After receiving a dynamic compilation request, the modular packager compiles the code according to the dependencies of the code module and generates the corresponding code block. After the compilation is completed, the modular packager provides a loading mechanism. After the code block is loaded, the code in it is executed to initialize and register the code module. Compilation result cache: Stores compiled code modules and corresponding code blocks in local cache or memory.

3. The on-demand compilation and dynamic subpackaging method based on modular packager according to claim 1 is characterized in that: Dynamic subpackaging includes the following steps: Dependency analysis: During the application construction or operation phase, the dependencies between code modules are analyzed and a dependency graph is constructed. Define a dynamic subpackaging strategy: package the components corresponding to each route and their dependencies into a separate chunk, package independent code modules or large components and their dependencies into a single chunk, and extract dependencies shared by multiple code modules into separate chunks. Dynamic subpackaging: Configure the corresponding subpackaging strategy in the module packager configuration; Code management and loading: When the application is running, for the code modules that need to be loaded, the corresponding code block files are dynamically loaded according to the chunk information where the code modules are located. The application's performance data and module usage are regularly analyzed to optimize the subpackaging strategy.

4. The on-demand compilation and dynamic subpackaging method based on modular packager according to claim 1 is characterized in that: Integrating the packager involves the following steps: Select a packager: Choose a suitable modular packager based on project requirements and the team's technology stack; Select packager extension: Select the plug-in or extension required by the modular packager; Develop custom plug-ins or extensions: Develop custom packager plug-ins or extensions based on on-demand compilation and dynamic subpackaging requirements; Configure the packager: In the modular packager configuration file, introduce and configure custom plug-ins or extensions, and adjust other configuration items of the modular packager as needed, including the entry file, output path, and code optimization options; Testing and debugging: Test the integration effect in actual projects to verify whether on-demand compilation and dynamic subpackaging work as expected. Use the debugging tools provided by the modular packager or browser developer tools to debug and resolve any problems.

5. The on-demand compilation and dynamic subpackaging method based on modular packager according to claim 1 is characterized in that: Preloading and precompilation performance optimization includes the following steps: User behavior prediction: Collect historical user data, analyze user behavior patterns based on this data using statistical methods or machine learning models, and predict the code modules or functions that users will need at a predetermined time in the future to obtain user behavior analysis results. Define preloading strategy: Define preloading strategy based on user behavior analysis results; Preloading implementation: Use HTML tags to load resources when the browser is idle, or dynamically create tags through JavaScript code to load preloaded code blocks; Performance monitoring and optimization: Monitor the performance of preloading and adjust the preloading strategy based on the actual results.

6. The on-demand compilation and dynamic subpackaging method based on modular packager according to claim 1 is characterized in that: Module dependency management and version control include the following steps: Build a dependency registry: When the application starts or during packaging, build a global module dependency registry to record the version information of all code modules and their dependencies. Dependency version declaration: declare the dependencies and their version requirements in the metadata or configuration files of each code module; Dependency loading check: When a new code module needs to be loaded, check whether its dependencies have been registered in the module dependency registry. If the dependencies have not been loaded, load the specified version of the dependencies. If the dependencies have been loaded, check whether the loaded version meets the requirements of the current module. Version conflict handling: If a version conflict is found, relevant operations are performed according to the predetermined version conflict strategy. The version conflict strategy includes parallel loading, on-demand upgrade / downgrade, and error prompts. Parallel loading involves loading dependencies of different versions and isolating them using namespaces or other mechanisms to avoid conflicts. On-demand upgrade / downgrade involves upgrading or downgrading loaded dependencies to compatible versions if conditions permit. Error prompts: If the version conflict cannot be resolved, the error is reported to the developer or user. Dependency update and cleanup: When a code module is uninstalled or the application status changes, the module dependency registry is updated, and unnecessary dependencies are cleaned up to release resources.

7. The on-demand compilation and dynamic subpackaging method based on modular packager according to claim 1 is characterized in that: Resource lazy loading and placeholder rendering include the following steps: Resource type identification: Identify the types of resources that need to be lazy loaded in the application, including images, videos, fonts, components or modules; Lazy loading strategy implementation: The lazy loading strategy for images is to use the lazy attribute of the img tag or use the IntersectionObserverAPI to monitor whether the image enters the visible area and dynamically set the src attribute. The lazy loading strategy for videos is the same as that for images, or the video resource is loaded when the user clicks the play button. The lazy loading strategy for fonts is to use the FontLoadingAPI or CSSFontLoadingModule to control the loading timing of fonts. The lazy loading strategy for components or modules is to render a placeholder for components or modules that need to be loaded dynamically until they are loaded. Placeholder rendering: define placeholders for resources or components that need to be lazy loaded; Synchronize with code loading: synchronize lazy loading of resources with on-demand loading and dynamic subpackaging of code.

8. A modular packager-based on-demand compilation and dynamic subpackaging system, characterized in that: Used to implement on-demand compilation and dynamic subpackaging of code through an on-demand compilation and dynamic subpackaging method based on a modular packager as described in any one of claims 1 to 7, the system comprising an on-demand compilation module, a dynamic subpackaging module, an integrated packager module, a preloading and precompilation performance optimization module, a module dependency management and version control module, and a resource lazy loading and placeholder rendering module; The on-demand compilation module is used to perform the following tasks: monitor the application status in real time, dynamically identify the currently required code modules when the application status changes, and trigger the compilation and loading of the code modules; The dynamic subpackaging module is used to perform the following: when the application is running, it analyzes the dependencies between code modules, divides the code modules into multiple code block files according to the pre-configured subpackaging strategy, and dynamically loads the corresponding code block files on demand; The integrated packager module is used to perform the following: select an adapted modular packager based on development requirements, develop a custom packager plug-in or extension based on on-demand compilation and dynamic subpackaging requirements, and integrate the custom packager plug-in or extension with the adapted modular packager; The preloading and precompilation performance optimization module is used to perform the following: analyze user behavior based on historical user data, define preloading strategies based on the user behavior analysis results, integrate the preloading strategies with the modular packager, and generate resource links or codes required for preloading during packaging; The module dependency management and version control module is used to perform the following tasks: During application startup or packaging, it builds a global module dependency registry, declares dependencies and version requirements for each code module in its metadata or configuration file, and manages and maintains the dependencies and versions of code modules when loading new ones. The resource lazy loading and placeholder rendering module is used to perform the following: For resource types that need to be lazy loaded in the application, define placeholders for the resources or components that need to be lazy loaded, and use placeholders to improve the user experience during the loading process.

Images