모바일 브라우저의 캐시 제한 : 안드로이드, IOS, 그리고 웹 OS»야후 사용자 인터페이스 블로그 (YUIBlog)

모바일 브라우저의 캐시 제한 : 안드로이드, IOS, 그리고 웹 OS

년 | 8시 45분에서 2010년 6월 28일 라이언 그루브에 의해 오전 개발 , 성능 | 19 코멘트

업데이트 (2010년 7월 12일) :이 문서에서 설명하는 결과가 HTML 페이지에 대한 정확한있는 동안, 새로운 테스트 CSS와 JS 리소스에 대한 매우 다른 캐시 제한을 공개했습니다. 업데이트된 결과에 설명되어 있습니다 Revisited 모바일 브라우저의 캐시 제한, .

2008 년 초에, 웨인 쉬어과 Tenni Theurer가에 YUI 블로그 포스트 작성 아이폰 Cacheability 들이 아이폰 OS 1.x.에서 모바일 사파리의 캐시의 다양한 특성과 한계에 대한 연구 결과를 공유하는가 다른 것들 중, 그들은 4백75킬로바이트와 500킬로바이트 사이의 최대 총 캐시 크기가있다는 것을 25킬로바이트보다 큰 개별 구성 요소가 캐시에 없다는 사실을 발견합니다.

지금은 그때랑 상황이 많이 바뀌었습니다. 우리는 아이폰에 도전하는 등장 두 가지 새로운 주요 릴리스와 아이폰 OS (현재 IOS), 그리고 고도의 능력을 브라우저와 여러 다른 모바일 장치의 많은 마이너 릴리스를 봤어요. Stoyan Stefanov는, 늦은 2009 년에 발견 아이폰의 캐시 제한이 변경 (슬프게도, 최악의 경우). 하지만 지금은 어디에 서합니까? 그리고 그 이외의 IOS 브라우저 어떻습니까?

배경

브라우저 우리가이 시험의 목적에 가장 신경을 쓰고 캐시의 두 가지 유형이 있습니다

구성 요소 캐시 또는 개체 캐시는 개별 파일을 저장합니다. HTML, CSS, 자바 스크립트, 이미지는 모든 구성 요소 캐시로 이동합니다. 그것이 이러한 구성 요소 중 하나를 필요 때마다, 브라우저는 먼저 네트워크 요청을하기 전에 캐시를 확인합니다.
또한 뒤로 / 앞으로 캐시로 알려진 페이지 캐시, 전체 페이지 및 모든 구성 요소뿐만 아니라, 자신의 현재 상태를 저장합니다. 당신은 뒤로 또는 앞으로 단추를 사용하면, 브라우저는 가능하면 페이지 캐시에서 페이지를로드합니다.

HTML5 응용 프로그램 캐시는 널리 모바일 브라우저에서 지원의 캐시의 또 다른 유형입니다. 브라우저 제조 업체는 이미 응용 프로그램 캐시의 한계를 문서화의 좋은 일을, 그래서 난 내 테스트를 포함하지 않았다. 나중에 응용 프로그램 캐시에 대한 자세한.

장치 테스트

필자의 경우는 다음과 모바일 브라우저 / 플랫폼 조합을 테스트 :

안드로이드 2.1 (넥서스 원)
IOS 3.1.3에서 모바일 사파리 (1 - 세대 아이폰)
IOS 3.2에서 모바일 사파리 (iPad)
IOS 4.0 (아이폰 3GS)에 모바일 사파리
IOS 4.0에서 모바일 사파리 (아이폰 4)
웹 OS 1.4.1 (팜 사전 플러스)

참고 : IOS 4.0에서 모바일 사파리를 제외하고, 나는 각 카테고리에 하나의 장치를 테스트했습니다. 개별 장치 또는 OS 이상의 설치된 소프트웨어에 따라 차이 차이가있다면, 나의 시험 그 변화를 감지하지 것입니다. 그들은 내가 접근할 수 있었던 사람 때문에 나는 그들이 다른 기기보다 더 중요하다고 생각하기 때문에 이러한 특정 장치가 아닌 테스트되었습니다.

방법론

캐시 테스트는 지루하지만, 비교적 간단.

나는 작은시나 트라 응용 프로그램 (작성 GitHub에 포크! pseudorandom의 영숫자 및 공백 바이트의 요청 번호로 구성된 응답을 생성합니다). 응답 중 gzip으로 압축하거나 압축 제공될 수 있습니다. 다음과 같은 먼 미래의 만료 응답 헤더는 모든 응답이 캐시로 간주되는 것을 보장하기 위해 보내집니다 :

 캐시 - 제어 : 최대 - 나이 = 315,360,000
 만료 : 2020년 5월 1일 (금) 그리니치 표준시 03시 47분 24초을

내 로컬 네트워크를 통해, 나는 다음 수동으로 구성 요소 캐시를 테스트하기 위해 각 장치에서 다음 단계를 수행 :

캐시 테스트 색인 페이지를로드합니다.
5킬로바이트에서 20메가바이트에 이르기까지 특정 크기의 구성 요소에 링크를 누르, 그것이 로딩을 완료 기다립니다.
뒤로 버튼을 누릅니다.
다시 같은 링크를 누릅니다. 서버 콘솔 구성 요소가 2 단계에서 캐시되었습니다 여부를 확인하는 요청에 대한 로그 항목을 인쇄 여부를 임의의 문자가 동일한지 여부를 관찰합니다.
캐시되는 최대 구성 요소 크기를 결정하기 위해 필요한 구성 요소 크기를 반복하고 조정합니다.

페이지 캐시를 테스트하려면, 그 대신에 4 단계에서 다시 링크를 도청의 제가가 페이지 캐시가 아닌 구성 요소 캐시를 사용하는 원인, 브라우저의 앞으로 버튼을 도청 제외하고 기본적으로 동일한 단계를 수행했습니다.

지원 ETag 및 Last-Modified 해당 보낼 조정 서버에 의해 결정되었다 ETag 또는 Last-Modified 응답 헤더를 (별도 테스트) 및 먼 미래 만료 헤더를 생략합니다. 나는 다음 브라우저가 예상 전송되었는지 확인하기 위해 서버에서받은 요청 헤더를 검사 If-None-Match 또는 If-Modified-Since 4 단계에서 헤더.

결과

나는 gzip으로 테스트한 모두 활성화 및 비활성화,하지만 gzip으로 어떤 장치에 cacheability에 전혀 아무런 영향을 미치지 않았다는 사실을 발견했습니다. 압축되지 않은 구성 요소의 크기에 관계없이의 구성 요소를 gzip으로 압축 제공 여부와 상관없이 모든 경우에 중요합니다. 따라서, 여기에 언급된 모든 구성 요소 크기는 압축되지 않은 사이즈입니다.

아래 표는 내 전반적인 결과를 보여줍니다.

표 : 모바일 브라우저의 캐시 특성
브라우저 / OS / 장치	단일 구성 요소 제한	총 구성 요소 제한	페이지 캐시 크기 제한	마지막 수정 지원	ETag를 지원	전원주기 남아
안드로이드 2.1 (넥서스 원)	~ 2메가바이트 (~ 2048000 B)	~ 2메가바이트 (~ 2048000 B)	^∞이	예	예	예
모바일 사파리, IOS 3.1.3 (1 - 세대 아이폰)	0b ^일	0b ^일	^∞이	아니	아니	아니
모바일 사파리, IOS 3.2 (iPad)	25.6KB (26,214 B)	~ 281.6KB (~ 288354 B)	25.6KB (26,214 B)	예	예	아니
모바일 사파리, IOS 4.0 (아이폰 3GS)	51.199KB (52428 B)	~ 1.05MB (~ 1100988 B)	^∞이	예	예	아니
모바일 사파리, IOS 4.0 (아이폰 4)	102.399KB (104857 B)	~ 1.9MB (~ 1992283 B)	^∞이	예	예	아니
웹 OS 1.4.1 (팜 사전 플러스) ³	~ 1메가바이트 (~ 1,048,576)	?	~ 1메가바이트 (~ 1,048,576)	아니	아니	예

참고 사항 :

IOS 3.1.3 ¹ 모바일 사파리는 페이지 캐시를 제외하고, 크기에 관계없이, 모든 구성 요소를 캐시에 나타나지 않습니다. 이것이 의도하거나 버그인지 명확하지 않다.

² 페이지는 안드로이드 2.1, IOS 3.1.3에 캐시하고, 개별 페이지 크기에 올 때 IOS 4.0 (아니지만 IOS 3.2) 만 사용 가능한 RAM에 의해 제한 될 나타납니다. 나는 별도의 페이지가 한번에 페이지 캐시에 공존할 수있는 정확하게 얼마나 많은 결정하는 시도하지 않았다.

³ 웹 OS 테스트 결과는 일관성이되었으며 휴대폰 전원 순환될 때까지 여러 지점에서 캐시 모두 작동을 멈출 것 같았다. 난이 결과는 확실한, 또는 신뢰 생각하지 않지만, 그들은 비교를 위해 여기에 나와있어.

기계적 인조 인간

안드로이드 브라우저는 테스트를 모든 장치 최고의 캐시 동작을 전시. 그것이 개별 구성 요소의 크기에 제한을 부과하지 나타나지만, 전체 캐시 크기는 각각의 구성 요소를 효과적으로 잘 2메가바이트로 제한됩니다 즉, 약 2메가바이트 제한 것으로 보인다.

페이지 캐시는 즐겁게 사용할 수있는 RAM이 소진되고 브라우저가 추락한 때까지 나는 그것을 던져 모든 바이트 캐싱, 각 페이지의 크기에 제한을 부과하지 나타났다.

내가 유쾌 안드로이드의 구성 요소 캐시가 브라우저를 다시 시작 및 전원 사이클을 모두 살아남았다는 것을 찾을 수 놀랐습니다 IOS 장치의 위업에 아무도 일치 할 수 없었다.

가능한 경고 :의 검토 안드로이드의 웹킷 소스 트리가 나에게는 캐시 제한이 RAM 및 / 또는 플래시가 실행의되는 특정 장치에서 사용할 수있는 메모리의 양을 기반으로 적응 수 있다고 생각하는 리드. true이면 숫자는 넥서스 하나에 해당 될 수 있습니다. 캐시 크기가 사용되지 않는 메모리보다는 전체 메모리에 따라 적응하는 경우 실제로, 숫자는 단지 내 넥서스 하나에 해당 될 수 있습니다.

제가 잘못,하지만 아이폰 3GS와 아이폰 4 IOS 4.0 테스트 결과의 차이가이 이론을 지원 수 있습니다. (안드로이드와 모바일 사파리는 웹킷 기반 브라우저 모두 있으며, 그래서 그들은 공통점이 동작을 할 수 있습니다.) 당신은 웹킷 소스에 익숙한있어이에 대한 자세한 되거 수있다면, 나와 함께 연락 주시기 바랍니다.

IOS

결과 IOS의 최근 3 버전에 걸쳐 격렬하게 다양. 일까요, IOS 3.1.3에서 모바일 사파리는 분명 무제한 페이지 캐시 크기를 있음에도 불구하고, 어떤 크기의 구성 요소를 캐시에 저장하지 않았다. 그것이 IOS 3.1.3 사용자는 가능성들이 무선랜을 사용하지 않는 특히, suboptimal 브라우징 경험을지고 의미 때문에이 열세에있다. 그것은 다시 / 앞으로 navigations으로 게임에 와서부터 무제한 페이지 캐시 크기는, 작은 좋은 않습니다. 이 문제는 다른 사람들이 이전 IOS 릴리스에서 관찰하고 그것에 대한 이유를 상상할 수없는 무엇에서 중요한 변화이다, 그래서 이것이 버그 수 있습니다하라.

IOS 3.2에서 모바일 사파리는 (어떤이 iPad에서만 사용 가능합니다)이 버그를 전시하지 않습니다. 그 25.6KB 컴포넌트 제한하고 ~ 281.6KB 총 캐시 제한은 아무것도없는 것보단 낫지 있지만, 그들은 여전히 테스트를 다른 장치에 비해 압도 것 같습니다. 유니 클리 IOS 장치간에, iPad는 25.6KB 수있는 페이지 캐시에 페이지의 구성 요소 크기 제한 같은 크기를 제한하는가 나타납니다.

IOS 4.0에서 모바일 사파리는 한계가 가능한 RAM (; 테스트 두 장치는 플래시 메모리 32GB의 가지고 있던 아이폰 4 5백12메가바이트 반면 아이폰 3GS가 2백56메가바이트있다)에 따라 적응되는 의미 아이폰 3GS와 아이폰 4 가지 한계를 전시 . 아이폰 3GS에서 IOS 4.0 51.199KB 구성 요소 크기 제한과 ~ 1.05MB 전체 구성 요소 캐시 크기를하고 있습니다.

아이폰 4, 구성 요소의 크기 제한 102.399KB에서 거의 정확하게 아이폰 3GS에 두 번 제한되었다. 총 구성 요소 캐시 크기는 약 1.9MB되었습니다. IOS 3.2 IOS 4.0이 별도로 개발하지만, 공통된 조상에서 분기되었습니다 아마 때문에 IOS 4.0 페이지 캐시 크기는 두 장치에서 사용 가능한 RAM에 의해 제한 것으로 보인다는 IOS 3.1.3처럼 테스트.

실제로 브라우저를 죽이지 않고 응용 프로그램을 단순히 전환할 때 그들은 캐시를 보존 못했지만 IOS 장치의 아무도, 강제 브라우저를 다시 시작하거나 장치 전원주기에 걸쳐 캐시의 내용을 보존하지 않습니다.

웹 OS

웹 OS에 대한 검사 결과는 내가 그들의 작은 자신감을 가지고 너무 일관성이 있었다. 내가 완성도를 위해서 순수하게 수집 관리 어떤 데이터가 거의 포함되어 있습니다. 소금의 무거운 입자로 받아주십시오.

근처로 결정 수있었습니다으로 웹 OS는 페이지 캐시에 일치하는 페이지 크기 제한으로 1메가바이트 약 개별 구성 요소의 크기 제한을 할 수도 있습니다. 나는 동축 케이블 수 없습니다 If-None-Match 또는 If-Modified-Since 가 지원하지 않는 의미 웹 OS에서 요청 헤더 ETag 하고 Last-Modified .을

몇 가지 테스트에서, 그것은 웹 OS의 최대 구성 요소 크기은 1MB보다 큰 것을 나타나지만, 이것은 앞뒤가 맞지 않았어요. 휴대폰 전원 순환될 때까지 내가 말할 수 있는건, 웹 OS는 포인트 가능한 최대 총 캐시 크기가되었을 때 특정 도달 - 캐시 완벽하게 모두 작동을 중지 후, 심한 버그가 어디 것 같습니다. 어떤 경우에는 심지어 전원 자전거는 캐시 파손 문제를 해결 아니, 난 결국 문제와 웹 OS 캐시의 정확한 한계의 정확한 원인을 수립하기 위해 노력하고 포기.

문서에 대한 전화

브라우저 제조 업체는 브라우저의 캐시 제한을 문서화하고 게시 고려하시기 바랍니다. 바탕 화면 세계에서 이러한 제한은 일반적으로 비 - 문제 될 정도로 높은 위치를, 설명서가 필요되지 않았습니다. 모바일 세계에서 브라우저의 캐시 제한은 웹 개발자들이 강력한 기능으로 performant 웹사이트를 만들기 위해해야되는 중요한 정보입니다.

localStorage 및 응용 프로그램 캐시와 같은 새로운 기능의 한계는 일반적으로 잘 설명되어 있습니다. 뿐만 아니라 구성 요소 캐시에 문서의 수준을 확장하십시오.

공유 및 확장 : del.icio.us로 스크랩 | 디그 그것! | 레딧!

19 코멘트

좋은 물건, 라이언이 일을 주셔서 감사합니다!
워드 프로세서에 대한 전화를 들으려고 업체 기다리는 동안이 수표는 browserscope.org 추가 할 멋질 것입니다. 자원 봉사자? :)
에 의해 코멘트 Stoyan - 2010년 6월 28일 #
이러한 결과를 게시 주셔서 감사합니다! 나는 최근에 내 자신에 대한 유사한 연구를 실행하고 또한 안드로이드가 휴대 전화 전원이 순환될 이후에도 살아남은 캐시 구성 요소를 처리하는 방법으로 인상을 받았습니다.
나는 또한 메모리 캐시 및 "디스크"캐시, 전체 브라우저 다시 시작하거나 전원을 껐다가 남아있는 후자의 구분을하기 위해 중요한 건 내 연구에서 발견. 사용자가 페이지에서 페이지를 탐색하는 동안 메모리 캐시는 메모리에 상주하고,이 유스 케이스에 대한 구성 요소 크기가 (저는 2메가바이트 구성 요소의 크기까지 테스트) 훨씬 더 큰 것으로 나타났습니다. 캐시 제어, 먼 미래에 유효하고, 페이지에서 모바일 사파리이나 안드로이드도가 서버에 왕복을 보이게 될 것입 페이지에 탐색 Etags의 제거와 함께. 몇 분 그러나 이후 두 브라우저에서 가장 큰 구성 요소 (이 경우 2메가바이트에서)의 상태를 확인하기 위해 왕복을하게되고 서버는 파일이 여전히 클라이언트의 메모리에 거주하는 것을 나타내는 304을 돌려 보낼 것입니다. 몇 분의 과정을 통해 브라우저는 구성 요소의 크기에 따라 내림차순 위해, 각 구성 요소에 대해이 작업을 수행하는 계속했다.
나는 TechPulse 신문에 연구를 한지만 더 내 결과를 정리하고 그들을 게시할 수 있는지 알아 볼게.
마지막 생각 : 이것이 안드로이드 사용자의 대다수를 대표 불행히도 같은 그것이, 안드로이드 1.5 1.6 연구를 지켜보는 것도 흥미로울 수 있습니다. 이러한 사용자는 안드로이드 설명서 (미안 지금은 링크를 제공할 수 없습니다)에 업데이트된 공식 통계에 의하면 안드로이드 사용자의 단지 50 % 이상을 나타냅니다. 나는 이것이 웹 OS의 사용자에 비해 훨씬 더 많은 사용자를 대표하는 이해하는 바로는, 그냥 안드로이드 1.5/1.6의 확장 연구 아마도보다 관련성이 높은 것입니다 때문에.
마지막으로, 내 컴퓨터로 사과 가게에 난 내 아이폰이 입력입니다. 아마 훈장이나 그런 가치가있어!
에 의해 코멘트 데이비드 Calhoun - 2010년 6월 28일 #
Doh, 난 그것은 아이폰 캐시와 함께 그렇게 끔찍한 것을 사고 (전통적인 캐싱과 같은 새로운 캐싱 기법과는 반대로) 생각하지 얘기를 깜빡 했네요. 나는 그들이 Flash를 지원하지 이룬 것처럼, 의도적으로 강제로 봉투를 밀어 이것을 한 것 같아요. 그것은 기본적으로 플래시의 제거 새로운 CSS3 변환과 애니메이션을 사용하는 방법에 대한 자세한 내용은 개발자가 강제와 마찬가지로, 개발자가 캐시 매니 페스트와 로컬 저장소를 사용하는 방법에 대한 자세한 내용을 시켰어요.
에 의해 코멘트 데이비드 Calhoun - 2010년 6월 28일 #
작은이 32기가바이트 읽어야 "플래시 메모리의 32메가바이트했다 테스트 두 장치"에 오타 있어요.
업데이트된 결과를 주셔서 감사합니다, 이거 정말 유용합니다!
니콜라에 의해 코멘트 - 2010년 6월 28일 #
@ Stoyan : 좋은 생각이야!
@ 데이비드 : 흥미 롭 군. 나는 많은 시간을 내 요청 사이를 통과하는 것을 허용하지, 그래서 당신이 설명하는 확인 요청을 통보하지 않았다. 당신의 결과의 나머지 부분을보고 싶네요.
@ 니콜라 : 좋은 지적이야. 나는 교정으로 게시물을 업데이 트했습니다. 감사합니다!
에 의해 코멘트 라이언 그로브 - 2010년 6월 28일 #
나는 웹 OS에서 캐시의 부족을 확인할 수 있습니다. 이게도 안정적으로 간단한 페이지 (이 같은) 캐시에 저장하지 않습니다. : (
에 의해 코멘트 리차드 - 2010년 6월 28일 #
잘했어 라이언
에 의해 코멘트 필립 텔리스 - 2010년 6월 28일 #
좋은 기사! 감사 라이언.
하지만 그것을 "3.1.3에서 3G/3GS"내 대한 시도해 준, 그들은 정확하게 자원을 캐시 것 같았다.
당신은 2G 아이폰로 "제 1 세대 아이폰 '않았을 의미?
난 3.1.3에서 OS, 3G/3GS는 2G (1 세대)보다 다르게 동작 같은데요.
이 도움이 될 바랍니다.
드웨인에 의해 코멘트 - 2010년 6월 29일 #
따라서 안드로이드가 최고의 브라우저도 플래시가 있습니다. Fu는 iPaid!
감사 라이언, 좋은 일을 매우 유용합니다.
에 의해 코멘트 펠릭스 Nagel - 2010년 6월 29일 #
잘했어,하지만 난이 좋은 테스트라고 생각합니다. 사용자는 특정 IMG 또는 스타일 시트 URL을 클릭 거의 없습니다 - 대신에, 그들은 페이지에 걸쳐 이동합니다. 테스트는 일반적인 웹 워크플로우 동안 캐시가 작동하는 방법 좀 보시지 관련성이 높은 것. 데이비드와 마찬가지로, 나는 다른 페이지에 걸쳐 탐색으로 큰 자원 (> 1메가바이트) 캐시 보여주는 모바일 사파리에서 테스트 해봤는데. 이것은보다 일반적인 사용자 시나리오입니다. 따라서 예를 들어, 52K 아이폰 3 전용 캐시를, 말을 잘못을 보인다. 최소한, 우리는 또 다른 열을 필요합니다. 이것은 코드가 Github에 것을 좋아하지만, 사람들이 시도 수있는 시험의 호스팅 버전이있다면 그것이 되어야죠. 멋진 직장 -하지만 이것이 실제 사용자가 발생하는지 명확히 생각하지 않습니다. 저에게 직접 Ping을 우리는 더욱 철저한 테스트 설계 밖으로 범위하실 수 있습니다.
에 의해 코멘트 스티브 Souders - 2010년 6월 29일 #
@ 스티브 : 나는 시험 방법 개선을위한 귀하의 발견과 아이디어에 대한 자세한 내용을 듣고 싶어요. 난 당신에게 이메일을 보냈습니다.
에 의해 코멘트 라이언 그로브 - 2010년 6월 29일 #
"페이지 캐시 즐겁게 사용할 수있는 RAM이 소진되고 브라우저가 추락한 때까지 나는 그것을 던져 모든 바이트 캐싱, 각 페이지의 크기에 제한을 부과하지 나타났다."
이 무너지는 바람직한 행동인가? IOS와 웹 OS에있는 브라우저도 추락시 켰나요? 더 인색 캐시 제한이 충돌을 제한할 수 있도록 고안된 수도 그냥 생각, 난 내 인생에서 모바일 사파리 충돌하는 데 기억이 안나요.
@ 펠릭스, 어떻게 이러한 결과는 안드로이드가 "최고의 브라우저"를 가지고 뜻 이죠? 그냥 캐싱 동작보다 "최고"로 훨씬 더 있어요.
다이에 의해 코멘트 - 2010년 6월 30일 #
@ 다이 : 사고는 결코 바람직하지만,이 경우에 문제를 일으킬 5메가바이트 또는 더 큰의 구성 요소를했습니다. 모바일 사파리는 제 1 세대 아이폰에 5메가바이트 주위에 문제가있을 경향, 크기는 10MB 주변 3GS에서,하지만 난 그것도 20메가바이트에서 아이폰 4 충돌을 얻을 수 없습니다. 넥서스 하나의 안드로이드는 10메가바이트 주위에 문제가 시작하는 경향. 웹 OS는 페이지 캐시의 크기를 제한 나타나 다른 이들처럼 충돌하지 못했지만 문서에 썼던 것처럼, 그것은 자신의 문제를했다.
다운로드받은 데이터를 표시 또한 관련된 테스트 있기 때문에, 이것은 메모리 사용량에 기여 것입니다. 나는 표시되지 않습니다, 또는 단순히 파일 시스템에 다운로드되는 리소스와 같은 동작을 기대하지 않을 것이다.
에 의해 코멘트 라이언 그로브 - 2010년 6월 30일 #
사용 iCab : IOS와 아이폰, iPad 및 아이팟 터치에 대해서.
iCab 브라우저는 모바일 플랫폼에 최고의 모바일 브라우저의 캐시를하고 있습니다. 아무것도 다시 다운로드받을 필요가 없다 그래서 전체 웹 페이지를 저장합니다. 당신은 웹 사이트 전체 웹 페이지를 저장할 수있는 선택할 수 있습니다. 그것은 데스크톱 브라우저에 유사한하기 위해 탭 및 기타 기능을 가지고 있습니다.
iCab.
매우 만족 웹 브라우징 경험에 대한 대답이야.
제임스 Katt에 의해 코멘트 - 2010년 7월 1일 #
안녕하세요! 리뷰 주셔서 감사합니다. Android 마켓에 많은 다른 브라우저 주식 것 말고 있기 때문에, 내가 예를 들어 돌고래 [HD]와 같은 다른 널리 사용되는 브라우저를 테스트하는 의미가 생각합니다. 나는 최근에 돌고래가 SD 카드로 물건을 캐싱 옵션을 포함 것으로 나타났습니다 ...
에 의해 코멘트 블라디미르 Kelman - 2010년 7월 2일 #
당신의 노력을 추천하고 라이언 작업뿐 아니라 스티브의 의견을 반향. 당신들이 생산 무엇을 기대하겠습니다.
당신이 알고 있는지 확실 참고 : 안드로이드 브라우저의 디스크 캐시 알고리즘은 웹킷 repo (브라우저에 네트워킹이 자바 층 웹킷 C / C + + 레이어 안에 의해 처리됩니다)에 실제로되지 않습니다. 에 CacheManager.java 봐 http://bit.ly/azhsGH . 이 알고리즘은 약 디스크 캐시가 6메가바이트 초과하는 경우 매 5 네트워크 요청이가 줄어들 도착한다는 것입니다. 당신은 또한 연구를 찾은 것 2메가바이트 디스크 캐시 구성 요소의 크기를 제한 상수 CACHE_MAX_SIZE을 볼 수 있습니다. 당신은 경험 충돌이 6메가바이트 트림 제한과 관련이있을 수도해도 난 놀라지 않을 겁니다. (난 한때 클라이언트의 운영 체제 소스 캐시 버그를 수정했기 때문에 변태 나는 이것을 알아야한다.)
당신이 알고 있겠지만 어쨌든,이 의미는 실제로 그것이 엔지니어 정확한 캐시 제한 (반대하기 어려울 수있다는 것이 무엇입니까 예를 들어 안드로이드를 위해, 결과는 다섯 번째 네트워크 요청되었습니다 여부에 따라 다를 수 있습니다 아니면 안 - 누가 아이폰 알고리즘은 무엇입니까 알고), 당신이 여기 한 것 같은 몇 가지 가능한 지침을 해독하고 게시하는 제조 업체에 요구하는 것은 여전히 유용하지만.
에 의해 코멘트 Ishan 아난드 - 2010년 7월 2일 #
@ Ishan : 여분의 안드로이드 정보 주셔서 감사합니다! 아주 도움. 스티브와 나는 현재 몇 가지 새로운 테스트 작업을 곧이 더 설명해 주실 수 있도록 희망하고 있습니다.
에 의해 코멘트 라이언 그로브 - 2010년 7월 2일 #
있다면 나는 또한 호기심 오전 UIWebView 하나가 모바일 사파리와 같은 한계를 가지고있는 IOS 응용 프로그램에 포함할 수 있습니다. stackoverflow 질문 나타냅니다 UIWebView에서 HTML5 캐시 매니 페스트가 작동하지 않습니다.
케빈 Hakanson에 의해 코멘트 - 2010년 7월 6일 #
이러한 결과를 게시 주셔서 감사합니다! 그것은 기본적으로 플래시의 제거 새로운 CSS3 변환과 애니메이션을 사용하는 방법에 대한 자세한 내용은 개발자가 강제와 마찬가지로, 개발자가 캐시 매니 페스트와 로컬 저장소를 사용하는 방법에 대한 자세한 내용을 시켰어요.
에 의해 댓글 기술 블로그 - 2010년 7월 18일 #

죄송합니다, 코멘트 양식이 시간에 문을 닫습니다.

에서 제공하는 워드 프레스 에서 야후! 웹 호스팅 .

야후 블로그 사용자 인터페이스 (YUIBlog)