safari 和 ios 在做canvas.toDataUrl 时报错怎么处理

Posted 2023-04-25

参考技术A 1.关于toDataURL(type,ratio)函数，参数type在image/png，image/jpeg,image/svg+xml等MIME类型中选择（可以不填，默认是image/png）。如果是type=“image/jpeg”，可以有第二个参数，如果第二个参数ratio的值在0-1之间，则表示JPEG的质量等级，否则使用浏览器内置默认质量等级。2.关于getImageData()函数，这个涉及到js安全问题，你的代码涉及到了跨域访问，比如你在上面画了某个图片。解决法有2个：要么用firefox（推荐），要么自己架设一个web服务器，网页放里面，然后浏览器访问（如果只是自己玩玩js+canvas的话可以使用AptanaStudio3，比较方便，不需要设置什么）

在 Safari 桌面和 iOS 中分析内存的技术？

【中文标题】在 Safari 桌面和 iOS 中分析内存的技术？

【英文标题】：Techniques for profiling memory in Safari desktop and iOS?

【发布时间】：2011-04-27 15:20:20

【问题描述】：

10/21 更新：更改了标题和问题，以便可能得到答案（“否”除外）。

我们在 Safari 中遇到漏洞（在 Windows 和 Mac 中得到确认，在 iOS 中被怀疑）。 是否有任何 Safari 扩展程序可以让一个分析 JavaScript/DOM 内存使用情况来发现潜在的泄漏？更好的是，是否有任何工具可以在 iOS 或 Apple iOS 模拟器中使用？ 有哪些建议的技术可以在 Safari 中发现可能导致 JavaScript/DOM 内存泄漏的原因？有谁知道访问 iOS 内存信息的任何方法？

背景

我们正在开发一个 iOS Safari 网络应用程序，它使用单页应用程序范例，加载 100 张全屏图像。我们通过重置图像标签的来源绕过了正常的 6.5 MB iOS Safari 图像限制，但现在我们遇到了我认为是 iOS Safari 中的内存泄漏。加载大约 250-300 张图像后，iOS Safari 会停止加载图像，因为我们怀疑是内存泄漏。这并不奇怪，因为在 Windows 的 Safari 和 Mac 的 Safari 中都出现了同样的泄漏——在 Windows 上尤其糟糕；对于每张新的全屏高分辨率图像，会消耗另外 10-15 MB 的内存，如果我们切换到较低分辨率的图像，它仍然会吞噬每张图像约 5 MB。

在 Windows 中，我们将泄漏隔离为在浏览器视口中渲染图像的简单行为 - 我们有一个图像轮播，即使是零 DOM 操作，只需通过视口转换 (3d) 图像，内存已分配且永不释放。在 Windows 上，内存消耗会迅速上升到约 1.5 GB，此时 Safari 就会崩溃。在 Mac 上它并没有那么糟糕，但内存很容易从一开始的 100 MB 跃升至 500 MB 甚至更高。相比之下，托管同一页面的 Chrome 选项卡/进程会从大约 33MB 增长到 ~120MB，然后稳定下来。

尝试的解决方法

我们已经尝试删除单个图像标签并用占位符图像替换它们而不是重置它们，但这似乎并不能缓解问题，并且还会导致性能问题，可能是由于 DOM churn。有趣的是，删除/分离所有图像确实有效 - 一旦命令执行，内存就会被释放。然而，这会导致其自身的问题，管理 UI 状态和构建轮播备份也需要大量时间。刷新页面是另一种解决方法，但这会导致更多的用户体验中断。

04/10 更新： 只是我们最终所做的更新：iOS 4.2 引入了一个限制，将 3D 转换的 Div 截断为 122,900 像素。不知道为什么，但它迫使我们重新设计并使用动态轮播而不是我们之前的静态幻灯片。

其次，我们发现使用带有背景图像的 div 比使用图像本身效果更好。这似乎是 Safari 中的另一个错误，或者充其量是不一致的限制实现。

结束更新

想法？如果您在 Safari 中遇到了可疑的泄漏，您采取了哪些解决方法？

【参考方案1】：

安装 iOS SDK 时，还会安装一个名为 Instruments 的实用程序。它可以跟踪各种使用统计信息，包括内存（甚至还有一个“泄漏”模板）。最棒的是它可以跟踪 iPhone/iPad 模拟器和任何连接的 iOS 开发设备。当然，它也可用于监控 Mac OS 中的内存使用情况，因此它也可能对 Safari 有所帮助。您可以在 /Developer/Applications 中找到 Instruments。

其他方便的事情是，每当您将 iPad/iPhone 与 iTunes 同步时，它还会将任何崩溃报告从设备同步到您的计算机。它们可以在 ~/Library/Logs/CrashReporter/MobileDevice/[设备名称]/ 中找到。

我们在为 iPad 开发时发现的一件事情是，它很容易由于内存问题而崩溃，尤其是在像我们这样的图像繁重的应用程序中。我们了解到的一件事是，仅删除 DOM 元素并不意味着该元素将被浏览器垃圾收集。我们发现，在将图像 src（或背景图像，如果它是一个 div）从 DOM 中删除之前将其设置为空字符串非常有帮助。

不确定是否有任何帮助，但希望启动和运行 Instruments 可以让您更好地了解所有内存的去向。

【讨论】：

布拉德，谢谢 - 这很有帮助（并且投票赞成）。我倾向于奖励你答案和赏金，但想在我扣动扳机前几天给它......

布拉德，已选择答案，已获得赏金。感谢您的洞察力。

请注意：将 Image 的 src 属性设置为 null 而不是空字符串将阻止其他一些浏览器（使用 Chrome 记录）向与网页。

我刚刚测试了设置null，但Chrome尝试下载地址currentpage/null的图像。我建议将其设置为short image data URI，而不是像这篇关于Mobile Safari's image resource limit 的文章中所建议的那样。 img.src = 'data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7

这个答案应该解释如何设置仪器和监控 Safari。