AutoReleasePool探索

探索中

背景

关于自动释放池，这个在第一次写iOS程序的时候，就能看到main.m中有@autoreleasepool字样。所以它到底是干什么的，内部结构怎样，又是通过什么机制释放的？这是这篇文章主要解答的几个问题。

1. autoreleasepool内部结构

将mian.m文件编译为C++代码时候，可以看到起内部的实现是借助__AtAutoreleasePool进行实现，内部结构是AutoreleasePoolPage，如下源码所示：

 /*@autoreleasepool */ { __AtAutoreleasePool __autoreleasepool; 
        return UIApplicationMain(argc, argv, __null, NSStringFromClass(((Class (*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("AppDelegate"), sel_registerName("class"))));
    }

// -----

extern "C" __declspec(dllimport) void * objc_autoreleasePoolPush(void);
extern "C" __declspec(dllimport) void objc_autoreleasePoolPop(void *);

struct __AtAutoreleasePool {
  __AtAutoreleasePool() {atautoreleasepoolobj = objc_autoreleasePoolPush();}
  ~__AtAutoreleasePool() {objc_autoreleasePoolPop(atautoreleasepoolobj);}
  void * atautoreleasepoolobj;
};

从上述源码中，可以看到__AtAutoreleasePool的构造函数，调用的是内部objc_autoreleasePoolPush、objc_autoreleasePoolPop方法，从上述extern可知，可以从源码中查看其内部实现情况：

void *
objc_autoreleasePoolPush(void)
{
    return AutoreleasePoolPage::push();
}

void
objc_autoreleasePoolPop(void *ctxt)
{
    AutoreleasePoolPage::pop(ctxt);
}

查看相应的类结构如下（精简后）：

class AutoreleasePoolPage 
{
    magic_t const magic;
    id *next;
    pthread_t const thread;
    AutoreleasePoolPage * const parent;
    AutoreleasePoolPage *child;
    uint32_t const depth;
    uint32_t hiwat;
}

从上述结构可以得出一下几个直观的结论：

一个AutoreleasePoolPage对象，对应一个thread；
从parent和child的类型知，AutoreleasePoolPage是一个双向链表；
表中的下一成员由next指针指向等。

通过在main.m中@autoreleasepool处添加断点，查看其内部汇编代码如下图1.1所示：

图1.1 main中汇编

从上图1.1中可以查看代码下一步执行的代码是：调用地址0x10d2718d2处的指令，内部进行一系列的push和jmp指令操作，即图1.1中的注释：objc_autoreleasePoolPush的操作；从图1.1 中的35行，也可以看出，还有一个相对应的objc_autoreleasePoolPop与之对应。感兴趣的可以查看源代码进行分析一下具体的流程。

在测试类中，添加如下的测试代码：


    NSAutoreleasePool *pool1 = [[NSAutoreleasePool alloc] init];
    
    Person *per1 = [[[Person alloc] init] autorelease];
    NSLog(@"11111111111-%p", per1);

    _objc_autoreleasePoolPrint();
    
    [pool1 drain];

在代码中将_objc_autoreleasePoolPrint();声明为外部调用的函数，即可以借助该函数可以查看其内部的存储在AutoreleasePoolPage中的情况。该函数是源码内部中的日志函数。结果如下所示（精简之后）：

     //objc[21609]: [0x7fea5d046d40]  ################  POOL 0x7fea5d046d40
     //objc[21609]: [0x7fea5d046d48]    0x604000009a90  Person
     //objc[21609]: ##############

从其中可以看出，当调用autorelease方法时，内部是将该对象的地址存储在page中的。当表释放后，该对象从表中移除。那么该表是何时释放的呢？这是之后需要讨论的问题。

2. autoreleasepool中的对象何时释放

2.1 主线程

通过在主线程中打印当前runloop中的对象，可以看到如下的情况：

    observers = (
    "{valid = Yes, activities = 0x1, repeats = Yes, order = -2147483647, callout = _wrapRunLoopWithAutoreleasePoolHandler (0x111373276), context = {type = mutable-small, count = 1, values = (\n\t0 : <0x7fa794002048>\n)}}",
    "{valid = Yes, activities = 0x20, repeats = Yes, order = 0, callout = _UIGestureRecognizerUpdateObserver (0x1119611a9), context = }",
    "{valid = Yes, activities = 0xa0, repeats = Yes, order = 1999000, callout = _beforeCACommitHandler (0x1113a2fdc), context = }",
    "{valid = Yes, activities = 0xa0, repeats = Yes, order = 2000000, callout = _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv (0x116d1d648), context = }",
    "{valid = Yes, activities = 0xa0, repeats = Yes, order = 2001000, callout = _afterCACommitHandler (0x1113a3057), context = }",
    "{valid = Yes, activities = 0xa0, repeats = Yes, order = 2147483647, callout = _wrapRunLoopWithAutoreleasePoolHandler (0x111373276), context = {type = mutable-small, count = 1, values = (\n\t0 : <0x7fa794002048>\n)}}"
),

在日志中，搜索autoreleasepool字样，可以看到主线程runloop中的observer在监听到activities = 0x1, 0xa0状态时，会调用：callout = _wrapRunLoopWithAutoreleasePoolHandler。

/* Run Loop Observer Activities */
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry = (1UL << 0),
    kCFRunLoopBeforeTimers = (1UL << 1),
    kCFRunLoopBeforeSources = (1UL << 2),
    kCFRunLoopBeforeWaiting = (1UL << 5),
    kCFRunLoopAfterWaiting = (1UL << 6),
    kCFRunLoopExit = (1UL << 7),
    kCFRunLoopAllActivities = 0x0FFFFFFFU
};

其中0x1, 0xa0对应着三种状态：进入kCFRunLoopEntry, kCFRunLoopBeforeWaiting和kCFRunLoopExit三种状态。通过上述的断点就可以查看，对象的真正释放是在runloop的kCFRunLoopBeforeWaiting和kCFRunLoopExit两种状态进行操作的。而关于具体的细节，到底是如何进行释放的，可以进行查看相应的源码进行自主分析。

这是主线程有runloop的情况。此时会立刻想到，子线程的runloop在没有手动开启时，又是通过什么机制进行操作的呢？

2.2 子线程

可以简单的通过如下代码开启一个子线程执行相应的操作：

[[[NSThread alloc] initWithTarget:self selector:@selector(testThreadRelease) object:nil] start];

- (void)testThreadRelease
{
 
    @autoreleasepool {
        
        Person *per1 = [[Person alloc] init];
        NSLog(@"11111111111-%p", per1);
        
        _objc_autoreleasePoolPrint();

    }

    NSLog(@"%s", __func__);
}

通过在@autoreleasepool处打断点，查看汇编代码进行单步调试，可以来到autoreleaseNewPage，接着是：autoreleaseNoPage，关键代码就在该函数中（精简之后）：

static __attribute__((noinline))
    id *autoreleaseNoPage(id obj)
    {
        // Install the first page.
        AutoreleasePoolPage *page = new AutoreleasePoolPage(nil);
        setHotPage(page);
        
        // Push a boundary on behalf of the previously-placeholder'd pool.
        if (pushExtraBoundary) {
            page->add(POOL_BOUNDARY);
        }
        
        // Push the requested object or pool.
        return page->add(obj);
}

可以看到，是重新新建了一个AutoreleasePoolPage作为当前活跃的页表结构，进而将该page进行类似入栈的操作。

从上述代码执行的捕捉过程来看，子线程中对象借助自动释放池进行释放的时机是和runloop无关的。

demo基本在例子中有详细的说明，因此如果有谁需要代码，可以发我邮件。
在阅读中，如果发现文章有不合理的地方，欢迎提出疑问至邮箱:[email protected].
原创文章，转载请注明：转自：Try_Try_Try
OK, game over.

好了，以上内容就是简单的探索过程。

参考的文章有：
《iOS与OS+X多线程和内存管理》

AutoReleasePool探索

背景

1. autoreleasepool内部结构

2. autoreleasepool中的对象何时释放

2.1 主线程

2.2 子线程

你可能感兴趣的:(AutoReleasePool探索)