Communication control method of applet, applet construction method, device and equipment

Abstract

The invention provides an applet communication control method, an applet construction method, devices and equipment. The invention relates to the technical field of computers, in particular to the technical field of applets. According to the specific implementation scheme, when the applet is started, an event bus is initialized in a host environment, and the event bus is used for maintaining the event subscription relation of each independent subpackage; generating a corresponding event message through the event bus in response to a calling request sent by the first independent subpackage for the target service; under the condition that a second independent subpackage of the target service is not loaded in the local memory, temporarily storing the event message in a message queue, and triggering a downloading and loading process of the second independent subpackage; and monitoring the loading state of the second independent subpackage, and when it is detected that the second independent subpackage is loaded and registered to the event bus, taking out the event message from the message queue and distributing the event message to the second independent subpackage. According to the scheme, the starting speed of the applet is increased, and continuity and stability of the business process are guaranteed.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of computer, and particularly relates to the technical field of applet. BACKGROUND

[0002] With the rapid development of mobile internet technology, as an application that can be used without downloading and installing, applet has become an important carrier connecting users and services. With the continuous enrichment of business scenarios, the code size and business complexity of applet are increasing, and applet gradually evolves from a lightweight tool to a super application platform carrying complex business logic. SUMMARY

[0003] The present disclosure provides a communication control method of applet, an applet construction method, device and equipment.

[0004] According to an aspect of the present disclosure, a communication control method of applet is provided, comprising: initializing an event bus in a host environment when the applet starts, the event bus being used to maintain event subscription relationships of each independent package; generating a corresponding event message through the event bus in response to a calling request for a target business issued by a first independent package; storing the event message in a message queue and triggering a downloading and loading process of a second independent package of the target business in the case that the second independent package is not loaded in the local memory; monitoring the loading state of the second independent package, and taking out the event message from the message queue and distributing it to the second independent package to trigger the second independent package to execute corresponding business logic when it is detected that the second independent package is loaded and registered to the event bus.

[0005] According to another aspect of the present disclosure, an applet construction method applied to a computing device is provided, comprising: obtaining source codes of multiple business modules of an applet and a common base code; compiling the common base code into a common layer package and compiling each business module into an independent package which does not depend on each other according to a packaging configuration strategy, wherein the independent package is configured to only depend on the common layer package, and there is no code reference relationship between the independent packages; generating attribute definition metadata for each independent package and encapsulating it in the corresponding code package, the attribute definition metadata at least including module identification, input parameter definition, output result definition and dependency relationship; injecting event bus control code in the common layer package or the main package, the event bus control code being configured to manage event communication and asynchronous loading queue between each independent package when the applet runs; generating an applet release package containing the common layer package and the multiple independent packages.

[0006] According to another aspect of this disclosure, a communication control device for a mini-program is provided, comprising: The bus management module is used to initialize the event bus in the host environment when the mini-program starts. The event bus is used to maintain the event subscription relationship of each independent sub-package. The communication scheduling module is used to respond to the call request for the target service issued by the first independent sub-packet and generate the corresponding event message through the event bus; The loading control module is used to temporarily store event messages in the message queue and trigger the download and loading process of the second independent sub-package when the second independent sub-package of the target service is not loaded in local memory. The monitoring and distribution module is used to monitor the loading status of the second independent subpackage. When it is detected that the second independent subpackage has been loaded and registered to the event bus, the module retrieves the event message from the message queue and distributes it to the second independent subpackage to trigger the second independent subpackage to execute the corresponding business logic.

[0007] According to another aspect of this disclosure, a mini-program building apparatus is provided, applied to a computing device, comprising: The acquisition module is used to acquire the source code and common basic code of multiple business modules of the mini program; The compilation module is used to compile common base code into a common layer package according to the subpackage configuration strategy, and compile each business module into an independent subpackage that does not depend on each other. The independent subpackages are configured to depend only on the common layer package, and there is no code reference relationship between the independent subpackages. The encapsulation module is used to generate attribute definition metadata for each independent subpackage and encapsulate it in the corresponding code package. The attribute definition metadata includes at least the module identifier, input parameter definition, output result definition, and dependency relationship. The injection module is used to inject event bus control code into the common layer package or the main package. The event bus control code is configured to manage event communication and asynchronous loading queues between independent sub-packages during the mini-program runtime. The generation module is used to generate a mini-program release package that includes a common layer package and multiple independent sub-packages.

[0008] According to another aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and The memory is communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described in the present disclosure.

[0009] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any of the methods according to embodiments of this disclosure.

[0010] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the methods according to embodiments of this disclosure.

[0011] By utilizing the solution disclosed herein, decoupled communication and data transfer between modules are achieved, improving the startup speed of the mini-program and ensuring the continuity and stability of cross-subcontract business processes.

[0012] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0013] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a flowchart illustrating a communication control method for a mini-program according to an embodiment of the present disclosure; Figure 2 This is a flowchart illustrating a method for building a mini-program according to an embodiment of this disclosure; Figure 3 This is a diagram of a layered architecture-based mini-program system according to embodiments of this disclosure; Figure 4 This is a schematic diagram of the structure of a communication control device for a mini-program according to an embodiment of the present disclosure; Figure 5 This is a schematic diagram of the structure of a mini-program building apparatus according to an embodiment of the present disclosure; Figure 6 This is a block diagram of an electronic device used to implement embodiments of the present disclosure. Detailed Implementation

[0014] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0015] In related technologies, to cope with increasingly complex code management needs, current mini-program development typically adopts a modular or component-based development model. In terms of architectural design, mainstream mini-program platforms generally support a "main package + sub-package" loading mechanism. Typically, the main package contains the mini-program's startup logic, common resources (such as common styles and scripts), and the bottom tab bar page; while sub-packages are divided according to business functions (such as order modules and activity modules), carrying specific business pages and logic. This mechanism allows the mini-program to download only the main package at startup, and then download the corresponding sub-package when the user enters a specific business, which alleviates the problems of package size limitations and loading time to some extent.

[0016] While existing subcontracting mechanisms and development frameworks have addressed code organization issues to some extent, the following technical bottlenecks and shortcomings still exist when dealing with large-scale, multi-team collaboration, and high-performance requirements for mini-program development: First, the coupling between modules remains high, resulting in significant costs for cross-application migration. In a typical subpackage architecture, subpackages often heavily depend on common code in the main package, and there are often direct code references or complex business logic interspersed between subpackages or between subpackages and the main package. This makes it difficult for a single business module (such as a ride-hailing function) to be directly extracted and reused in another mini-program like a "building block," often requiring a large amount of code decoupling and refactoring work.

[0017] Secondly, the size of the main package is difficult to control, affecting startup performance. Since subpackages usually allow dependencies on the main package, as business iterates, a large amount of common logic, third-party libraries, and static resources can easily accumulate in the main package, causing its size to continuously expand. Even if a user only uses a peripheral function, they must first download the massive main package, resulting in excessively long initial loading times for the mini-program and a degraded user experience.

[0018] Finally, there is a lack of effective communication mechanisms in physically isolated environments. To optimize performance to the extreme, some platforms provide "independent sub-packages" technology (i.e., sub-packages can run independently of the main package). However, in this mode, the JS execution environments between sub-packages and between sub-packages and the main package are isolated from each other, and communication cannot be achieved through conventional global variables or file references.

[0019] In order to at least partially solve one or more of the above-mentioned problems and other potential problems, the embodiments of this disclosure provide a communication control method and a construction method for a mini-program. By utilizing the technical solutions of the embodiments of this disclosure, decoupled communication and data flow between modules can be realized in a physically isolated environment.

[0020] Figure 1 This is a flowchart illustrating a communication control method for a mini-program according to an embodiment of this disclosure. Figure 1As shown, the method includes the following steps: S110. When the mini-program starts, initialize the event bus in the host environment. The event bus is used to maintain the event subscription relationship of each independent sub-package.

[0021] In this embodiment of the disclosure, the event bus can be understood as a communication mechanism for transmitting messages and triggering events between different modules. In a mini-program based on an independent sub-package architecture, due to the physical isolation between each sub-package, it is impossible to directly reference and call the methods of each other. Therefore, an event bus is needed to achieve cross-sub-package communication.

[0022] In practice, a globally unique event bus instance can be created when the mini-program's host environment (such as WeChat client, Baidu App, etc.) starts. This event bus operates based on a publish-subscribe pattern, responsible for maintaining an event subscription list, recording the events registered and listened to by each independent sub-package and their corresponding callback handling functions.

[0023] S120. In response to the call request for the target service issued by the first independent sub-package, generate the corresponding event message through the event bus.

[0024] In this embodiment, the first independent subpackage refers to the source module that initiates the business request, such as the "Ride-hailing Homepage" module; the target business refers to the function or service that needs to be called, such as the "Payment Service". When the first independent subpackage needs to interact with other modules, it does not directly call the code of the target module, but instead sends a call request to the event bus. After receiving the request, the event bus encapsulates it into a standard event message object, which contains metadata such as event type, target business identifier, business parameter payload, and source module information.

[0025] For example, when a user clicks the "Go to Payment" button on the "Ride-hailing Homepage," the "Ride-hailing Homepage" module (the first independent sub-package) sends a request to the event bus with the content "Payment service needs to be called, order ID is 12345, amount is 50 yuan." The event bus encapsulates this request into an event message, such as "Call payment."

[0026] S130. If the second independent sub-package of the target service is not loaded in local memory, the event message is temporarily stored in the message queue, and the download and loading process of the second independent sub-package is triggered.

[0027] In this embodiment, the second independent subpackage refers to a functional module responsible for implementing the target business, such as a "payment module." Due to the independent subpackage strategy, this module may not yet have been downloaded to the user's device, or although it has been downloaded, it may not yet be loaded into memory for operation. Before distributing messages, the event bus checks the loading status of the target module. If the target module is found to be unloaded, to prevent message loss, the event bus temporarily stores the event message in a first-in-first-out message queue and suspends it, while immediately triggering the host environment's package manager to download and load the second independent subpackage.

[0028] For example, when the event bus is ready to dispatch a "call payment" message, it queries the status table and finds that the "payment module" (the second independent subpackage) has not yet been loaded. At this point, the event bus puts the message into the processing queue and calls the interface used to load the subpackage to start downloading the code package of the "payment module".

[0029] S140. Monitor the loading status of the second independent sub-package. When the second independent sub-package is detected to be loaded and registered to the event bus, retrieve the event message from the message queue and distribute it to the second independent sub-package to trigger the second independent sub-package to execute the corresponding business logic.

[0030] After the download process is triggered, the event bus continuously monitors or uses a callback mechanism to learn about the loading progress of the second independent sub-package. Once the second independent sub-package has finished downloading, its code has been injected into memory, and initialization is complete (including registering its event handling capabilities with the event bus), the event bus will receive a notification. At this point, the event bus checks the message queue for any temporary messages destined for that sub-package. If any are found, it retrieves these messages sequentially and distributes them to the event handling function of the second independent sub-package through a dispatch mechanism, thereby triggering the execution of the corresponding business logic.

[0031] For example, once the "payment module" is loaded, the event bus immediately retrieves the previously stored payment request message from the message queue and calls the function in the "payment module" used to handle the corresponding business logic. Subsequently, the "payment module" pops up the payment window and begins executing the payment process.

[0032] According to the solution of this disclosure, by introducing an event bus and asynchronous message queue mechanism during the mini-program runtime, the problems of communication message loss and call failure caused by physical isolation and asynchronous loading of modules in an independent sub-package architecture are solved. Compared with the bloated main package and slow startup caused by strong dependencies between modules in the prior art, or the communication difficulties caused by simple sub-package, this solution achieves a combination of complete decoupling of modules and on-demand loading, which not only ensures the ultra-fast startup experience of the mini-program, but also improves the continuity and stability of cross-sub-package business processes.

[0033] In one possible implementation, in step S130, if the second independent sub-package of the target service is not loaded in local memory, the event message is temporarily stored in the message queue, and the download and loading process of the second independent sub-package is triggered, further including the following steps: S131. Determine the current status of the second independent sub-packet by querying the sub-packet status table maintained in the event bus.

[0034] The sub-package status table can be understood as a data structure maintained internally by the event bus to record the lifecycle status of all independent sub-packages in the mini-program in real time. Statuses typically include "Not Downloaded," "Downloading," "Downloaded but Not Loaded," and "Loaded." When processing cross-package calls, the event bus first queries this table to determine the subsequent processing strategy.

[0035] For example, the sub-module status table might be a hash map, where the key is a unique identifier for the sub-module (such as module_id), and the value is an enumeration of the current status. When a message is received for the "active module," the event bus queries this table to find that the current status of the "active module" is not loaded.

[0036] S132. If the current state of the second independent sub-package is not downloaded, call the network interface of the host environment to download the code package of the second independent sub-package and mark the event message as suspended.

[0037] When it is confirmed that the target subpackage has not yet been downloaded, the system needs to perform two parallel operations: first, call the underlying network download interface to fetch the code package from the server; second, mark the current event message as "suspended" and store it in a message queue, waiting to process it after the download is completed. This step ensures that during the network request, the business request will not report an error or be lost due to the absence of the target code.

[0038] For example, if the system detects that the "Activity Module" has not been downloaded, it will call the download interface. Simultaneously, the "Click Event Message" that triggered the activity will be marked as suspended and added to a queue. The user may see a loading animation on the interface, while the background silently downloads the package and queues the messages.

[0039] According to the solution of this disclosure embodiment, by refining the judgment logic of the sub-package status, different processing paths are distinguished between "not downloaded" and "loaded". When not downloaded, a network request is automatically triggered and the message is suspended, effectively handling the timing dependency problem in the loading process of mini-program sub-packages. This avoids program crashes or logic interruptions caused by the absence of target modules, realizes on-demand loading without the user's awareness, and greatly improves the robustness of the system and the user experience.

[0040] In one possible implementation, the communication control method of the mini-program further includes the following steps: S150. Before the second independent subpackage completes initialization, render the preset transition placeholder component or skeleton screen in the current page interface of the mini program.

[0041] In this embodiment, the transition placeholder component or skeleton screen can be understood as a temporary interface element displayed before the actual content has finished loading. It typically consists of gray blocks, lines, or simple graphics, and its layout is similar to the actual page, providing the user with visual feedback that "content is loading," thus alleviating waiting anxiety. During the interval between independent sub-package downloads and initialization, if the interface remains unresponsive, the user may mistakenly believe the program has frozen. Therefore, upon triggering sub-package loading, the system immediately renders such a transitional interface on the current page.

[0042] For example, when a user clicks the "Ride-hailing" button on the homepage and the "Ride-hailing module" is downloading, a skeleton screen immediately appears on the screen, containing a map outline, vehicle icon placeholders, and address bar color blocks. This skeleton screen does not contain actual map data or vehicle information, but it tells the user that "the ride-hailing page is opening."

[0043] S160. Upon receiving a notification that the second independent subpackage has finished loading, destroy the transition placeholder component or skeleton screen, and render the actual business interface of the second independent subpackage.

[0044] Once the code package of the second independent subpackage has been downloaded, parsed, and initialized, it will send a ready notification. Upon receiving this notification, the main program will perform cleanup work, removing (destroying) the previously displayed skeleton screen or placeholder components from the view layer, and displaying the real business interface rendered by the second independent subpackage to the user, completing a seamless switch from "virtual placeholder" to "real business".

[0045] For example, once the "ride-hailing module" is loaded and the real map components and vehicle location information are rendered, the previous gray skeleton screen disappears instantly and is replaced by the real ride-hailing page, allowing users to start inputting their destination and other operations.

[0046] According to the solution of this disclosure, by introducing a skeleton screen or transition animation during asynchronous loading of sub-packages, the problem of "white screen" or "no response to clicks" caused by network latency or code package size is solved. This visually smooth transition significantly reduces the user's psychological waiting time and reduces user churn caused by slow loading.

[0047] In one possible implementation, the image control method of the mini-program further includes the following steps: S170. Obtain the current network status of the device and the user's operation context in the mini-program.

[0048] In this embodiment, the operational context can be understood as information such as the user's current behavior trajectory, location, and interaction state within the mini-program. Network status refers to the device's current network connection type (e.g., Wi-Fi, 4G, 5G) and signal quality. The system needs to collect this information in real-time or periodically as a basis for subsequent decisions.

[0049] S180. Determine whether the network status meets the preset high-quality conditions, and determine whether the operation context matches the preset packet association rules.

[0050] High-quality conditions typically refer to a good network environment, such as fast download speeds that do not consume expensive mobile data (e.g., Wi-Fi). Packet association rules are a predefined set of logic used to determine whether the current user's behavior suggests they may be about to access a packet that has not yet been loaded. The system compares the collected status information with these predefined conditions.

[0051] For example, the criteria for a good user experience can be set as "being in a Wi-Fi environment and having a download speed greater than 2MB / s". The association rule can be set as "when a user stays at the bottom of the homepage for more than 3 seconds". The system will then match the data obtained from S170 with these rules.

[0052] S190. If both the quality condition and the sub-package association rule are met, silently download the code package of the independent sub-package that has not yet been loaded in the background.

[0053] When the network environment and user behavior meet the preset conditions, the system will consider it a suitable time to preload future resources. Therefore, the system will start a download task in the background, silently (i.e., without interrupting the user's current operation or displaying a loading progress bar) downloading the predicted individual packages that the user might need to the local machine.

[0054] For example, given the current Wi-Fi environment and the user's interest in the recommended content at the bottom (timeout), the system predicts a high probability that the user will click to enter the details page. Therefore, the system automatically downloads the code package for the "details page module" in the background. When the user actually clicks, the page can open instantly because the package is already local.

[0055] According to the solution of this disclosure, by combining network status and user context with an intelligent preloading strategy, the contradiction between the waste of bandwidth in traditional "full preloading" and the slow startup of "lazy loading" is resolved. This solution only consumes resources when network conditions are good and the user has potential needs, thus saving user bandwidth and device resources while improving the startup speed of the mini-program.

[0056] In one possible implementation, step S180 includes at least one of the following strategies in the preset sub-package association rules: S181, Critical Path Strategy: When a user triggers the initial action of a core business process, the download of necessary dependent sub-packages for subsequent core business processes is forcibly triggered.

[0057] The critical path refers to the series of steps necessary to complete a core business process (such as placing an order or making a payment). When a user takes the first step on this path, the system has reason to believe that the user will complete the entire process, and therefore can download the resources needed for subsequent steps in advance.

[0058] For example, in an e-commerce mini-program, when a user clicks "Buy Now" to enter the "Order Confirmation Page," this marks the beginning of a core process. Based on this, the system determines that the user is highly likely to enter the "Checkout Page" within seconds. Therefore, while loading the "Order Confirmation Page," the pre-download of the "Checkout Sub-package" is forcibly triggered.

[0059] S182. Idle Time Prediction Strategy: When it is detected that the user's dwell time on the current page exceeds a preset threshold, the pre-download of the extended function sub-packages that are related to the current page's business is triggered.

[0060] Idle time prediction utilizes the "idle time window" when users browse pages. If a user stays on a page for a long time, it means that he is reading or thinking carefully. At this time, bandwidth and CPU are relatively idle, and the probability of the user taking the next action (such as clicking on a related link) increases.

[0061] For example, if a user reads an article for 10 seconds (exceeding the set 3-second threshold), and there is an entry to the "Comments" section at the bottom of the page, the system uses this reading time to pre-download a sub-package of the "Comments Module" in the background.

[0062] S183, Component-level lazy loading strategy: The download of the independent sub-package corresponding to a specific module is triggered only when the user scrolls the page to the visible area of ​​the specific module.

[0063] Component-level lazy loading is a strategy based on view visibility. For modules that are not on the first screen of a long page, their resources are only loaded when they are about to enter the user's field of view. This can greatly reduce first-screen loading time and unnecessary resource consumption.

[0064] According to the solutions in this disclosure, by providing a variety of refined preloading strategies, developers can flexibly configure the most suitable loading logic according to specific business scenarios. This refined resource scheduling mechanism balances "loading speed" and "resource consumption" to the greatest extent, ensuring the smooth operation of core processes while avoiding unnecessary traffic waste.

[0065] In one possible implementation, after detecting that the second independent subpackage has finished loading and registered with the event bus in S140, an event message is retrieved from the message queue and distributed to the second independent subpackage to trigger the second independent subpackage to execute the corresponding business logic, further including the following steps: S141. Obtain the attribute definition metadata of the second independent subpackage that has been pre-registered.

[0066] In this embodiment of the disclosure, attribute definition metadata refers to a data structure that describes the module interface specification, typically including module identifier, input parameter definitions (parameter name, type, required fields, etc.), output result definitions, and dependencies. Each independent subpackage defines this metadata during the development phase and synchronizes it to the event bus during loading and registration.

[0067] S142. Validate the payload format of the event message based on the input parameter definitions in the attribute definition metadata.

[0068] Before dispatching a message, the event bus compares the data (payload) carried in the event message with the input format required by the target module. If missing parameters or incorrect types are found, the system can intercept and report an error in advance to prevent incorrect calls from causing the target module to crash or produce unpredictable behavior.

[0069] S143. After the verification is passed, the event handling function of the second independent sub-package is called to respond to the event message in order to execute the business logic of the target business.

[0070] The event bus will only allow access if the message payload fully conforms to the metadata definition. It will then locate the callback function for the corresponding event registered in the second independent sub-package and pass the validated data as a parameter to that function, thereby officially initiating the target business logic.

[0071] According to the solution of this disclosure embodiment, by introducing a runtime interface verification mechanism based on metadata, the problem of difficulty in enforcing contracts between modules under loosely coupled architecture is solved, which greatly improves the security of cross-subpackage calls and the stability of the system, and reduces runtime failures caused by parameter errors.

[0072] Figure 2 This is a flowchart illustrating a method for building a mini-program according to an embodiment of this disclosure. Figure 2 As shown, it includes the following steps: S210. Obtain the source code and common basic code of multiple business modules of the mini-program.

[0073] In this embodiment of the disclosure, this step typically occurs within the developer's build tools. The system reads the project's source code directory and identifies which parts are business logic code (such as "ride-hailing" and "food delivery") and which parts are basic code shared by all modules (such as "user login", "network request library", and "log reporting").

[0074] For example, the build tool scans the project directory and identifies src / pages / taxi (ride-hailing service), src / pages / food (food delivery service), and src / common (common infrastructure).

[0075] S220. According to the subpackage configuration strategy, compile the common basic code into a common layer package, and compile each business module into an independent subpackage that does not depend on each other.

[0076] The code splitting and packaging strategy refers to the rules specified by the developer in the configuration file. The build tool then physically splits and packages the code according to these rules. Crucially, common foundational code is packaged into a separate common layer package or part of the main package, while each business module is packaged into an independent sub-package. The build tool ensures that there are no direct code references between the independent sub-packages; they can only depend on the common layer package.

[0077] S230. Generate attribute definition metadata for each independent subpackage and encapsulate it in the corresponding code package. The attribute definition metadata shall include at least the module identifier, input parameter definition, output result definition and dependency relationship.

[0078] During compilation, the build tool parses specific description files (such as interface definition files or comments) in the business module to extract the module's metadata information. Then, the tool serializes this information and packages it as a resource file into the corresponding independent sub-package.

[0079] S240. Inject event bus control code into the common layer package or main package. The event bus control code is configured to manage event communication and asynchronous loading queues between independent sub-packages during the applet's runtime.

[0080] To support cross-package communication at runtime, the build tool automatically injects the core implementation code of the event bus into the startup logic of the common layer package or the main package. This code is responsible for initializing the bus when the mini-program starts and providing basic capabilities such as publishing, subscribing, and message queue management.

[0081] S250: Generate a mini-program release package that includes a common layer package and multiple independent sub-packages.

[0082] Finally, the build tool combines all the compiled package files (public package and individual sub-packages) and the generated configuration files together to form the final mini-program release format (such as a collection of .wxapkg files), ready to be uploaded to the mini-program platform for release.

[0083] According to the solution of this disclosure embodiment, the physical isolation and logical decoupling of the mini-program architecture are achieved through an automated build process. The build tool automatically handles code splitting, metadata generation, and basic settings injection, allowing developers to focus on business logic development without manually managing complex sub-package dependencies and underlying communication code. This ensures that the final generated code package meets the architectural requirements of high cohesion and low coupling, improving runtime performance.

[0084] In one possible implementation, S220 compiles each business module into independent, undependent subpackages, further including the following steps: S221. Generate attribute definition metadata for each independent subpackage and encapsulate it in the corresponding code package.

[0085] In this embodiment of the disclosure, attribute definition metadata serves as a bridge connecting build time and runtime. During the compilation phase, tools analyze the source code or configuration files and automatically generate data describing the characteristics of the module.

[0086] S222. Attribute definition metadata shall include at least the following: module identifier, input parameter definition and output result definition, dependency relationship, and triggering event.

[0087] Module Identifier: Used to uniquely index this independent sub-packet in the event bus.

[0088] Input parameter definition and output result definition: These define the standard format for data interaction between this independent subpackage and the outside world, similar to a machine-readable version of API documentation.

[0089] Dependencies: Declare common layer resources or other services required for the operation of this independent subpackage, and ensure that the runtime environment meets the requirements.

[0090] Triggering events: Declare the set of business events that this independent subpackage can publish or respond to.

[0091] According to the solution of this disclosure, the "self-description" capability of a module is achieved by forcibly generating standardized metadata during the build phase. This allows the module to be used as a "black box" at runtime, where external callers do not need to understand its internal implementation and only need to follow the contract defined by the metadata. This provides a standardized interface basis for cross-application migration, reuse, and automated testing of modules.

[0092] In one possible implementation, S250 generates a mini-program release package containing a common layer package and multiple independent sub-packages, further including the following steps: S251. Generate a global route configuration file, which defines the mapping relationship between the page paths of the mini program and the list of module identifiers.

[0093] A global routing configuration file is a navigation map. It records not only page paths (URLs) but also the modules that make up those pages. This mapping is no longer hard-coded in the code but is externalized in the configuration file.

[0094] S252. The mapping relationship is used to instruct the mini-program host environment to dynamically pull the corresponding independent sub-packages according to the module identifier list at runtime, and to nest and combine multiple independent sub-packages into a complete business page according to the configuration order.

[0095] At runtime, the host environment (or the main control logic of the common layer) reads this configuration file. When a user accesses / pages / home, the main control logic parses out the three module IDs required by the page, and then uses the event bus and loading mechanism to pull these three independent sub-packages in parallel or serially, and renders them into the page container in sequence, finally assembling them into a complete homepage.

[0096] According to the solution of this disclosure, the page structure is defined in the form of a configuration file, realizing a "configuration-based assembly" development model. Developers do not need to modify the code; they only need to modify the configuration file to adjust the page layout or add or delete functional modules.

[0097] like Figure 3 As shown in the figure, this application provides a layered architecture diagram of a mini-program system. The architecture is divided into a basic project tool layer, a business module layer, and an upper application layer from bottom to top. The specific definitions and interaction relationships of each layer are as follows: 1. Project Basic Tools Layer This layer serves as the underlying support for the entire mini-program architecture and is typically deployed within the mini-program's main package. For example... Figure 3 As shown, this layer encapsulates the basic capabilities common to all business modules, including but not limited to: Logger: Used to collect and report exception stacks and behavior logs during client runtime; Global state cache (Store): Used to maintain global data shared across modules (such as user information and system configuration) to ensure data consistency; Network Request Adapter (Request): Encapsulates the underlying HTTP / HTTPS requests, providing a unified interception, signing, and error handling mechanism; Other basic tools include: device location and data tracking SDK.

[0098] Architecture function: By sinking common capabilities to this layer, it ensures that upper-layer business modules do not need to reinvent the wheel, and the size of this layer is strictly controlled, thereby ensuring that only the most necessary code needs to be loaded when the mini-program starts, solving the problem of excessive bloat in the main package.

[0099] 2. Business Module Layer This layer is the core business area of ​​the mini-program, consisting of several independent sub-packages that do not depend on each other. For example... Figure 3 As shown in the middle section, each business module (such as the "ride-hailing module") is physically a separate folder, which is highly cohesive and specifically contains: Subcontracting page: Responsible for displaying the business logic; Subpackaged components: UI components that are reused only within this subpackage; Subpackage logic: includes utility functions specific to this business, specific request logic, and private SDK.

[0100] There are no direct imports / requirements between module A (as shown in the left box) and module B (as shown in the right box) in this layer. They only have a one-way dependency on the underlying "project infrastructure tool layer". This physical isolation forces decoupling between modules, allowing individual modules to be independently split, tested, or migrated to other applications.

[0101] 3. Upper application layer This level is an aggregation container for modules, representing the final user-facing mini-program instance (such as the "Ride-hailing Mini-program").

[0102] This layer mainly consists of global configuration files (such as app.json) and route mapping tables. Developers select the necessary building blocks (independent packages) from the "business module layer" through configuration, and assemble them into a complete application with the support of the "project basic tools layer".

[0103] This design makes the upper-layer application extremely lightweight. When a new derivative mini-program needs to be developed, the existing business sub-packages can be quickly reused simply by reconfiguring the list of referenced modules at the application layer, without any intrusive modifications to the sub-package code.

[0104] According to the solution of this disclosure embodiment, through the above-described three-layer architecture design of "basic layer - module layer - application layer" and the physical deployment strategy of "independent sub-packages", high cohesion and low coupling of business logic are forcibly achieved at the architectural level. This not only improves the first-screen startup performance of the mini-program to an industry-leading level (loading only the basic tool layer), but also significantly reduces the cost of cross-team collaboration and the complexity of code maintenance through the black-box encapsulation of modules.

[0105] Figure 4 This is a schematic diagram of the communication control device 400 for a mini-program provided according to an embodiment of this disclosure. Figure 4 As shown, the device includes: The bus management module 401 is used to initialize the event bus in the host environment when the mini-program starts. The event bus is used to maintain the event subscription relationship of each independent sub-package. The communication scheduling module 402 is used to generate corresponding event messages through the event bus in response to the call request for the target service issued by the first independent sub-packet. The loading control module 403 is used to temporarily store the event message in the message queue and trigger the download and loading process of the second independent sub-package when the second independent sub-package of the target service is not loaded in the local memory. The monitoring and distribution module 404 is used to monitor the loading status of the second independent sub-package. When it is detected that the second independent sub-package has been loaded and registered to the event bus, the module retrieves the event message from the message queue and distributes it to the second independent sub-package to trigger the second independent sub-package to execute the corresponding business logic.

[0106] In one possible implementation, the loading control module 403 is used for: The current status of the second independent sub-packet is determined by querying the sub-packet status table maintained in the event bus. If the current state of the second independent sub-package is not downloaded, call the network interface of the host environment to download the code package of the second independent sub-package, and mark the event message as pending.

[0107] In one possible implementation, the device further includes a user interface rendering module for: Before the second independent subpackage completes initialization, render the preset transition placeholder component or skeleton screen in the current page interface of the mini program. Upon receiving a notification that the second independent subpackage has finished loading, destroy the transition placeholder component or skeleton screen, and render the actual business interface of the second independent subpackage.

[0108] In one possible implementation, the device further includes a preloading module for: Obtain the current network status of the device and the user's operation context in the mini-program; Determine whether the network status meets the preset high-quality conditions, and determine whether the operation context matches the preset packet association rules; If both the quality criteria and the subpackage association rules are met, the code packages of the independent subpackages that have not yet been loaded will be downloaded silently in the background.

[0109] In one possible implementation, the pre-defined sub-package association rules include at least one of the following strategies: Critical path strategy: When a user triggers the initial action of a core business process, the download of necessary dependent sub-packages for subsequent core business processes is forced. Off-peak prediction strategy: When it is detected that the time a user stays on the current page exceeds a preset threshold, the pre-download of the extended function packages that are related to the current page is triggered; Component-level lazy loading strategy: The download of the independent sub-package corresponding to a specific module is triggered only when the user scrolls the page to the visible area of ​​the specific module.

[0110] In one possible implementation, the monitoring and distribution module 404 is used for: Retrieve the pre-registered attribute definition metadata of the second independent subpackage; The payload format of the event message is validated based on the input parameter definitions in the attribute definition metadata. After the verification is successful, the event handling function of the second independent subpackage is called to respond to the event message in order to execute the business logic of the target business.

[0111] Figure 5 This is a schematic diagram of a mini-program building apparatus 500 provided according to an embodiment of the present disclosure. The apparatus is applied to a computing device and includes: Module 501 is used to obtain the source code and common basic code of multiple business modules of the mini program; The compilation module 502 is used to compile the common basic code into a common layer package according to the subpackage configuration strategy, and compile each business module into an independent subpackage that does not depend on each other. The independent subpackage is configured to depend only on the common layer package, and there is no code reference relationship between the independent subpackages. The encapsulation module 503 is used to generate attribute definition metadata for each independent subpackage and encapsulate it in the corresponding code package; the attribute definition metadata includes at least the module identifier, input parameter definition, output result definition, and dependency relationship; Injection module 504 is used to inject event bus control code into the common layer package or the main package. The event bus control code is configured to manage event communication and asynchronous loading queues between independent sub-packages during the mini-program runtime. Module 505 is used to generate a mini-program release package that includes a common layer package and multiple independent sub-packages.

[0112] In one possible implementation, compiler module 502 is used for: Generate attribute definition metadata for each independent subpackage and encapsulate it in the corresponding code package; Attribute definition metadata should include at least: Module identifier, used to uniquely index this independent sub-packet in the event bus; Input parameter definitions and output result definitions are used to define the standard format for data interaction between this independent sub-package and the outside world; Dependencies are used to declare the common layer resources required for the operation of this independent subpackage; Trigger events are used to declare the set of business events that this independent subpackage can publish or respond to.

[0113] In one possible implementation, the generation module 505 is used for: Generate a global route configuration file, which defines the mapping relationship between the page paths of the mini program and the list of module identifiers; The mapping relationship is used to instruct the mini-program host environment to dynamically pull the corresponding independent sub-packages according to the module identifier list at runtime, and to nest and combine multiple independent sub-packages into a complete business page according to the configuration order.

[0114] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0115] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0116] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0117] Figure 6 A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0118] like Figure 6As shown, device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 602 or a computer program loaded into random access memory (RAM) 603 from storage unit 608. RAM 603 may also store various programs and data required for the operation of device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0119] Multiple components in device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of monitors, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0120] The computing unit 601 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as applet communication control methods and applet construction methods. For example, in some embodiments, the applet communication control methods and applet construction methods can be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the applet communication control methods and applet construction methods described above can be performed. Alternatively, in other embodiments, the computing unit 601 may be configured in any other suitable manner (e.g., by means of firmware) to execute the communication control method or the applet construction method.

[0121] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0122] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0123] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0124] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0125] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0126] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0127] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0128] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A communication control method for a WeChat Mini Program, comprising: When the mini-program starts, an event bus is initialized in the host environment. The event bus is used to maintain the event subscription relationship of each independent sub-package. In response to the call request for the target service issued by the first independent sub-package, a corresponding event message is generated through the event bus; If the second independent sub-package of the target service is not loaded in local memory, the event message is temporarily stored in the message queue, and the download and loading process of the second independent sub-package is triggered. Monitor the loading status of the second independent subpackage. When the loading of the second independent subpackage is completed and registered to the event bus, retrieve the event message from the message queue and distribute it to the second independent subpackage to trigger the second independent subpackage to execute the corresponding business logic.

2. The method according to claim 1, wherein, In the case that the second independent sub-package of the target service is not loaded in local memory, the event message is temporarily stored in a message queue, and the download and loading process of the second independent sub-package is triggered, including: The current status of the second independent sub-packet is determined by querying the sub-packet status table maintained in the event bus. If the current state of the second independent sub-package is not downloaded, call the network interface of the host environment to download the code package of the second independent sub-package, and mark the event message as pending.

3. The method according to claim 1, further comprising: Before the second independent subpackage completes initialization, a preset transition placeholder component or skeleton screen is rendered in the current page interface of the mini-program. Upon receiving a notification that the second independent subpackage has finished loading, the transition placeholder component or skeleton screen is destroyed, and the actual business interface of the second independent subpackage is rendered.

4. The method according to claim 1, further comprising: Obtain the current network status of the device and the user's operation context in the mini-program; Determine whether the network status meets the preset high-quality conditions, and determine whether the operation context matches the preset packet association rules; If both the quality conditions and the sub-package association rules are met, the code packages of the independent sub-packages that have not yet been loaded will be downloaded silently in the background.

5. The method according to claim 4, wherein, The preset sub-packet association rules include at least one of the following strategies: Critical path strategy: When a user triggers the initial action of a core business process, the download of the necessary dependent sub-packages for the subsequent core business process is forcibly triggered; Off-peak prediction strategy: When it is detected that the time a user stays on the current page exceeds a preset threshold, the pre-download of the extended function sub-packages that are related to the business of the current page is triggered; Component-level lazy loading strategy: The download of the independent sub-package corresponding to a specific module is triggered only when the user scrolls the page to the visible area of ​​the specific module.

6. The method according to claim 1, wherein after detecting that the second independent subpackage has finished loading and registered with the event bus, retrieving the event message from the message queue and distributing it to the second independent subpackage to trigger the second independent subpackage to execute the corresponding business logic, includes: Obtain the attribute definition metadata pre-registered in the second independent subpackage; The payload format of the event message is validated based on the input parameter definitions in the attribute definition metadata. After the verification is passed, the event handling function of the second independent sub-package is called to respond to the event message in order to execute the business logic of the target service.

7. A method for building a mini-program, applied to a computing device, comprising: Obtain the source code and common basic code of multiple business modules of the mini-program; According to the subpackage configuration strategy, the common basic code is compiled into a common layer package, and each of the business modules is compiled into an independent subpackage that does not depend on each other. The independent subpackage is configured to depend only on the common layer package, and there is no code reference relationship between the independent subpackages. For each independent subpackage, attribute definition metadata is generated and encapsulated in the corresponding code package. The attribute definition metadata includes at least module identifier, input parameter definition, output result definition, and dependency relationship. Inject event bus control code into the common layer package or main package. The event bus control code is configured to manage event communication and asynchronous loading queues between independent sub-packages during the mini-program runtime. Generate a mini-program release package that includes the aforementioned common layer package and multiple independent sub-packages.

8. The method according to claim 7, wherein, The step of compiling each of the aforementioned business modules into independent, undependent subpackages includes: Generate attribute definition metadata for each independent subpackage and encapsulate it in the corresponding code package; The attribute definition metadata includes at least: A module identifier, used to uniquely index this independent sub-packet within the event bus; Input parameter definitions and output result definitions are used to define the standard format for data interaction between this independent sub-package and the outside world; Dependencies are used to declare the common layer resources required for the operation of this independent subpackage; Trigger events are used to declare the set of business events that this independent subpackage can publish or respond to.

9. The method according to claim 7, wherein, The process of generating a mini-program release package that includes the common layer package and multiple independent sub-packages includes: Generate a global routing configuration file, which defines the mapping relationship between the page paths of the mini program and the list of module identifiers; The mapping relationship is used to instruct the mini-program host environment to dynamically pull the corresponding independent sub-packages according to the module identifier list during runtime, and to nest and combine multiple independent sub-packages into a complete business page according to the configuration order.

10. A communication control device for a mini-program, comprising: The bus management module is used to initialize the event bus in the host environment when the mini-program starts. The event bus is used to maintain the event subscription relationship of each independent sub-package. The communication scheduling module is used to generate a corresponding event message through the event bus in response to a call request for the target service issued by the first independent sub-packet. The loading control module is used to temporarily store the event message in the message queue and trigger the download and loading process of the second independent sub-package when the second independent sub-package of the target service is not loaded in the local memory. The monitoring and distribution module is used to monitor the loading status of the second independent subpackage. When it is detected that the second independent subpackage has been loaded and registered to the event bus, the module retrieves the event message from the message queue and distributes it to the second independent subpackage to trigger the second independent subpackage to execute the corresponding business logic.

11. A mini-program building device, applied to a computing device, comprising: The acquisition module is used to acquire the source code and common basic code of multiple business modules of the mini program; The compilation module is used to compile the common basic code into a common layer package according to the subpackage configuration strategy, and to compile each of the business modules into independent subpackages that do not depend on each other. The independent subpackages are configured to depend only on the common layer package, and there is no code reference relationship between the independent subpackages. An encapsulation module is used to generate attribute definition metadata for each independent subpackage and encapsulate it in the corresponding code package; wherein, the attribute definition metadata includes at least module identifier, input parameter definition, output result definition, and dependency relationship; An injection module is used to inject event bus control code into the public layer package or main package. The event bus control code is configured to manage event communication and asynchronous loading queues between independent sub-packages during the mini-program runtime. The generation module is used to generate a mini-program release package that includes the common layer package and multiple independent sub-packages.

12. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-9.

13. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-9.

14. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-9.

Images