ArcGIS graphic engine acceleration and interaction method and system suitable for mobile terminal

Abstract

The invention discloses an ArcGIS graphic engine acceleration and interaction method and system suitable for a mobile terminal, and belongs to the technical field of mobile geographic information systems. The system comprises a data processing subsystem, a graphic rendering subsystem, an interactive response subsystem and a data synchronous updating subsystem. The method comprises the following steps: in a preloading stage, performing layered thinning and caching on geographic data; in the concurrent rendering stage, graph drawing is conducted through a dynamic multi-thread model and GPU acceleration, and the anti-aliasing level is dynamically adjusted based on the equipment performance; in the interactive event processing stage, response is optimized through a viewport position prediction model and a double-buffering technology; and in a data dynamic updating stage, incremental data synchronization is carried out. The technical problems of rendering performance bottleneck, interaction response lag and high system resource consumption of the ArcGIS on the mobile terminal are solved, and the map rendering efficiency, the interaction fluency and the system resource utilization rate are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of geographic information system technology, and more specifically to an ArcGIS graphics engine acceleration and interaction method and system suitable for mobile devices. Background Technology

[0002] ArcGIS, as a mature geographic information system platform, possesses powerful map processing and rendering capabilities on desktop computers. However, it faces significant challenges when applied to mobile devices where computing resources, storage space, and battery capacity are limited. Existing technologies mainly suffer from the following shortcomings: 1. Rendering performance bottleneck: When mobile terminals process large-scale, multi-layered geographic data, rendering delays, frame drops, or even application crashes are likely to occur.

[0003] 2. Delayed interactive response: User zooming, dragging, and other operations cannot receive real-time feedback, making it difficult to meet the high real-time requirements of emergency command, on-site investigation, and other business operations.

[0004] 3. High system resource consumption: Traditional ArcGIS mobile applications often excessively consume CPU, GPU and memory resources, causing the device to overheat and consume power too quickly, affecting user experience and the normal operation of other device functions.

[0005] Traditional solutions lack in-depth optimization for mobile hardware characteristics, such as efficient and adaptive mechanisms for data loading, thread scheduling, graphical interface calls, and interactive event handling. Therefore, there is an urgent need for a technical solution that can fully leverage the performance of mobile terminal hardware and significantly improve the ArcGIS application experience. Summary of the Invention

[0006] To achieve the above objectives, the present invention provides the following technical solution: A method for accelerating and enhancing the interaction of the ArcGIS graphics engine on mobile devices includes the following steps: S1. Preloading stage: Geographic data is preprocessed according to layers or uses, vector graphics are thinned, tiles are partitioned, and a multi-level cache structure is generated. S2. Concurrent Rendering Stage: The main thread handles interactive commands, while child threads are responsible for drawing partitioned layers. Dynamic multi-threaded rendering control is used, and the formula for optimizing the number of threads is as follows: in The number of CPU cores is used to constrain the maximum number of threads to 4. The actual number of threads is 75% of the number of CPU cores and then rounded up. S3. Interactive Event Handling Phase: Capture user gesture events, match registration operation behaviors, dynamically adjust the map view state based on gestures, quickly provide new content feedback, and use the viewport position prediction model formula to predict the view state. The prediction formula is as follows: in Based on the current position, velocity (vx, vy) and time difference ( Predict the viewport position after a gesture swipe. FrictionFactor is the coefficient of friction; the higher the speed, the lower the coefficient of friction, and the faster the deceleration. S4. A dual-buffering strategy is adopted in the rendering process to avoid frequent redrawing from interfering with user operations. The buffer priority formula is as follows: Where distance is the distance from the layer to the viewport, viewportSize is the diagonal length of the viewport, spatial proximity has a weight of 70%, and temporal locality has a weight of 30%. Simultaneously, memory is reclaimed, and the formula for calculating the memory reclamation ratio is as follows: Where pressureLevel is the memory pressure level (1-10), and k is the system tuning coefficient. A logarithmic function is used to gradually increase the recovery ratio as the pressure increases, so as to avoid overly aggressive memory recovery. S5. Data Dynamic Update Phase: The background periodically or proactively triggers data source checks. After detecting changes, only the data with differences is synchronized, and the updated content synchronously triggers map refresh.

[0007] Furthermore, step S2 also includes dynamically adjusting the anti-aliasing level based on device performance. The formula for calculating the dynamic anti-aliasing level is as follows: The anti-aliasing level is positively correlated with the GPU frequency. A base value is calculated based on the GPU frequency, and then limited to an effective range of 1-4 to balance rendering quality and GPU load. Then, the tile clarity is selected as needed to dynamically adapt to DPI and device screen parameters.

[0008] Furthermore, the multi-level cache structure in step S1 is local database - memory LRU cache - disk cold data.

[0009] Furthermore, in step S2, graphics rendering uniformly uses the GPU channel and is called through the OpenGL or Vulkan interface.

[0010] An ArcGIS graphics engine acceleration and interaction system suitable for mobile devices is provided. The system applies the aforementioned ArcGIS graphics engine acceleration and interaction method suitable for mobile devices. The system includes a data processing subsystem, a graphics rendering subsystem, an interactive response subsystem, and a data synchronization and update subsystem. The data processing subsystem performs layered thinning, geometric simplification, and cache priority management on massive geographic data, automatically classifying it according to data type, such as vector, raster, and service stream, and storing it in a local database cache. The graphics rendering subsystem separates the main UI thread from graphics drawing tasks using a multi-threaded architecture, utilizing GPU parallel pipelines to perform base map rendering, layer symbolization, and dynamic annotation, automatically adjusting resolution, anti-aliasing level, and resource loading strategy based on device hardware capabilities. The interaction response subsystem introduces an event-driven model, binding touch gestures to map function actions. The data synchronization and update subsystem monitors remote service version changes, triggers incremental data fetching, asynchronously updates cached content, and dynamically refreshes the visible map area. Compared with the prior art, the beneficial effects of the present invention are mainly reflected in: 1. Improved Rendering Smoothness: By building a high-performance rendering engine specifically for mobile devices and deeply optimizing data loading, thread scheduling, and graphics interface calls, this invention completely solves the rendering bottleneck of traditional ArcGIS mobile applications when processing large-scale, multi-layer geographic data. After implementation, the technical solution enables smooth rendering of complex geographic data, effectively eliminating rendering latency and frame drops, greatly reducing the risk of application crashes, and providing users with a stable and continuous map visualization experience.

[0011] 2. Ensuring Real-Time Response to Interactive Operations: Addressing the issue of delayed responses to user actions such as zooming and dragging, this invention optimizes the entire processing chain from interactive event capture to graphical interface updates. By establishing an efficient and adaptive interactive event handling mechanism, it ensures that user operations receive immediate and smooth visual feedback. This improvement fully meets the stringent real-time requirements of business scenarios such as emergency command and on-site investigation, significantly enhancing the interactive efficiency and user experience of mobile ArcGIS applications.

[0012] 3. Achieving Intelligent and Efficient Utilization of System Resources: This invention introduces resource scheduling and power consumption control strategies to achieve intelligent and refined management of key resources such as the mobile terminal's CPU, GPU, and memory. The technical solution effectively suppresses the problem of excessive resource consumption in traditional applications, significantly reduces device power consumption and heat generation, and extends battery life. This not only improves the user experience of the ArcGIS application itself but also ensures the normal operation of other device functions, achieving a balance in overall system performance. Attached Figure Description

[0013] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0014] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments, but the implementation of the present invention is not limited thereto. These embodiments are carried out based on the technical solution of the present invention, but the scope of protection of the present invention is not limited to the following embodiments.

[0015] Example 1 The flowchart of the method of the present invention is shown below. Figure 1 As shown. Taking the Android platform as an example, on the Android platform, we developed based on ArcGIS Runtime SDK for Android 100.12 and above, making full use of its modern APIs and hardware acceleration capabilities.

[0016] 1. Specific implementation of the data processing subsystem The core task of this subsystem is to implement data preprocessing and intelligent caching. Its specific workflow is as follows: When a user loads a map service, such as a WMS service or a local GeoJSON file, the system first starts a background asynchronous task, such as using AsyncTask or JobIntentService. In this task, vector data, such as administrative boundaries and pipeline networks, undergoes geometric thinning using the Douglas-Peucker algorithm, removing redundant nodes based on the current view scale to significantly reduce the data volume. For raster data, it is resampled according to the device's screen DPI to generate adapted multi-level tiles.

[0017] The preprocessed data is stored in a multi-level cache. First, metadata and frequently accessed hot data are stored in an in-memory cache (LRU cache). Second, all data is persisted to a local SQLite-based database as a disk cache. Cache management is the core of this intelligent system.

[0018] When the system needs to release cache space, it calculates the priority of each layer or tile data according to the following formula: Here, `distance` is calculated quickly using spatial indexes, such as R-Tree, to determine the distance between the data bounding box and the current viewport center point. `lastAccessTime` is the timestamp of the last time the data was accessed. The system prioritizes releasing data with lower priority.

[0019] When the system detects an increase in memory pressure through ActivityManager.getMemoryInfo, it dynamically calculates the reclaim ratio based on the memory pressure level (pressureLevel, 1-10): reclaimRatio = k * ln(1 + pressureLevel) Where k is an empirical coefficient, set to 0.15 by default. This logarithmic model ensures gentle reclamation in the early stages of memory pressure, and stronger reclamation when the pressure is high, avoiding performance fluctuations caused by frequent aggressive reclamation.

[0020] 2. Specific implementation of the graphics rendering subsystem This subsystem is responsible for efficiently and smoothly drawing maps, and its implementation involves thread scheduling and GPU acceleration. Dynamic multithreaded rendering: The system creates a fixed-size thread pool for rendering tasks. The size of the thread pool... It is not fixed, but dynamically determined based on the number of CPU cores in the device: For example, on an 8-core device, = min(4, ceil(0.75 * 8)) = min(4,ceil(6))=4. This ensures sufficient concurrency while avoiding the context switching overhead caused by too many threads. The main UI thread is only responsible for receiving interaction events and scheduling; all time-consuming layer drawing and symbolization tasks are submitted to this thread pool for parallel execution.

[0021] GPU acceleration and adaptive rendering: Rendering tasks are ultimately submitted to the GPU for execution via OpenGL ES 3.2 or the Vulkan API. To balance image quality and performance, the system queries the GPU frequency (gpuFreq) in real time and dynamically adjusts the full-screen anti-aliasing (FSAA) level (aaLevel). The clamp function restricts the calculation result to the integer range [1, 4]. When the GPU frequency is high and the load is light, a higher level of anti-aliasing is used to achieve a smoother effect; otherwise, the level is reduced to ensure the frame rate.

[0022] 3. Specific implementation of the interactive response subsystem This subsystem ensures that user actions receive immediate and smooth feedback, and its core lies in prediction and buffering: Viewport position prediction: When the system captures the user's swipe gesture (MotionEvent.ACTION_MOVE), it calculates the gesture's velocity (vx, vy). At the moment the gesture ends (ACTION_UP), the final position after the inertial swipe is calculated using the viewport position prediction model. Here, Δt represents an estimated animation duration, such as 300ms. This model simulates the frictional deceleration effect in the physical world, making map sliding more natural. The system will immediately begin preloading data within the predicted viewport range, preparing for possible subsequent observations by the user.

[0023] Double-buffered rendering: This invention uses Android's SurfaceView for map rendering. All rendering operations are first completed in an off-screen buffer. Once the entire frame of content is ready, it is then swapped to the foreground buffer for display using SurfaceHolder.lockCanvas() and unlockCanvasAndPost(). This completely eliminates screen flickering and tearing that may be caused by rendering layer by layer.

[0024] 4. Specific implementation of the data synchronization and update subsystem This subsystem is responsible for maintaining consistency between offline data and server data. Incremental update mechanism: The system utilizes Android's JobScheduler to periodically wake up the synchronization task when the device is charging and connected to Wi-Fi. This task sends a request to the map server, carrying the version number or timestamp of the locally cached data. The server returns an incremental data packet containing the changed data. After parsing the incremental packet, the system updates only the changed data in the SQLite database, rather than replacing the entire database, greatly saving network traffic and processing time.

[0025] Notification and Refresh: After the data update is complete, the system publishes a data update event through an event bus, such as LiveData or RxJava. Upon receiving the event, the map rendering component automatically refreshes the currently visible area, allowing users to see the latest content without manual intervention.

[0026] Example Effect Verification To verify the effectiveness of the invention, satellite imagery maps and smart city network layers of a certain city were tested on a test device equipped with a Qualcomm Snapdragon 888 chip.

[0027] Scenario 1: High-resolution image loading. After applying this method, the loading time for 2560x1440 resolution images was reduced from the traditional 2.3 seconds to 0.7 seconds. Simultaneously, due to efficient thread management and GPU scheduling, GPU utilization decreased from 82% to 47%, device surface temperature was significantly reduced, and power consumption was optimized by approximately 3.2W.

[0028] Scenario 2: Multi-layer browsing and interaction. When loading 10 city pipeline network layers simultaneously, peak memory usage dropped from 850MB to 320MB. During rapid zooming and panning operations, the frame rate remained stable at 60fps, operation feedback latency was less than 35ms, and the junk rate (stuttering rate) was less than 6%, resulting in a significant improvement in user experience smoothness.

[0029] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for accelerating and interacting with ArcGIS graphics engine suitable for mobile terminals, characterized in that, Comprise the following steps: S1, preloading stage: geographical data according to layer or use pretreatment, vector graphics, tile partitioning, and generating multi-level cache structure; S2, concurrent rendering stage: using the main thread to process interactive instructions, sub thread is responsible for partition layer drawing, dynamic multi-thread rendering control, thread number optimization model formula as follows: wherein is the number of CPU cores, the upper limit of the number of threads is 4, and the actual number of threads is rounded up to 75% of the number of CPU cores. S3, interactive event processing stage: capture user gesture event, match registration operation behavior, according to gesture dynamic adjustment map view state, and quickly feedback new content, using viewport position prediction model formula to predict the view state, prediction formula as follows: wherein , the viewport position after gesture swipe is predicted based on current position, velocity (vx, vy) and time difference (t2-t1) ), frictionFactor is the friction coefficient, the higher the velocity, the smaller the friction coefficient, the faster the deceleration S4, drawing link adopts double buffer strategy, avoid frequent redraw interference user operation, cache priority formula as follows: Wherein distance is the distance of layer to viewport, viewportSize is the diagonal length of viewport, spatial proximity weight 70%, time locality weight 30%, At the same time, the memory is recycled, and the memory recycling ratio calculation formula is as follows: Wherein pressureLevel is the memory pressure level (1-10), k is the system tuning coefficient, using logarithmic function makes the recycling ratio gradually increases with the pressure, avoid memory recycling too aggressive; S5, data dynamic update stage: background timing or active trigger data source inspection, after detecting changes, only synchronize the data that has changed, and the updated content synchronously triggers map refresh.

2. The method of claim 1, wherein the method is applied to a mobile terminal. The step S2 further comprises dynamically adjusting the anti-aliasing level based on the device performance, and the dynamic anti-aliasing level calculation formula is as follows: Wherein the anti-aliasing level is positively correlated with the GPU frequency, the base value is calculated through the GPU frequency, and then is limited in the effective range of 1-4, the rendering quality and GPU load are balanced, then the tile clarity is selected as needed, and the DPI and device screen parameters are dynamically adapted.

3. The method of claim 1, wherein the method is applied to a mobile terminal. The multi-level cache structure in the step S1 is local database-memory LRU cache-disk cold data.

4. The method of claim 1, wherein the method is applied to a mobile terminal. In the step S2, the graphic rendering is uniformly through the GPU channel, and is called through the OpenGL or Vulkan interface.

5. An ArcGIS graphics engine acceleration and interaction system suitable for mobile terminals, characterized in that, The system applies the ArcGIS graphic engine acceleration and interaction method for mobile terminal in any one of claims 1-4, and the system comprises a data processing subsystem, a graphic rendering subsystem, an interactive response subsystem and a data synchronization updating subsystem. The data processing subsystem performs hierarchical thinning, geometry simplification and cache priority management on massive geographical data, automatically stores in the local database cache according to the data types such as vector, raster and service flow classification; the graphic rendering subsystem separates the main UI thread and the graphic drawing task by using a multi-thread architecture, performs base map rendering, layer symbolization and dynamic labeling by using GPU parallel pipeline, and automatically adjusts the resolution, anti-aliasing level and resource loading strategy according to the device hardware capability; the interactive response subsystem binds touch gestures and map function actions by introducing an event-driven model; and the data synchronization updating subsystem monitors remote service version changes, triggers incremental data pulling, updates cache content asynchronously and dynamically refreshes the visible map area.

Images