ios CoreData NSManagedObject 生命周期

用同样的检索条件从context检索出的对象是一个？？？？所以 在主页的3个brand没法释放，在仅仅处理brand的时候？？？？

 

和 多个 context无关

 

我重写了NSManagedObject 子类的 的 dealloc 方法，让它在释放时，输出log，这样就能检测它的释放情况了。

先看一个简单的情况，局部变量里用 insertNewObjectForEntityForName 方法插入一个对象，不保存context。代码如下：

 TestFile *file = [NSEntityDescription insertNewObjectForEntityForName:@"TestFile" inManagedObjectContext:[[DBManager sharedManager] managedObjectContext]];

没有log输出，说明没有释放。 之后保存context，释放的log输出了。我又测试了函数完成后2秒后再进行save context，结果log输出就变成了2秒后。

之后我又把这个变量写成全局变量，代码如下：

file = [NSEntityDescription insertNewObjectForEntityForName:@"TestFile" inManagedObjectContext:[[DBManager sharedManager] managedObjectContext]];

这次立即保存context也没有输出log。

从上面这2个测试可以看出，NSManagedObject 也是遵守 oc 的释放规则的：有强引用就不释放。有些特殊的地方是：当建立一个局部变量时，如果这个变量还没被保存，那么context会自动进行强引用，防止数据丢失，这样就出现了 即使是局部变量，对象的生命周期也没有在函数结束后就结束！

 

测完insert，再测测查询。

先看简单的查询：

 HubFile *file = [HubFileDAO retrieveHubFilesByFileID:[NSNumber numberWithInt:1103]];

函数结束后，立即输出了释放log。换成全局变量后，没有log输出了。

再看update，代码如下：

 HubFile *file = [HubFileDAO retrieveHubFilesByFileID:[NSNumber numberWithInt:1103]];
    
 file.shownName = @"aaaaaa";

函数结束后，没有log输出。就像insert时的情况一样了，context 必须保存后才能释放对象。

 

由此进一步总结一下，对于一个NSManagedObject对象，如果它有任何新内容没有被context保存，那么对应的context就会对它进行强引用，直到我们对context 进行保存。

 

再看下面代码

同样的检索条件检索出的对象的地址是一致的！不要把他们当做2个对象！有特殊情况存在，见下面的测试！ 

再看以下代码：

  HubFile *file1 = [HubFileDAO retrieveHubFilesByFileID:[NSNumber numberWithInt:1136]];
    
    [[DBManager sharedManager].managedObjectContext reset];
    
    NSLog(@"file name is %@",file1.shownName);

输出是 file name is (null)。

由于掉用了reset，NSManagedObject 的数据部分变成了 fault（可以理解为无效的）。虽然这时的file1指针仍然指向NSManagedObject对象，但是对所有data属性都变成了nil。

再看以下代码：

    HubFile *file1 = [HubFileDAO retrieveHubFilesByFileID:[NSNumber numberWithInt:1136]];
    
    [[DBManager sharedManager].managedObjectContext reset];
    
    HubFile *file2 = [HubFileDAO retrieveHubFilesByFileID:[NSNumber numberWithInt:1136]];
    
    NSLog(@"file1 name is %@",file1.shownName);
    NSLog(@"file2 name is %@",file2.shownName);

输出是

file1 name is (null)

 file2 name is aaaa

看看NSLog(@"file2 name is %@",file2.shownName);调用后的内存情况：

 

 

虽然检索条件相同，但是由于在中间掉用了reset函数，file1和file2指向了不同的地址。可以看出，在context reset后，所有之前查询到的指针都失去了作用，虽然它们的地址不是空，但是无法对任何数据属性进行访问了。再次查询也不会在原来的地址上进行内存分配，而是重新分配了一块内存。简单地说，调用 reset 后 ，就不该使用以前的旧对象引用了！

 

再看由于使用 relationship 产生的 retain circle

   HubBrand *oldBrand = [HubBrandDAO retrieveHubBrandByModelID:@"5586476805"];
   oldBrand.shownName = @"aaaa";
   [[DBManager sharedManager] saveContext];

brand对象可以释放。

   HubBrand *oldBrand = [HubBrandDAO retrieveHubBrandByModelID:@"5586476805"];
    oldBrand.shownName = @"aaaa";
    oldBrand.iconFile.shownName = @"tttttt";
    [[DBManager sharedManager] saveContext];

brand 对象无法释放，这里iconFile是一个一对一的relationship，关联一个File对象。

这里有一个解释：http://stackoverflow.com/questions/1789974/core-data-and-retain-cycles

When you have relationships between managed objects, each object maintains a strong reference to the object or objects to which it is related. In a managed memory environment, this causes retain cycles (see Object Ownership and Disposal) that can prevent deallocation of unwanted objects. To ensure that retain cycles are broken, when you're finished with an object you can use the managed object context method refreshObject:mergeChanges: to turn it into a fault.

根据说明，我们再试试下面代码：

 HubBrand *oldBrand = [HubBrandDAO retrieveHubBrandByModelID:@"5586476805"];
    oldBrand.shownName = @"aaaa";
    oldBrand.iconFile.shownName = @"tttttt";
  
    //必须在save之后调用,不然无法达到打破retain circle的作用！
    //[[DBManager sharedManager].managedObjectContext refreshObject:oldBrand mergeChanges:YES];
   
      [[DBManager sharedManager] saveContext];
    
     [[DBManager sharedManager].managedObjectContext refreshObject:oldBrand mergeChanges:YES];

brand 和 file 对象都被正确释放了！