서버 리턴 패킷 : 캐시 제어 : 최대 사용 기간 = 600은, 파일이 국부적으로 캐시 될 것을 표시하고, 유효 길이가 (요청)에서 600 초 때. 이 자원에 대한 요청이있을 경우 다음 600초에서, 브라우저는 HTTP 요청을 발행하지 않지만 직접 사용 파일을 로컬 캐시.

만료 : 캐시 제어와 같은 기능, 즉, 캐시 유효 시간을 제어를

HTTP1.0이 분야에서 표준 만료, 캐시 제어 표준 HTTP1.1 새로 추가 된 필드

이 두 필드가 동시에 표시, 캐시 제어 높은 우선 순위

마지막으로 수정 : 식별이 파일이 마지막으로 서버에 업데이트 된

때 다음 요청 파일 캐시가 만료되면 통해 브라우저 띠 변성 때문에 필드는 서버로 전송이 시간, 서버는 파일이 변경되었는지 여부를 결정하기 위해 타임 스탬프를 비교하면. 다음 200으로 돌아가 변경이있는 경우, 최신 파일을 반환 변경 사항이 없을 경우, 서버는 304 캐시를 계속 사용하려면 브라우저에 지시 반환합니다.

ETAG : 즉 신분 증명서가 마지막으로 서버에 업데이트 된, 마지막으로 수정과 기능.

차이는 Etag입니다 특성치는 파일 식별 문자열 한쌍된다.

(304)없이 업데이트 패키지 뒷면 : 파일 서버에 대한 업데이트가 있는지 여부를 쿼리, 최신 캐릭터의 특징과 일치하는 문자열을 서버로 전송 기능에 IF-없음 - 매치 필드 및 파일 서버에 의해 브라우저에서 파일 업데이트 여부를 확인하는 경우 200에 대한 업데이트 패키지 뒷면

Etag입니다 마지막으로 수정하고, 수요 한두에 따라 병용 할 수있다. 두 사람이 동시에 한 그룹이 충족되는 조건 중 하나로서, 고려 때 파일이 업데이트되지 않습니다.

일반적인 사용법은 다음과 같습니다

캐시 제어는 마지막으로 수정에 사용;

Etag입니다 사용할 만료;

즉 캐시 미스 후, 업데이트에 대한 서비스 확인을 위해, 캐시 유효 시간을 제어하는 데 사용됩니다

특징

장점 : 지원 HTTP 프로토콜 층

부적절한 : 생성 될 캐시 파일을로드 한 후 처음으로 필요성 제한된 브라우저 캐시 메모리, 캐시 가능성이 클리어하는 것입니다 캐시 파일은 확인하지 않습니다.

전술 한 바와 같은 문제점을 해결하기 위해, 당신은 Q 오프라인 패키지 손을 참조 할 수 있습니다

시나리오

같은`JS, CSS`, 글꼴, 사진 등과 같은 정적 리소스 파일을 저장합니다.

안드로이드 웹보기 기록 파일을 캐시됩니다 및 파일 내용은 현재 응용 프로그램의 데이터 디렉토리에 존재합니다.

실현

브라우저 캐시 메커니즘은 일반적으로 안드로이드 웹보기가 자동으로 내장하는 기준을 달성하기 위해, 브라우저 커널에 의해 사용됩니다.

2.2 응용 프로그램 캐시 캐시 메커니즘

캐시 파일 단위 및 (브라우저 캐시 메커니즘과 유사) 특정 파일 업데이트 메커니즘이있다

매니페스트 및 매니페스트 파일 특성 : AppCache를 원리는 두 가지 핵심 포인트가있다.

헤더의 매니페스트 파일 매니페스트 속성에 의해 참조 HTML

매니페스트 파일 다음은 위의 파일 앱 캐시 결말이다, 그것은 파일이 필요 목록을 캐시 할 수있는 일반적인 파일입니다

브라우저가 처음로드 HTML 파일이 매니페스트 속성을 구문 분석, 절을 얻기 위해 매니페스트 파일을 읽을 때 : 파일의 목록을 CACHE MANIFEST에서 캐시 한 다음 파일 캐시합니다

// 원리는 다음과 같다 :

AppCache를 첫 번째로드 생성 후,뿐만 아니라 메커니즘을 업데이트합니다. 업데이트 할 경우 파일을 캐시, 당신은 매니페스트 파일을 업데이트해야

브라우저로드 다음 번에 기본 캐시를 사용하는 것 외에도, 그것은 또한 백그라운드에서 매니페스트 파일을 확인합니다 때문에, 어떤 수정 (바이트 단위)이 없다

수정 한 것으로,이 섹션의 매니페스트 파일을 검색합니다 : 파일 CACHE MANIFEST 목록에서 업데이트를 확인

매니페스트 파일을 확인하고 캐시 파일은 또한 브라우저 캐시 메커니즘을 준수 업데이트

이러한 사용자가 수동 AppCache를 다음로드 캐시를 지울 때와 같이 캐시를 다시 생성합니다 브라우저는 캐시 업데이트로 간주 될 수있다

AppCache를 5메가바이트 (하위 HOST)는 지역 공간 제약에 있기 때문에 AppCache를 캐시 파일, 브라우저 캐시 파일은 별도로 저장됩니다

특징

쉬운 웹 응용 프로그램 사용 캐싱 메커니즘 개발 오프라인을 위해 특별히 설계된 빌드 웹 응용 프로그램 캐싱에있는 AppCache는 브라우저 캐시 메커니즘을 보완합니다.

시나리오

정적 파일 저장 (예를 JS 등, CSS, 폰트 파일)

실현

   // 通过设置WebView的settings来实现
        WebSettings settings = getSettings();
        String cacheDirPath = context.getFilesDir().getAbsolutePath()+"cache/";
        settings.setAppCachePath(cacheDirPath);
        // 1. 设置缓存路径
        settings.setAppCacheMaxSize(20*1024*1024);
        // 2. 设置缓存大小
        settings.setAppCacheEnabled(true);
        // 3. 开启Application Cache存储机制

각 응용 프로그램 만 WebSettings.setAppCachePath ()와 WebSettings.setAppCacheMaxSize 번이라고합니다 ()

2.3 돔 스토리지 캐싱 메커니즘

값이 제공되는 - 저장 문자열 키로

: 다른 범위 것 이외에는 모두 사용 실질적으로 동일한, DOM 저장소 및 로컬 스토리지 sessionStorage 나누어

a.sessionStorage : 임시 저장된 데이터의 페이지와 연관되는,이 페이지 이후에 사용될 수있다 닫히고

b.localStorage는 : 페이지 닫은 후 저장된 데이터가 사용될 수있다, 즉, 영구적이다.

특징

저장 공간 (5메가바이트) : 쿠키와 같은 다른 브라우저, 저장 공간 만 4킬로바이트

저장 안전하고 편리한 : 돔 저장 데이터는 로컬 상호 작용에 저장하고, 자주 서버가 필요하지 않습니다

쿠키마다 페이지 요청과는 달리, 네트워크는 서버에 요청을 보내드립니다

시나리오

임시 저장, 간단한 데이터

대신 정보 쿠키의 전통적인 방법에 저장되어있는 서버 노하우를 할 필요가 없습니다

안드로이드 SharedPreference의 메커니즘과 유사 돔 저장 메커니즘

실현

// 通过设置 `WebView`的`Settings`类实现
WebSettings settings = getSettings();
// 开启DOM storage
settings.setDomStorageEnabled(true);

2.4 데이터베이스 캐싱 메커니즘

데이터베이스 저장 메커니즘`SQL`을 바탕으로

특징

쿼리를 데이터를 쉽게 추가 할 수있는 데이터베이스를 활용, 삭제, 수정

시나리오

데이터베이스의 데이터 저장 구조

실현

  // 通过设置WebView的settings实现
        WebSettings settings = getSettings();
        String cacheDirPath = context.getFilesDir().getAbsolutePath()+"cache/";
        settings.setDatabasePath(cacheDirPath);
        // 设置缓存路径
        settings.setDatabaseEnabled(true);
        // 开启 数据库存储机制

공식 설명에 따르면, 웹 SQL 데이터베이스 저장 메커니즘은 더 이상 색인화 된 캐싱 메커니즘으로 대체 (유지 보수)를 권장하지 않습니다.

2.5 색인화 된 캐싱 메커니즘

가치를 제공 할 수 - 형 NoSQL 데이터베이스는 키가 저장되어있는 문자열이 속하는

키 - 값 저장 유사 돔 저장 저장 메커니즘

특징

강력한 쉬운 사용, 데이터베이스의 트랜잭션 메커니즘에 의해 데이터 조작에, 객체는 잘 알고, 쉽게 접근 할 수의 인덱스를 생성 할 수 있습니다.

돔 스토리지보다 훨씬 더 큰 저장 공간, 기본 2백50메가바이트.

유연한 접근 객체에 키 - 값 방식은, 바이너리를 포함하여 값이나 개체의 모든 종류의 할 수있다.

비동기 API가 영향을 미치는 경험을 기다리고 피하기 위해 호출합니다.

시나리오

데이터의 저장은 복합 구조화 데이터 량

실현

// 웹보기 설정을 설정하여 달성, 그냥 자동으로 열리지 지원 JS 색인화 저장 메커니즘으로 설정, 안드로이드 4.4, 색인화에 대한 지원에 참여 단순히 JS가 잘 수행 할 수 있도록 스위치를 켭하기 시작했다.

  WebSettings settings = getSettings();
  settings.setJavaScriptEnabled(true);

2.6 파일 시스템

가상 파일 시스템 데이터 H5 페이지를 제공하기 위해

네이티브 앱 액세스 로컬 파일 시스템으로, 탐색 작업을, 쓰기를 파일 (폴더), 읽기를 만들 삭제할 수

가상 파일 시스템은 샌드 박스에서 실행

웹 애플리케이션 다른 가상 파일 시스템은 서로 가상 파일 시스템에서 격리 및 로컬 파일 시스템은 서로 격리됩니다.

일시 및 지속성 : 가상 파일 시스템은 두 가지 종류의 메모리를 제공한다 :

임시 저장이 : 브라우저에 의해 자동으로 할당하지만, 브라우저가 재활용 될 수 있습니다

영구 저장 공간 : 명시 적으로 적용 할 필요성 자체 관리 (브라우저가이 내용을 삭제하지 않습니다, 복구하지 않습니다) 할당량 관리를 통해 저장 공간, 초기 할당량이 처음으로 적용됩니다 할당량 소진 필요성을 다시 적용합니다.

특징

데이터의 대용량 바이너리 데이터 저장 될 수 리소스 파일을 미리로드 할 수있다, 당신은 파일을 직접 편집 할 수 있습니다.

시나리오

파일 시스템을 통해 관리 데이터

특정 사용

파일 때문에 시스템 H5 신입, 그것은 지원하지 않는 캐싱 메커니즘은 안드로이드 웹보기

2.7 캐싱 메커니즘 개요

3 캐시 모드

캐시 모드는 그 전에하면 웹 페이지가 H5로드 읽는 방법을 때 로컬 캐시를 저장하는 방법입니다

방법 수행하는 데 사용

즉 안드로이드 WebView를 읽기 캐시, 캐시를 읽을 수있는 방법을 알려줍니다

안드로이드 웹보기는 네 종류가 있습니다 캐시 모드와 함께 제공 :

// 캐시 모드 설명 :

// LOAD_CACHE_ONLY : 네트워크를 사용하지 않는, 로컬 캐시 데이터를 읽고

// LOAD_NO_CACHE : 전용 네트워크에서 데이터를 가져 오기 위해, 캐시를 사용하지 않습니다.

// LOAD_DEFAULT : (기본값) 캐시 제어에 따라 네트워크에서 데이터를 가져 여부를 결정합니다.

// LOAD_CACHE_ELSE_NETWORK, 한 만료 또는 전혀 캐시는 캐시의 데이터를 사용하는지 여부, 지역이있다.

특정 사용

WebView.getSettings().setCacheMode(WebSettings.LOAD_CACHE_ELSE_NETWORK);

Ever69

게시 57 개 원래 기사 · 원 찬양 26 ·은 40000 +를 볼

개인 편지 우려

안드로이드 웹보기 캐싱 메커니즘을 설명하기

1.WebView 성능 문제

1.1 H5 느린 페이지가로드

1.1.1 느린 렌더링 속도

1.1.2 자원 페이지가로드 천천히

1.2 걸리는 트래픽

2. 웹보기 웹 캐싱

2.1 브라우저 캐시 메커니즘

2.2 응용 프로그램 캐시 캐시 메커니즘

2.3 돔 스토리지 캐싱 메커니즘

2.4 데이터베이스 캐싱 메커니즘

2.5 색인화 된 캐싱 메커니즘

2.6 파일 시스템

2.7 캐싱 메커니즘 개요

3 캐시 모드

추천