iphone 微信缓存_iPhone缓存

iphone 微信缓存

2010 update: Lo, the Web Performance Advent Calendar hath moved

2010年更新： Lo， Web Performance Advent Calendar已移动

Dec 22 This post is part of the 2009 performance advent calendar experiment. Stay tuned for the articles to come - only 2 to go!

12月22日这篇文章是2009年性能出现日历实验的一部分。请继续关注本文，仅2件！

Some time ago there was a post on YUIBlog highlighting the findings of Wayne Shea and Tenni Theurer on the caching behavior of the iPhone. Curious if things have changed several iPhone OS updates later, I ran some experiments with OS3 and OS3.1.

前一段时间，YUIBlog上有一篇文章重点介绍了Wayne Shea和Tenni Theurer在iPhone缓存行为方面的发现。奇怪的是，事后是否更改了多个iPhone OS更新，我对OS3和OS3.1进行了一些实验。

强调 (Highlights)

iPhone will not cache components bigger than 15K (was 25K in the previous experiment)iPhone不会缓存大于15K的组件(在先前的实验中为25K)
total cache is about 1.5MB (was 500K)总缓存约为1.5MB(原为500K)
short-term memory cache will store components up to 1941K provided the component size does not divide by 4短期内存缓存将最多存储1941K的组件，前提是组件的大小不除以4
powering off the device still clears all the cache, Expires headers still important关闭设备电源仍会清除所有缓存，Expires标头仍然很重要
not sure since when, but closing all tabs clears the cache too不知道从什么时候开始，但是关闭所有选项卡也会清除缓存
consider HTML5 application cache to improve cacheability and provide offline experience – components in the application cache can be bigger than 15K and stay cached even after you clear Safari's cache from the Settings app (or clear it any other way)考虑使用HTML5应用程序缓存来提高可缓存性并提供脱机体验-即使从“设置”应用程序清除Safari的缓存(或以其他任何方式清除)，应用程序缓存中的组件也可能大于15K并保持缓存状态

15是新的25(15 is the new 25)

Previous experiment showed that the iPhone will not cache components bigger that 25K, but this number is now down to 15K. And this is ungzipped size, meaning if you have for example a 20K JavaScript and your server sends it gzipped down to 10K, it will not be cached by the iPhone.

先前的实验表明，iPhone不会缓存大于25K的组件，但现在该数量已降至15K。这是未压缩的大小，这意味着，例如，如果您有20K JavaScript，并且您的服务器将其压缩到10K，它将不会被iPhone缓存。

So minification can definitely help you here. Minification may not be as beneficial as gzipping in desktop browsers, but it may be the difference between a cache hit or miss in the iPhone. Minify, then gzip. And, in general, try to keep your component sizes low - that always helps in any browser.

因此，缩小绝对可以在这里为您提供帮助。缩小可能不像在桌面浏览器中gziping那样有益，但可能是iPhone中缓存命中或未命中的区别。缩小，然后压缩。而且，一般来说，请尽量减小组件的尺寸-这在任何浏览器中总是有帮助的。

总缓存大小 (Total cache size)

First off, how was the experiment run? I simply tailed the access log of a server, in order to monitor which components get requested:

首先，实验是如何进行的？我只是添加了服务器的访问日志，以监视请求了哪些组件：

$ tail -f ~/logs/http/access.log | grep "XXX.YYY.ZZZ.000"

Where XXX.YYY.ZZZ.000 is the IP address. You can also replace that with just "iPhone" if you think no one else is hitting this site with an iPhone.

其中XXX.YYY.ZZZ.000是IP地址。如果您认为没有其他人用iPhone登陆该网站，则也可以仅用“ iPhone”代替。

Then I requested components with different sizes and look at what the log tail says.

然后，我要求使用不同尺寸的组件，并查看原木尾巴上的内容。

Once it was clear that 15K is the maximum components size, the next question was how many of those 15K components can be cached before iPhone runs out of space allocated for caching? And the result was 105. Attempting to cache one more file resulted in removing existing ones from the cache. Then playing with the size of the very last component helped nail the exact number of bytes available in the cache – 105 * 15 + 7 = 1582K.

一旦明确知道最大组件大小为15K，下一个问题是在iPhone用完用于缓存的空间之前，可以缓存这15K组件中的多少个？结果为105。尝试再缓存一个文件会导致从缓存中删除现有文件。然后，使用最后一个组件的大小可以帮助确定高速缓存中可用的确切字节数– 105 * 15 + 7 = 1582K。

So the total cache is just a little over 1.5 MB (earlier research showed 0.5MB for earlier iPhone OS). Have in mind that this is the total cache shared between all pages, it's not per domain or per tab.

因此，总缓存仅略高于1.5 MB(早期的研究表明，较早的iPhone OS为0.5MB)。请记住，这是所有页面之间共享的总缓存，而不是每个域或每个选项卡。

内存缓存 (Memory cache)

The iPhone has a little bit more cache space in the form of memory cache. The memory cache has no per-component size limit, so your components can be as big as the memory cache – 1941 bytes (don't ask how many attempts it took to nail this number).

iPhone具有内存缓存形式的更多缓存空间。内存缓存没有每个组件的大小限制，因此您的组件可以和内存缓存一样大-1941字节(不要问要为该数字指定多少次尝试)。

There a little catch though, probably due to a bug, and it's that if the component size divides by 4, it won't be cached in memory. That's true for JavaScripts – they will be requested on every page load. CSS files with sizes over 15 that divide by 4 will not be requested in the same tab session, but if you close the tab and open the page in another tab, they will be requested again.

但是，有一个小问题，可能是由于错误所致，它是如果组件大小除以4，则不会将其缓存在内存中。对于JavaScript来说确实如此-每次加载页面时都会请求它们。超过15CSS文件除以4CSS文件不会在同一选项卡会话中被请求，但是如果您关闭该选项卡并在另一个选项卡中打开页面，则将再次请求它们。

So components under 15K go to the disk cache, a 16K component is never cached (so is 20, 24, …, 36,.. 100,… 1024 and so on), 17K and up (up to almost 2 megs) components are cached in memory.

因此，低于15K的组件将进入磁盘缓存，永远不会缓存16K的组件(因此20、24，…，36，.. 100，…1024等)，17K及以上(最多2兆)的组件缓存在内存中。

This memory cache is very unreliable as you can guess, because it gets cleared very often, it's probably useful only in the same user session on your web site.

您可能猜到，此内存缓存非常不可靠，因为它经常被清除，它可能仅在网站上的同一用户会话中有用。

一些观察 (Some observations)

Closing all tabs, except for blank ones (as when you do "New Page") and then closing Safari is the same as clearing the cache from Settings. So it's a good idea in your normal daily use to leave at least one page open, before you close Safari in order not to cause the implicit cache clearing.关闭所有选项卡(空白选项卡除外)(如执行“新建页面”时一样)，然后关闭Safari，与从“设置”中清除缓存相同。因此，在日常使用中，最好在关闭Safari之前至少打开一个页面，以免导致隐式缓存清除。
Tapping the reload icon in the address bar sends unconditional requests for all components, without the If-Modified-Since header and ignoring the Expires header. So to speed up your browsing, refresh the page by tapping the address bar and then tapping GO, don't use the refresh icon.

轻触地址栏中的重新加载图标可发送所有组件的无条件请求，而无需If-Modified-Since标头，而忽略Expires标头。因此，为了加快浏览速度，请通过点按地址栏然后点按“ GO”来刷新页面，请不要使用刷新图标。
The tests I ran were using OS 3.0 and OS 3.1.2. I got my phone last Christmas which means that according to this page it came with OS 2.2. I don't remember if I ran any tests with OS2.2. too. I do remember though that I tried some tests back when I didn't have a phone and asked help from Ryan Grove and Nicole Sullivan. Chatting over IM they were loading pages while I was tail-ing the server log. Those tests must have been with OS 2 or OS2.1. Back then the results showed that the limit for a component that gets stored in the cache was 10Meg, which was also the total size of the cache. Now I have my doubts that back then we only tested memory cache, not disk cache. In any event, it's important to note that those restrictions are all software restrictions. No matter what model the phone, it's the OS that sets the limits. Different models with the same OS will behave the same when it comes to caching sizes.

我运行的测试是使用OS 3.0和OS 3.1.2。去年圣诞节我拿到了手机，这意味着根据此页面，该手机随附OS 2.2。我不记得我是否在OS2.2上进行过任何测试。太。我确实记得，当我没有手机时我曾尝试过一些测试，并要求瑞安格罗夫( Ryan Grove)和妮可•沙利文( Nicole Sullivan)的帮助。当我跟踪服务器日志时，通过IM聊天他们正在加载页面。这些测试必须在OS 2或OS2.1上进行。当时的结果表明，存储在缓存中的组件的限制为10Meg，这也是缓存的总大小。现在我有疑问，那时候我们只测试了内存缓存，而不是磁盘缓存。无论如何，必须注意这些限制都是软件限制。不管手机是什么型号，都由操作系统来设置限制。具有相同操作系统的不同型号在缓存大小方面的行为相同。

HTML5离线应用程序缓存 (HTML5 offline application cache)

All in all we can safely summarize that the iPhone has no cache to speak of. 15K per component is nothing and the limit of 1.5Megs shared with all other pages will have your cached components kicked out pretty quickly.

总而言之，我们可以安全地总结出iPhone没有缓存可言。每个组件15K没什么，与所有其他页面共享的1.5Meg限制将使您缓存的组件很快被淘汰。

So – what's an iPhone performance optimizer to do? Use HTML5 goodies.

那么– iPhone性能优化器是做什么的？使用HTML5好吃的东西。

One thing to consider is some form of client storage supported by the mobile webkit (either key-value or SQLite), but that will require some of your javascript to handle the caching, expiration and so on.

要考虑的一件事是移动Webkit支持的某种形式的客户端存储(键值或SQLite)，但这将需要您的一些javascript来处理缓存，到期等。

Another thing to do is use the offline application cache. It's meant to support applications to work offline, but it also ends up being useful to improve caching of online applications as well.

另一件事是使用脱机应用程序缓存。它旨在支持应用程序脱机工作，但最终也有助于改善在线应用程序的缓存。

What you need is a simple text file called a manifest. In there you list all the components required by your application. E.g.

您需要一个称为清单的简单文本文件。在其中列出了应用程序所需的所有组件。例如

CACHE MANIFEST
/root/path/to/images/image.jpg
or/maybe/relative/paths/too/scripts.js
http://example.org/good-old/absolute/path/oojs-home.jpg

It's important to serve this file with content type text/cache-manifest.

使用内容类型text/cache-manifest来提供此文件很重要。

Then in your html tag just point to that file. Let's say you called the manifest mycache.manifest (could be dynamic, php, or anything, as long as it's served with the proper content type). So your HTML should start like the following:

然后在您的html标记中html向该文件。假设您调用了清单清单mycache.manifest (可以是动态的，php或其他任何形式，只要它具有正确的内容类型即可)。因此，您HTML应该像下面这样开始：

<!DOCTYPE html>
<html manifest="mycache.manifest">

And this is it. There's also JavaScript API available if you want to play with the items stored in the cache.

就是这样。如果您想使用缓存中存储的项目，还可以使用JavaScript API。

Now the browser will request the manifest file every time (Expires header won't help you here) and if its contents is changed it will quietly and unobtrusively download the updated components in the background and the next time the user will see the updated page. Needless to say it makes sense that all the pages of the site share the same manifest.

现在，浏览器每次都会请求清单文件(Expires标头在这里无济于事)，如果其内容发生更改，它将在后台安静且毫不干扰地下载更新的组件，而下次用户将看到更新的页面。不用说，站点的所有页面共享同一清单是有意义的。

The best part is that when using offline cache none of the restrictions mentioned above apply – you can store files bigger than 15K and you don't share your total cache space with anyone.

最好的部分是，使用脱机缓存时，上述任何限制均不适用–您可以存储大于15K的文件，并且不与任何人共享总缓存空间。

I used this for a personal project – whomsy.com if you want to play with some requests and monitor the traffic (e.g. using the iPhone simulator and Charles proxy).

我将此用于个人项目– whosy.com(如果您想处理一些请求并监控流量)(例如，使用iPhone模拟器和Charles代理)。

清单–不仅限于iPhone？ (Manifest – not just for iPhone?)

The manifest idea sounds so nice, it makes sense to apply it to desktop browsers as well. In a way it's similar to the idea of having web archives – a zip with all page components (sorry, can't find the URL for the proposal for web archives right now). You can include the manifest on your homepage and, after onload, the browser preloads all the other components used by internal pages (no need to do preloading yourself in JavaScript, no need to worry about spriting images and so on). This is absolutely doable and it also provides the side benefit that your app is available offline, which is the original purpose of the offline cache