Android three-dimensional offline tile loading system based on hybrid architecture

Abstract

The invention discloses an Android three-dimensional off-line tile loading system based on a hybrid architecture, and relates to the technical field, the Android three-dimensional off-line tile loading system comprises an initialization module used for starting an embedded HTTP server and mapping an off-line tile storage directory, and loading a Cesium engine entry page through WebView; the dynamic tile downloading module comprises a tile calculation unit and a multi-thread downloading scheduling unit, and the tile calculation unit is used for analyzing an off-line downloading area in a GeoJSON format, calculating tile index parameters and generating a tile number list; the multi-thread downloading and scheduling unit is used for downloading tile data in parallel through a thread pool and writing the tile data into an offline tile storage directory; the tile loading module is used for enabling Cesium to request tiles from the embedded HTTP server according to the current view to realize three-dimensional off-line rendering; according to the method, the problem of offline of the three-dimensional map of the mobile terminal is solved, on-demand downloading is supported, and the data management efficiency and the rendering performance are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Android three-dimensional offline tile loading, and more particularly to an Android three-dimensional offline tile loading system based on a hybrid architecture. BACKGROUND

[0002] With the application range of mobile GIS in field exploration, emergency command and other aspects becoming wider and wider, higher requirements are put forward for high-precision three-dimensional map visualization in offline environment. The mainstream algorithms currently used have problems such as low precision and slow running speed.

[0003] Weak three-dimensional offline support capability: the mainstream three-dimensional map engine Cesium generally uses network services to pull tile maps, and cannot be used in the absence of network or poor network conditions. The traditional offline map application of Android is often only implemented in two-dimensional maps such as Leaflet, and cannot realize the rendering and interaction of three-dimensional terrain. Since the Cesium three-dimensional map engine is based on Web development, it cannot use the file: / / method to introduce local tile map files on the Android end under the security mechanism of the browser, and the source code of the engine needs to be modified. The compatibility of the engine transplanted to the Android system is poor.

[0004] Low data management efficiency: offline tile files are large in size, and most mobile terminals currently use the method of pre-pulling full data, which occupies a large amount of storage space and cannot achieve selective offline download according to specific areas, lacks flexibility, and cannot realize user on-demand download of tiles in a certain area.

[0005] The above problems seriously affect the application effect of mobile GIS in emergency response, field work and other functions; the present application is proposed to solve the above problems, and is an Android mobile three-dimensional offline tile loading system based on a hybrid architecture and algorithm design. SUMMARY

[0006] In order to overcome the above-mentioned defects of the prior art, the embodiments of the present application provide an Android three-dimensional offline tile loading system based on a hybrid architecture to solve the problems proposed in the background art.

[0007] To achieve the above-mentioned purposes, the present application provides the following technical solutions:

[0008] An Android three-dimensional offline tile loading system based on a hybrid architecture comprises the following modules:

[0009] The initialization module is configured to call the AndServer to start the embedded HTTP server when the Android application is started, map the offline tile storage directory in the external storage to a local HTTP access path, and load the entry page integrated with the Cesium three-dimensional engine through the WebView, so that the entry page accesses the offline tile file through the local URL.

[0010] The dynamic tile downloading module includes a tile calculation unit and a multi-threaded downloading scheduling unit. The tile calculation unit is configured to receive the offline downloading area and the zoom level parameter, perform syntax and coordinate legality verification on the offline downloading area, calculate the tile index parameter representing the zoom level and the row and column positions according to a preset projection and tile division mode, generate a tile number list covering the offline downloading area according to the row and column traversal, and determine the local storage path for each tile in the tile number list according to a preset local storage rule based on the tile index parameter.

[0011] The multi-threaded downloading scheduling unit is configured to encapsulate each tile in the tile number list as a downloading task, and obtain the corresponding tile data from the remote tile service in parallel through a thread pool and write the tile data into the offline tile storage directory. The tile loading module is configured to enable the Cesium running in the WebView to generate an HTTP request containing the tile index parameter according to the current view and send the HTTP request to the embedded HTTP server, so that the embedded HTTP server locates and reads the corresponding offline tile file in the offline tile storage directory and returns the offline tile file to the Cesium for three-dimensional rendering.

[0012] In a preferred embodiment, the initialization module is configured to build the embedded HTTP server through the AndServer, set the listening address to the local loopback address and a preset port, map the offline tile storage directory in the external storage of the Android to a local HTTP access path, and map the application Assets directory to an access path of the entry page and related static resources.

[0013] In a preferred embodiment, the offline tile file is stored according to a local storage rule based on the tile index parameter, and the tile index parameter at least includes a zoom level z, a row index x, and a column index y, so that the embedded HTTP server can directly locate the corresponding offline tile file according to the tile index parameter carried in the request. The local storage rule is that the offline tile file adopts a file naming manner of z_x_y.ext, where ext is a file extension of an image format.

[0014] In a preferred embodiment, the initialization module is also used to establish a bidirectional communication mechanism between WebView and the Android native layer. After WebView loads the entry page integrating the Cesium 3D engine, it passes the offline tile storage directory, server port and offline download parameters to the Web-side script, and registers native interfaces in WebView for the Web-side to call, so as to trigger the start download, pause download and cancel download operations.

[0015] In a preferred embodiment, the tile calculation unit is used to take the GeoJSON format offline download area as input, perform syntax parsing and validity verification on the GeoJSON string, including at least: detecting whether the type field is Polygon, checking whether the beginning and end of the coordinate array are closed and whether the latitude and longitude are within the preset valid range, and obtaining the minimum longitude, maximum longitude, minimum latitude and maximum latitude after parsing all vertices to form the outer rectangle of the offline download area.

[0016] In a preferred embodiment, calculating the tile index parameters representing the scaling level and row / column position includes: at each selected scaling level, the tile calculation unit uses a preset projection to convert the latitude and longitude of the four boundary points of the outer rectangle into tile coordinates to obtain a floating-point tile index range, and performs boundary expansion and coordinate system adaptation by subtracting one from the minimum row / column number, adding one to the maximum row / column number, and flipping the row index according to the TMS method, thereby generating a list of tile numbers covering the offline download area; wherein, the preset projection is the WebMercator projection.

[0017] In a preferred embodiment, the multi-threaded download scheduling unit includes a task queue and a thread pool. The list of tile numbers generated by the tile calculation unit is encapsulated one by one into a download task object containing tile index parameters, remote tile service request address and local storage path and written into the task queue. Each worker thread in the thread pool obtains the download task from the task queue and requests the corresponding tile data from the remote tile service through an HTTP client.

[0018] In a preferred embodiment, the multi-threaded download scheduling unit sets connection timeout and read timeout thresholds and a preset number of retries for each download task. When a single tile fails to download or times out, the corresponding task is put back into the task queue. When the maximum number of retries is exceeded, the tile is recorded in the list of failed tiles for the user to be notified on the web interface.

[0019] In a preferred embodiment, the multi-threaded download scheduling unit also maintains download control flags for downloading, paused, and canceled, and records the number of completed tiles and failed tiles in memory using an atomic counter. At preset time intervals, it feeds back the current download progress and failure status to the web interface through the communication mechanism between Android and the web, driving the progress bar display and abnormal tile prompts.

[0020] The technical effects and advantages of the present invention, which is an Android 3D offline tile loading system based on a hybrid architecture: Architectural innovation: Using an embedded local server AndServer to connect Cesium with offline files, the problem of mobile 3D offline processing can be solved without modifying the engine code;

[0021] Efficient data management: The tile calculation algorithm supports dynamic region selection, allowing you to download tiles for a specified region according to actual needs, significantly reducing storage space;

[0022] Performance optimization: On Android devices with medium performance, the CPU utilization peak of the multi-threaded download module is no more than 55% and the memory jitter is no more than 15MB when the concurrency is 10; Cesium's view frustum clipping and LRU tile elimination mechanism ensure smooth scrolling operations. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the main process of an Android 3D offline tile loading system based on a hybrid architecture according to the present invention;

[0024] Figure 2 This is a flowchart illustrating the tile calculation unit in an Android 3D offline tile loading system based on a hybrid architecture, according to the present invention.

[0025] Figure 3 This is a flowchart illustrating the multi-threaded download scheduling unit in an Android 3D offline tile loading system based on a hybrid architecture, according to the present invention. Detailed Implementation

[0026] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] Example 1

[0028] Please see Figure 1As shown, this invention discloses an Android 3D offline tile loading system based on a hybrid architecture, comprising the following modules:

[0029] The initialization module is responsible for starting and configuring the embedded HTTP server, setting resource mapping paths, and establishing a communication mechanism between the Android native layer and the web client.

[0030] The dynamic tile download module includes a tile calculation unit and a multi-threaded download scheduling unit. The tile calculation unit is used to receive offline download area and scaling level parameters, perform syntax and coordinate validity checks on the offline download area, calculate tile index parameters representing scaling level and row and column positions according to preset projection and tile division method, generate a tile number list covering the offline download area by traversing rows and columns, and determine the local storage path for each tile in the tile number list according to preset local storage rules based on tile index parameters.

[0031] The multi-threaded download scheduling unit encapsulates each tile in the tile number list into a download task, retrieves the corresponding tile data from the remote tile service in parallel through a thread pool, and writes it to the offline tile storage directory; the initialization module starts and configures the embedded HTTP server, sets the resource mapping path, and establishes a communication mechanism between the Android native layer and the web client, specifically including:

[0032] This invention adopts a hybrid architecture, with core components including the Android native layer, an embedded HTTP server, and preferably using the AndServer library, WebView component, and a web-based 3D engine such as Cesium. The initialization module is the first step in the operation of the entire system. Its task is to configure and start the embedded HTTP server when the application starts, so that the components can work together and to pre-set the necessary parameters for subsequent processes.

[0033] Embedded HTTP server initialization includes: calling the builder provided by the AndServer library to create a server instance in the Android main thread or application startup service, and setting the service port number; based on experience in this embodiment, the default port is set to 8091; the reason for choosing this port is that it usually does not conflict with commonly used system ports, such as 80 and 8080, can be used on mobile devices without root privileges, and is easy to keep consistent with the local URL configured in WebView; when configuring the server, a network timeout should also be set, such as 30 seconds, to cope with mobile network fluctuations and prevent requests from being unresponsive for a long time;

[0034] The server needs to map the local Assets directory and the external storage directory so that they can be accessed as static resources at the HTTP layer. The specific mapping method is as follows: the Assets directory located in the application package, such as a folder named html, is mapped to the access path of the HTML, CSS and JavaScript files required by the web client, so that the WebView can directly access these files when it loads; at the same time, the external storage directory, such as / storage / emulated / 0 / tiles / , is mapped to the offline tile storage directory. After the server receives the path, it will read the tile images in this directory and return them; the external storage directory needs to be created when the application runs for the first time, and write storage permissions are requested from the user to grant authorization; / storage / emulated / 0 / is chosen as the root directory because it has good compatibility on Android devices and is easy for users to access. The subdirectory name is set to tiles to clearly identify the tile content; to avoid the loss of search efficiency due to too many files in a single directory, subsequent modules will further establish a hierarchical structure in this directory according to the scaling level and tile coordinates, such as dividing the subdirectories according to the level and row and column indexes;

[0035] After configuring the port number and resource mapping, the server instance should be started. During the startup process, the user can be notified that the server has started through log output or interface prompts. For example, information such as HTTP, serverstartedonport8091, etc. can be recorded in the Android log. After the server starts, it will listen on the local port and wait for HTTP requests from WebView or other clients.

[0036] It's important to note that the WebView configuration embeds a web page into the Android native layer via the WebView control, pointing its loading address to an embedded HTTP server, such as http: / / localhost:8091 / index.html. To ensure the web client can access the embedded HTTP server correctly, JavaScript needs to be enabled in the WebView settings, access to local files should be allowed, and the browser's DOM storage function should be enabled. Additionally, enabling development / debugging mode helps in troubleshooting. These settings ensure that the WebView can execute the JavaScript logic required by libraries like Cesium and access local storage.

[0037] Furthermore, it also includes a two-way communication mechanism, specifically: communication between the Android native layer and the Web client, that is, after the native code has finished loading the Webview page, it uses the evaluateJavascript method to execute JS methods;

[0038] In a preferred embodiment, after the embedded HTTP server starts successfully and the offline tile storage directory is created, Android, in the callback after the page loads, concatenates an initialization string containing fields such as the server port number, tile storage path, and current download status according to a preset format, and injects it into a specified callback function on the page via evaluateJavascript. This callback function then completes the configuration of the offline layer and the initialization of the progress bar on the web side. To avoid lag caused by frequent calls, the system can also set the minimum time interval between two calls to more than 500 milliseconds.

[0039] Web client communicates with the Android native layer: Register the JS call interface on the Android client and register the Android native method in the Window window on the web client;

[0040] In a preferred embodiment, Android registers a bridge object named AndroidBridge in the WebView, exposing only a limited set of interfaces such as start download, pause download, and resume download. The Web client calls these methods uniformly through AndroidBridge under the Window object, passing in parameters such as GeoJSON data of the user-selected area, minimum and maximum zoom levels, and whether TMS conversion is enabled as a JSON string. After receiving the call, the Android client first verifies whether the string length, latitude and longitude range, and zoom level are between 1 and 18. Only when the verification passes will the subsequent tile calculation and multi-threaded download process be started.

[0041] For example, on a mid-performance Android device such as the Dimensity 1000 processor and 8GB of RAM, the system presents a loading page to the user after startup; after the application requests and successfully obtains storage and network permissions, it calls AndServer to create a server on port 8091; it maps the two directories assets / html and external / tiles; the WebView loads http: / / localhost:8091 / index.html, and the web page uses the Cesium library to render the Earth; when the user clicks the button to select a download area, the system launches a JS interface and passes GeoJSON data to the native layer through AndroidBridge.startDownload(); at this point, the initialization phase ends, and the tile calculation and download module begins execution;

[0042] Preferably, to ensure the server can only be accessed locally, AndServer listens on the local loopback address 127.0.0.1 by default. If local area network access is required, it can also be configured to listen on other network card addresses, but for security reasons, this embodiment only recommends binding to the local machine. Android 7.0 and above systems need to avoid exposing file URIs through the FileProvider mechanism. This can be done by declaring the corresponding Provider in AndroidManifest.xml and listing the allowed shared directories in the file path configuration. In addition, the application needs to dynamically request permissions to read external storage, write to external storage, and access the network at runtime, and guide the user to grant permissions in accordance with the Android permission management specifications. If the user refuses authorization, the application should prompt that the offline download function will not work properly.

[0043] The dynamic tile download module includes a tile calculation unit and a multi-threaded download scheduling unit;

[0044] Please see Figure 2 As shown, the tile calculation unit receives the offline download area and scaling level parameters, performs syntax and coordinate validity checks on the offline download area, calculates tile index parameters representing the scaling level and row / column position based on a preset projection and tile partitioning method, generates a tile number list covering the offline download area by traversing rows and columns, and determines a local storage path for each tile in the tile number list according to preset local storage rules based on tile index parameters; specifically:

[0045] Region resolution: Users input GeoJSON polygons through the Android interface, for example, coordinate range [125.3474, 43.9953] to [125.4244, 43.9702], and the polygon data format is Polygon;

[0046] In this embodiment, the terminal interface provides tools for selecting areas or drawing polygons. After the user completes the area drawing on the 3D globe view, the Web client encapsulates the user-selected vertex sequence into a GeoJSON string and submits it to the Android client. The coordinate range [125.3474, 43.9953] to [125.4244, 43.9702] is only a typical example used to represent a local rectangular area of ​​a city. This invention is not limited to this specific coordinate. Those skilled in the art can choose polygons of any latitude and longitude range as needed.

[0047] In a preferred embodiment, the system first performs syntax parsing and validity checks on the GeoJSON string, confirming that the type field is Polygon, that the coordinate array has consistent coordinates at the beginning and end, and checking point by point whether the longitude falls within the valid range of -180 to 180 degrees and the latitude falls within the valid range of -85 to 85 degrees; only when all the above conditions are met is the polygon recognized as a valid download area and used as input data for subsequent tile calculation; the coordinate values ​​of each vertex are entirely derived from the user's drawing results on the Android interface, without smoothing or interpolation processing, to ensure that the area boundary is consistent with the user's selection;

[0048] Specifically, after receiving the GeoJSON string from the Web client, the Android client first parses the fields such as type and coordinates according to the GeoJSON standard. If the type is not Polygon or MultiPolygon, or if the length of the coordinate array is less than a preset threshold (e.g., less than 3 vertices), it is determined to be illegal input and an error message is immediately returned to the user. Subsequently, the system checks whether the beginning and end of the coordinate array are the same. If they are not the same, the system automatically fills in the beginning and end points to ensure that the polygon is closed. For each coordinate point, this embodiment compares whether the longitude and latitude are within the range of -180 to 180 degrees and -85 to 85 degrees, respectively. The selection of the longitude and latitude range is based on the fact that the current mainstream online maps and WebMercator projection have good numerical stability within this range. In particular, when the absolute value of latitude is greater than about 85 degrees, the projection distortion increases sharply. Therefore, in the implementation, the effective latitude is limited to -85 to 85 degrees to avoid calculation instability.

[0049] After completing GeoJSON syntax and range validation, the system proceeds to the outer rectangle calculation process. After completing GeoJSON parsing, this embodiment performs a traversal of all vertices of the polygon to obtain the minimum longitude value minLng, the maximum longitude value maxLng, the minimum latitude value minLat, and the maximum latitude value maxLat, forming an outer rectangle that includes the user-drawn area for subsequent tile index range calculation. Since the user-drawn polygon may have irregular shapes, such as polylines or concave polygons, this embodiment uses a point-by-point scanning method to obtain the above four extreme values, thereby ensuring that the outer rectangle covers all vertices of the user-selected area.

[0050] To avoid missing edge tiles due to floating-point rounding errors, when converting the above four boundaries into tile row and column numbers, the smallest row and column number is subtracted by 1, and the largest row and column number is added by 1, which is equivalent to retaining an extra ring of tiles in each of the four directions. The present invention preferably sets the expansion amount to 1, which is a compromise result selected after comparing the three values ​​of 0, 1, and 2 in multiple typical scenarios. This ensures the continuity of edges during rendering without causing a sharp increase in the number of tiles.

[0051] Specifically, when mapping longitude and latitude to tile indices in the subsequent process, the theoretical floating-point index value is first obtained. , , , If the integer is directly rounded, a very small number of tiles at the boundary may fall outside the range due to floating-point rounding, which manifests as small gaps at the edge of the offline map.

[0052] To avoid this situation, this embodiment adopts a method in the x-direction. , The expansion method; the same applies to the y-direction. , The expansion is carried out outward; by comparing the number of tiles generated and the display effect when the expansion amount is 0, 1 and 2, the present invention found that expanding by 1 index unit can effectively cover numerical errors, and the number of newly added tiles is relatively limited. Therefore, it is preferable to set the expansion amount to 1.

[0053] It should be noted that, to ensure the consistency of subsequent algorithms, unless otherwise specified, the offline download area selected by the user in the terminal interface in this embodiment is described in GeoJSON format. The latitude and longitude coordinates in the GeoJSON are all based on the WGS-84 geographic coordinate system, where the units of longitude and latitude are angles. Those skilled in the art will understand that WGS-84 is a commonly used geographic coordinate reference system in current Internet map services. Using this coordinate system can easily interface with existing online tile map services. Therefore, no additional coordinate reference transformation is required during tile calculation and subsequent WebMercator projection, which helps to simplify implementation and reduce sources of error.

[0054] Through the above steps, a valid download area bounding rectangle (minLng, maxLng, minLat, maxLat) and the corresponding coordinate point sequence are output.

[0055] Building upon the completed region parsing, this embodiment further calculates the tile coordinates of the outer rectangle. The tile calculation involves: parsing GeoJSON to extract boundary points and calculating the extreme values ​​of the outer rectangle; for each scaling level z, using the formula... and Transform coordinates, where The value is in radians representing latitude. Indicates the longitude value of the boundary point; Indicates the total number of tiles;

[0056] Furthermore, adjustments were made using the TMS method, and the boundary was extended by one pixel to handle floating-point errors to obtain a list of tile numbers.

[0057] Specifically, in this embodiment, when performing WebMercator projection calculations, the latitude angle values ​​are first converted into radians, and the conversion relationship is as follows:

[0058] ;in, Represents geographical latitude in degrees. This represents the latitude in radians; then, the radian value is substituted into the tile coordinate calculation formula to ensure the accuracy and consistency of the calculation results; radians are used because trigonometric functions in mathematical libraries generally use radians, and directly inputting degrees would lead to calculation errors;

[0059] It should be noted that, in terms of zoom level settings, this embodiment supports 18 levels by default, from z=1 to 18; smaller z corresponds to a global or national overview with fewer tiles; larger z corresponds to street-level or building-level detail with the number of tiles increasing sharply with 2 raised to the power of z; performance testing showed that on a typical Android terminal, when the maximum zoom level exceeds 18, the local storage pressure and download time increase significantly, so the default upper limit is set to 18.

[0060] At each selected scaling level z, the system uses the aforementioned formula to map the four boundary points of the outer rectangle to the tile coordinate system, obtaining the floating-point index range. , , , Then expand outward by one more index unit. , , , Similarly, the range of integer indices is obtained. , Then, a double loop is performed within this range, checking each set of tile index parameters. Combine and generate a tile task and add it to the task list; if the target server uses the TMS coordinate system, this embodiment will also perform a flipping process when generating the y-index, that is... , used to adapt to bottom-up tile row numbering conventions;

[0061] In this embodiment, to simplify the server's process of locating offline tile files, the offline tile files are named using locally stored file naming rules. Specifically, for a tile with a scaling level of z, a row index of x, and a column index of y, its local filename is preferably in the form of z_x_y.ext, where ext is the file extension used to indicate the encoding format of the tile image. For example, when z = 12, x = 2156, y = 1013 and the tile uses the WebP encoding format, the corresponding filename is 12_2156_1013.webp. Through the above naming method, the server can construct the target filename according to fixed rules after parsing the z, x, and y parameters, which facilitates rapid retrieval.

[0062] It should be noted that, in the description of this invention, the tile index parameter is used to uniquely identify the tile position in the 3D map, and to characterize the zoom level of the tile and its row and column positions at that zoom level; in one specific implementation, the tile index parameter adopts the form (z,x,y), where z represents the zoom level, x represents the row index, and y represents the column index;

[0063] The local storage rules based on tile index parameters mentioned in this invention are used to map tile index parameters to local file paths and filenames, so that the embedded HTTP server can quickly locate the corresponding offline tile file according to the tile index parameters carried in the request; and offline tile data refers to offline tile image data stored in the offline tile storage directory in the form of files, specifically offline tile files, that is, offline tile files named according to z_x_y.ext;

[0064] In one specific implementation, the offline tile files are named using the z_x_y.ext filename format, where ext is the file extension for png, jpg, or webp image formats.

[0065] It should be noted that the file extension ext can take various formats such as png, jpg, webp, etc. This embodiment prefers to use the webp format to significantly reduce the file size while ensuring visual quality. The specific configuration of ext is read from the configuration file during system initialization and can be unified into a single format. It can also automatically select an appropriate extension based on the Content-Type returned by the remote service during the tile download stage. The unified naming rule allows the embedded HTTP server to directly locate the corresponding tile in the file system when processing requests, simply by concatenating the string according to the z, x, and y parameters carried in the URL, without the need to maintain a complex index structure.

[0066] Please see Figure 3As shown, the multi-threaded download scheduling unit encapsulates each tile in the tile number list into a download task, retrieves the corresponding tile data from the remote tile service in parallel through a thread pool, and saves it to the offline tile storage directory in the form of offline tile files. Specifically:

[0067] After completing GeoJSON region parsing and tile number generation, the system obtains a list of tile tasks sorted by scaling level z, row index x, and column index y. Each record corresponds to a local filename denoted as offline tile file z_x_y.ext. In this embodiment, the system then enters a multi-threaded download phase, using a preset thread pool and dynamic scheduling mechanism to download the tile tasks from the remote tile service to the offline tile storage directory as needed.

[0068] When initiating multi-threaded downloads, the system employs a dynamic scheduling mechanism to optimize download efficiency: First, based on the total number of tiles and the preset thread pool size, the download task is divided into multiple batches, with each batch processing a fixed number of tiles; the scheduler manages the download tasks through a blocking queue, automatically retrieving new tasks from the queue after a thread completes its current task; simultaneously, a timeout retry mechanism is set up, automatically re-adding a tile to the queue when the download times out, ensuring the integrity and stability of the download tasks;

[0069] Based on this, this embodiment encapsulates the tile number list into download task objects one by one. Each object contains at least the z, x, and y values ​​of the tile, the target file name, the local save path, and the current number of retries. All download task objects are sequentially placed into a thread-safe blocking queue, which serves as the unified task entry point for the dynamic scheduling mechanism. Each worker thread in the thread pool retrieves a task from this queue when idle, uses an HTTP client, such as OkHttpClient, to send a request to the remote tile service, obtains the image data, and writes it to the offline tile storage directory according to the agreed-upon z_x_y.ext naming rule. When all download tasks in the blocking queue have been completed, the multi-threaded download scheduling unit records the start and end times of the download process to calculate the total time, and closes the thread pool to release related system resources after all worker threads exit.

[0070] It should be noted that, in terms of concurrency configuration, this embodiment sets the initial thread pool size to 10. The reason for choosing 10 is that, on the one hand, typical Android terminals generally have 4 to 8 CPU cores, and 10 download threads can make good use of multi-core resources in I / O-intensive tasks; on the other hand, in multiple rounds of experiments, it was found that when the number of threads exceeds 15, the overhead of thread switching and context scheduling increases significantly, and the overall download time may actually become longer. Therefore, 10 is preferred as a compromise value. This invention does not limit the thread pool size to 10, and those skilled in the art can adjust it according to device performance and server concurrency limits.

[0071] In terms of task scheduling, this embodiment adopts a producer-consumer model: the tile number generation module acts as a producer, putting all tasks to be downloaded into a blocking queue at once; multiple download threads act as consumers, retrieving tasks from the queue in parallel for execution; since the queue maintains a first-in-first-out order internally, tasks with smaller zoom levels z are prioritized at the head of the queue, ensuring that users receive lower-level overview tiles first when viewing the offline area for the first time, thereby improving the visual experience; if it is necessary to set higher priority for tiles of certain zoom levels or certain areas, the tasks can be reordered according to weight before being put into the queue, or a priority blocking queue can be used, which is not limited in this invention;

[0072] Regarding network parameter settings, this embodiment sets connection timeout and read timeout parameters for each tile download request. In this embodiment, the download timeout is preferably set to 30 seconds. The source of this time threshold is the comprehensive test results of typical tile sizes such as 10-200KB and mobile network bandwidths such as 10-40Mbps: In most environments, a single tile can usually be downloaded within 1-3 seconds. Setting the timeout to 30 seconds can effectively cover network jitter and temporary congestion, while also releasing thread resources as soon as possible when the connection is unresponsive for a long time, preventing the download process from freezing.

[0073] Regarding task reliability, preferably, to improve download stability, this embodiment can set a retry mechanism for each download task. For example, when a network anomaly occurs, the server returns an error status code, or the download is not completed within 30 seconds, the system increments the retry count of the current task and puts the task back to the end of the blocking queue. If the number of retries for a task exceeds the preset retry limit, preferably 3 times, it will no longer be automatically retried, but the task will be recorded in the failed tile list for later unified display or manually triggered by the user to re-download. The choice of a maximum retry limit of 3 is based on the fact that in multiple actual tests, most transient network failures can be recovered after 1 to 2 retries. Trying the same resource multiple times will bring unnecessary network overhead or even trigger server rate limiting. Therefore, a compromise setting of a maximum of 3 retries is adopted.

[0074] For example, during the download process, a tile with a zoom level of 15 and coordinates (z=15, x=11523, y=5621) fails to receive a response within 30 seconds due to network jitter. At this point, the system determines the task has timed out, immediately interrupts the request, increments the retry count from 0 to 1, and puts it back into the queue. A few seconds later, the task is retrieved again by an idle thread and re-requested. If the network recovers by this time, the tile can be successfully downloaded and written locally, with only one timeout event recorded in the log. If the same tile times out or the server returns an error three times consecutively, the system will not automatically retry. Instead, it will write the tile's z, x, and y numbers along with the corresponding URL to the failed tile list. Later, the user will be notified via the web interface that several tiles have failed to download, and can choose to retry or ignore them, thus ensuring that the task is completed successfully. While ensuring service integrity, this embodiment avoids infinite retries. Furthermore, to guarantee the controllability of the entire download process, a download control flag is set, including states such as downloading, paused, and canceled. When the user clicks the pause or cancel button on the interface, the web client sends a control command to the native layer through the aforementioned web-to-Android communication interface. Upon receiving the command, the native layer modifies the global control flag, and the thread checks this flag before each new task is retrieved from the queue. If the state is paused, the thread temporarily stops retrieving tasks from the queue, retaining only the already executing requests until completion. If the state is canceled, the thread immediately exits the loop after completing the current task and clears the task queue, thus stopping the entire download task. In this way, any size list of tiles generated is incorporated into a unified download process that can be paused, resumed, and canceled.

[0075] To enable users to monitor download progress in real time, this embodiment maintains several atomic counters in memory: one is the number of completed tiles, which is incremented each time a tile is successfully written to the local file system; the second is the number of downloaded bytes, which is accumulated according to the actual file size; and the third is a counter that records the number of failed tasks. Before the download begins, the system estimates the total number of bytes based on the tile number list and the header information returned by the remote service, and reads the above counters at fixed time intervals, such as every 100 milliseconds, to calculate the current completion percentage and instantaneous download speed. This information is then pushed to the web page via the Android-to-Web communication channel to drive the progress bar and speed display. The 100-millisecond statistical period is a compromise value selected after considering the smoothness of UI updates and computational overhead. If the period is too short, it will lead to frequent interface redraws and increased power consumption; if the period is too long, it will give users the illusion of unresponsiveness.

[0076] Example 2

[0077] After completing the aforementioned modules, the system has generated offline tile files with the unified name z_x_y.ext in the terminal's external storage and stored them in the offline tile storage directory. The task of the tile loading module is to build an embedded HTTP server inside the Android terminal, map the aforementioned offline tile storage directory to an HTTP access path, and request these tiles on demand through the 3D engine in WebView, such as Cesium, to achieve fast loading of the offline 3D scene.

[0078] In this embodiment, the local service and tile loading module first relies on the embedded HTTP server started during the initialization phase to perform path mapping on the offline tile storage directory. Specifically:

[0079] WebView loads a local URL: The terminal application first creates a WebView component in the Android native layer and points its loading address to the entry page provided by the embedded HTTP server, for example, set to http: / / localhost:8091 / index.html; the entry page pre-integrates the Cesium engine and related initialization scripts, thereby ensuring that the subsequent 3D scene can run in the local browser control;

[0080] Cesium engine initialization: After the entry page is loaded, the JavaScript code on the web side automatically creates a CesiumViewer instance and disables the default online base map layer according to business needs, retaining only the basic settings suitable for offline mode, such as coordinate system, lighting and initial camera position; in this way, Cesium only relies on image data provided by the subsequent local tile service for rendering, and will not attempt to access external Internet map services;

[0081] Configure the offline tile path: After the Viewer is initialized, the web script creates an image layer provider object, such as UrlTemplateImageryProvider, and configures its URL template to point to the tile access path of the embedded HTTP server, for example, http: / / localhost:8091 / tiles / {z}_{x}_{y}.webp; z, x, and y in the template correspond to the zoom level, row index, and column index, respectively, which is consistent with the naming rules of the z_x_y.webp file used in the aforementioned download module, thereby ensuring that the same set of indexes has a one-to-one correspondence between the front end and the back end;

[0082] User actions trigger tile requests: When a user performs zooming, panning, or rotating operations in the 3D interface, Cesium automatically calculates a set of tile numbers to be loaded in the current view based on the current view frustum range and the configured projection and segmentation scheme, i.e., several (z,x,y) triples; all these calculation processes are completed within the Web engine, without requiring developers to write additional logic;

[0083] Initiating an HTTP request: For each tile number to be loaded, Cesium substitutes it into the aforementioned URL template to generate a specific HTTP request path, and initiates a GET request to the embedded HTTP server through the browser's network stack; for example, when the current view needs to load a tile with a zoom level of 12, a row index of 2156, and a column index of 1013, the engine will automatically construct the request path / tiles / 12_2156_1013.webp and send it to port 8091;

[0084] Server Request Processing: Upon receiving the above request, the embedded HTTP server identifies that the request belongs to offline tile access based on the pre-registered routing rules. It parses the filename part of the URL into three parameters: z, x, and y, and constructs the corresponding local file path based on the unified naming rules, for example, mapping it to / storage / emulated / 0 / tiles / 12_2156_1013.webp. Subsequently, the server checks the existence of the file path, and if it confirms that the file exists and is readable, it opens and reads the tile image data in binary mode.

[0085] For example, in a typical embodiment, when a user opens an offline area that has been successfully downloaded by the aforementioned tile calculation and download module on the terminal, the system automatically switches to offline browsing mode. When the user zooms the view to a zoom level z=12 and moves to a city block, the web-based 3D engine calculates several tiles that need to be loaded based on the current view frustum, one of which is numbered z=12, x=2156, y=1013. The engine generates a request path / tiles / 12_2156_1013.webp according to a preset URL template and sends it to the local service via http: / / localhost:8091. Upon receiving the request, the server parses z, x, y, and the webp extension, converts them to the path / storage / emulated / 0 / tiles / 12 / 12_2156_1013.webp in external storage, performs a file existence check, reads the image bytes, constructs an HTTP 200 response with the content type image / webp, and returns it to the web client. The web client completes image decoding and texture uploading within approximately 16–33 milliseconds, and the tile is then correctly rendered in the 3D scene. The above process is merely a specific example illustrating the request and response flow of this invention, and this invention is not limited to this numerical and path format.

[0086] Returning image data: After the offline tile file is successfully read, the server constructs an HTTP 200 normal response, writes the image byte stream into the response body and returns it to the web client. At the same time, the content type field matching the tile format is set in the response header. For example, for WebP tiles, it can be set to image / webp. If the file does not exist or the reading fails, a default placeholder tile or an appropriate error status code can be returned according to the system configuration, but the basic request-response flow is not changed.

[0087] Tile rendering: After receiving image data from the embedded HTTP server, Cesium decodes the image into textures and applies them to the corresponding geographic grid according to its internal tile rendering pipeline. As more tile requests are processed, the surface texture of the corresponding area is gradually completed, and what the user sees on the terminal is a 3D map effect driven by local offline tile files.

[0088] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0089] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0090] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and inventive constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0091] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0092] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0093] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An Android 3D offline tile loading system based on a hybrid architecture, characterized in that, Includes the following modules: The initialization module is used to call AndServer to start the embedded HTTP server when the Android application starts, map the offline tile storage directory in external storage to the local HTTP access path, and load the entry page integrating the Cesium 3D engine through WebView, so that the entry page can access the offline tile files through the local URL; The dynamic tile download module includes a tile calculation unit and a multi-threaded download scheduling unit. The tile calculation unit is used to receive the offline download area and scaling level parameters, perform syntax and coordinate validity checks on the offline download area, calculate the tile index parameters representing the scaling level and row and column positions according to the preset projection and tile division method, generate a list of tile numbers covering the offline download area by traversing rows and columns, and determine the local storage path for each tile in the tile number list according to the preset local storage rules based on the tile index parameters. The multi-threaded download scheduling unit encapsulates each tile in the tile number list into a download task, retrieves the corresponding tile data from the remote tile service in parallel through a thread pool, and writes it to the offline tile storage directory. The tile loading module enables Cesium, which runs in WebView, to generate an HTTP request containing tile index parameters based on the current view and send it to the embedded HTTP server. The embedded HTTP server locates and reads the corresponding offline tile file in the offline tile storage directory and returns it to Cesium for 3D rendering.

2. The Android 3D offline tile loading system based on a hybrid architecture according to claim 1, characterized in that, The initialization module is configured to: build an embedded HTTP server using AndServer, set the listening address to the local loopback address and the preset port, map the offline tile storage directory in the Android external storage to the local HTTP access path, and map the application Assets directory to the access path for the entry page and related static resources.

3. The Android 3D offline tile loading system based on a hybrid architecture according to claim 1, characterized in that, The offline tile files are stored using a local storage rule based on tile index parameters. These tile index parameters include at least the scaling level z, row index x, and column index y, enabling the embedded HTTP server to directly locate the corresponding offline tile file based on the tile index parameters carried in the request. The local storage rule is that the offline tile files are named using the z_x_y.ext filename format, where ext is the file extension for image formats.

4. The Android 3D offline tile loading system based on a hybrid architecture according to claim 2, characterized in that, The initialization module is also used to establish a two-way communication mechanism between WebView and the Android native layer. After WebView loads the entry page that integrates the Cesium 3D engine, it passes the offline tile storage directory, server port and offline download parameters to the Web script, and registers native interfaces in WebView for the Web client to call to trigger the start download, pause download and cancel download operations.

5. The Android 3D offline tile loading system based on a hybrid architecture according to claim 1, characterized in that, The offline download area is subjected to syntax and coordinate validity checks, including at least: checking whether the type field is Polygon, checking whether the beginning and end of the coordinate array are closed and whether the latitude and longitude are within the preset valid range, and obtaining the minimum longitude, maximum longitude, minimum latitude and maximum latitude after parsing all vertices to form the outer rectangle of the offline download area.

6. The Android 3D offline tile loading system based on a hybrid architecture according to claim 5, characterized in that, The calculation of tile index parameters representing scaling level and row / column position includes: at each selected scaling level, the tile calculation unit uses a preset projection to convert the latitude and longitude of the four boundary points of the outer rectangle into tile coordinates to obtain a floating-point tile index range. Boundary expansion and coordinate system adaptation are performed by subtracting one from the minimum row / column number, adding one to the maximum row / column number, and flipping the row index according to the TMS method, thereby generating a list of tile numbers covering the offline download area; wherein, the preset projection is the WebMercator projection.

7. The Android 3D offline tile loading system based on a hybrid architecture according to claim 1, characterized in that, The multi-threaded download scheduling unit includes a task queue and a thread pool. The list of tile numbers generated by the tile calculation unit is encapsulated one by one into a download task object containing tile index parameters, remote tile service request address and local storage path and written into the task queue. Each worker thread in the thread pool obtains the download task from the task queue and requests the corresponding tile data from the remote tile service through an HTTP client.

8. The Android 3D offline tile loading system based on a hybrid architecture according to claim 7, characterized in that, The multi-threaded download scheduling unit sets connection timeout and read timeout thresholds and a preset number of retries for each download task. When a single tile fails to download or times out, the corresponding task is put back into the task queue. When the maximum number of retries is exceeded, the tile is recorded in the list of failed tiles for the web interface to notify the user.

9. The Android 3D offline tile loading system based on a hybrid architecture according to claim 8, characterized in that, The multi-threaded download scheduling unit also maintains download control flags for in progress, paused, and canceled downloads, and records the number of completed tiles and failed tiles in memory using an atomic counter. At preset time intervals, it feeds back the current download progress and failure status to the web interface through the communication mechanism between Android and the web, which drives the progress bar display and abnormal tile prompts.

Images