앱 캐싱을 사용하는 오프라인 웹 애플리케이션이 있습니다. 주로 PNG 이미지 파일로 구성된 (클라이언트 측) 저장할 데이터의 약 10MB-20MB를 제공해야합니다. 작업은 다음과 같습니다.

1. 웹 애플리케이션 다운로드 및 appcache에서 설치 (매니페스트 사용)
2. 서버 PNG 데이터 파일의 웹 앱 요청 (방법?-아래 대안 참조)
3. 때때로 웹 앱이 서버와 다시 동기화되고 PNG 데이터베이스에 대한 작은 부분 업데이트 / 삭제 / 추가 작업을 수행합니다.
4. 참고 : 서버는 픽업을 위해 wwwroot에 파일을 배치 할 수있는 JSON REST 서버입니다.

다음은 이진 Blob 저장소를 처리하는 클라이언트 기반 "데이터베이스"에 대한 현재 분석입니다.

하단에서 업데이트보기

• AppCache (매니페스트를 통해 모든 PNG를 추가 한 다음 요청시 업데이트)
  • 단점 : PNG 데이터베이스 항목이 변경되면 매니페스트의 모든 항목이 완전히 다운로드됩니다 (정말 나쁜 소식입니다!).
• WebStorage
  • 단점 : JSON 스토리지 용으로 설계됨
  • 단점 : base64 인코딩을 통해서만 blob을 저장할 수 있습니다 (디 인코딩 비용으로 인해 치명적인 결함 일 수 있음).
  • 단점 : webStorage에 대한 하드 제한 5MB http://htmlui.com/blog/2011-08-23-5-obscure-facts-about-html5-localstorage.html
• PhoneGap 및 SQLLite
  • 단점 : 스폰서는 인증이 필요한 기본 앱으로 거부합니다.
• 압축 파일
  • 서버가 zip 파일을 생성하고이를 wwwroot에 배치하고 클라이언트에 알립니다.
  • 사용자는 수동으로 압축을 풀고 (적어도 내가 보는 방식) 클라이언트 파일 시스템에 저장해야합니다.
  • 웹 앱은 FileSystem API를 사용하여 파일을 참조합니다.
  • 단점 : ZIP이 너무 클 수 있습니다 (zip64?), 생성하는 데 시간이 오래 걸립니다.
  • 단점 : FileSystem API가 항상 샌드 박스에서 읽을 수 있는지 확실하지 않습니다.
• USB 또는 SD 카드 (석기 시대로 돌아 가기 ....)
  • 사용자는 오프라인으로 전환하기 전에 서버에 로컬입니다.
  • 그래서 우리는 그에게 SD 카드를 삽입하도록 할 수 있고, 서버가 그것을 PNG 파일로 채우도록 할 수 있습니다.
  • 그런 다음 사용자는 노트북, 태블릿에 연결합니다.
  • 웹 앱은 FileSystem API를 사용하여 파일을 읽습니다.
  • 단점 : FileSystem API가 항상 샌드 박스에서 읽을 수 있는지 확실하지 않습니다.
• WebSQL
  • 단점 : w3c가 포기했습니다.
  • IndexedDB 및 WebSQL을 폴백으로 사용하는 Javascript 래퍼를 고려할 수 있습니다.
• FileSystem API
  • Chrome은 Blob 읽기 / 쓰기를 지원합니다.
  • 단점 : IE 및 FireFox에 대해 명확하지 않음 (IE10, 비표준 msSave 포함)
  • caniuse.com은 IOS 및 Android 지원을보고합니다 (하지만 이것은 JSON의 r / w 일 뿐입니 까, 아니면 작성을위한 전체 blob API를 포함합니까?
  • 단점 : FireFox 사람들은 FileSystem API를 싫어하고 blob 저장을 지원하는지 명확하지 않습니다 : https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/
  • PRO : jsperf http://jsperf.com/indexeddb-vs-localstorage/15 에 따라 Blob 용 IndexedDB보다 훨씬 빠름 (2 페이지)
• IndexedDB
  • IE10, FireFox에서 우수한 지원 (Blob 저장, 읽기)
  • 파일 시스템보다 빠르고 쉬운 관리 (삭제, 업데이트)
  • PRO : 속도 테스트 참조 : 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 자바 스크립트 래퍼 http://brian.io/lawnchair/
  • PRO : IndexedDB, WebSQL 또는 보유하고있는 모든 데이터베이스에 대한 매우 깨끗한 래퍼 (폴리 필을 생각해보세요)
  • 단점 : 바이너리 blob을 저장할 수없고 data : uri (base64 인코딩) 만 (아마도 디코딩 비용으로 인해 치명적인 결함이 있음)
• IndexedDB JQUERY polyFill https://github.com/axemclion/jquery-indexeddb
  • Parashuram은 원시 IndexedDB 인터페이스에 대한 멋진 JQUERY 래퍼를 작성했습니다.
  • PRO : IndexedDB 사용을 크게 단순화합니다. Chrome FileSystemAPI에 대한 shim / polyfill을 추가하고 싶었습니다.
  • 단점 : Blob을 처리해야하지만 작동하지 못했습니다.
• idb.filesystem.js http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api
  • Eric Bidelman @ Google은 Indexed DB를 폴백으로 사용하는 파일 시스템 API 인 PolyFill을 잘 테스트했습니다.
  • PRO : FileSystem API는 Blob 저장에 적합합니다.
  • PRO : FireFox 및 Chrome에서 잘 작동합니다.
    • PRO : 클라우드 기반 CouchDB와의 동기화에 적합
  • 단점 : 이유는 명확하지 않지만 IE10에서는 작동하지 않습니다.
• PouchDB 자바 스크립트 라이브러리 http://pouchdb.com/
  • CouchDB를 로컬 DB와 동기화하는 데 적합합니다 (WebSQL 또는 IndexedDB 사용 (내 문제는 아님))
  • 단점 : 단점 없음, PouchDB는 이제 모든 최신 브라우저 (IE, Chrome, Firefox, 모바일 용 Chrome 등) 및 많은 이전 브라우저에 대해 바이너리 Blob을 지원합니다. 이 게시물을 처음했을 때는 그렇지 않았습니다.

참고 : PNG의 data : uri 인코딩을 보려면 http://jsbin.com/ivefak/1/edit 에서 예제를 만들었습니다.

원하는 / 유용한 / 유용하지 않은 기능

• 클라이언트 (순수 웹 애플리케이션)에 네이티브 (EXE, PhoneGap, ObjectiveC 등) 앱 없음
• 노트북 용 최신 Chrome, FireFox, IE10에서만 실행하면됩니다.
• Android 태블릿에 대해 동일한 솔루션을 강력히 원하지만 (IOS도 좋을 것입니다) 작동하려면 브라우저가 하나만 필요합니다 (FF, Chrome 등).
• 빠른 초기 DB 채우기
• 요구 사항 : 저장소 (DB, 파일)에서 웹 애플리케이션으로 이미지를 매우 빠르게 검색
• 소비자를위한 것이 아닙니다. 브라우저를 제한하고 사용자에게 특별한 설정 및 작업을 요청할 수 있지만 최소화하겠습니다.

IndexedDB 구현

• IE, FF 및 Chrome이 내부적으로이를 구현하는 방법에 대한 훌륭한 기사가 http://www.aaron-powell.com/web/indexeddb-storage에 있습니다.
• 요컨대 :
  • IE는 IndexedDB에 대해 Exchange 및 Active Directory와 동일한 데이터베이스 형식을 사용합니다.
  • Firefox는 SQLite를 사용하므로 SQL 데이터베이스에 NoSQL 데이터베이스를 구현하는 것과 같습니다.
  • Chrome (및 WebKit)은 BigTable에 유산이있는 키 / 값 저장소를 사용하고 있습니다.

내 현재 결과

• IndexedDB 접근 방식을 사용하기로 선택했습니다 (그리고 Blob 지원을 제공 할 때까지 Chrome 용 FileSystemAPI로 폴리 필)
• 타일을 가져 오기 위해 JQUERY 사람들이 이것을 AJAX에 추가하는 것에 대해 kvetching 때문에 나는 딜레마를 가졌습니다.
• Phil Parsons의 XHR2-Lib를 사용했는데 JQUERY .ajax () https://github.com/pmp/xhr2-lib 와 매우 비슷합니다.
• 100MB 다운로드 성능 (IE10 4s, Chrome 6s, FireFox 7s).
• Blob (lawnchair, PouchDB, jquery-indexeddb 등)에 대해 작동하도록 IndexedDB 래퍼를 가져올 수 없습니다.
• 내 래퍼를 감았는데 성능은 (IE10 2s, Chrome 3s, FireFox 10s)
• FF를 사용하면 비 SQL 스토리지에 관계형 DB (sqllite)를 사용할 때 성능 문제가 발생한다고 가정합니다.
• 참고로 Chrome에는 IndexedDB의 상태를 검사하기위한 뛰어난 디버그 도구 (개발자 탭, 리소스)가 있습니다.

답변으로 아래 게시 된 최종 결과

최신 정보

PouchDB는 이제 모든 최신 브라우저 (IE, Chrome, Firefox, 모바일 용 Chrome 등)와 많은 이전 브라우저에 대해 바이너리 Blob을 지원합니다. 이 게시물을 처음했을 때는 그렇지 않았습니다.

PNG 미끄러운 맵에 대한 오프라인 Blob 캐시

테스팅

• PNG 파일 171 개 (총 3.2MB)
• 테스트 된 플랫폼 : Chrome v24, FireFox 18, IE 10
• Android 용 Chrome 및 FF에서도 작동해야합니다.

웹 서버에서 가져 오기

• 웹 서버에서 Blob 다운로드를 위해 XHR2 (거의 모든 브라우저에서 지원됨) 사용
• JQUERY .ajax ()와 매우 유사한 Phil Parsons의 XHR2-Lib를 사용했습니다.
  • https://github.com/pmp/xhr2-lib

저장

• IE 및 FireFox 용 IndexedDB
• Chrome : Polyfill (FileSystem API를 사용하여 저장된 Blob, IndexedDB에 보관 된 참조) polyfill
• "브라우저가 IndexedDB 데이터를 저장하는 방법"에 대한 기사를 읽어야합니다.
  • http://www.aaron-powell.com/web/indexeddb-storage
• 참고 : FireFox는 NOSQL IndexedDB에 SQLlite를 사용합니다. 이것이 느린 성능의 이유 일 수 있습니다. (별도로 저장된 블랍)
• 참고 : Microsoft IE는 확장 가능한 저장소 엔진을 사용합니다.
  • http://en.wikipedia.org/wiki/Extensible_Storage_Engine
• 참고 : Chrome은 LevelDB http://code.google.com/p/leveldb/를 사용합니다 .

디스플레이

• 지도 타일을 표시하기 위해 Leaflet http://leafletjs.com/ 을 사용 하고 있습니다.
• DB에서 타일 레이어를 가져 오기 위해 Ishmael Smyrnow의 기능 타일 레이어 플러그인을 사용했습니다.
  • https://github.com/ismyrnow/Leaflet.functionaltilelayer
• DB 기반 타일 레이어를 순수 로컬 (localhost : //) 저장소와 비교했습니다.
• 성능에는 눈에 띄는 차이가 없습니다! IndexedDB와 로컬 파일 사용 사이!

결과

• Chrome : 가져 오기 (6.551 초), 저장 (8.247 초), 총 경과 시간 : (13.714 초)
• FireFox : 가져 오기 (0.422s), 저장 (31.519s), 총 경과 시간 : (32.836s)
• IE 10 : 가져 오기 (0.668s), Store : (0.896s), 총 경과 시간 : (3.758s)

요구 사항에 따라 FileSystem API에서 IndexedDB로 , IndexedDB에서 WebSQL 로의 다른 두 가지를 기반으로 새로운 polyfill을 개발하는 것이 최선의 선택입니다.

전자는 Chrome (FileSystem API) 및 Firefox (IndexedDB)에 Blob 저장을 지원하는 반면 후자는 Android 및 iOS ( WebSQL )에 대한 지원을 제공해야합니다 . 필요한 것은 이러한 polyfill이 함께 작동하도록 만드는 것입니다. 나는 그것이 어렵지 않다고 생각합니다.

NB : 웹에서 이에 대한 정보를 찾을 수 없기 때문에 WebSQL 폴리 필을 사용하여 Blob을 저장하는 것이 iOS 및 Android에서 작동하는지 테스트해야합니다. 그래도 작동해야 할 것 같습니다.

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

출처

지도 캐싱 예제가 있습니다 ( 예제 열기, 지역 검색 및 확대 / 축소, 오프라인 전환 및 검색된 지역 사용 가능).

있습니다 map.js- 오프라인 타일에 대한지도 층 storage.js- 색인화 및 WebSQL에 기반 스토리지 구현 (하지만 성능 저하이 단지 시험 구현).

• 사이트 파일 (html, css, js 등)의 경우 애플리케이션 캐시를 선호합니다.
• 스토리지의 경우 Indexed DB (Blob 지원), Web SQL (base64 만 해당), FileWriter (Blob 지원, Chrome 만 지원)를 선호합니다. 솔직히 스토리지는 이것에 대한 큰 문제입니다. 이들을 모두 혼합 할 수있는 가장 빠른 핵심 가치 솔루션이 필요합니다. 기존 솔루션을 사용하는 것이 좋은 결정이라고 생각합니다.
• 가져 오기를 위해 CORS와 함께 캔버스를 사용했습니다. 그러나 WebWorkers 및 XHR2에 대해 생각하고 캔버스가 다른 브라우저 및 기타에서 CORS에 약간의 문제가 있기 때문에 캔버스 대신 더 좋을 수 있습니다 (예를 들어이 제목 은 오페라 에 잘못 저장 되었습니다 ).

20 억 도시의 크기에 대한 추가 정보 ( 민스크 ) :

• 줌-9, 타일-2, 크기-52kb, 이전-52kb;
• 줌-10, 타일-3, 크기-72kb, 이전-124kb;
• 줌-11, 타일-7, 크기-204kb, 이전-328kb;
• 줌-12, 타일-17, 크기-348kb, 이전-676kb;
• 줌-13, 타일-48, 크기-820kb, 이전-1.5mb;
• 줌-14, 타일-158, 크기-2.2MB, 이전-3.7MB;
• 줌-15, 타일-586, 크기-5.5mb, 이전-9.3mb;
• 줌-16, 타일-2264, 크기-15mb, 이전-24.3mb;

몇 년 전 (정확히 석기 시대는 아님), 서버에서 요구 사항 동기화 / 업데이트를 쿼리하고 서버에서 적절한 파일을 다운로드하여 사용자의 파일 시스템 (데이터베이스 아님)에 저장하는 서명 된 Java 애플릿을 사용했습니다. 애플릿을 작성하고 서명 할 사람이 필요하지만이 솔루션이 효과가있을 수 있습니다. 데이터베이스 솔루션의 경우 이러한 애플릿은 적절한 포트 (예 : MySQL의 경우 3306)에서 localhost를 사용하여 대부분의 데이터베이스에서 사용할 수있는 jdbc를 사용할 수 있습니다. 애플릿 태그가 Html5에서 더 이상 사용되지 않는다고 생각하지만 여전히 작동합니다. Android 태블릿에 대한 경험이 없으므로 해당 부분에 대해 언급 할 수 없습니다.