问题描述
当我尝试使用MFMailCompose作为附件发送图像(摘要大小约为4mb)时，活动监视器会说使用了100(+-2)mb的内存.发送或取消内存后，内存释放了约20兆字节，但是如果重新分配了带有图像的共享项，剩下的80兆又发生了什么呢?谢谢！:)
When I try to send images as attachements(summar size ~4mb) by using MFMailCompose, activity monitor says, what 100(+-2)mb of memory is used. After sending or cancelling memory is freeing ~20 megabytes, but what happened to the remaining 80 megabytes if shared item with images is deallocated?Thanks!:)
推荐答案
图像的文件大小和显示时所消耗的内存量是完全不同的两件事.
An image's file size and the amount of memory it consumes when displayed are two completely different things.
诸如JPEG和PNG之类的图像被压缩.当它们被绘制到屏幕上时，它们将被解压缩.
Images such as JPEGs and PNGs are compressed. When they are drawn to the screen they are uncompressed.
一种快速的经验法则可以确定图像在显示时将消耗多少内存
A quick rule of thumb to figure out how much memory an image will consume when displayed is
memory consumed = (width * height) * 4
例如，磁盘上的2 KB图像但尺寸为62 x 52像素的图像实际上将消耗12896字节或12 KB.我以为磁盘上有4 MB的映像会消耗4 MB以上的内存.
Example, a image that is 2 KB on disk, but is 62 x 52 pixels will actually consume 12,896 bytes or 12 KB. I imagine an image that is 4 MB on disk will consume a lot more than 4 MBs.
问题在于，当您将图像作为附件添加时，MFMailComposer会在其撰写视图中显示图像，结果它们被解压缩，从而占用了内存.因此，您4 MB的图像实际上消耗的能量比您想象的要多.
The problem is that MFMailComposer displays the images in it's compose view when you add them as attachments and as a result they are decompressed, consuming memory. So your 4 MBs of images actually consume a lot more than you think they do.
也许尝试一次只发送一张图像.您还需要注意，在使用完图像和MFMailComposeViewController后，它们将被释放，否则肯定会导致泄漏.
Perhaps try sending only one image at a time. You also need to be conscious that you're releasing the images and the MFMailComposeViewController when you're done with them, or that would surely be the source of the leak.
还请注意您最初如何加载图像. UIImage的imageNamed:方法实际上是缓存图像.缓存的图片只会在内存不足的情况下清除，因此如果您没有达到限制，它们可能会闲逛一会儿.
Also be aware of how you initially load your images. UIImage's imageNamed: method actually caches images. Cached images are only purged in low memory situations, so they can hang around for a while if you're not hitting the limits.
最后，您已经注意到您看到了Instruments中的内存消耗，但是您是否实际验证了这确实是一个问题?在未 与仪器或调试器连接的情况下测试应用时，是否由于内存不足而导致应用崩溃?
Finally, you've noted that you're seeing the memory consumption in Instruments, but have you actually verified that it is actually a problem? Are you experiencing app crashes due to low memory when testing your app while it is not connected to Instruments or the debugger?
没有任何一个机构是完美的-苹果公司也是如此.过去有记录在案的案例，其中苹果的框架显示内存泄漏(iOS 2.x中UIImage的缓存泄漏)，但是当您注意到内存消耗激增时，我不会很快责怪这些框架.如果泄漏仪器未显示任何泄漏，并且分析仪未显示任何问题，则最可能的情况是它只是内存消耗，而不是泄漏.
No body is perfect - and that goes for Apple too. There have been documented cases in the past where Apple's frameworks have shown memory leaks (UIImage's caching leaked in iOS 2.x), but I wouldn't be so quick to blame the frameworks when you notice a spike in memory consumption. If the leaks instrument is not showing any leaks, and the analyser isn't showing any issues, the likeliest scenario is that it's just simply memory consumption and not a leak.
请记住，iOS设备不像计算机那样具有千兆字节的RAM，这一点很重要.您需要对所使用的内存保持保守.如果这意味着不能同时发送XX MB的图像，那么就必须这样做.
Its important to remember that iOS devices don't have gigabytes of RAM like computers do. You need to be conservative with the memory that you use. If that means not sending XX MBs of images at the same time, then that's the way it has to be.
这篇关于MFMailComposeViewController使用太多内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！