Question

我的应用程序中有一部分是我同时执行操作的。它们包括初始化许多CALayers并将它们渲染到位图。

不幸的是，在这些操作过程中（每次在iphone 4上完成大约需要2秒钟），VM Tracker指示的脏大小达到~120MB。分配达到~12MB（不累积）根据我的理解，Dirty size是无法释放的内存。通常，我的应用程序和后台的所有其他应用程序都会被杀死。

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究竟做了什么？以及如何减少脏记忆？

编辑：尝试在串行队列上执行此操作，并且没有改进Dirty memory的大小

另一个问题。 Dirty Memory和分配有多大？

更新：

- (void) render
{
    for (id thing in mylist) {
        @autorelease {
            CALayer *layer = createLayerFromThing(thing);
            UIImage *img = [self renderLayer:layer];
            [self writeToDisk:img];
        }
    }
}

在createLayerFromThing（thing）中;我实际创建了一个包含大量子图层的图层

已更新

maxConcurrentOperationCount = 4的第一个截图

对于maxConcurrentOperationCount = 1

，

秒

maxConcurrentOperationCount = 4

maxConcurrentOperationCount = 1

============================================ ================================================== ================================================== ============

由于它减少了并发操作的数量几乎没有下降，我决定尝试maxConcurrentOperationCount = 10

maxConcurrentOperationCount = 10

Answer 1

如果没有任何细节，很难说出现了什么问题，但这里有一些想法。

一个。使用@autorelease。 CALayers在背景中生成位图，如果它们没有及时释放，它们可以占用大量空间。如果您正在创建和渲染多个图层，我建议在渲染循环中添加一个自动释放块。如果所有图层都嵌套并且需要同时进行渲染，这将无济于事。

- (void) render
{
    for (id thing in mylist) {
        @autorelease {
            CALayer *layer = createLayerFromThing(thing);
            [self renderLayer:layer];
        }
    }
}

B中。此外，如果您使用CGBitmapCreateContext进行渲染，您是否正在调用匹配的CGContextRelease？这也适用于CGColorRef。

℃。如果你使用malloc或calloc分配内存，你完成后可以释放它吗？确保这种情况发生的一种方法

发布渲染循环的代码以提供更多上下文。

Answer 2

我相信这里有两种可能性：

您创建的项目未自动释放。
由于你正在进行的并发操作数量，你所占用的内存就是它。

在第一种情况下，解决方案很简单。在创建图层和图片时向其发送autorelease条消息。

在第二种情况下，您可以使用NSOperationQueue来限制并发操作的数量。操作队列具有名为maxConcurrentOperationCount的属性。我会尝试使用值4，并查看内存行为如何从您当前的状态变化。当然，您可能必须尝试不同的值才能获得正确的内存与性能平衡。

Answer 3

Autorelease将等到运行循环结束以进行清理。如果你明确释放它可以从堆中取出而不填充池。

- (void) render {
    for (id thing in mylist) {
        CALayer *layer = createLayerFromThing(thing);    // assuming this thing is retained
        [self renderLayer:layer];                        
        [layer release];                                 // this layer no longer needed  
    } }

还可以使用analyze运行构建，看看是否有泄漏并修复它们。

VM Tracker显示较大的脏大小

3 个答案: