Map display methods, electronic devices and computer program products
By managing map cache pools and controlling instance states, the memory and performance issues caused by multiple map instances are resolved, enabling efficient reuse of map components and resource optimization, thereby improving the performance and user experience of the AI dialogue system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- KE COM (BEIJING) TECHNOLOGY CO LTD
- Filing Date
- 2026-02-11
- Publication Date
- 2026-06-02
Smart Images

Figure CN122132502A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the technical fields of data processing, and in particular to a map display method, electronic device, and computer program product. Background Technology
[0002] In AI (Artificial Intelligence) dialogue systems, each question response is displayed as an independent "dialogue card" (i.e., a UITableViewCell). When the AI response involves geographic information, multiple map instances are embedded within a single dialogue card to display different locations. Each map instance consumes significant resources during initialization, essentially running multiple "mini-map applications" simultaneously. When multiple map cards exist concurrently, the number of map instances accumulates rapidly, easily causing memory spikes, scrolling stutters, loading delays, and even application crashes, severely impacting performance and user experience. Summary of the Invention
[0003] This disclosure provides a map display method, an electronic device, and a computer program product.
[0004] According to one aspect of this disclosure, a map display method is provided, comprising: responding to a call instruction regarding a map instance, obtaining target business data to be displayed contained in the call instruction; selecting a target map instance in an idle state from a map cache pool, the target map instance being a map component capable of displaying the target business data, the idle state indicating that the corresponding map instance is not added to a visual container; configuring the target map instance to present the target business data; and adding the configured target map instance to a target visual container associated with the target business data, so that a user interface carrying the target visual container displays the target business data. According to one aspect of the technical solution, by reusing idle map instances in the cache, the performance overhead caused by repeated creation is avoided, achieving on-demand loading and efficient reuse of map components, effectively reducing memory consumption and initialization latency.
[0005] In some implementations, prior to responding to a call instruction regarding a map instance, the process includes: setting up a map cache pool for storing map instances; and configuring status information for the map instances stored in the map cache pool, the status information including an idle state and a usage state, the usage state indicating that the corresponding map instance is in a state of being added to a visual container.
[0006] According to one technical solution, by pre-setting a map cache pool and managing the instance status, centralized scheduling and lifecycle control of map instances are achieved, avoiding duplicate creation and resource waste, effectively reducing memory overhead, and improving the reuse efficiency of map components and system response performance.
[0007] In some implementations, after adding the configured target map instance to the target visual container associated with the target business data, the method includes: binding the target container identifier of the target visual container to the target map instance in the map cache pool.
[0008] According to one technical solution, by binding the container identifier of the target visual container to the map instance, the association between the instance and the response information is maintained, supporting container-priority reuse and targeted invocation, thereby improving the accuracy of resource scheduling and response efficiency.
[0009] In some implementations, after adding the configured target map instance to the target visual container associated with the target business data, the process includes: configuring a timestamp for the target map instance in the map cache pool, the timestamp recording the time when the target map instance was last added to the visual container.
[0010] According to one technical solution, by configuring the timestamp of the last time a map instance was added to the visual container, the frequency and order of instance usage can be accurately tracked, providing a basis for the cache reclamation mechanism. When instance resources are scarce, the earliest used instance can be reclaimed first, improving the cache hit rate and system resource utilization efficiency.
[0011] In some implementations, selecting a target map instance that is in an idle state from the map cache pool includes: determining whether there is an idle map instance in the map cache pool; when there is an idle map instance in the map cache pool, determining whether the idle map instance includes a map instance bound to a target container identifier; and selecting the map instance bound to the target container identifier as the target map instance.
[0012] According to one technical solution, by prioritizing the selection of idle map instances that have been bound to target container identifiers, instance-oriented reuse based on context association is achieved, which improves the call hit rate and response speed, while enhancing the continuity and consistency of map display under the same response information.
[0013] In some implementations, after determining whether there are any idle map instances in the map cache pool, the method further includes: when there are no idle map instances in the map cache pool, performing a recycling operation on the map instance with the earliest timestamp in the map cache pool; and using the map instance that has completed the recycling operation as the target map instance.
[0014] According to one technical solution, by reclaiming the instance with the earliest timestamp, it is ensured that usable map instances can still be obtained under resource constraints, realizing the dynamic release and recycling of cache space, effectively avoiding unlimited memory growth, and ensuring system stability and continuous availability of map loading.
[0015] In some implementations, a recycling operation is performed on the map instance corresponding to the earliest timestamp in the map cache pool, including: setting the status information of the map instance corresponding to the earliest timestamp to an idle state; and removing the container identifier of the map instance corresponding to the earliest timestamp, wherein the maximum number of map instances stored in the map cache pool is greater than the number of map instances displayed in parallel in the visible area of the user interface.
[0016] According to one technical solution, by resetting the state of the map instance with the earliest timestamp to idle and clearing its container identifier, the resource release and context unbinding of the instance are realized, so that it can be reallocated and reused. This effectively supports the dynamic recycling mechanism of the cache pool, improves instance utilization and overall system performance.
[0017] In some implementations, after determining whether the map instances in the idle state include map instances bound to a target container identifier, the method further includes: when the map cache pool does not contain map instances bound to the target container identifier, determining whether there are map instances in the map cache pool that are not bound to a container identifier; and using the map instances in the map cache pool that are not bound to a container identifier as the target map instances; or, performing a recycling operation on the map instances in the map cache pool corresponding to the earliest timestamp.
[0018] According to one technical solution, by prioritizing the reuse of map instances that are already bound to the target container, and then choosing unbound instances or reclaiming the earliest used instance when no matching instance is available, a hierarchical resource scheduling strategy is implemented. This not only improves the reuse rate of context-related instances, but also ensures the availability and flexibility of calls, effectively balancing performance and resource utilization.
[0019] In some implementations, after adding the configured target map instance to the target visual container associated with the target business data, the method further includes: monitoring the display status of the user interface; and when the user interface does not display the target visual container, setting the status information of the target map instance to an idle state and removing the target container identifier of the target map instance; or, when the user interface displays the target visual container, generating the invocation instruction.
[0020] According to one technical solution, the binding and unbinding of map instances are dynamically managed by monitoring the user interface display status: when the visual container is invisible, its state is set to idle and the container identifier is cleared, thus releasing resources in a timely manner; when the container is visible, a call command is triggered to ensure on-demand loading. This mechanism achieves precise synchronization between the lifecycle of map instances and the interface state, effectively reducing background resource consumption and improving system response efficiency and memory utilization.
[0021] According to one aspect of this disclosure, another electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, causing the processor to perform the map display method according to any embodiment of this disclosure.
[0022] According to one aspect of this disclosure, yet another readable storage medium is provided, characterized in that the readable storage medium stores executable instructions, which, when executed by a processor, are used to implement the map display method according to any embodiment of this disclosure.
[0023] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the map display method described in any embodiment of this disclosure. Attached Figure Description
[0024] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.
[0025] Figure 1 This is a schematic diagram of the scene shown on the map.
[0026] Figure 2 This is a schematic diagram illustrating an application scenario of the map display method according to an embodiment of the present disclosure.
[0027] Figure 3 This is a flowchart of a map display method according to an embodiment of the present disclosure.
[0028] Figure 4This is a schematic diagram of a map cache pool structure according to an embodiment of the present disclosure.
[0029] Figure 5 This is a flowchart of the process for determining a target map instance according to an embodiment of the present disclosure.
[0030] Figure 6 This is a schematic block diagram of the structure of a map display device according to an embodiment of the present disclosure.
[0031] Figure 7 This is a block diagram illustrating the structure of an electronic device according to one embodiment of the present disclosure. Detailed Implementation
[0032] The present disclosure will now be described in further detail with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.
[0033] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.
[0034] In an AI (Artificial Intelligence) dialogue system, each user question and its AI response are displayed as a separate "dialogue card" (i.e., a UI Table View Cell). When the AI response involves geographic information, multiple maps (such as Baidu / Gaode Maps) need to be embedded within the dialogue card to display different locations. A single dialogue card can contain multiple (e.g., 3) map instances.
[0035] Figure 1 This is a schematic diagram of the scene displayed on the map. For example... Figure 1As shown, when a customer inquires (Q) about the surrounding amenities of Community A, the AI responds (A) with multi-dimensional information, such as "1. Transportation: Comprehensive subway and bus coverage. Multiple subway lines intersect near Community A, allowing access to the city center and surrounding shopping malls; there are also multiple bus stops with comprehensive route coverage, saving commuters considerable time. Below is a commuter map for a clear understanding of subway and bus distribution," embedding subway line n, partial routes of subway line m, the relative location of subway station X where the two lines intersect, and the relative location of bus stop Y. Additionally, the AI's response includes "2. Commerce: Coverage of multiple shopping malls. The following map shows the distribution of these malls and supermarkets," embedding the corresponding maps. Although these maps are not visible on the current page, they are loaded and running by the system, consuming memory and computing resources comparable to the visible commuter map. Similarly, this AI response card may also include other supporting map components such as medical and educational resources—even if these maps are not displayed in the current viewport, they are still instantiated as part of the card, continuously consuming system resources.
[0036] If the page renders two or more such AI dialogue cards at the same time, and each card integrates multiple map components, the overall memory usage and resource consumption will increase exponentially, putting significant pressure on system performance.
[0037] Therefore, this disclosure proposes a map display method.
[0038] Figure 2 This is a schematic diagram illustrating an application scenario of the map display method according to embodiments of this disclosure. For example... Figure 2 As shown, this application scenario may include a server 100 and a terminal device 200. The server 100 and the terminal device 200 can interact with each other via a network connection. The server 100 can be a cloud server or a physical server, and the terminal device 200 can be a smart device such as a computer, mobile phone, or tablet. The server 100 can receive requests from the terminal device 200 and run the map display method disclosed herein.
[0039] Figure 3 This is a schematic diagram illustrating an application scenario of the map display method according to embodiments of this disclosure. For example... Figure 3As shown, the map display method M300 of this disclosure proposes a map cache pool. When a map call command is received, a map instance that has been created but is in an idle state is selected from the map cache pool, configured, and added to the target visual container, instead of creating a new map instance. This method achieves efficient reuse of map instances and effectively reduces the performance overhead caused by map initialization. At the same time, the map cache pool can control the upper limit of the number of running map instances, avoiding excessive memory consumption and system resource pressure caused by running too many map instances at the same time. Step S310: In response to the call command about the map instance, the target business data to be displayed contained in the call command is obtained.
[0040] A map instance is a map component with independent operational capabilities. It can load map tiles, render geographic features, and respond to user interactions (such as dragging, zooming, and clicking). It also supports automatically positioning the view to the target business data after it has been determined. Furthermore, each map instance maintains its own state information (such as center coordinates, zoom level, and label layers), which can be independently configured and controlled, ensuring that multiple instances do not interfere with each other. Before being configured with target business data, a map instance is a base map instance, and the displayed center point and zoom level are default values, which are not restricted here.
[0041] The triggering of the invocation command is controlled by the display state of the visual container. When a visual container is displayed in the user interface, a corresponding invocation command is automatically generated to drive the on-demand loading of map content. The invocation command includes a container identifier, the target business data to be displayed, the target zoom level (such as street level, region level, or city level), and optional map style parameters. Among them, the target business data serves as the central anchor point of the map instance, and the zoom level determines the granularity of the displayed details, ensuring that the map accurately presents key information with an appropriate field of view. By binding map rendering with container visibility, lazy loading and dynamic configuration of map instances are achieved, effectively avoiding the problem of invisible containers occupying resources in advance and improving the overall system performance.
[0042] Target business data can be points of interest, navigation routes including points of interest and points of interest, areas of interest, etc., without any restrictions. Target business data refers to geographical entities that need to be visualized on a map, such as the specific locations of a residential area, shopping mall, or supermarket; navigation routes from location A to location B; or the scope of a business district.
[0043] Depending on the specific scenario requirements, the target business data can be single or multiple. When multiple target business data exist, the center point (such as the centroid or geometric center) of the geographic coordinates of these business data is calculated and used as the display center of the target map instance, ensuring that all target business data are within the visible range.
[0044] If the target business data is a point of interest (PO), the map instance can automatically center its view on that PO after it is determined, achieving dynamic display centered on the PO. If the target business data is a navigation route containing an origin and destination of interest, the map instance can determine the optimal view range to fully display the navigation route and highlight key nodes along the route. If the target business data is a target area, the map instance can highlight the area boundaries, thus providing a richer, more context-aware interactive map experience.
[0045] Step S320: Select an idle target map instance from the map cache pool.
[0046] The map cache pool is a memory unit used for centralized management and storage of created map instances. Its core function is to enable the preloading and efficient reuse of map instances. The map cache pool has a defined storage capacity limit, which is determined by system resources (such as memory size, processor power, and browser process quotas) and performance strategies. For example, the cache pool may be set to hold a maximum of 5 map instances. When the capacity limit is reached, a mechanism to reclaim used instances will be triggered, releasing the oldest used map instance for reuse. This capacity constraint mechanism effectively prevents the uncontrolled creation of map instances. It should be noted that the map cache pool is only used to store map instances; all other system data is stored in other memory units.
[0047] All map instances used by visual containers are derived from initialized and idle instances in the map cache pool, avoiding the repeated execution of time-consuming map initialization operations. When a visual container slides out of the user interface's visible area or is destroyed, its bound map instance will be unbound, its state reset to idle, and it will wait for subsequent calls to reuse it.
[0048] By setting the upper limit of the map cache pool capacity, the number of map instances running at the same time can be precisely controlled, which fundamentally limits the peak memory usage and rendering thread load, significantly alleviates the resource overload problem caused by multiple map instances using the map concurrently, and realizes controllable scheduling and performance optimization of map resources.
[0049] The idle state indicates that the corresponding map instance has not been added to any visual container, meaning it is in a reusable, standby state. Map instance state information is divided into two types: idle state and usage state. The usage state indicates that the instance has been added to a visual container and is participating in rendering or responding to user interactions. Of course, map instances in the idle state also include two cases: one is that it is bound to a corresponding visual container, but has not been added to that visual container for rendering to the user interface, and is currently invisible, but can be reused by the bound visual container at any time; the other is that it is not bound to any visual container and can be called by any visual container at any time.
[0050] It's important to note that each map instance can only be exclusively used by one view container at a time; cross-container sharing is not supported. Therefore, when a map instance is in use, it should be excluded from the candidate pool when processing new invocation commands to avoid duplicate allocation. When a map instance is idle, it's also necessary to determine if it's bound to another view container. If no idle map instance is available without a bound view container, the map instance bound to another view container must be unbound before it can be invoked. When selecting a target map instance, its current state information must be considered to ensure that selection is only made from idle instances, guaranteeing the correctness and consistency of resource scheduling.
[0051] Step S330: Configure the target map instance to display target business data.
[0052] The target map instance is a map instance in the map cache pool that can satisfy the call command. It can be an idle map instance not bound to any visual container, or an idle map instance that happens to be bound to that visual container. It's important to note that when a map instance is bound to a visual container, a container identifier is configured for that map instance in the map cache pool. This container identifier is the same as the container identifier of the bound visual container. Each visual container has a unique and independent container identifier used to distinguish it from other containers.
[0053] The map instance features zoom, pan, and center positioning capabilities. After acquiring the target business data, its center (or the centers of multiple target business data points) is set as the center anchor point of the map instance. The instance is then initialized and displayed according to the preset zoom level (such as street level, region level, or city level) in the calling command, thereby achieving precise focusing on the target area. By centering and configuring the map instance's hierarchy, it can accurately present the target business data and its surrounding geographic information, meeting the visualization requirements of the response content.
[0054] Step S340: Add the configured target map instance to the target visual container associated with the target business data.
[0055] A target map instance can only trigger the rendering process and be displayed on the user interface after it is added to the target visual container. The visual container is the visible area of the user interface (such as a dialog card) used to hold and display content, responsible for managing the layout, display state, and user interaction of its internal information. Before being added to the visual container, the map instance exists in the map cache pool but does not participate in page layout, consume rendering resources, or respond to user actions. Only when it is explicitly inserted into the target visual container will it be bound to the actual DOM (Document Object Model) node, triggering the map engine's rendering pipeline (such as loading tiles, drawing layers, and initializing event listeners), ultimately achieving the effect of displaying the target business data on the user interface.
[0056] Furthermore, the display state of the visual container (such as whether it is within the visible area or hidden) directly affects the visibility and behavior of map instances. By linking the rendering of map instances with the lifecycle of the visual container, on-demand loading and resource release can be achieved, preventing invisible content from continuously consuming processor, memory, and network resources, thereby improving overall performance and user experience.
[0057] The following is a more detailed description of the entire process of displaying target business data.
[0058] During the dialogue between the user and the AI, the AI analyzes the user's questions to provide responses that meet the user's needs. If the response includes a requirement to display target business data, the AI will need to invoke and display map instances when presenting the response to the user, which is where this method comes in.
[0059] Before displaying the target business data, a map cache pool needs to be pre-built. The map cache pool is a dedicated memory unit for storing initialized map instances. All map instances corresponding to the business data displayed in the user interface are existing map instances retrieved from this map cache pool. Through the map instance preloading and on-demand allocation mechanism, the performance overhead caused by repeatedly creating map instances each time target business data is displayed is effectively avoided, significantly reducing resource consumption.
[0060] Meanwhile, the maximum capacity of the map cache pool imposes a hard constraint on the number of map instances that can run simultaneously in the user interface, preventing excessive memory consumption due to concurrent map rendering by multiple dialog cards. To ensure a good user experience, the maximum number of map instances stored in the map cache pool is greater than the number of map instances that can be displayed in parallel within the visible area of the user interface. In other words, the capacity of the map cache pool should be set to be greater than the maximum number of map instances that can be displayed simultaneously within the visible area of the user interface, thus satisfying display requirements while avoiding resource redundancy and achieving a balance between performance and efficiency.
[0061] Figure 4 This is a schematic diagram of a map cache pool structure according to an embodiment of this disclosure. For example... Figure 4 As shown, the map cache pool records map instance 1, map instance 2 to map instance T, where T is the upper limit of the number of map instances that can be stored in the map cache pool. The value of T can be 5, and of course, other reasonable values are also within the protection scope of this disclosure.
[0062] During the initialization phase of the map cache pool, a small number of map instances (e.g., two) are pre-loaded and stored. As the demand for map instances increases during user interaction, new map instances are dynamically loaded into the map cache pool until a set upper limit is reached. Once the map cache pool reaches its capacity limit, unused map instances are reclaimed, returning them to an idle state, thus achieving cyclical reuse of existing map instances. This mechanism ensures efficient resource utilization while avoiding unnecessary duplicate creation and destruction operations.
[0063] Specifically, after adding the configured target map instance to the target visual container associated with the target business data, the method further includes: monitoring the display status of the user interface; setting the status information of the target map instance to an idle state and removing the target container identifier of the target map instance when the user interface does not display the target visual container; or, generating a calling instruction when the user interface displays the target visual container.
[0064] The status information of a map instance is used to identify its current running status, including "Used Status," "Waiting Status," and "Idle Status." The Used Status indicates that the instance has been added to a visual container and is participating in rendering or display; the Waiting Status indicates that the instance has been added to a visual container but is not participating in display; and the Idle Status indicates that the instance is not bound to any visual container and can be reused.
[0065] In some implementations, when the target visual container is not displayed in the visible area, it is determined whether the target visual container is configured with a refresh task; when the target visual container is not displayed in the visible area and is not configured with a refresh task, the target map instance in the target visual container is set to an idle state, and the target container identifier of the target map instance is removed; if the target visual container is not displayed in the visible area and is configured with a refresh task, the target map instance in the target visual container is set to a waiting state. The target map instance in the use state or the waiting state is associated with a container identifier to identify the target visual container it is bound to.
[0066] Furthermore, the execution status of the refresh task is monitored. When the refresh task is completed, the target map instance bound to the target visual container is invoked and displayed in the visible area.
[0067] In this implementation, a refresh task refers to an asynchronous processing task configured when the target visual container is not displayed in the visible area, but the content of the target map instance still needs to be updated (e.g., reloading triggered by data changes or user operations). To ensure user experience and resource efficiency, target map instances not displayed in the visible area are managed differently depending on whether such refresh tasks exist: if there are no refresh tasks, the target map instance is immediately released to an idle state; if there are, it is placed in a waiting state while retaining its binding relationship with the target visual container.
[0068] Based on this, when the target visual container reappears in the visible area and the refresh task is completed, the map instance already bound to that container identifier can be directly reused without reallocation or initialization. This not only significantly improves the response speed of map display, but more importantly, it effectively avoids problems such as map loss, flickering, or inconsistent states caused by the incorrect recycling or repeated creation of instances in streaming refresh scenarios, thereby ensuring the stability and continuity of interaction.
[0069] In addition, a timestamp is maintained for each map instance, recording the time when it was last added to the visual container, usually accurate to the minute. When all map instances in the map cache pool are in use and a new call instruction arrives, a recycling mechanism is triggered. The instance with the earliest timestamp (i.e., least recently used) is selected from the currently used instances and recycled, removing it from the original container and resetting it to an idle state for reuse by new requests.
[0070] Figure 5 This is a flowchart illustrating the process of determining a target map instance according to an embodiment of this disclosure. The following is in conjunction with... Figure 5 The process of determining the target map instance is explained.
[0071] In step 501, the calling instruction is read and the target visual container corresponding to the calling instruction is determined.
[0072] When a user swipes to bring a visual container into the visible area of the user interface, and the response information corresponding to that container requires the display of target business data, that visual container is identified as the target visual container associated with the target business data. This determination process is typically triggered by the front-end's view monitoring mechanism, which monitors the intersection state of each visual container with the browser viewport in real time. Once a container is detected to be within the visible range, its content rendering process is immediately activated. This mechanism avoids the performance waste caused by traditional full preloading and enables lazy loading and on-demand activation of heavy components such as maps.
[0073] Subsequently, a calling instruction is generated based on the current display state of the target visual container. This instruction is a structured data object that encapsulates the key parameters required for map rendering. The container identifier uniquely identifies the target visual container, ensuring that the map instance can be accurately bound back to the correct container location during subsequent scheduling. The target business data includes its geographic coordinates (latitude and longitude or a range of latitude and longitude), name, and type (e.g., residential area, shopping mall, subway station), serving as the basis for map center positioning. Furthermore, the calling instruction can carry more granular control parameters: for example, zoom level, used to set the map's display granularity—city level for city overview, street level for street details; map style, supporting different visual styles such as standard blue, dark mode, and satellite imagery, adapting to nighttime browsing or specific scenario requirements; and even layer on / off configurations, such as whether to display traffic conditions, target business data labels, walking paths, etc., achieving a highly customized display effect.
[0074] This call instruction, serving as the configuration blueprint for initializing the map instance, is passed to the map management module, driving a series of subsequent operations such as selecting an instance from the map cache pool, configuring the view, and binding the container. By encapsulating display requirements into structured instructions, the system decouples map rendering logic from interface display, improving maintainability and scalability between modules. It also provides a flexible interface foundation for supporting more complex geographic information interactions in the future (such as dynamic heatmaps and multi-target business data aggregation).
[0075] In step 502, it is determined whether there is an idle map instance.
[0076] An idle map instance refers to a map instance that is in an idle state, meaning it is not currently bound to or added to any view container and can be scheduled for reuse. As mentioned earlier, each map instance can only be exclusively used by one view container at a time and does not support cross-container sharing. Therefore, only map instances in an idle state are eligible to be bound and added to a target view container.
[0077] When an idle map instance exists in the map cache pool, step 503 is executed to determine whether the corresponding map instance is bound to a target container identifier, i.e., whether the idle instance has been pre-associated with the container identifier of the target visual container. If an idle instance has previously been marked as bound to the current target visual container, it indicates that it has priority access to that container, and this instance will be selected first for configuration and rendering. That is, step 504 is executed, using the map instance bound to the target container identifier and in an idle state as the target map instance to improve response speed and user experience. This mechanism achieves targeted reservation and efficient matching of resources, optimizing the scheduling efficiency of map instances while ensuring concurrency control.
[0078] When there are no idle map instances in the map cache pool, it indicates that all created map instances are in "use," meaning they have been bound to their respective visual containers and are participating in rendering or interaction. If a new call arrives at this time, an available instance cannot be directly allocated; resources must be released through a reclamation mechanism. Proceed to step 505 to initiate the instance reclamation process. To ensure the rationality of reclamation and the continuity of user experience, an LRU (Least Recently Used) strategy is adopted, selecting the map instance with the earliest timestamp as the reclamation target. The timestamp records the specific time (accurate to minutes or seconds) when each map instance was last added to the visual container, accurately reflecting its real-time usage frequency and user attention.
[0079] Setting the map instance corresponding to the earliest timestamp to an idle state means that the instance changes from being in use to being reusable. Its binding relationship with the original visual container is released, and it no longer participates in the original container's rendering process. Simultaneously, the system removes the container identifier associated with this instance, detaching it from its original context and preventing container misalignment or data confusion during subsequent calls. This unbinding operation is crucial for resource reuse, ensuring that the instance can be reassigned to new call requests without being affected by historical states.
[0080] It's worth noting that while reclaimed instances are no longer displayed, their internal state (such as map engine context, event listeners, and some cached tiles) remains in memory, only logically released. This "lightweight reclamation" method avoids the high overhead of complete destruction and reconstruction, significantly improving subsequent reuse speed. This mechanism effectively prevents memory overflow caused by the unlimited growth of map instances, while ensuring system stability and responsiveness under high load scenarios.
[0081] Further, step 506 is executed, using the map instance that has completed the recycling operation as the target map instance to continue the subsequent configuration process. Although this instance previously served other visual containers, after state reset and container identifier clearing, it has been transformed into a clean and reusable resource. It can be rebound to the target visual container corresponding to the current invocation command, and center positioning, scaling level settings, and layer rendering can be performed based on the new target business data to achieve seamless reuse. This mechanism ensures that new map display requests can still be continuously responded to even when the map cache pool is full, avoiding loading failures or interface lag due to resource exhaustion, significantly improving the robustness of the system and the continuity of the user experience.
[0082] When there are idle map instances in the map cache pool, but none of them are bound to the current target visual container, the process proceeds to step 507 to further determine if there are any general idle instances that are not bound to any container identifier. These instances are not associated with any specific visual container and belong to the global shared resource pool, making them suitable for any new map call request. If such instances exist, one will be selected as the target map instance (i.e., step 508) to avoid immediately triggering a high-overhead recycling mechanism. This hierarchical scheduling strategy reflects a priority design for resource utilization: dedicated pre-bound instances are used first, followed by general idle instances, and only then is the recycling process initiated, minimizing system disruption.
[0083] Conversely, if there are neither instances bound to the target container nor unbound general-purpose idle instances (i.e., all idle map instances are bound to other visual containers but not used), then the current resources are considered extremely scarce, and step 505 must be executed to initiate the LRU reclamation mechanism, selecting the map instance with the earliest timestamp for forced release. Then, step 506 is executed, using it as the target map instance. This design ensures that the system always has the capacity to supply map instances under extremely high concurrency or multi-task parallel scenarios, achieving dynamic resource balancing and efficient flow. The entire scheduling logic is clear, closed-loop, and balances performance, stability, and scalability.
[0084] Finally, the selected target map instance is configured to accurately represent the target business data. This configuration process includes setting the map's center coordinates to the geographic latitude and longitude of the target business data's center, specifying the zoom level (such as street level, regional level, or city level) in the application's invocation command, loading the appropriate map style (such as standard map, satellite imagery, or night mode), and adding necessary annotation layers (such as icons for the target business data, information windows, and path markers). Furthermore, specific functional modules can be dynamically enabled based on the context of the response information, such as traffic heatmaps, aggregated display of surrounding facilities, or 3D building model rendering, to enhance the richness of information presentation and the user's interactive experience.
[0085] After configuration, add the map instance to the target visual container. Once added successfully, the browser's rendering engine will trigger the map instance display process, loading map tiles, drawing layers, and binding user interaction events (such as dragging, zooming, and clicking), ultimately presenting a complete geographic view centered on the target business data in the user interface. Users can not only see the precise location of the target business data but also intuitively understand its surrounding environment, such as nearby subway stations, shopping malls, schools, hospitals, and other supporting facilities, achieving spatialized and visual representation of information.
[0086] It's worth noting that the map instance is not a static snapshot, but a dynamic component with full interactive capabilities. Users can zoom, pan, and click to view detailed information, and the map instance will respond and update its view state in real time. Furthermore, the instance's lifecycle is synchronized with the visual container: when the container slides out of the visible area or is destroyed, the map instance will be unbound and recycled to the map cache pool to continue serving subsequent requests. This "load on demand, reclaim after use" mechanism ensures a smooth user experience while minimizing memory usage and performance overhead, making it suitable for complex AI interaction scenarios involving multiple cards and maps displayed in parallel.
[0087] At this point, the container identifier of the target visual container is bound to the target map instance in the map cache pool, establishing a logical association between the two. This container identifier is unique and traceable, used to mark the specific context of the map instance's current service, such as an AI dialogue card or information panel. Through this binding mechanism, a persistent association between the map instance and specific response content is achieved, providing a priority matching basis for subsequent possible reuse requests. For example, when the user swipes back to the visual container, the previously configured map instance can be quickly located and reused by comparing the container identifier, avoiding repeated initialization and data loading, and significantly improving response speed.
[0088] Simultaneously, a timestamp is configured for the target map instance in the map cache pool to record the precise time it was added to the visual container. This timestamp serves as an important basis for instance usage frequency and timeliness, participating in subsequent resource reclamation decisions. When the map cache pool is full and no idle instances are available, the earliest used instance will be selected for reclamation based on its timestamp, ensuring that resource scheduling conforms to the "least recently used" principle, thereby improving cache hit rate and overall operating efficiency.
[0089] Furthermore, updating the map instance's status information from "idle" to "used" signifies that it has officially entered the active operation phase. Map instances in the used state will participate in page rendering, event listening, and user interaction, and their memory resources will be continuously occupied until the task is completed.
[0090] When the user continues to swipe the interface, causing the target visual container to move out of the visible area, the system detects that the container is no longer displayed and triggers a resource release process: the state information of the map instance is reset to "idle state," indicating that it has been removed from the rendering process and can be reused by subsequent requests. Although the instance remains in memory, it no longer consumes processor rendering resources or responds to user operations. This mechanism enables "on-demand activation and non-displayable / non-displayable" of map components, effectively reducing background runtime overhead and preventing performance degradation caused by multiple invisible map instances residing in memory simultaneously. It is particularly suitable for resource optimization and management in scenarios with long lists and multi-card scrolling.
[0091] This scheduling mechanism constructs a complete map instance lifecycle management system through a three-level strategy of "prioritizing pre-binding → selecting general idle resources → finally reclaiming the oldest ones." It not only achieves high-performance reuse but also ensures the reliability and scalability of resource scheduling through state synchronization, container binding, and timestamp tracking, making it suitable for complex front-end scenarios with multiple cards, multiple maps, and high concurrency.
[0092] This solution establishes a map cache pool with state management to enable the preloading, on-demand reuse, and recycling of map instances. This avoids the performance overhead caused by repeatedly creating and destroying map instances in multi-card scenarios, effectively reducing memory usage and initialization latency. At the same time, it controls the number of concurrent instances through capacity constraints and recycling mechanisms, thereby improving system resource utilization and interface response speed.
[0093] Figure 6 This is a schematic block diagram of the structure of a map display device according to an embodiment of the present disclosure. Figure 6 As shown, this disclosure proposes a map display device 600, including: an instruction response module 610, used to respond to a call instruction regarding a map instance and obtain the target business data to be displayed contained in the call instruction; an instance selection module 620, used to select a target map instance in an idle state from a map cache pool, the target map instance being a map component capable of displaying the target business data, the idle state indicating that the corresponding map instance is not added to the visual container; a configuration module 630, used to configure the target map instance to present the target business data; and a display module 640, used to add the configured target map instance to the target visual container associated with the target business data, so that the user interface carrying the target visual container displays the target business data. The map display device 600 of this disclosure can be in the form of computer software, and the various modules of the map display device 600 can be in the form of computer software modules.
[0094] The various modules of the map display device 600 disclosed herein are set up to implement the various steps of the map display method. Their execution principles and steps can be referred to the above text and will not be repeated here.
[0095] Figure 7 This is a schematic block diagram of an electronic device according to one embodiment of the present disclosure. Figure 7 As shown, this disclosure also provides an electronic device 1000, including: a processor 1200 and a memory 1300, the memory 1300 storing execution instructions; the processor 1200 executes the execution instructions stored in the memory 1300, causing the processor 1200 to execute a map display method.
[0096] The hardware architecture of the electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnect buses and bridges, depending on the specific application of the hardware and overall design constraints. Bus 1100 connects various circuits, including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400, such as peripheral devices, voltage regulators, power management circuits, external antennas, etc.
[0097] Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, only one connection line is used in this diagram, but this does not imply that there is only one bus or only one type of bus.
[0098] This disclosure also provides a readable storage medium storing a computer program that, when executed by a processor, is used to implement the methods described above. A "readable storage medium" can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of a readable storage medium include: an electrical connection with one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.
[0099] This disclosure also provides a computer program product, the methods of which can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, all or part of the processes or functions of this disclosure are performed.
[0100] Computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any available medium capable of access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or it can include both volatile and non-volatile types of storage media.
[0101] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, electronic devices, readable storage media, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0102] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0103] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0104] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0105] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., refer to specific features, structures, or characteristics described in connection with that embodiment / mode or example, which are included in at least one embodiment / mode or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.
[0106] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0107] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.
Claims
1. A map display method, characterized in that, include: In response to a call command regarding a map instance, obtain the target business data to be displayed contained in the call command; Select an idle target map instance from the map cache pool. The target map instance is a map component that can display the target business data. The idle state indicates that the corresponding map instance has not been added to the visual container. Configure the target map instance to present the target business data; as well as The configured target map instance is added to the target visual container associated with the target business data, so that the user interface carrying the target visual container displays the target business data.
2. The map display method according to claim 1, characterized in that, Before responding to a call instruction regarding a map instance, the following is included: Configure the map cache pool for storing map instances; and Configure status information for map instances stored in the map cache pool. The status information includes the idle status and the usage status. The usage status indicates that the corresponding map instance is in the state of being added to the visual container.
3. The map display method according to claim 1, characterized in that, After adding the configured target map instance to the target visual container associated with the target business data, the process includes: In the map cache pool, the target container identifier of the target visual container is bound to the target map instance.
4. The map display method according to claim 1, characterized in that, Adding the configured target map instance to the target visual container associated with the target business data includes: In the map cache pool, a timestamp is configured for the target map instance, which records the time when the target map instance was last added to the visual container.
5. The map display method according to claim 1, characterized in that, Select idle target map instances from the map cache pool, including: Determine whether there are any idle map instances in the map cache pool; When there are idle map instances in the map cache pool, determine whether the idle map instances include a map instance bound to a target container identifier; and The map instance that is bound to the target container identifier is used as the target map instance.
6. The map display method according to claim 5, characterized in that, After determining whether there are any idle map instances in the map cache pool, the process further includes: When there are no idle map instances in the map cache pool, a recycling operation is performed on the map instance with the earliest timestamp in the map cache pool; and The map instance that has completed the recycling operation will be used as the target map instance.
7. The map display method according to claim 6, characterized in that, Perform a recycling operation on the map instance with the earliest timestamp in the map cache pool, including: Set the status information of the map instance corresponding to the earliest timestamp to idle; and Remove the container identifier of the map instance corresponding to the earliest timestamp, wherein the maximum number of map instances stored in the map cache pool is greater than the number of map instances displayed in parallel in the visible area of the user interface.
8. The map display method according to claim 5, characterized in that, After determining whether the map instances in the idle state contain map instances bound to a target container identifier, the process further includes: When the map cache pool does not contain a map instance bound to the target container identifier, determine whether there is a map instance in the map cache pool that is not bound to a container identifier; and Use the map instance in the map cache pool that is not bound to a container identifier as the target map instance; or, perform a recycling operation on the map instance in the map cache pool that corresponds to the earliest timestamp.
9. An electronic device, characterized in that, include: The memory stores execution instructions; as well as A processor that executes execution instructions stored in the memory, causing the processor to perform the map display method according to any one of claims 1 to 8.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the map display method according to any one of claims 1 to 8.