VM Tracker显示较大的脏大小 [英] VM Tracker shows large Dirty Size
问题描述
我的应用程序中有一部分是我同时执行操作的。它们包括初始化许多CALayers并将它们渲染到位图。
There is a part of my app where I perform operations concurrently. They consist of initializing many CALayers and rendering them to bitmaps.
不幸的是，在这些操作期间（每次在iphone 4上完成大约需要2秒），Dirty Size指示VM Tracker的峰值达到~120MB。分配达到~12MB（不累积）根据我的理解，Dirty size是无法释放的内存。通常，我的应用程序和后台的所有其他应用程序都会被杀死。
Unfortunately, during these operations (each takes about 2 seconds to complete on an iphone 4), the Dirty Size indicated by VM Tracker spikes to ~120MB. Allocations spike to ~12MB(does not accumulate) From my understanding, the Dirty size is memory that cannot be freed. so often, my app and all other apps in the background gets killed.
Incident Identifier: 7E6CBE04-D965-470D-A532-ADBA007F3433
CrashReporter Key: bf1c73769925cbff86345a576ae1e576728e5a11
Hardware Model: iPhone3,1
OS Version: iPhone OS 5.1.1 (9B206)
Kernel Version: Darwin Kernel Version 11.0.0: Sun Apr 8 21:51:26 PDT 2012; root:xnu-
1878.11.10~1/RELEASE_ARM_S5L8930X
Date: 2013-03-18 19:44:51 +0800
Time since snapshot: 38 ms
Free pages: 1209
Active pages: 3216
Inactive pages: 1766
Throttled pages: 106500
Purgeable pages: 0
Wired pages: 16245
Largest process: Deja Dev
Processes
Name UUID Count resident pages
geod <976e1080853233b1856b13cbd81fdcc3> 338
LinkedIn <24325ddfeed33d4fb643030edcb12548> 6666 (jettisoned)
Music~iphone <a3a7a86202c93a6ebc65b8e149324218> 935
WhatsApp <a24567991f613aaebf6837379bbf3904> 2509
MobileMail <eed7992f4c1d3050a7fb5d04f1534030> 945
Console <9925a5bd367a7697038ca5a581d6ebdf> 926 (jettisoned)
Test Dev <c9b1db19bcf63a71a048031ed3e9a3f8> 81683 (active)
MobilePhone <8f3f3e982d9235acbff1e33881b0eb13> 867
debugserver <2408bf4540f63c55b656243d522df7b2> 92
networkd <80ba40030462385085b5b7e47601d48d> 158
notifyd <f6a9aa19d33c3962aad3a77571017958> 234
aosnotifyd <8cf4ef51f0c635dc920be1d4ad81b322> 438
BTServer <31e82dfa7ccd364fb8fcc650f6194790> 275
CommCenterClassi <041d4491826e3c6b911943eddf6aaac9> 722
SpringBoard <c74dc89dec1c3392b3f7ac891869644a> 5062 (active)
aggregated <a12fa71e6997362c83e0c23d8b4eb5b7> 383
apsd <e7a29f2034083510b5439c0fb5de7ef1> 530
configd <ee72b01d85c33a24b3548fa40fbe519c> 465
dataaccessd <473ff40f3bfd3f71b5e3b4335b2011ee> 871
fairplayd.N90 <ba38f6bb2c993377a221350ad32a419b> 169
fseventsd <914b28fa8f8a362fabcc47294380c81c> 331
iapd <0a747292a113307abb17216274976be5> 323
imagent <9c3a4f75d1303349a53fc6555ea25cd7> 536
locationd <cf31b0cddd2d3791a2bfcd6033c99045> 1197
mDNSResponder <86ccd4633a6c3c7caf44f51ce4aca96d> 201
mediaremoted <327f00bfc10b3820b4a74b9666b0c758> 257
mediaserverd <f03b746f09293fd39a6079c135e7ed00> 1351
lockdownd <b06de06b9f6939d3afc607b968841ab9> 279
powerd <133b7397f5603cf8bef209d4172d6c39> 173
syslogd <7153b590e0353520a19b74a14654eaaa> 178
wifid <3001cd0a61fe357d95f170247e5458f5> 319
UserEventAgent <dc32e6824fd33bf189b266102751314f> 409
launchd <5fec01c378a030a8bd23062689abb07f> 126
**End**
仔细观察，脏记忆主要包括Image IO和Core Animation页面。多个条目，包含数百到数千页。 Image IO和Core Animation究竟做了什么？如何减少脏内存？
On closer inspection, the dirty memory consists mostly of Image IO and Core Animation pages. multiple entries consisting of hundreds to thousands of pages. What does Image IO and Core Animation do exactly? and how can I reduce the Dirty Memory?
编辑：尝试在串行队列上执行此操作，并且没有改进Dirty memory的大小
edit: tried doing this on a serial queue and no improvement on size of Dirty memory
另一个问题。 Dirty Memory和分配有多大？
another question. how large is too large for Dirty Memory and allocations?
更新：
- (void) render
{
for (id thing in mylist) {
@autorelease {
CALayer *layer = createLayerFromThing(thing);
UIImage *img = [self renderLayer:layer];
[self writeToDisk:img];
}
}
}
在createLayerFromThing（thing）中;我实际创建了一个包含大量子图层的图层
in createLayerFromThing(thing); I actually creating a layer with a huge amount of sub layers
更新
maxConcurrentOperationCount = 4的第一个截图
first screenshot for maxConcurrentOperationCount = 4
秒为maxConcurrentOperationCount = 1
second for maxConcurrentOperationCount = 1
================== ================================================== ================================================== ======================================
因为它减少了并发操作的数量几乎没有减少，
我决定尝试maxConcurrentOperationCount = 10
and since it bringing down the number of concurrent operations barely made a dent, I decided to try maxConcurrentOperationCount = 10
推荐答案
很难说你出了什么问题任何细节，但这里有一些想法。
It's difficult to say what's going wrong without any details but here are a few ideas.
A。使用@autorelease。 CALayers在背景中生成位图，如果它们没有及时释放，它们总共会占用大量空间。如果您正在创建和渲染多个图层，我建议在渲染循环中添加一个自动释放块。如果所有图层都嵌套并且需要同时进行渲染，这将无济于事。
A. Use @autorelease. CALayers generate bitmaps in the backgound, which in aggregate can take-up lots of space if they are not freed in time. If you are creating and rendering many layers I suggest adding an autorelease block inside your rendering loop. This won't help if ALL your layers are nested and needed at the same time for rendering.
- (void) render
{
for (id thing in mylist) {
@autorelease {
CALayer *layer = createLayerFromThing(thing);
[self renderLayer:layer];
}
}
}
B.此外，如果您使用CGBitmapCreateContext进行渲染，您是否调用匹配的CGContextRelease？这也适用于CGColorRef。
B. Also if you are using CGBitmapCreateContext for rendering are you calling the matching CGContextRelease? This goes also for CGColorRef.
C.如果你使用malloc或calloc分配内存，你完成后可以释放它吗？确保发生这种情况的一种方法
C. If you are allocating memory with malloc or calloc are you freeing it when done? One way to ensure that this happens
发布渲染循环的代码以提供更多上下文。
Post the code for the rendering loop to provide more context.
这篇关于VM Tracker显示较大的脏大小的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
