Tiles in an archive must need a certain amount of processing - the map needs to extract them from the zip archive.
There's no processing overhead with tiles just cached to the file system BUT storing many small files this way is inefficient.
The file system is likely to be formatted using a FAT32 file system.
FAT32 file systems have a
cluster size that defines the minimum amount of space a file will occupy.
Let's say the cluster size is 16KB.
Every tile will occupy at least 16KB of space and always occupy a multiple of 16KB.
Look at your tile sizes - can you see how a large number of small tiles will occupy a large amount of space?
FAT32 also has limits on the number of files that can be stored in a single directory - i read on one site that the limit is 268,173,300.
That might or might not be a problem with directories containing many tiles.
Search the forum for
MBTiles.
This is an alternative format for offline tiles.
One advantage of the MBTiles format is that it tries to reduce or eliminate duplicate tiles.
For example, if you have an area of sea you will likely have
many identical tiles for many tile positions and many zoom levels.
MBTiles is a solution for this.
Reducing the number of identical tiles
might significantly reduce the size of your tile archive.
The b4a OSMDroid library currently has no support for MBTiles.
I could add support for MBTiles - as long as i can find some code examples that show how to implement it.
With AHViewPager i think re-initializing the entire MapView again is the only solution that will work.
It gets destroyed when scrolled more than 1 page away so must be re-created and re-initialized.
Though i seem to remember that you could specify how many pages the AHViewPager keeps in memory at any one time.
If the default is 3 pages - the current page and pages to the left and right of the current page.
If that number could be increased you might be able to avoid the page containing the MapView being destroyed.
