javascript 在 Safari 桌面和 iOS 中分析内存的技术？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3971218/
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
Techniques for profiling memory in Safari desktop and iOS?
提问by Oskar Austegard
Updated 10/21:Changed title and question in order to possibly get an answer (other than "no").
10/21 更新：更改标题和问题以便可能得到答案（“否”除外）。
We're experiencing leaks in Safari (confirmed in Windows and Mac, suspected in iOS). Are there any Safari extensions that lets one profile JavaScript/DOM memory usage to discover potential leaks? Better yet, is there any tool that can be used on iOS or in the Apple iOS emulator?What are suggested techniques for discovering what may be causing memory leaks in JavaScript/DOM in Safari? And does anyone know of ANY way to access memory information for iOS?
我们在 Safari 中遇到了泄漏（在 Windows 和 Mac 中确认，在 iOS 中怀疑）。 是否有任何 Safari 扩展可以让一个配置文件 JavaScript/DOM 内存使用情况来发现潜在的泄漏？更好的是，是否有任何工具可以在 iOS 或 Apple iOS 模拟器中使用？在 Safari 中发现可能导致 JavaScript/DOM 内存泄漏的原因有哪些建议的技术？有谁知道访问 iOS 内存信息的任何方式？
Background
背景
We're developing an iOS Safari web application that uses the single-page app paradigm, loading 100s of full-screen images. We've bypased the normal 6.5 MB iOS Safari image limit by resetting the source for the image tags, but now we're running into what I believe is a memory leak in iOS Safari. After loading ~250-300 images iOS Safari simply stops loading the images, due to what we suspect is a memory leak. Not surprising, given that the same leak appears both in Safari for Windows and Safari for Mac - on Windows it is especially bad; for every new full-screen high res image, another 10-15 MB of memory is consumed, if we switch to lower res images it still gobbles up ~5 MB per image.
我们正在开发一个 iOS Safari Web 应用程序，该应用程序使用单页应用程序范例，加载数百张全屏图像。我们通过重置图像标签的源绕过了正常的 6.5 MB iOS Safari 图像限制，但现在我们遇到了我认为是 iOS Safari 中的内存泄漏。加载约 250-300 张图像后，iOS Safari 只是停止加载图像，因为我们怀疑是内存泄漏。毫不奇怪，鉴于相同的泄漏出现在 Windows 的 Safari 和 Mac 的 Safari 中——在 Windows 上尤其糟糕；对于每个新的全屏高分辨率图像，另外会消耗 10-15 MB 的内存，如果我们切换到较低分辨率的图像，它仍然会占用每张图像约 5 MB。
In Windows we've isolated the leak to the simple act of rendering the image in the browser viewport - we have a carousel of images, and even with zero DOM manipulation, by simply translating (3d) the image through the viewport, memory is allocated and never released. On Windows, memory consumption can quickly escalate to ~1.5 GB, at which point Safari simply crashes. On Mac it's not as bad, but memory easily jumps from 100 MB at the start to 500MB and beyond. In comparison, a Chrome tab/process hosting the same page grows from about 33MB to ~120MB and then stabilizes.
在 Windows 中，我们已经隔离了在浏览器视口中渲染图像的简单行为的泄漏 - 我们有一个图像轮播，即使是零 DOM 操作，通过简单地通过视口翻译（3d）图像，内存被分配并且从未被释放。在 Windows 上，内存消耗会迅速上升到约 1.5 GB，此时 Safari 就会崩溃。在 Mac 上它并没有那么糟糕，但是内存很容易从一开始的 100 MB 跃升到 500 MB 甚至更高。相比之下，托管同一页面的 Chrome 选项卡/进程从大约 33MB 增长到大约 120MB，然后稳定下来。
Attempted Workarounds
尝试的解决方法
We have tried deleting the individual image tags and replacing them with the placeholder image rather than resetting them, but this does not seem to alleviate the problem, and also causes performance problems, presumably due to DOM churn. Interestingly, deleting/detaching ALL the images does work - as soon as the command executes, the memory is released. However this causes its own problems, managing the UI state, and building the carousel back up also takes a noticeable amount of time. Refreshing the page is another workaround, but that causes even more UX disruption.
我们已经尝试删除单个图像标签并用占位符图像替换它们而不是重置它们，但这似乎并没有缓解问题，并且还会导致性能问题，大概是由于 DOM 搅动。有趣的是，删除/分离所有图像确实有效 - 一旦命令执行，内存就会被释放。然而，这会导致其自身的问题，管理 UI 状态和构建轮播备份也需要花费大量时间。刷新页面是另一种解决方法，但这会导致更多的用户体验中断。
Update 04/10:Just an update on what we ended up doing: iOS 4.2 introduced a limitation that cuts off a 3D transformed Div at 122,900 pixels. Not sure why, but it forced us to re-architect and go with a dynamic carousel instead of our previous static filmstrip.
2010 年 4 月 10 日更新：只是对我们最终做了什么的更新：iOS 4.2 引入了一个限制，即在 122,900 像素处切断 3D 转换的 Div。不知道为什么，但它迫使我们重新设计并使用动态轮播而不是我们以前的静态幻灯片。
Second, we found that using divs with background images work better than images themselves. This seems like a yet another bug in Safari, or at best an inconsistent limitation implementation.
其次，我们发现使用带有背景图片的 div 比图片本身效果更好。这似乎是 Safari 中的另一个错误，或者充其量是一个不一致的限制实现。
end update
结束更新
Thoughts?If you have encountered suspected leaks in Safari, what has been your approach to work around them?
想法？如果您在 Safari 中遇到了可疑的泄漏，您是如何解决这些问题的？
回答by Brad Daily
When you install the iOS SDK, a utility named Instruments is also installed. It can track all sorts of usage stats, including memory (there is even a "Leaks" template). The great thing is that it can track both the iPhone/iPad simulator and any connected iOS development device. It also, of course, can be used to monitor memory usage in Mac OS, so it may help with Safari as well. You can find Instruments in /Developer/Applications.
安装 iOS SDK 时，还会安装名为 Instruments 的实用程序。它可以跟踪各种使用统计信息，包括内存（甚至还有一个“泄漏”模板）。最棒的是它可以跟踪 iPhone/iPad 模拟器和任何连接的 iOS 开发设备。当然，它还可以用于监视 Mac OS 中的内存使用情况，因此它也可能对 Safari 有所帮助。您可以在 /Developer/Applications 中找到 Instruments。
Something else that is handy is that whenever you sync your iPad/iPhone with iTunes, it also syncs any crash reports from the device to your computer. They can be found at ~/Library/Logs/CrashReporter/MobileDevice/[Device Name]/.
另一件方便的事情是，每当您将 iPad/iPhone 与 iTunes 同步时，它还会将所有崩溃报告从设备同步到您的计算机。它们可以在 ~/Library/Logs/CrashReporter/MobileDevice/[Device Name]/ 中找到。
One thing we found when developing for the iPad in particular was that it was very prone to crashing due to memory issues, particularly in image heavy applications like ours. One thing we learned was that just removing a DOM element does not mean that element will be garbage collected by the browser. We found that setting the image src (or background-image, if it was a div) to an empty string before removing it from the DOM helped immensely.
我们在为 iPad 开发时特别发现的一件事是，由于内存问题，它很容易崩溃，尤其是在像我们这样的图像繁重的应用程序中。我们了解到的一件事是，仅仅删除一个 DOM 元素并不意味着该元素将被浏览器垃圾收集。我们发现在从 DOM 中删除图像之前将图像 src（或背景图像，如果它是一个 div）设置为空字符串有很大帮助。
Not sure if any of that helps, but hopefully getting Instruments up and running will give you a better idea of where all that memory is going.
不确定这些是否有帮助，但希望启动并运行 Instruments 会让您更好地了解所有内存的去向。
