为离线web应用程序(客户端存储数据库)存储图像数据

I have an offline web application using appcaching. I need to provide it about 10MB - 20MB of data that it will save (client-side) consisting mainly of PNG image files. The operation is as follows:

我有一个使用appcache的离线web应用程序。我需要提供它将保存(客户端)的大约10MB - 20MB的数据，这些数据主要由PNG图像文件组成。操作如下:

1. Web application downloads and installs in appcache (uses manifest)
2. Web应用程序在appcache中下载和安装(使用清单)
3. Web app requests from server PNG data files (how? - see alternatives below)
4. 来自服务器PNG数据文件的Web应用程序请求(如何?见下面的选择)
5. Occasionally web app resyncs with server, and does small partial updates/deletes/additions to PNG database
6. web应用程序偶尔会与服务器同步，并对PNG数据库进行小的部分更新/删除/添加
7. FYI: Server is a JSON REST server, that can place files in wwwroot for pickup
8. 提示:服务器是一个JSON REST服务器，它可以将文件放在wwwroot中进行提取

Here is my current analysis of client-based "databases" that handle binary blob storage

下面是我对处理二进制blob存储的基于客户端的“数据库”的当前分析

SEE UPDATE at Bottom

• AppCache (via manifest add all the PNG and then update on demand)
  • CON: any change of a PNG database item will mean complete download of all items in manifest (Really bad news!)
  • 反方:PNG数据库项的任何更改将意味着清单中所有项的完整下载(真是坏消息!)
• AppCache(通过manifest添加所有PNG，然后按需更新)CON: PNG数据库项的任何更改将意味着清单中所有项的完整下载(真是坏消息!)
• WebStorage
  • CON: Designed for JSON storage
  • 缺点:为JSON存储而设计
  • CON: can only store blobs via base64 encoding (probably fatal flaw due to cost of de-encoding)
  • 缺点:只能通过base64编码来存储blobs(可能由于去编码的成本而导致致命的缺陷)
  • CON: Hard limit of 5MB for webStorage http://htmlui.com/blog/2011-08-23-5-obscure-facts-about-html5-localstorage.html
  • 缺点:webStorage (http://htmlui.com/blog/2011-08-23-5-obscure- facre - abouthtml5 -localstorage.html)的硬限制为5MB
• WebStorage CON:为JSON存储而设计的CON:只能通过base64编码存储blobs(可能由于解码成本而致命的缺陷)CON: WebStorage http://htmlui.com/blog/2011-08-2-3-5 -obscure-facts- html5-localstorage.html的5MB的硬限制
• PhoneGap & SQLLite
  • CON: Sponsor will reject it as a native app requiring certification
  • 缺点:赞助商会拒绝它作为一个需要认证的本地应用
• PhoneGap & SQLLite CON:赞助商将拒绝它作为需要认证的本地应用
• ZIP file
  • Server creates a zip file, places it in wwwroot, and notifies client
  • 服务器创建一个zip文件，将其放在wwwroot中，并通知客户端
  • user has to manually unzip (At least that is how I see it) and save to client file system
  • 用户必须手动解压(至少我是这么看的)并保存到客户端文件系统
  • Web app uses FileSystem API to reference files
  • Web应用程序使用文件系统API来引用文件
  • CON: ZIP might be too large (zip64?), long time to create
  • 缺点:ZIP可能太大(zip64?)，创建时间太长
  • CON: Not sure if FileSystem API can always read out of the sandbox (I think so)
  • 缺点:不确定文件系统API是否总是能从沙箱中读出(我想是的)
• ZIP文件服务器创建一个ZIP文件,地方wwwroot,和通知客户端用户必须手动解压(至少我看到它)和保存到客户端文件系统Web应用程序使用文件系统API参考文件反对:邮政可能太大(zip64 ?),长时间来创建反对:不确定文件系统API可以读出的沙箱(我这么认为)
• USB or SD card (back to the stone age....)
  • The user will be local to the server before going offline
  • 在脱机之前，用户将是本地服务器。
  • So we could have him insert a SD card, let the server fill it with PNG files
  • 我们可以让他插入一张SD卡，让服务器用PNG文件填充
  • Then the user will plug it into the laptop, tablet
  • 然后用户将它插入笔记本电脑，平板电脑
  • Web app will use FileSystem API to read the files
  • Web应用程序将使用文件系统API来读取文件
  • CON: Not sure if FileSystem API can always read out of the sandbox (I think so)
  • 缺点:不确定文件系统API是否总是能从沙箱中读出(我想是的)
• USB或SD卡(回到石器时代....)用户将本地离线服务器之前,我们可以让他插入SD卡,让服务器填充PNG文件然后用户将把它插到笔记本电脑,平板电脑Web应用程序将使用文件系统API来读取文件反对:不确定文件系统API可以读出的沙箱(我这么认为)
• WebSQL
  • CON: w3c has abandoned it (pretty bad)
  • 缺点:w3c放弃了它(相当糟糕)
  • I might consider a Javascript wrapper that uses IndexedDB and WebSQL as a fall-back
  • 我可能会考虑使用IndexedDB和WebSQL作为备份的Javascript包装器
• WebSQL CON: w3c已经放弃了它(非常糟糕)，我可能会考虑使用IndexedDB和WebSQL作为后备的Javascript包装器
• FileSystem API
  • Chrome supports read/write of blobs
  • Chrome支持blobs的读写
  • CON: not clear about IE and FireFox (IE10, has non-standard msSave)
  • 缺点:不清楚IE和FireFox (IE10有非标准的msSave)
  • caniuse.com reports IOS and Android support (but again, is this just r/w of JSON, or does it include the full blob API for writing?
  • caniuse.com报告了IOS和Android的支持(但同样，这是JSON的r/w，还是包含完整的blob API用于编写?)
  • CON: FireFox folks dislike FileSystem API & not clear if they are supporting saving blobs: https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/
  • 缺点:FireFox不喜欢文件系统API &不清楚他们是否支持保存blobs: https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/
  • PRO: Much faster than IndexedDB for blobs according to jsperf http://jsperf.com/indexeddb-vs-localstorage/15 (page 2)
  • PRO:根据jsperf http://jsperf / IndexedDB -vs-localstorage/15, blobs比IndexedDB快得多(第2页)
• 文件系统API Chrome支持blobs CON的读写:不清楚IE和FireFox (IE10，有非标准的msSave) caniuse.com报告了IOS和Android的支持(但同样，这只是JSON的r/w，还是包含完整的blob API用于写作?)缺点:FireFox不喜欢文件系统API，不清楚他们是否支持保存blobs: https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/ PRO:根据jsperf http://jsperf.com/indexeddb-vs-localstorage/15(第2页)
• IndexedDB
  • Good support in IE10, FireFox (save, read blobs)
  • 支持IE10, FireFox(保存，读取blobs)
  • Good speed and easier management than a file system (deletes, updates)
  • 比文件系统更快更容易管理(删除，更新)
  • PRO: see speed tests: http://jsperf.com/indexeddb-vs-localstorage/15
  • PRO:请参阅速度测试:http://jsperf.com/indexeddb-vs-localstorage/15
  • See this article on storing and display of images in IndexedDB: https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/
  • 请参阅本文关于在IndexedDB中存储和显示图像的文章:https://hacks.mozilla.org/2012/02/storing-images-- and- files-indexeddb/
  • CON: I confirmed that Chrome does not yet support blob writing (current bug, but not clear when it will be fixed)
  • 缺点:我确认Chrome还不支持blob写入(当前的bug，但不清楚什么时候会修复)
  • UPDATE: Chrome developers confirm they are working on this for both desktop and android! no timeline yet.
  • 更新:Chrome开发人员确认他们正在为桌面和android开发这款应用!没有时间表。
• IndexedDB好支持IE10浏览器,FireFox(保存、读取blob)良好的速度和更容易管理比文件系统(删除、更新)专业:看到速度测试:http://jsperf.com/indexeddb-vs-localstorage/15看到本文的图像存储和显示IndexedDB:https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/反对:我证实,Chrome还不支持blob写作(目前的缺陷,但不清楚何时固定)更新:Chrome开发人员确认他们正在为桌面和android开发这款应用!没有时间表。
• LawnChair JavaScript wrapper http://brian.io/lawnchair/
  • PRO: very clean wrapper for IndexedDB, WebSQL or whatever database you have (think polyfill)
  • PRO: IndexedDB、WebSQL或任何数据库的非常干净的包装器(想想polyfill)
  • CON: cannot store binary blobs, only data:uri (base64 encoding) (probably fatal flaw due to cost of de-encoding)
  • 缺点:不能存储二进制blobs，只能存储数据:uri (base64编码)(可能由于反编码成本而致命的缺陷)
• LawnChair JavaScript包装器http://brian。io/lawnchair/ PRO: IndexedDB、WebSQL或任何数据库的非常干净的包装器(想想polyfill) CON:不能存储二进制blobs，只能存储数据:uri (base64编码)(可能由于反编码成本的致命缺陷)
• IndexedDB JQUERY polyFill https://github.com/axemclion/jquery-indexeddb
  • Parashuram has writtent a nice JQUERY wrapper for the raw IndexedDB interface
  • Parashuram为原始的IndexedDB接口编写了一个漂亮的JQUERY包装器
  • PRO: greatly simplifies using IndexedDB, I was hoping to add a shim/polyfill for Chrome FileSystemAPI
  • PRO:使用IndexedDB大大简化，我希望为Chrome文件系统api添加一个shim/polyfill
  • CON: It should handle blobs, but I was unable to get it to work
  • 反面观点:它应该能处理斑点，但我没办法让它工作
• IndexedDB JQUERY polyFill https://github.com/axemclion/jquery-indexeddb Parashuram为原始的IndexedDB接口PRO编写了一个漂亮的JQUERY包装:极大地简化了使用IndexedDB的过程
• idb.filesystem.js http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api
  • Eric Bidelman @ Google has written a well tested PolyFill the FileSystem API that uses Indexed DB as a fall back
  • Eric Bidelman @谷歌编写了一个经过良好测试的PolyFill文件系统API，它使用索引DB作为后退
  • PRO: FileSystem API is well suited for storing blobs
  • PRO:文件系统API非常适合存储blobs
  • PRO: works great on FireFox and Chrome
    • PRO: great for synchronizing with cloud based CouchDB
    • PRO:非常适合与基于云的CouchDB同步。
  • PRO:在FireFox和Chrome PRO上运行良好:非常适合与基于云的CouchDB进行同步
  • CON: no clear why, but it is not working on IE10
  • 反方:不清楚为什么，但它并没有在IE10上发挥作用
• idb.filesystem。js Eric Bidelman @ http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api谷歌已经写好测试PolyFill FileSystem API使用DB回落PRO:索引文件系统API非常适合存储blob PRO:伟大的工作在FireFox和Chrome正方观点:对同步和基于云的CouchDB反对:不清楚为什么,但它不是问世
• PouchDB JavaScript Library http://pouchdb.com/
  • great for syncing a CouchDB with a local DB (uses either WebSQL or IndexedDB (not my problem though)
  • 非常适合与本地DB同步CouchDB(使用WebSQL或IndexedDB(但不是我的问题))
  • CON: NO CONS, PouchDB now supports binary blobs for all recent browsers (IE, Chrome, Firefox, Chrome on mobile, etc.) as well as many older browsers. That was not the case when I first did this post.
  • 缺点:没有缺点，PouchDB现在支持所有最近的浏览器(IE, Chrome, Firefox, Chrome on mobile等)和许多旧浏览器的二进制blobs。当我第一次写这篇文章时，情况并非如此。
• PouchDB JavaScript库http://pouchdb.com/非常适合与本地数据库同步CouchDB(使用WebSQL或IndexedDB(这不是我的问题)CON:没有缺点，PouchDB现在支持所有最近的浏览器(比如，Chrome, Firefox，移动浏览器Chrome等)和许多旧浏览器的二进制blobs。当我第一次写这篇文章时，情况并非如此。

NOTE: to see a data:uri encoding of PNG I created an example at: http://jsbin.com/ivefak/1/edit

注意:要查看PNG的数据:uri编码，我在http://jsbin.com/ivefak/1/edit上创建了一个示例

Desired/Usefull/Uneeded Features

所需的/有用/ Uneeded特性

• No native (EXE, PhoneGap, ObjectiveC, etc) app on client (pure web application)
• 客户端上没有本机(EXE、PhoneGap、ObjectiveC等)应用程序(纯web应用程序)
• Only needs to run on latest Chrome, FireFox, IE10 for laptops
• 只需要在最新的Chrome, FireFox, IE10上运行
• Strongly want same solution for Android Tablet (IOS would be nice too) but only need one browser to work (FF, Chrome, etc.)
• 强烈希望Android平板电脑也有同样的解决方案(IOS也不错)，但只需要一个浏览器就可以运行(FF、Chrome等)。
• Fast initial DB population
• 快速初始DB人口
• REQUIREMENT: Very fast retrieval of images by web application from storage (DB, file)
• 需求:通过web应用程序从存储(DB, file)快速检索图像
• Not meant for consumers. We can restrict browsers, and ask user to do special setup & tasks, but let's minimize that
• 不意味着对消费者。我们可以限制浏览器，并要求用户执行特殊的设置和任务，但是让我们最小化它。

IndexedDB Implementations

IndexedDB实现

• There is an excellent article on how IE,FF,and Chrome internally implement this at: http://www.aaron-powell.com/web/indexeddb-storage
• 有一篇很好的文章介绍了IE、FF和Chrome的内部实现方式:http://www.aaron-powell.com/web/indexeddb-storage。
• In short:
  • IE uses the same database format as Exchange and Active Directory for IndexedDB
  • IE使用与IndexedDB的Exchange和Active Directory相同的数据库格式
  • Firefox is using SQLite so are kind of implementing a NoSQL database in to SQL database
  • Firefox使用的是SQLite，所以在SQL数据库中实现了NoSQL数据库
  • Chrome (and WebKit) are using a Key/ Value store which has heritage in BigTable
  • Chrome(和WebKit)正在使用一个密钥/值存储库，它在BigTable中具有传统
• 简而言之:IE使用与Exchange相同的数据库格式，而IndexedDB Firefox使用的是SQLite，所以在SQL数据库中实现NoSQL的数据库Chrome(和WebKit)使用的是在BigTable中有历史的密钥/值存储

My Current Results

我现在的结果

• I chose to use an IndexedDB approach (and polyfill with FileSystemAPI for Chrome until they ship blob support)
• 我选择了使用IndexedDB方法(并且在使用Chrome的时候，使用了多填充的文件系统api，直到他们使用blob支持)
• For fetching the tiles, I had a dilemna since the JQUERY folks are kvetching about adding this to AJAX
• 对于取回这些块，我遇到了一个两难的问题，因为JQUERY开发人员对将其添加到AJAX感到不满
• I went with XHR2-Lib by Phil Parsons, which is very much like JQUERY .ajax() https://github.com/p-m-p/xhr2-lib
• 我使用了Phil Parsons的XHR2-Lib，非常像JQUERY .ajax() https://github.com/p-m-p/xhr2-lib。
• Performance for 100MB downloads (IE10 4s, Chrome 6s, FireFox 7s).
• 100MB下载的性能(IE10 4s, Chrome 6s, FireFox 7s)。
• I could not get any of the IndexedDB wrappers to work for blobs (lawnchair, PouchDB, jquery-indexeddb, etc.)
• 我无法让任何IndexedDB包装器用于blobs (lawnchair、PouchDB、jquery-indexeddb等)。
• I rolled my own wrapper, and performance is (IE10 2s, Chrome 3s, FireFox 10s)
• 我推出了我自己的包装，性能是(IE10 2s, Chrome 3s, FireFox 10s)
• With FF, I assume we are seeing the performance issue of using a relational DB (sqllite) for a non-sql storage
• 在FF中，我假设我们看到了使用关系数据库(sqllite)来实现非sql存储的性能问题。
• NOTE, Chrome has outstanding debug tools (developer tab, resources) for inspecting the state of the IndexedDB.
• 注意，Chrome有出色的调试工具(developer选项卡，参考资料)来检查IndexedDB的状态。

FINAL Results posted below as answer

最终结果公布在下面作为答案

Update

PouchDB now supports binary blobs for all recent browsers (IE, Chrome, Firefox, Chrome on mobile, etc.) as well as many older browsers. That was not the case when I first did this post.

PouchDB现在支持所有最近的浏览器(比如，Chrome, Firefox，移动浏览器的Chrome等等)以及许多旧浏览器的二进制blobs。当我第一次写这篇文章时，情况并非如此。

4 个解决方案

#1

Results Offline blob cache for PNG slippy maps

结果PNG slippy映射的离线blob缓存

Testing

测试

• 171 PNG files (total of 3.2MB)
• 171个PNG文件(共3.2MB)
• Platforms tested: Chrome v24, FireFox 18, IE 10
• 测试平台:Chrome v24, FireFox 18, ie10。
• Should also work with Chrome & FF for Android
• 还应该使用Chrome和FF操作Android吗

Fetch from web server

获取从web服务器

• using XHR2 (supported on almost all browsers) for blob download from web server
• 使用XHR2(几乎所有浏览器都支持)从web服务器下载blob
• I went with XHR2-Lib by Phil Parsons, which is very much like JQUERY .ajax()
  • https://github.com/p-m-p/xhr2-lib
  • https://github.com/p-m-p/xhr2-lib
• 我使用了Phil Parsons的XHR2-Lib，非常像JQUERY .ajax() https://github.com/p-m-p/xhr2-lib。

Storage

存储

• IndexedDB for IE and FireFox
• 用于IE和FireFox的IndexedDB
• Chrome: Polyfill (blob stored using FileSystem API, reference kept in IndexedDB) polyfill
• Chrome: Polyfill (blob存储在文件系统API中，引用保存在IndexedDB中)Polyfill
• A Must read article on "How the browsers store IndexedDB data"
  • http://www.aaron-powell.com/web/indexeddb-storage
  • http://www.aaron-powell.com/web/indexeddb-storage
• 必须阅读关于“浏览器如何存储IndexedDB数据”的文章http://www.aaron-powell.com/web/indexeddb-storage
• Note: FireFox uses SQLlite for the NOSQL IndexedDB. That might be the reason for the slow performance. (blobs stored separately)
• 注意:FireFox对NOSQL IndexedDB使用SQLlite。这可能是表现不佳的原因。(blob存储分开)
• Note: Microsoft IE uses the extensible storage engine:
  • http://en.wikipedia.org/wiki/Extensible_Storage_Engine
  • http://en.wikipedia.org/wiki/Extensible_Storage_Engine
• 注意:Microsoft IE使用可扩展存储引擎:http://en.wikipedia.org/wiki/Extensible_Storage_Engine
• Note: Chrome uses LevelDB http://code.google.com/p/leveldb/
• 注意:Chrome使用的是LevelDB http://code.google.com/p/leveldb/

Display

显示

• I am using Leaflet http://leafletjs.com/ to show the map tiles
• 我正在使用传单http://leafletjs.com/来显示地图块
• I used the functional tile layer plugin by Ishmael Smyrnow for fetching the tile layer from the DB
  • https://github.com/ismyrnow/Leaflet.functionaltilelayer
  • https://github.com/ismyrnow/Leaflet.functionaltilelayer
• 我使用了Ishmael Smyrnow的功能平铺层插件从DB https://github.com/ismyrnow/Leaflet.functionaltilelayer获取平铺层
• I compared the DB-based tiles layer with a purely local (localhost://) storage
• 我比较了基于db的tiles层和一个纯粹本地(localhost://)存储。
• There is no noticeable difference in performance! between using IndexedDB and local files!
• 在性能上没有明显的区别!在使用IndexedDB和本地文件之间!

Results

结果

• Chrome: Fetch (6.551s), Store (8.247s), Total Elapsed Time: (13.714s)
• Chrome: Fetch(6.551)、Store (8.247s)、总用时:(13.714s)
• FireFox: Fetch (0.422s), Store (31.519s), Total Elapsed Time: (32.836s)
• FireFox: Fetch(0.422秒)、Store(31.519秒)、总用时:(32.836秒)
• IE 10: Fetch (0.668s), Store: (0.896s), Total Elapsed Time: (3.758s)
• IE 10: Fetch (0.668s)， Store: (0.896s)，总用时:(3.758s)

#2

For your requirements I suggest that developing a new polyfill based on two others: FileSystem API to IndexedDB and IndexedDB to WebSQL — is the best option.

对于您的需求，我建议基于另外两个开发一个新的polyfill:用于IndexedDB的文件系统API和指向WebSQL的IndexedDB—是最好的选择。

The former one will enable support for storing blobs in Chrome (FileSystem API) and Firefox (IndexedDB), while the latter should provide the support for Android and iOS (WebSQL). What is needed is just making these polyfills work together, and I suppose it's not hard.

前者将支持在Chrome(文件系统API)和Firefox (IndexedDB)中存储blobs，而后者应该支持Android和iOS (WebSQL)。我们需要的是让这些填充材料一起工作，我想这并不难。

NB: Since I couldn't find any information on the web about this, you should test if storing blobs using the WebSQL polyfill will work on iOS and Android. It looks like it should work though:

NB:因为我在网上找不到关于这个的任何信息，你应该测试一下使用WebSQL polyfill存储blobs是否适用于iOS和Android。看起来它应该是有效的:

var sql = ["CREATE TABLE", idbModules.util.quote(storeName), "(key BLOB", createOptions.autoIncrement ? ", inc INTEGER PRIMARY KEY AUTOINCREMENT" : "PRIMARY KEY", ", value BLOB)"].join(" ")

Source

源

#3

A few years back (not exactly the stone age), I was using a signed java applet that would query its server for syncing/updating requirements, download appropriate files from the server and save them on the user's filesystem (not a database). That solution might work for you, although you will need someone to write the applet and sign it. For database solutions, such an applet can use the jdbc available for most databases using localhost on a suitable port (e.g., 3306 for MySQL). I believe the applet tag is deprecated in Html5 but it still works. No experience on Android tablets, so can't comment on that part.

几年前(不完全是石器时代)，我使用了一个签名的java applet，它可以查询服务器的同步/更新需求，从服务器下载适当的文件，并将它们保存在用户的文件系统(而不是数据库)上。这个解决方案可能适合您，尽管您需要有人编写applet并签名。对于数据库解决方案，这样的小应用程序可以使用在适当端口上使用localhost的jdbc来访问大多数数据库(例如，对于MySQL, 3306)。我相信applet标签在Html5中已经过时了，但是它仍然可以工作。没有Android平板电脑的经验，所以不能评论这部分。

#4

I have map caching examples(open example, discover regions and zooms, switch offline and discovered regions will availaible).

我有映射缓存示例(打开示例、发现区域和缩放、脱机切换和发现区域将可用)。

There are map.js - map layer for offline tiles, storage.js - storage implementation based on IndexedDb and WebSQL (but this just test implementation with poor performance).

有地图。js -贴图层为离线贴图，存储。js -基于IndexedDb和WebSQL的存储实现(但这只是对性能较差的实现进行测试)。

• For site files (html, css, js and etc.) I prefer use application cache.
• 对于站点文件(html、css、js等)，我更喜欢使用应用程序缓存。
• For storage I prefer use Indexed DB (support blob), Web SQL (only base64), FileWriter (support blob, but only chrome). Frankly storage is big issue for this. You need the fastest key value solution that will mix them all. I think is good decision to use exist solution.
• 对于存储，我更喜欢使用索引DB(支持blob)、Web SQL(只使用base64)、FileWriter(支持blob，但只使用chrome)。坦率地说，存储是一个大问题。您需要最快的键值解决方案来混合它们。我认为使用现有的解决方案是明智的。
• For fetching I used canvas with CORS. But I thinking about WebWorkers and XHR2 and this can be better instead canvas because canvas have some troubles with CORS in different browsers and other (for example this title was stored bad in opera).
• 取的时候我用的是帆布。但是我想到了webworker和XHR2，这可以替代canvas，因为canvas在不同的浏览器和其他浏览器中与CORS有一些问题(例如，这个标题在opera中存储得很糟糕)。

Additional information about sizes for 2 billion city (Minsk):

关于20亿城市(明斯克)规模的附加信息:

• Zoom - 9, tiles - 2, size - 52 kb, with previous - 52 kb;
• 缩放- 9，贴图- 2，大小- 52kb，先前- 52kb;
• Zoom - 10, tiles - 3, size - 72 kb, with previous - 124 kb;
• 缩放- 10，贴图- 3，大小- 72 kb，先前- 124kb;
• Zoom - 11, tiles - 7, size - 204 kb, with previous - 328 kb;
• 缩放- 11，花砖- 7，大小- 204 kb，与先前- 328 kb;
• Zoom - 12, tiles - 17, size - 348 kb, with previous - 676 kb;
• 缩放- 12，花砖- 17，大小- 348kb，先前- 676kb;
• Zoom - 13, tiles - 48, size - 820 kb, with previous - 1.5 mb;
• 缩放- 13，平铺- 48，大小- 820kb，先前- 1.5 mb;
• Zoom - 14, tiles - 158, size - 2.2 mb, with previous - 3.7 mb;
• Zoom - 14，瓷砖- 158，大小- 2.2 mb，与之前- 3.7 mb;
• Zoom - 15, tiles - 586, size - 5.5 mb, with previous - 9.3 mb;
• 变焦- 15，贴图- 586，大小- 5.5 mb，先前- 9.3 mb;
• Zoom - 16, tiles - 2264, size - 15 mb, with previous - 24.3 mb;
• 变焦- 16，贴图- 2264，大小- 15 mb，先前- 24.3 mb;