JavaScript 中变量的大小
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/5254278/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Size of a variable in JavaScript
提问by TobyEvans
Out of interest, is it possible to determine the size of a JavaScript variable, in bytes?
出于兴趣，是否可以以字节为单位确定 JavaScript 变量的大小？
I have a web-app that runs great on the desktop but blows up* on the iPad. I'm guessing it's because there's a much more limited amount of memory in iPad Safari, but I'd like to get some idea of what's going on in my app.
我有一个在桌面上运行良好但blows up在 iPad 上运行良好的网络应用程序。我猜这是因为 iPad Safari 的内存有限，但我想了解一下我的应用程序中发生了什么。
I can estimate relative sizes, based on the size of the JSON source, but it'll be even better to know the actual size of the serialised object
我可以根据 JSON 源的大小估计相对大小，但最好知道序列化对象的实际大小
- "Blows up" = Safari slows down, then the screen goes black, and I'm back to the standard iPad home screen. Whatever that's called. Looks to me, that Safari has run out of the memory allocated for a browser instance.
- “爆炸” = Safari 速度变慢，然后屏幕变黑，然后我又回到了标准的 iPad 主屏幕。不管那叫什么。在我看来，Safari 已用完为浏览器实例分配的内存。
回答by Andrew
This won't directly answer your question. The JS language reference doesn't specify how to store data, so it's up to the groups doing the implementation, in this case the WebKit team, and I've not seen anything public on that. I've definitely not seen anything about Mobile Safari's implementation of WebKit.
这不会直接回答你的问题。JS 语言参考没有指定如何存储数据，所以这取决于执行实施的团队，在这种情况下是 WebKit 团队，我还没有看到任何公开的内容。我绝对没有看到有关 Mobile Safari 的 WebKit 实现的任何信息。
What I would say is that things may actually not be running great on the desktop, it's just that the the desktop's speed and size masks "problems" that show up on the mobile devices. On iOS, a browser instance has a ceiling of 10MB in which to operate if I remember correctly, though in practice, you start to hit the wall right around 6 or 7MB. On a PC, when you run out of RAM, the computer will simply just dump out unused memory to the disk. On iOS either resources stop loading (such as images) or the browser just exits (which is probably what you are experiencing).
我想说的是，实际上桌面上的运行情况可能不是很好，只是桌面的速度和大小掩盖了移动设备上出现的“问题”。在 iOS 上，如果我没记错的话，浏览器实例的上限为 10MB，可以在其中进行操作，但在实践中，您会在 6 或 7MB 左右开始碰壁。在 PC 上，当 RAM 用完时，计算机只会将未使用的内存转储到磁盘。在 iOS 上，资源停止加载（例如图像）或浏览器刚刚退出（这可能是您遇到的情况）。
If you have a Mac, you can snoop on Safari to see how it's doing by using a tool called "Instruments" (it's part of the iOS SDK). If you don't have a Mac or don't want to download the SDK, just open a clean instance of Safari, open up Windows' Task Manager or Mac's Activity Monitor and watch how your memory usage changes when you load up your webapp.
如果您有 Mac，则可以使用名为“Instruments”的工具（它是 iOS SDK 的一部分）窥探 Safari 以查看其运行情况。如果您没有 Mac 或不想下载 SDK，只需打开一个干净的 Safari 实例，打开 Windows 的任务管理器或 Mac 的活动监视器，并观察加载 web 应用程序时内存使用情况的变化。
Staying within the 6MB window is annoying. The biggest thing is try to avoid creating new images. For example, this pattern is a huge problem on an iPhone:
停留在 6MB 窗口内很烦人。最重要的是尽量避免创建新图像。例如，这种模式在 iPhone 上是一个大问题：
function placeImage(imagename,targetelement) {
var image = new Image();
image.src = imagename;
targetelement.appendChild(image);
}
In this case, even if you remove the image from the DOM, and even though imageis scoped within placeImage, it will never, ever get released and it is just a matter of time before this application crashes the browser. If this is your case, instead think about how many images you need to display at once, create image objects only for those elements and recycle them (just reset the srcany time you want a new image).
在这种情况下，即使您从 DOM 中删除图像，并且即使image在 范围内placeImage，它也永远不会被释放，并且此应用程序使浏览器崩溃只是时间问题。如果是这种情况，请考虑一次需要显示多少张图像，仅为这些元素创建图像对象并回收它们（只需在src需要新图像的任何时候重置）。
Also, I've found that JavaScript's application stack is much smaller than on a desktop browser, so if you have a lot of recursion, you'll see the problem much faster on iOS. The way to spot this problem is to open up the Developer Tools in Safari and use the profiler to see what functions are getting called the most.
此外，我发现 JavaScript 的应用程序堆栈比桌面浏览器小得多，因此如果您有很多递归，您会在 iOS 上更快地看到问题。发现此问题的方法是在 Safari 中打开开发人员工具并使用分析器查看哪些函数被调用最多。
[edit] I can't remember if this is the exact technique that exposes how numbers are stored differently internally by webkit, but I think it is. Basically, you do a sort on a million random numbers, first with a float, then (if you uncomment the line) an integer and then a large integer. I'm not good with typed languages, so I'm not exactly sure what this proves other than that internally numbers are treated differently depending on their smallest possibly representation.
[编辑] 我不记得这是否是揭示 webkit 内部如何以不同方式存储数字的确切技术，但我认为是。基本上，您对一百万个随机数进行排序，首先使用浮点数，然后（如果您取消注释该行）一个整数，然后是一个大整数。我不擅长类型化语言，所以我不确定这证明了什么，除了内部数字根据它们的最小可能表示被区别对待。
arrTarget = [];
for (var i = 0; i < 1000000; i++) {
arrTarget.push(Math.random() * 16000000);
// arrTarget.push(Math.floor(Math.random() * 16000000));
// arrTarget.push(Math.floor(Math.random() * 1600000000000));
}
// Time how long it takes to sort the array:
var time = new Date().getTime();
arrTarget.sort();
console.log(new Date().getTime() - time);
回答by Wayne
This isn't something you can do in general, but the sizes of some JavaScript objects are notimplementation specific, so you do have someguarantees:
这不是您通常可以做的事情，但某些 JavaScript 对象的大小不是特定于实现的，因此您确实有一些保证：
- "A string value is a member of the type String and is a finite ordered sequence of zero or more 16-bit unsigned integer values."
- "The type Number is a set of values representing numbers. In ECMAScript, the set of values represents the double-precision 64-bit format IEEE 754 values including the special "Not-a-Number" (NaN) values, positive infinity, and negative infinity."
- “字符串值是 String 类型的成员，是零个或多个 16 位无符号整数值的有限有序序列。”
- “类型 Number 是一组表示数字的值。在 ECMAScript 中，这组值表示双精度 64 位格式 IEEE 754 值，包括特殊的“非数字”(NaN) 值、正无穷大和负无穷大。”
