0

我在 iPad 上遇到崩溃，我认为这与我的应用程序内存不足有关，但是我似乎无法收集有关崩溃本身的任何信息以解决它。该应用程序使用 ARC。

该应用程序花费大约 20 分钟从我们的服务器下载数据并填充核心数据模型。在 20 分钟左右，应用程序崩溃了。

设备并没有耗尽空间——事实上，下载的内容只占用了 100 兆字节。我只使用一个托管上下文对象（注意，在整个数据集下载之前，我不会保存上下文）。

当我在启用了异常断点的调试中运行时，我的应用程序会崩溃而不会中断，也不会显示任何类型的警告或错误。

关于如何追踪问题的任何建议？从下面的崩溃日志中，看起来应用程序是否内存不足，或者可能是

这是崩溃日志：

Incident Identifier: A619465F-2E85-4BBC-BBE7-2330D4700FB8
CrashReporter Key:   6fa0c5a4f6cbeaf7a98e6c0e9ad8be6b27789039
Hardware Model:      iPad2,2
OS Version:          iPhone OS 6.0.1 (10A523)
Kernel Version:      Darwin Kernel Version 13.0.0: Wed Oct 10 23:29:31 PDT 2012; root:xnu-2107.2.34~2/RELEASE_ARM_S5L8940X
Date:                2013-04-27 09:53:43 +0200
Time since snapshot: 152 ms

Free pages:        934
Active pages:      3455
Inactive pages:    1821
Throttled pages:   103117
Purgeable pages:   0
Wired pages:       18795
Largest process:   GreaseBook

Processes
     Name                    <UUID>                       rpages       recent_max       [reason]          (state)

      MobileMail <27df582d2bed3501834661269810ad98>         3928             3928         [vm]         (continuous)
             kbd <24d58ac14ed3340380492fef46eac29d>          574              574         [vm]         (daemon)
            tccd <eb5ddcf533663f8d987d67cae6a4c4ea>          281              281         [vm]         (daemon)
      GreaseBook <2f5df68a7078386298eadbb24ebbdb33>        84210            84210         [vm]         (frontmost) (resume)
            ptpd <0cac6936ffeb362d98eb8073af935d21>          992              992                      (daemon)
    mediaserverd <bdc35c073fe134b9a39b96342a80159e>         1082             1082                      (daemon)
         syslogd <cbef142fa0a839f0885afb693fb169c3>          281              281                      (daemon)
       locationd <4bee615548dd33f48e18bfed4296f05d>         1675             1675                      (daemon)
           wifid <a243b2fcde2537159660b3ee7e809df4>          649              649                      (daemon)
      aosnotifyd <01901b13681f3582b5bfbe53504d08d6>          480              480                      (daemon)
     dataaccessd <117e4e475b14305982f52484564cfbc7>         1319             1319                      (daemon)
   iaptransportd <f784f30dc09d32078d87b450e8113ef6>          241              241                      (daemon)
     SpringBoard <0e3571e8067533e2811a6d444f10a349>         4058             4058                     
      backboardd <a9b5346126a939dfb0920a4bbc48201b>         6057             6057                      (daemon)
         imagent <d15f873abdd233f0a34d77a7d36e9e0f>          329              329                      (daemon)
   mDNSResponder <3e557693f3073697a58da6d27a827d97>          283              283                      (daemon)
  UserEventAgent <6edfd8d8dba23187b05772dcdfc94f90>          589              589                      (daemon)
    syslog_relay <45e9844605d737a08368b5215bb54426>            0                0                      (daemon)
       CVMServer <3ec015e0150d341a929ebbbc45f4c8ac>          104              104                      (daemon)
            afcd <b0aff2e7952e34a9882fec81a8dcdbb2>          165              165                      (daemon)
notification_pro <845b7beebc8538ca9ceef731031983b7>          203              203                      (daemon)
filecoordination <fbab576f37a63b56a1039153fc1aa7d8>          195              195                      (daemon)
       distnoted <a89af76ec8633ac2bbe99bc2b7964bb0>          132              132                      (daemon)
            apsd <d0e432fd45023d629ffb305b7e79d7fb>          403              403                      (daemon)
      aggregated <cd70154f955c31bbab58bf5f0acd3acd>          108              108                      (daemon)
        networkd <b24547cbe04b3e94a4bd406e586cdf8a>          222              222                      (daemon)
        BTServer <f57113a7cc2c33678ee832bc088276be>          356              356                      (daemon)
         configd <4245d73a9e96360399452cf6b8671844>          576              576                      (daemon)
   fairplayd.K94 <1a5f575df8f4368db1eae7ba3da11150>          270              270                      (daemon)
       fseventsd <996cc4ca03793184aea8d781b55bce08>          362              362                      (daemon)
          powerd <2d2ffed5e69638aeba1b92ef124ed861>          198              198                      (daemon)
       securityd <c35e701a5aab3968ae8d93ef8db02e07>          159              159                      (daemon)
       lockdownd <481275a4062931708a7440ff0f73f229>          495              495                      (daemon)
CommCenterClassi <c10fa2a1b7673e1ab14e6ecd11b9b7e7>          557              557                      (daemon)
         notifyd <51c0e03da8a93ac8a595442fcaac531f>          199              199                      (daemon)

**End**
4

1 回答 1

3

在将大型数据集下载到核心数据中时，您需要考虑很多事情。当谈到内存管理时，下面描述了更流行的问题。

首先，您需要经常保存，这可以让您从NSManagedObjectContext（又名 MOC）中清除内存。在任何时候，您都可以通过查看 MOC 的registeredObjects属性来查看 MOC 有哪些对象。

通常，当您保存 MOC 时，任何对它们没有强引用的对象都会从 MOC 中删除。同样，您可以在保存后通过查看registeredObjects. 但是，如果您的模型中有关系，那么对象将包含对彼此的强引用，这会创建一个保留循环。因此，对象将永远不会被释放，直到保留周期被打破。

您可以通过使用来打破 MOC 中的保留周期refreshObject:object mergeChanges:NO。您可以通过调用来清除所有对象，reset但这相当严格，并且您需要确保在执行此操作时不持有对托管对象的任何引用。

即使您的托管对象之间没有保留周期，您仍然可能无意中保留了您将永远不会再次使用的对象。这就是，即使您使用 ARC，您仍然需要了解一些内存管理规则。具体来说，自动释放对象。它们将被自动释放，但直到自动释放池回收对象。

因此，您应该将您的操作包装在您自己的自动释放池中。这很简单：

@autoreleasepool {
    // Unless you hold references elsewhere, objects allocated in here will be
    // auto released when this scope ends.
}

如果您有一个线程在进行下载，并且您使用 MOC NSPrivateQueueConcurrencyType，则您传递给的块performBlock会自动包装在自动释放池中。

于 2013-04-27T14:11:47.430 回答