http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/

 

테스트에 사용된 기종은 다음과 같습니다.

 

- 안드로이드 2.1이 설치된 넥서스원

- iOS 3.1.3 버전의 아이폰3G

- iOS 3.2 버전의 아이패드

- iOS 4.0 버전의 아이폰3GS

- iOS 4.0 버전의 아이폰4

- webOS 1.4.1의 Palm Pre Plus 입니다.

 

 

테스트는 링크된 본문에 나타난 Methology 를 이용하였고, 웹 페이지의 각각의 Component Cache와 Page Cache 등을 측정하였습니다.

 

결과는 다음과 같습니다.

 

Table: Mobile browser cache characteristics

Browser/OS/Device Single Component Limit Total Component Limit Page Cache Size Limit Supports Last-Modified Supports ETag Survives Power Cycle
Android 2.1 (Nexus One) ~2MB (~2,048,000b) ~2MB (~2,048,000b)  2 Yes Yes Yes
Mobile Safari, iOS 3.1.3 (1st-gen iPhone) 0b 1 0b 1  2 No No No
Mobile Safari, iOS 3.2 (iPad) 25.6KB (26,214b) ~281.6KB (~288,354b) 25.6KB (26,214b) Yes Yes No
Mobile Safari, iOS 4.0 (iPhone 3GS) 51.199KB (52,428b) ~1.05MB (~1,100,988b)  2 Yes Yes No
Mobile Safari, iOS 4.0 (iPhone 4) 102.399KB (104,857b) ~1.9MB (~1,992,283b)  2 Yes Yes No
webOS 1.4.1 (Palm Pre Plus) 3 ~1MB (~1,048,576) ? ~1MB (~1,048,576) No No Yes

(잘라낸 표는 저작권 문제시 삭제하겠습니다)

 

전체적으로 안드로이드 2.1의 넥서스원이 가장 우수한 결과를 보였습니다.

 

먼저 Single Component 와 Total Component 모두 2MB의 캐시 용량을 보여주고 있습니다.

웹브라우징을 할 때 이미지나 텍스트 등의 합이 2MB 이내일 경우 버벅거리는 현상(캐쉬의 읽고, 쓰기) 없이
브라우징을 할 수 있다는 이야기지요.

 

Page Cache Size Limit는 안드로이드 OS의 가용램이 허용하는 범위 내에서 무한대 만큼 사용할 수 있습니다.

그 외에 특이할 만한 점으로는 유일하게 Survives Power Cycle을 지원한다는 점인데요.
자바스크립트나 입력필드의 항목 등 사용자의 다양한 입력으로 생성된 캐시들이 멀티태스킹을 위해
프로세스가 대기 상태에 들어가거나, 핸드폰 대기 버튼을 누르더라도 유지가 된다는 점이지요.

 

 

----------------------------------------------------------------------------------------------------------------

안드로이드 OS에서 웹브라우저의 성능(자바스크립트 엔진, 캐시 등)이 우수하게 나오는걸 보면
웹과 앱에서 웹에 더 큰 비중을 두는 구글의 철학이 반영된 것이 아닐까 생각됩니다.

 

 

머지 않아 안드로이드와 크롬OS는 하나의 줄기가 될 것이라는 기대를 갖게 해주네요.