Popup window rendering method and device in applet, computer device and storage medium

Abstract

The specification discloses a pop-up layer rendering method and device in a small program, computer equipment and a storage medium, the method is applied to the technical field of the small program, the small program is a small program in a target application, and the method comprises the following steps: after detecting that the small program is started, an interactive operation between a user and the small program is acquired; according to the interactive operation, a native pop-up layer interface in a small program framework of the target application is called to render a target pop-up layer associated with the interactive operation, and the native pop-up layer interface is used to call a rendering container created by the target application in a native mode, so that the small program pop-up layer rendering with high performance and high success rate can be realized on the premise of ensuring the continuity of the user experience.

Description

Technical Field

[0001] This specification relates to the field of mini-program technology, and in particular to a method, apparatus, computer device, and storage medium for rendering pop-up layers within a mini-program. Background Technology

[0002] With the rapid development of mobile internet technology, mini-programs, as a new type of application that can be used without downloading or installation, have quickly penetrated into various aspects of users' daily lives, becoming an important carrier connecting users and services, thanks to their instant accessibility, lightweight nature, and convenience. At the same time, users have placed increasingly stringent demands on the smoothness of mini-program interactions, response speed, and visual experience; any slight lag or delay may affect users' perception and satisfaction with the overall service.

[0003] Among the diverse functions of mini-programs, pop-ups, as temporary interactive views presented as overlays or floats on the host application interface, play a crucial bridging role between public domain traffic and merchants' private domain operations. Common rendering methods for pop-ups within mini-programs include H5 pop-up rendering solutions based on WebView or pop-up solutions based on independent Cube pages. However, the WebView-based H5 pop-up solution suffers from long processing times and high failure rates, while the independent Cube page-based solution disrupts user flow, has limited form, and is complex to manage. Therefore, achieving high-performance, high-success-rate pop-up rendering in mini-programs while ensuring user experience continuity has become a pressing technical challenge. Summary of the Invention

[0004] This specification provides a method, apparatus, computer device, and storage medium for rendering pop-up layers within a mini-program. This method can achieve high-performance and high-success-rate pop-up layer rendering in mini-programs while ensuring the continuity of user experience.

[0005] Firstly, a pop-up rendering method within a mini-program is provided, wherein the mini-program is a mini-program within a target application. The method includes: after detecting that the mini-program has started, obtaining the interaction operation between the user and the mini-program; and, based on the interaction operation, calling the native pop-up interface within the mini-program framework of the target application to render a target pop-up associated with the interaction operation, wherein the native pop-up interface is used to call a rendering container natively created by the target application.

[0006] In conjunction with the first aspect, in some possible implementations, the step of calling the native pop-up interface within the mini-program framework of the target application to render the target pop-up associated with the interaction operation includes: determining a pop-up decision method adapted to the interaction operation based on the interaction operation between the user and the mini-program; determining whether a pop-up needs to be displayed and the pop-up content to be displayed based on the pop-up decision method; and, if it is determined that a pop-up needs to be displayed, calling the native pop-up interface within the mini-program framework of the target application to render the target pop-up associated with the interaction operation, wherein the target pop-up includes the pop-up content.

[0007] In conjunction with the first aspect, in some possible implementations, determining whether to display a pop-up and the pop-up content to be displayed based on the pop-up decision method includes: when the pop-up decision method is a first decision method, calling a target interface to determine whether to display a pop-up and the pop-up content to be displayed, wherein the target interface is a single interface merged from multiple backend interfaces; and when the pop-up decision method is a second decision method, determining whether to display a pop-up and the pop-up content to be displayed through preset rules, wherein the preset rules refer to the rules for determining whether to display a pop-up, and the preset rules include the correspondence between interactive operations and pop-up content.

[0008] In conjunction with the first aspect, in some possible implementations, the step of calling the native pop-up interface within the mini-program framework of the target application to render the target pop-up associated with the interaction operation according to the interaction operation includes: determining whether the mini-program framework of the target application meets preset pop-up conditions; if the pop-up conditions are met, calling the native pop-up interface within the mini-program framework of the target application to render the target pop-up associated with the interaction operation according to the interaction operation.

[0009] In conjunction with the first aspect, in some possible implementations, the step of calling the native pop-up interface within the mini-program framework of the target application to render the target pop-up associated with the interaction operation, based on the interaction operation, when the pop-up condition is met, includes: configuring the mini-program framework into the whitelist of the target application to enable the mini-program framework to call the native pop-up interface; and, if the whitelist includes the mini-program framework, calling the native pop-up interface within the mini-program framework of the target application to render the target pop-up associated with the interaction operation, based on the interaction operation.

[0010] In conjunction with the first aspect, in some possible implementations, determining whether the mini-program framework of the target application meets the preset pop-up conditions includes: determining whether the version of the mini-program framework of the target application meets the preset pop-up conditions within the lifecycle of the mini-program.

[0011] In conjunction with the first aspect, in some possible implementations, the native pop-up interface and the mini-program run in the same code context.

[0012] In conjunction with the first aspect, in some possible implementations, the user interface of the target pop-up layer is developed using the domain-specific language DSL of the applet.

[0013] Secondly, a pop-up rendering device within a mini-program is provided, comprising: an acquisition module, configured to acquire the interaction operation between the user and the mini-program after detecting that the mini-program has been launched; and a rendering module, configured to call the native pop-up interface within the mini-program framework of the target application according to the interaction operation, so as to render the target pop-up associated with the interaction operation, wherein the native pop-up interface is used to call the rendering container natively created by the target application.

[0014] Thirdly, a computer device is provided, the computer device including one or more processors and one or more memories, the one or more memories storing at least one computer program, the computer program being loaded and executed by the one or more processors to implement the pop-up rendering method in the above-mentioned applet.

[0015] Fourthly, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, the computer program being loaded and executed by a processor to implement the pop-up rendering method within the aforementioned applet.

[0016] Fifthly, a computer program product or computer program is provided, the computer program product or computer program including program code stored in a computer-readable storage medium, the processor of a computer device reading the program code from the computer-readable storage medium, the processor executing the program code, causing the computer device to execute the pop-up rendering method in the above-mentioned applet.

[0017] The technical solution provided in the embodiments of this specification deeply integrates the pop-up rendering chain into the mini-program framework. After detecting the mini-program's launch, based on the user's interaction with the mini-program, the native pop-up interface within the target application's mini-program framework is called to render the target pop-up. This eliminates the need for serial operations such as WebView creation and H5 loading, resulting in shorter rendering time. Furthermore, directly calling the native overlay API for pop-up rendering is equivalent to migrating the pop-up rendering carrier from an external, independent WebView to the native overlay API within the mini-program framework, fundamentally solving the performance and stability bottlenecks caused by WebView. The rendering container natively created by the target application has superior performance and a lower probability of technical failure. Therefore, calling the native rendering container created by the target application through the native pop-up interface to render the pop-up improves the success rate of pop-up rendering. Implementing pop-up rendering through the native rendering container created by the target application ensures that the target pop-up and the target application use the same rendering mechanism. Its animation effects, touch responses, and layout adaptation are consistent with the mini-program's native interface, maintaining the continuity and immersive experience of the interaction. The native pop-up interface is integrated within the mini-program framework, and its lifecycle is naturally connected with the mini-program framework's own event system. This allows developers to track the entire pop-up's status through a unified detection platform, including key indicators such as triggering conditions, rendering time, success rate, and user interaction. This solves the detection breakage problem caused by the complexity of cross-context communication in traditional WebView solutions. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the implementation environment of a pop-up rendering method within a mini-program provided in the embodiments of this specification; Figure 2 This is a schematic flowchart of a pop-up rendering method within a mini-program provided in the embodiments of this specification; Figure 3 This is a schematic flowchart of another pop-up rendering method in a mini-program provided in the embodiments of this specification; Figure 4 This is a schematic diagram of the structure of a pop-up rendering device within a mini-program provided in the embodiments of this specification; Figure 5 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification; Figure 6 This is a schematic diagram of the structure of a server provided in the embodiments of this specification. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this specification clearer, the embodiments of this specification will be further described in detail below with reference to the accompanying drawings.

[0021] In this manual, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor are there any restrictions on quantity or execution order.

[0022] In the specific embodiments of this application, any data related to the object, such as data involved in the use of the application, is required. When the embodiments of this application are applied to specific products or technologies, permission or consent from the object is required, and the collection, use, and processing of the relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. In other words, if any of the aforementioned object-related data is involved in the embodiments of this application, this data must be obtained with the object's authorization and consent, and in accordance with the relevant laws, regulations, and standards of the country and region.

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of the embodiments of this application and the technical effects produced by the technical solutions of this application will be described below with reference to the accompanying drawings and through the description of several exemplary embodiments. It should be noted that the following embodiments can be referred to, borrowed from, or combined with each other, and the same terms, similar features, and similar implementation steps in different embodiments will not be described again.

[0024] To facilitate understanding of the embodiments of this application, the main technical terms involved in the embodiments of this application will be explained below: 1. Overlay Layer A pop-up is a temporary interactive view that appears above the host application's interface, presented in a way that includes overlay or floating elements. It's used to support private domain operation functions such as marketing campaigns, membership services, and message notifications. Pop-ups coexist with the underlying page but are rendered independently, possessing temporariness, interactivity, and visual prominence. They serve as a key technological bridge connecting public domain traffic with merchants' private domain operations.

[0025] 2. Content Delivery Platform (CDP) A content delivery platform (CDP) refers to a centralized platform that integrates, manages, and analyzes user data to support refined operations and content delivery. In the related technologies involved in this application, CDP uses its provided Software Development Kit (SDK) to listen to mini-program lifecycle events, request confirmation from the decision interface regarding whether to display a pop-up layer, and drives the creation and rendering of the pop-up layer when it needs to be displayed. In related technologies, CDP uses its SDK to create a transparent WebView to render H5 pop-ups.

[0026] 3.Appx Appx refers to the runtime framework (also known as the container) of a mini-program. For example, when the host application is Alipay, Appx refers to the runtime framework of the Alipay mini-program. It is the native container built into the Alipay client, providing a complete runtime environment for the mini-program. Appx is used to provide page rendering, API calls, and extension capabilities. Its core responsibilities include: parsing the mini-program code package, managing the page lifecycle, and providing built-in components and APIs. It is the foundation for the mini-program to run securely and efficiently within the host application.

[0027] 4. Official Capability (Open Capability) Official capabilities refer to a standardized mechanism provided by Appx that allows one party to develop functions as custom components / JavaScript modules for the mini-program, which are then injected into the mini-program's runtime environment as needed by Appx, achieving "research-free" integration. This means mini-program developers can directly use these pre-built capabilities without additional development. This mechanism improves operational efficiency and flexibility in function coverage while ensuring secure isolation.

[0028] 5. Native Overlay Page Native Overlay pages refer to full-screen native pages (also known as native overlay pages) dynamically created by the host client within the context of a mini-program. They can overlay all native mini-program interface elements, including TabBar and TitleBar, and support continuous display across pages, making them an ideal carrier for high-performance pop-ups.

[0029] 6. WebView WebView is a component that embeds a web page rendering engine into a native application, used to embed and display web page content within the native application. In pop-up rendering scenarios, WebView is used as a container for H5 pop-ups.

[0030] With the rapid development of mobile internet technology, mini-programs, as a new type of application that can be used without downloading or installation, have quickly penetrated into various aspects of users' daily lives, becoming an important carrier connecting users and services, thanks to their instant accessibility, lightweight nature, and convenience. At the same time, users have placed increasingly stringent demands on the smoothness of mini-program interactions, response speed, and visual experience; any slight lag or delay may affect users' perception and satisfaction with the overall service.

[0031] Among the diverse functions of mini-programs, overlay layers, as temporary interactive views presented on top of the host application interface in a covered or floating manner, play a crucial bridging role between public domain traffic and merchants' private domain operations. Whether it's marketing campaigns, membership services, or message notifications, overlay layers directly impact operational effectiveness and user experience with their intuitive and efficient interaction methods. Therefore, how to achieve high-performance, high-success-rate rendering of overlay layers while ensuring the continuity of the main functions of the mini-program has become one of the urgent problems to be solved in the mini-program field.

[0032] This application, through research, has found that the rendering of pop-up layers within mini-programs in related technologies mainly involves the following two implementation schemes: Implementation Solution 1: H5 pop-up rendering solution based on WebView. WebView is a component that embeds a web page rendering engine into a native application. In this solution, after the mini-program starts, the CDP SDK begins listening and requests confirmation from the decision interface whether a pop-up needs to be displayed. If it is confirmed that a pop-up needs to be displayed, a transparent WebView is created, and then the H5 page is loaded and rendered. The technical path of this solution can be summarized as "mini-program starts → CDP SDK listens → requests decision interface → creates WebView → loads H5 → renders".

[0033] However, this implementation scheme 1 has the following technical defects in practical applications: Firstly, performance is not compressible: WebView creation and H5 loading are serial operations, which is the root cause of the performance bottleneck. The entire process takes too long. On Android, creating the WebView alone takes about 1.5 seconds. Adding the 500-800ms time spent on the deployment interface and loading H5 resources, the average opening time is as high as 3.8 seconds (Android) and 2 seconds (iOS), which seriously slows down the opening speed of the pop-up.

[0034] Secondly, it suffers from poor stability: affected by factors such as WebView creation failure and H5 loading timeouts, the pop-up's success rate is only 90%-91%. In scenarios with a large number of UVs (Unique Visitors), this means that hundreds of thousands of users cannot see the pop-up every day, causing significant losses. Issues such as WebView creation failure and network timeouts lead to a high technical failure rate, directly affecting the pop-up's usability.

[0035] Third, user experience is fragmented: Since the pop-up runs in the WebView context, which is in a different rendering environment from the mini-program, the WebView is isolated from the mini-program's native environment. Cross-context rendering leads to frequent issues with animation effects and layout compatibility, resulting in a fragmented user experience.

[0036] Fourth, detection of breaks: The communication mechanism between WebView and the host environment is complex, making it difficult to achieve accurate detection and data tracking across the entire link, which is not conducive to problem localization and performance optimization.

[0037] Implementation Solution 2: A pop-up solution based on an independent Cube page. Addressing the shortcomings of Solution 1, related technologies attempt to encapsulate the pop-up as an independent Cube page, invoked through a unified navigation method (such as startApp). This solution refactors the original pop-up on the current page into an independent page module, achieving decoupling and reuse. However, this solution also suffers from the following insurmountable drawbacks: First, it disrupts the context. This solution requires switching pages, interrupting the user's current operation flow. Jumping to a separate page will interrupt the user's operation on the original page, reducing the continuity of the interaction.

[0038] Secondly, its form is limited, making it difficult to achieve lightweight overlay effects, such as floating balls and half-screen pop-ups, which require overlaying on the current page.

[0039] Third, it is not natively integrated. The decoupling of this solution from the mini-program lifecycle leads to complicated triggering logic and lacks unified control capabilities.

[0040] In summary, the relevant technologies for pop-up rendering within mini-programs suffer from the following core problems: H5 pop-up solutions based on WebView are time-consuming and have a high failure rate; while solutions based on independent Cube pages interrupt user flow, have limited form, and are complex to manage. Therefore, achieving high-performance, high-success-rate pop-up rendering in mini-programs while ensuring a continuous user experience has become a pressing technical challenge.

[0041] To address the aforementioned technical issues, this specification provides a method for rendering pop-up layers in mini-programs. This method deeply integrates the pop-up rendering chain into the mini-program framework, bypassing the traditional WebView rendering path. It solves the problems of poor performance and unsmooth user experience associated with traditional solutions, achieving a pop-up layer opening time with a high success rate.

[0042] The implementation environment of the embodiments in this specification will be described below.

[0043] Figure 1 This is a schematic diagram illustrating the implementation environment of a pop-up rendering method within a mini-program, as provided in the embodiments of this specification. See also... Figure 1 This implementation environment may include terminal device 110 and server 120. Terminal device 110 may be a computer, mobile phone, or other terminal device. Server 120 may be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery network (CDN), and big data and artificial intelligence platforms.

[0044] Users can use terminal device 110 to interact with server 120 via a network to receive or send messages, etc. Various client applications can be installed on terminal device 110, such as mini-program applications, video applications, live streaming applications, instant messaging tools, email clients, social media platform software, etc. The terminal device here can be hardware or software. When the terminal device is hardware, it can be various electronic devices with a display screen, including but not limited to smartphones, tablets, e-book readers, laptops, and desktop computers. When the terminal device is software, it can be installed on the electronic devices listed above. It can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services) or as a single software program or software module. No specific limitations are made here.

[0045] Server 120 can be a server that provides various services, such as a backend server that supports terminal device 110. The backend server can analyze and process data such as running-related data requests (such as rendering pop-ups) and feed back the processing results (such as the rendered target pop-up) to the terminal device.

[0046] It should be noted that the pop-up rendering method in the mini-program provided in the embodiments of this specification can be executed by the terminal device 110.

[0047] Figure 2This is a schematic flowchart illustrating a pop-up rendering method within a mini-program provided in the embodiments of this specification. See also... Figure 2 Taking a terminal device as the executing entity as an example, the method includes the following steps.

[0048] Step 202: After detecting that the mini-program has started, obtain the interaction between the user and the mini-program.

[0049] Step 204: Based on the interaction, call the native pop-up interface within the mini-program framework of the target application to render the target pop-up associated with the interaction. The native pop-up interface is used to call the rendering container natively created by the target application.

[0050] exist Figure 2 In the illustrated embodiment, the pop-up rendering chain is deeply integrated into the mini-program framework. Upon detecting mini-program startup, based on user interaction with the mini-program, the native pop-up interface within the target application's mini-program framework is called to render the target pop-up. This eliminates the need for sequential repetitive operations such as WebView creation and H5 loading, resulting in shorter rendering time. Furthermore, directly calling the native overlay API for pop-up rendering effectively migrates the pop-up rendering carrier from an external, independent WebView to the native overlay API within the mini-program framework, fundamentally resolving the performance and stability bottlenecks caused by WebView. The rendering container natively created by the target application offers superior performance and reduces the probability of technical failures. Therefore, calling the native rendering container created by the target application through the native pop-up interface improves the success rate of pop-up rendering. Implementing pop-up rendering through the native rendering container created by the target application ensures that the target pop-up and the target application use the same rendering mechanism. Their animation effects, touch responses, and layout adaptation remain consistent with the mini-program's native interface, maintaining the continuity and immersive experience of the interaction. The native pop-up interface is integrated within the mini-program framework, and its lifecycle is naturally connected with the mini-program framework's own event system. This allows developers to track the entire pop-up's status through a unified detection platform, including key indicators such as triggering conditions, rendering time, success rate, and user interaction. This solves the detection breakage problem caused by the complexity of cross-context communication in traditional WebView solutions.

[0051] As can be seen, the embodiments in this specification, while ensuring the accuracy of pop-up triggering, completely reconstruct the rendering chain using the native pop-up interface, fundamentally eliminating the inherent performance bottlenecks and stability risks of the WebView solution, thereby achieving a reduction in pop-up opening time and simultaneous enhancement of user interaction experience and operation and maintenance detection capabilities.

[0052] The following is about Figure 2The specific implementation methods of each step in the illustrated embodiment are explained below: In step 202, after detecting that the mini-program has been launched, the terminal device obtains the interaction between the user and the mini-program.

[0053] In this context, a mini-program refers to a mini-program within the target application. The target application can also be described as a host application or a native application. The target application refers to the native application installed on the terminal device (such as a smartphone), which provides the runtime container environment and underlying capability interfaces for the mini-program. For example, the target application could be an application like Alipay that has mini-program functionality. A mini-program is a sub-application that runs within the target application and can be used without installation.

[0054] User interactions with a mini-program refer to user commands generated on the mini-program's interface that can be recognized and responded to. These interactions mainly include clicking, long-pressing, swiping, and inputting. After a mini-program is detected as launched, user interactions during its operation are monitored in real-time, as these interactions may trigger pop-up displays. For example, if a user clicks a button on the mini-program's interface that might trigger a pop-up display, it may trigger the subsequent pop-up rendering process.

[0055] In step 204, the terminal device, based on the interactive operation, calls the Native Overlay API within the mini-program framework to render the target overlay associated with the interactive operation. The Native Overlay API is used to call the rendering container natively created by the target application, and then the rendering of the target overlay is completed through this rendering container. The Native Overlay API can be understood as the JavaScript API exposed by the mini-program framework to developers for calling native overlay capabilities. The target overlay refers to the specific visual element (such as a modal dialog box or a floating view) that is ultimately presented on the user interface.

[0056] A target pop-up associated with an interactive operation refers to a pop-up that has a pre-defined trigger relationship with a certain interactive operation. It reflects the causal relationship in the interaction logic, that is, when a user performs a specific interactive operation, the corresponding specific pop-up is displayed. For example, if the interactive operation is that the user clicks the button to claim a coupon, then the target pop-up associated with this interactive operation can be a pop-up that displays the coupon.

[0057] Rendering the target pop-up by calling the Native Overlay API within the target application's mini-program framework means directly rendering the target pop-up onto the Native Overlay page using the target application's native pop-up capabilities. For example, when the target application is Alipay, instead of using a traditional H5 pop-up to display content, the underlying native pop-up API of the Alipay client is directly called to render the target pop-up directly onto Alipay's Native Overlay page. This avoids creating a WebView, saving time and resulting in better performance, faster pop-up response, and a higher success rate.

[0058] Furthermore, the experience is smoother, with animations, styles, and user interactions consistent with native applications, unlike H5 which is prone to lag or incompatibility. Simply put, it leverages Alipay's native capabilities to run mini-program code, bridging the gap between the two platforms.

[0059] By calling the Native Overlay API, mini-programs can directly render the target pop-up on the Native Overlay page, thus bypassing the creation of traditional WebViews and the loading of H5 pop-ups. In this embodiment, there is no need to load a separate webpage pop-up; instead, a pop-up is drawn directly, just like a native application, which is much faster. The Native Overlay API allows mini-programs to be deeply integrated with native applications, retaining the flexibility of hot updates while achieving the performance experience of native applications.

[0060] In some embodiments, the native pop-up interface and the mini-program run in the same code context.

[0061] In computer programs, the same code context refers to code sharing the same global object, memory stack, and event loop queue. In the embodiments of this specification, the same code context can be the same JavaScript context. For JavaScript, the same context means that variables can access each other, functions can be called directly, and timers and asynchronous callbacks are queued in the same queue. The native pop-up interface and the host applet running in the same JavaScript context means that the logic code of the native pop-up interface and the logic code of the host applet share the same JavaScript engine instance, rather than running in separate processes. This eliminates cross-process communication overhead and solves historical problems such as animation synchronization and style compatibility.

[0062] When calling the native pop-up interface, only a normal function call is needed within the same JavaScript context, eliminating the need for cross-process communication and further reducing the time spent rendering and displaying the pop-up. Parameters passed (such as pop-up title and content) do not require structured cloning or JSON serialization; they are passed directly by reference or value, reducing memory overhead.

[0063] In some embodiments, the user interface of the target pop-up is developed using the applet's domain-specific language (DSL).

[0064] A DSL (Specific Language Specification) is a computer language designed specifically for a particular problem domain or task set, as opposed to general-purpose programming languages ​​(such as JavaScript and Java). DSLs improve development efficiency and code readability by providing highly abstract syntactic structures and semantic rules, enabling developers to express solutions in a way that more closely resembles the problem domain. In the field of WeChat Mini Program development, a DSL specifically refers to a set of language specifications used to describe the structure, style, and interactive behavior of the Mini Program user interface.

[0065] The user interface (UI) of the target pop-up layer is developed using the Mini Program's DSL, meaning that the visual presentation of the target pop-up layer is entirely described by the markup language and style language within the Mini Program DSL. The interactive behavior of the target pop-up layer is associated with the JavaScript code in the logic layer through the event binding mechanism defined by the DSL. The target pop-up layer is encapsulated as an independent unit, a custom component conforming to the Mini Program specification. This means that developers construct target pop-ups in the same way they construct ordinary Mini Program pages or components, following the same syntax rules.

[0066] In some embodiments, the UI of the target pop-up is developed in the form of a standard mini-program custom component and registered as an official capability. This ensures full compatibility with the mini-program ecosystem and allows it to enjoy the performance optimization benefits of the Appx underlying layer.

[0067] In some embodiments, step 204 is implemented by including steps 2041 to 2043 as follows: Step 2041: Determine the pop-up decision-making method that is adapted to the interaction between the user and the mini-program.

[0068] This embodiment provides two decision-making methods for the pop-up layer: a first decision-making method and a second decision-making method. These two methods are based on different judgment criteria and execution paths, and are respectively applicable to interaction scenarios with unclear rules and those with clear rules.

[0069] Clearly defined rules mean that the pop-up to be displayed and what kind of pop-up to display can be uniquely determined based on the interaction and preset rules. For example: clicking the "Daily Check-in" button will always display a pop-up showing the check-in results. Clicking the "Activity Rules" button will always display a pop-up explaining the activity rules (static content, no query required). Clicking the "Share" button will always display a pop-up showing the sharing method selection (fixed options). In these clearly defined interaction scenarios, the triggering conditions and displayed content of the pop-up can be completely determined by local rules, without relying on external data.

[0070] Unclear rules refer to situations where, based on interactive operations and preset rules, it is impossible to uniquely determine whether a pop-up needs to be displayed and what type of pop-up should be displayed. For example, a user clicks the "Product Status" button, but the product's inventory changes dynamically and may vary depending on the user's geographical location; these factors require API calls to determine.

[0071] For example, the ambiguity of the rules manifests itself in one or more of the following situations: Triggering conditions depend on external states: Whether a pop-up is needed depends on dynamic factors such as user status (e.g., whether they are logged in or have claimed a coupon), product status (e.g., whether inventory is sufficient), and time conditions (e.g., whether the activity has started).

[0072] The pop-up content needs to be generated in real time: the specific information displayed in the pop-up (such as coupon value, remaining inventory, and personalized copy) needs to be obtained from the server.

[0073] The decision-making logic is complex, involving multiple conditions (such as "new user, during the event, and first click"), which cannot be concisely expressed by static rules.

[0074] In these interactive scenarios where rules are not clearly defined, which often exist in scenarios that require real-time data, the triggering conditions and displayed content of the pop-up cannot be completely determined by local rules and must rely on real-time data.

[0075] The first decision-making approach refers to a situation where, after an interaction occurs, it's impossible to determine whether a pop-up needs to be displayed or what type of pop-up should be displayed based solely on preset rules. Instead, the approach involves calling the target API to obtain necessary return data, and then using that data to decide whether to trigger the pop-up and what content to display. This first decision-making approach is suitable for interaction scenarios where rules are unclear.

[0076] The second decision-making method refers to matching based on predefined rules after an interaction occurs. If a match is successful, the corresponding target pop-up is triggered directly, without any additional network requests or API calls. The core of the second decision-making method lies in the exhaustiveness and determinism of the rules; the predefined rules are essentially the correspondence between the interaction and the pop-up content.

[0077] For example, when a user clicks the "Claim Coupon" button, the pop-up content displays a coupon. No API calls are needed; the pop-up immediately displays the coupon once the rules are matched, providing the user with instant visual feedback. This second decision-making method is suitable for interaction scenarios with clearly defined rules.

[0078] In some embodiments, the terminal device determines whether the current interaction scenario is a clearly defined or unclear one based on the user's interaction with the mini-program. If the current interaction scenario is unclear, the pop-up decision method is determined as the first decision method. If the current interaction scenario is clearly defined, the pop-up decision method is determined as the second decision method.

[0079] In some embodiments, the terminal device queries a preset rule to see if there is pop-up content corresponding to the interaction between the user and the mini-program. If there is pop-up content corresponding to the interaction in the preset rule, the pop-up decision method adapted to the interaction is determined to be the second decision method; if there is no pop-up content corresponding to the interaction in the preset rule, the pop-up decision method adapted to the interaction is determined to be the first decision method.

[0080] Step 2042: Based on the pop-up decision method, determine whether a pop-up needs to be displayed and the content of the pop-up to be displayed.

[0081] In some embodiments, when the pop-up decision method is the first decision method, the target interface is called to determine whether the pop-up needs to be displayed and the content of the pop-up to be displayed. The target interface is a single interface formed by merging multiple backend interfaces.

[0082] In this embodiment, to address the latency issue caused by multiple serial requests in traditional solutions, the multiple backend interfaces involved in the pop-up decision-making logic are optimized. These backend interfaces are merged into a single interface, the target interface, significantly reducing the data volume and response time of the general deployment interface. This target interface can be called a simplified CDP interface. By calling this simplified CDP interface, all the data required for pop-up decision-making can be retrieved at once. Based on the returned data from calling the simplified CDP interface, it can be determined whether a pop-up needs to be displayed and what content should be displayed. The result of the judgment based on the actual returned data may indicate that a pop-up needs to be displayed or that it does not need to be displayed. For example, in one scenario, multiple backend interfaces include a first interface for querying user information, a second interface for querying coupon status, a third interface for querying inventory quantity, and a fourth interface for querying activity configuration information. In this embodiment, the multiple backend interfaces originally used to query various types of data (such as user information, coupon status, inventory quantity, and activity configuration information) are merged into a single interface, which is processed uniformly by the server and returns the dataset required for complete decision-making. Based on this dataset, it is determined whether a pop-up needs to be displayed, and if it is determined that a pop-up needs to be displayed, the specific content of the pop-up to be displayed is determined. For example, it is necessary to determine whether the user has claimed a coupon based on the user information, and whether the coupon has been claimed based on the coupon status. If it is determined that the user has not claimed a coupon and the coupon has not been claimed, then it is determined that a pop-up needs to be displayed, and the specific content of the pop-up to be displayed is a coupon. Alternatively, if the queried inventory quantity is 0, it can be determined that a pop-up does not need to be displayed; if the queried inventory quantity is greater than 0, then it is determined that a pop-up needs to be displayed, and thus the specific content of the pop-up to be displayed is determined.

[0083] In some embodiments, when the pop-up decision method is the second decision method, the pop-up to be displayed and the pop-up content to be displayed are determined by preset rules. The preset rules refer to the rules for determining the pop-up to be displayed, and the preset rules include the correspondence between interactive operations and pop-up content.

[0084] In this embodiment, for interaction scenarios with clearly defined rules, a new protocol, namely the aforementioned preset rules, is formulated, enabling the client to make decisions directly based on local preset rules, achieving zero-time decision-making. When the pop-up decision method is the second decision method, it is already clear that the pop-up needs to be displayed, so the pop-up content corresponding to the interaction operation can be directly queried from the preset rules. For example, if the user's interaction operation is clicking the favorite / subscribe button, the corresponding pop-up content is "favorited / subscribed successfully," without needing to query through an interface.

[0085] Step 2043: If it is determined that a pop-up needs to be displayed, call the native pop-up interface within the mini-program framework of the target application to render the target pop-up associated with the interactive operation. The target pop-up includes the pop-up content mentioned above.

[0086] If it is determined that a pop-up needs to be displayed and the content of the pop-up to be displayed is determined, the Native Overlay API is called, and the Native Overlay page provided by Appx is used as a rendering container to render the target pop-up associated with the interactive operation. The target pop-up includes the aforementioned pop-up content.

[0087] In some embodiments, the above-mentioned method of calling the native pop-up interface within the mini-program framework of the target application to render the target pop-up associated with the interaction operation includes: determining whether the mini-program framework of the target application meets the preset pop-up conditions; if the pop-up conditions are met, calling the native pop-up interface within the mini-program framework of the target application to render the target pop-up associated with the interaction operation based on the interaction operation.

[0088] The pop-up condition is used to measure whether the version of the mini-program framework is higher than a preset version (e.g., 2.9.xxx). This measures whether the hardware capabilities allow for subsequent calls to the native pop-up interface to render the target pop-up. The mini-program framework version refers to the version number of the mini-program runtime framework (such as Alipay's Appx container) built into the target application (host application). This version number identifies the feature set supported by the underlying container, API stability, and performance optimization level.

[0089] For example, if testing confirms that the native pop-up interface performs stably and the animation is smooth on various models starting from version 2.9.12, then the default version can be set to 2.9.12.

[0090] Calling native pop-up interfaces, which are only supported in higher versions, from an older framework can lead to API call failures, non-existent interfaces or unexpected behavior, exceptions due to missing underlying implementations, malfunctioning pop-ups, lag, or inability to close them. Therefore, by using pop-up condition checks, native pop-up interfaces are only called when the mini-program framework has the necessary capabilities, fundamentally avoiding these problems and reducing the probability of errors and maintenance costs.

[0091] For example, if the conditions for a pop-up are not met, a WebView-based H5 pop-up rendering scheme or a pop-up scheme based on an independent Cube page can be used for subsequent pop-up rendering. In this way, under higher-version frameworks, users get a smooth, non-penetrating native pop-up experience; under lower-version frameworks, users can still see the pop-up (although the effect is slightly worse), but there will be no anomalies due to calling unstable native interfaces, and the terrible experience of being completely unresponsive is also avoided.

[0092] In some embodiments, determining whether the mini-program framework of the target application meets the preset pop-up conditions includes: determining whether the version of the mini-program framework of the target application meets the preset pop-up conditions within the lifecycle of the mini-program.

[0093] The mini-program lifecycle refers to the complete process from mini-program startup, foreground operation, background suspension, to destruction. In this embodiment, the judgment logic of the pop-up condition is directly compiled into the underlying code of the mini-program framework (i.e., the Appx container). This means that every mini-program running in this container has the ability to judge pop-up conditions, without the need for external CDP SDK listening. Instead, it is triggered directly by the mini-program framework within the mini-program lifecycle, avoiding redundant event listening.

[0094] Considering that external CDP SDK listeners typically require mounting independent listener functions on each page or component, increasing memory overhead and the length of the event handling chain, this embodiment embeds the pop-up condition listening logic (i.e., the judgment logic) into the mini-program framework. All events only need to be judged by the mini-program framework, without relying on the external CDP SDK, further reducing the time spent rendering and displaying the pop-up. The pop-up condition judgment logic, as part of the Appx container, has its lifecycle completely bound to the mini-program's running state. When the mini-program is destroyed, the pop-up condition judgment logic automatically becomes invalid, eliminating the need for developers to manually clean up the listeners and avoiding memory leaks.

[0095] In some embodiments, when the pop-up conditions are met, the native pop-up interface within the mini-program framework is invoked to render the target pop-up based on user operation. This includes: when the pop-up conditions are met, configuring the mini-program framework into the whitelist of the target application so that the mini-program framework has the permission to directly invoke the native pop-up interface; and when the whitelist includes the mini-program framework, invoking the native pop-up interface within the mini-program framework to render the target pop-up based on user operation.

[0096] In this context, a whitelist refers to a list of trusted entities maintained by the target application (host application). Entities listed in this whitelist (such as mini-program frameworks, specific mini-programs, or functional modules) are granted operational permissions that exceed conventional restrictions. In this embodiment, the whitelist specifically refers to a list of mini-program frameworks with permissions to directly call native pop-up interfaces. After obtaining these permissions, all mini-programs running within the mini-program framework can indirectly obtain the ability to call native pop-up interfaces through this framework.

[0097] If the pop-up conditions are met, it means that the mini-program framework currently has the ability to call the native pop-up interface for pop-up rendering. In this case, to grant the mini-program framework permission to call the native pop-up interface, it can be configured to be added to the target application's whitelist.

[0098] For example, if the pop-up conditions are met, the whitelist of the target application can be checked to see if the identifier of the currently running mini-program framework exists. If the identifier of the currently running mini-program framework does not exist in the whitelist, then the identifier of the currently running mini-program framework can be added to the whitelist.

[0099] In this embodiment, by including the mini-program framework in the whitelist and granting native pop-up interface call permissions, a balance is achieved between security, efficiency, and flexibility, providing a reliable permission foundation for the high-quality operation of pop-up rendering.

[0100] Figure 3 This is a schematic flowchart of another pop-up rendering method provided in the embodiments of this application.

[0101] For example, such as Figure 3 As shown, the pop-up rendering method includes: Step 301: The user has been detected entering the mini-program scene.

[0102] The user entering the mini-program scenario can be understood as the detection of mini-program launch mentioned above.

[0103] Step 302: The APPx container determines whether the pop-up condition is met. If yes, proceed to step 303; otherwise, proceed to step 304.

[0104] This step can be understood as follows: within the lifecycle of the mini-program, determine whether the version of the mini-program framework meets the preset pop-up conditions.

[0105] Step 303: Activate the official capability JS module.

[0106] Among them, the JS module, or JavaScript module, can be considered to have activated the official JS module capability when the mini-program framework is configured to be included in the target application's whitelist.

[0107] Step 304: Normal operation.

[0108] Normal operation refers to rendering schemes that do not call the Native Overlay API, i.e., H5 pop-up rendering schemes based on WebView or pop-up rendering schemes based on independent Cube pages.

[0109] Step 305: Determine the pop-up decision method that is compatible with the current interaction scenario. If the compatible pop-up decision method is Method A (optimized interface), proceed to step 306; if the compatible pop-up decision method is Method B (new protocol), proceed to step 307.

[0110] Method A is the first decision-making method mentioned above, and Method B is the second decision-making method mentioned above.

[0111] Step 306: Call the simplified CDP interface.

[0112] The simplified CDP interface is a single interface formed by merging the multiple backend interfaces mentioned above. In this step, the simplified CDP interface is called to determine whether a pop-up needs to be displayed and what content should be displayed.

[0113] Step 307: Decision made directly by local rules.

[0114] Among them, the local rule direct decision refers to determining the pop-up layer to be displayed and the content of the pop-up layer to be displayed through the above-mentioned preset rules.

[0115] Step 308: Call the Native Overlay API.

[0116] Step 309: Render the mini-program DSL component on the Native Overlay page.

[0117] The above-mentioned call to the Native Overlay API to render the mini-program DSL component on the Native Overlay page can be understood as: The Native Overlay API is invoked to render the target pop-up associated with the user's interaction. The Native Overlay API is used to call the rendering container natively created by the target application. This can also be understood as: rendering the target pop-up associated with the user's interaction on the Native Overlay page; the native overlay page is the rendering container provided by the mini-program framework, and the rendering container is natively created by the target application.

[0118] In summary, this embodiment, by deeply integrating the pop-up rendering chain into the mini-program framework and replacing WebView with NativeOverlay, achieves a deep reconstruction of the pop-up technology stack, moving away from WebView and towards native implementation. This reconstruction includes the following two key points: Key Point 1: View Link Innovation, namely Native Rendering based on Appx Official Capabilities.

[0119] Specifically, firstly, WebView is completely abandoned, and Appx's Native Overlay is used as the rendering container. This container is created natively by the client, resulting in superior performance. Secondly, Mini Program DSL is used for development, meaning the pop-up UI is developed as a standard Mini Program custom component and registered as an "official capability." This ensures full compatibility with the Mini Program ecosystem and allows it to benefit from Appx's underlying performance optimizations. Thirdly, it runs in the same context, meaning the pop-up component and the host Mini Program run in the same JavaScript context, eliminating cross-process communication overhead and resolving historical issues such as animation synchronization and style compatibility.

[0120] Key Point Two: Collaborative Optimization of Data and Control Links.

[0121] Specifically, firstly, decision-making chain cohesion was implemented, meaning the judgment logic for pop-up conditions is no longer handled by the external CDP SDK, but is directly triggered by the Appx container within the mini-program's lifecycle, avoiding redundant event listening. Secondly, Two pop-up decision-making methods are provided, as mentioned above: Method A (interface optimization), which involves co-building a simplified CDP interface with the backend, significantly reducing the data volume and response time of the general delivery interface. Method B (new protocol), which involves formulating new preset rules for interaction scenarios with clear rules (such as collection and subscription), allowing the client to directly decide on the pop-up content to be displayed based on local preset rules, achieving zero-time decision-making interface processing. Thirdly, centralized unified management and control are achieved. Since all pop-ups run in the Appx context, Appx naturally has the ability to prioritize and mutually exclude them, fundamentally solving the pop-up conflict problem.

[0122] This specification presents and implements a novel pop-up architecture based on official Mini Program capabilities and a Native Overlay. This architecture, for the first time, migrates the pop-up rendering carrier from an external, independent WebView to a Native Overlay within the Mini Program container. It utilizes Mini Program DSL components for high-performance rendering, fundamentally resolving the performance and stability bottlenecks imposed by WebView. Furthermore, it designs a full-link collaborative optimization strategy for pop-up decision-making and rendering. By cohesuring decision-making logic within the Mini Program container and combining "interface optimization" and "new protocols" as pop-up decision-making methods, it achieves excellent end-to-end performance from data acquisition to view display. Simultaneously, it constructs a centralized and unified management system for pop-ups within the Mini Program ecosystem. Leveraging the deep integration of official capabilities, Appx can uniformly manage priorities and mutual exclusion control for pop-ups from different sources and technology stacks, significantly improving the consistency and elegance of the overall user experience. Developers use the familiar Mini Program DSL for development, maintaining the agility of H5 solution iterations. At the same time, through Native rendering, it achieves near-native application performance and experience, balancing development efficiency and runtime quality.

[0123] All the above-described optional implementation methods can be combined in any way to form optional embodiments of this specification, and will not be described in detail here.

[0124] Figure 4 This is a schematic diagram of the structure of a pop-up rendering device within a mini-program provided in the embodiments of this specification. See also... Figure 4 The pop-up rendering device 400 within the mini-program includes: The acquisition module 401 is used to acquire the interaction between the user and the mini program after the mini program is detected to be launched; The rendering module 402 is used to call the native pop-up interface within the mini-program framework of the target application based on the interactive operation, so as to render the target pop-up associated with the interactive operation. The native pop-up interface is used to call the rendering container natively created by the target application.

[0125] In one possible implementation, the rendering module is specifically configured to: determine a pop-up decision method adapted to the interaction between the user and the mini-program; determine whether a pop-up needs to be displayed and the content of the pop-up to be displayed based on the pop-up decision method; and, if it is determined that a pop-up needs to be displayed, call the native pop-up interface within the mini-program framework of the target application to render the target pop-up associated with the interaction, wherein the target pop-up includes the pop-up content.

[0126] In one possible implementation, the rendering module is specifically used to: when the pop-up decision method is the first decision method, call a target interface to determine whether the pop-up needs to be displayed and the pop-up content to be displayed, wherein the target interface is a single interface merged from multiple backend interfaces; when the pop-up decision method is the second decision method, determine the pop-up to be displayed and the pop-up content to be displayed through preset rules, wherein the preset rules refer to the rules for determining whether the pop-up needs to be displayed, and the preset rules include the correspondence between interactive operations and pop-up content.

[0127] In one possible implementation, the rendering module includes: a judgment module, used to judge whether the mini-program framework of the target application meets the preset pop-up conditions; and a rendering unit, used to, if the pop-up conditions are met, call the native pop-up interface within the mini-program framework of the target application according to the interaction operation to render the target pop-up associated with the interaction operation.

[0128] In one possible implementation, the rendering module is specifically configured to: when the pop-up conditions are met, configure the mini-program framework into the whitelist of the target application, so that the mini-program framework has the permission to call the native pop-up interface; when the whitelist includes the mini-program framework, call the native pop-up interface within the mini-program framework of the target application according to the interaction operation, so as to render the target pop-up associated with the interaction operation.

[0129] In one possible implementation, the judgment module is specifically used to determine, within the lifecycle of the mini-program, whether the version of the mini-program framework of the target application meets the preset pop-up conditions.

[0130] In one possible implementation, the native pop-up interface runs in the same code context as the mini-program.

[0131] In one possible implementation, the user interface of the target pop-up is developed using the applet's domain-specific language DSL.

[0132] It should be noted that the pop-up rendering device within the mini-program provided in the above embodiments is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computer device can be divided into different functional modules to complete all or part of the functions described above. In addition, the pop-up rendering device within the mini-program provided in the above embodiments and the pop-up rendering method embodiments within the mini-program belong to the same concept, and the specific implementation process is detailed in the method embodiments, which will not be repeated here.

[0133] This specification provides a computer device for performing the above-described method. This computer device can be implemented as a terminal or a server. The structure of a terminal will be described below: Figure 5 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. The terminal 500 can be a smartphone, tablet computer, laptop computer, or desktop computer. The terminal 500 may also be referred to as a terminal device, portable terminal, laptop terminal, desktop terminal, or other names.

[0134] Typically, terminal 500 includes one or more processors 501 and one or more memories 502.

[0135] Processor 501 may include one or more processing cores, such as a quad-core processor or an octa-core processor. Processor 501 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 501 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 501 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the screen.

[0136] Memory 502 may include one or more computer-readable storage media, which may be non-transitory. Memory 502 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in memory 502 is used to store at least one computer program, which is executed by processor 501 to implement the pop-up rendering method within a applet provided in the method embodiments of this specification.

[0137] In some embodiments, the terminal 500 may also optionally include a peripheral device interface 503 and at least one peripheral device. The processor 501, memory 502, and peripheral device interface 503 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 503 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: a radio frequency circuit 504, a display screen 505, a camera assembly 506, an audio circuit 507, and a power supply 508.

[0138] Peripheral device interface 503 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 501 and memory 502. In some embodiments, processor 501, memory 502 and peripheral device interface 503 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 501, memory 502 and peripheral device interface 503 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0139] The radio frequency (RF) circuit 504 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 504 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 504 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 504 may include: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc.

[0140] Display screen 505 is used to display a user interface (UI). This UI may include graphics, text, icons, video, and any combination thereof. When display screen 505 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 501 for processing. In this case, display screen 505 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard.

[0141] The camera assembly 506 is used to capture images or videos. Optionally, the camera assembly 506 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal.

[0142] The audio circuit 507 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, and convert the sound waves into electrical signals that are input to the processor 501 for processing, or input to the radio frequency circuit 504 to realize voice communication.

[0143] Power supply 508 is used to supply power to the various components in terminal 500. Power supply 508 can be AC ​​power, DC power, a disposable battery, or a rechargeable battery.

[0144] In some embodiments, the terminal 500 further includes one or more sensors 509. The one or more sensors 509 include, but are not limited to, an accelerometer 510, a gyroscope 511, a pressure sensor 512, an optical sensor 513, and a proximity sensor 514.

[0145] Accelerometer 510 can detect the magnitude of acceleration on the three coordinate axes of a coordinate system established with terminal 500.

[0146] The gyroscope sensor 511 can detect the orientation and rotation angle of the terminal 500. The gyroscope sensor 511 can work in conjunction with the accelerometer sensor 510 to collect the user's 3D movements on the terminal 500.

[0147] The pressure sensor 512 can be installed on the side bezel of the terminal 500 and / or on the lower layer of the display screen 505. When the pressure sensor 512 is installed on the side bezel of the terminal 500, it can detect the user's grip signal on the terminal 500, and the processor 501 can perform left / right hand recognition or quick operation based on the grip signal collected by the pressure sensor 512. When the pressure sensor 512 is installed on the lower layer of the display screen 505, the processor 501 can control the operable controls on the UI interface based on the user's pressure operation on the display screen 505.

[0148] An optical sensor 513 is used to collect ambient light intensity. In one embodiment, the processor 501 can control the display brightness of the display screen 505 based on the ambient light intensity collected by the optical sensor 513.

[0149] The proximity sensor 514 is used to acquire the distance between the user and the front of the terminal 500.

[0150] Those skilled in the art will understand that Figure 5 The structure shown does not constitute a limitation on terminal 500, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0151] The aforementioned computer equipment can also be implemented as a server. The structure of a server is described below: Figure 6This is a schematic diagram of a server structure provided in an embodiment of this specification. The server 600 can vary significantly due to differences in configuration or performance. It may include one or more Central Processing Units (CPUs) 601 and one or more memories 602. The one or more memories 602 store at least one computer program, which is loaded and executed by the one or more processors 601 to implement the methods provided in the various method embodiments described above. Of course, the server 600 may also have wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The server 600 may also include other components for implementing device functions, which will not be elaborated upon here.

[0152] In an exemplary embodiment, a computer-readable storage medium is also provided, such as a memory including a computer program that can be executed by a processor to perform the pop-up rendering method within the applet in the above embodiments. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device, etc.

[0153] In an exemplary embodiment, a computer program product or computer program is also provided, which includes program code stored in a computer-readable storage medium. The processor of a computer device reads the program code from the computer-readable storage medium and executes the program code, causing the computer device to execute the pop-up rendering method within the aforementioned applet.

[0154] In some embodiments, the computer program described in this specification may be deployed and executed on a single computer device, or on multiple computer devices located in one location, or on multiple computer devices distributed across multiple locations and interconnected via a communication network. These multiple computer devices distributed across multiple locations and interconnected via a communication network may constitute a blockchain system.

[0155] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0156] The above are merely optional embodiments of this specification and are not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification shall be included within the scope of protection of this specification.

Claims

1. A pop-up rendering method within a mini-program, characterized in that, The mini-program is a mini-program within the target application, and the method includes: After detecting that the mini program has been launched, the interaction between the user and the mini program is obtained; Based on the interaction operation, the native pop-up interface within the mini-program framework of the target application is invoked to render the target pop-up associated with the interaction operation. The native pop-up interface is used to invoke the rendering container natively created by the target application.

2. The method according to claim 1, characterized in that, The step of calling the native pop-up interface within the mini-program framework of the target application to render the target pop-up associated with the interaction operation includes: Based on the user's interaction with the mini-program, determine the pop-up decision-making method that is adapted to the interaction. Based on the pop-up decision method, determine whether a pop-up needs to be displayed and the content of the pop-up to be displayed; If it is determined that a pop-up needs to be displayed, the native pop-up interface within the mini-program framework of the target application is invoked to render the target pop-up associated with the interactive operation, the target pop-up including the pop-up content.

3. The method according to claim 2, characterized in that, The step of determining whether to display a pop-up and the content of the pop-up to be displayed based on the pop-up decision method includes: When the pop-up decision method is the first decision method, the target interface is called to determine whether the pop-up needs to be displayed and the content of the pop-up to be displayed. The target interface is a single interface formed by merging multiple backend interfaces. When the pop-up decision method is the second decision method, the pop-up to be displayed and the pop-up content to be displayed are determined by preset rules. The preset rules refer to the rules for determining the pop-up to be displayed, and the preset rules include the correspondence between interactive operations and pop-up content.

4. The method according to claim 1, characterized in that, The step of calling the native pop-up interface within the mini-program framework of the target application to render the target pop-up associated with the interaction operation includes: Determine whether the target application's mini-program framework meets the preset pop-up conditions; If the pop-up conditions are met, the native pop-up interface within the mini-program framework of the target application is invoked according to the interaction operation to render the target pop-up associated with the interaction operation.

5. The method according to claim 4, characterized in that, When the pop-up conditions are met, the native pop-up interface within the mini-program framework of the target application is invoked according to the interaction operation to render the target pop-up associated with the interaction operation, including: If the pop-up conditions are met, the mini-program framework is configured to be added to the whitelist of the target application, so that the mini-program framework has the permission to call the native pop-up interface. If the whitelist includes the mini-program framework, the native pop-up interface within the mini-program framework of the target application is invoked according to the interaction operation to render the target pop-up associated with the interaction operation.

6. The method according to claim 4, characterized in that, The step of determining whether the mini-program framework of the target application meets the preset pop-up conditions includes: The mini-program framework determines whether the version of the target application's mini-program framework meets preset pop-up conditions during the mini-program's lifecycle.

7. The method according to any one of claims 1 to 6, characterized in that, The native pop-up interface runs in the same code context as the mini-program.

8. The method according to any one of claims 1 to 6, characterized in that, The user interface of the target pop-up layer is developed using the domain-specific language DSL of the applet.

9. A pop-up rendering device within a mini-program, characterized in that, The mini-program is a mini-program within the target application, and the device includes: The acquisition module is used to acquire the interaction operations between the user and the mini program after the mini program is detected to be launched; The rendering module is used to call the native pop-up interface within the mini-program framework of the target application according to the interactive operation, so as to render the target pop-up associated with the interactive operation. The native pop-up interface is used to call the rendering container natively created by the target application.

10. A computer device, characterized in that, The computer device includes one or more processors and one or more memories, wherein at least one computer program is stored in the one or more memories, the computer program being loaded and executed by the one or more processors to implement the method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which is loaded and executed by a processor to implement the method as described in any one of claims 1 to 8.

Images