眾所周知，block可以封裝一個匿名函數為對象，并捕獲上下文所需的數據，并傳給目標對象在適當的時候回調。正因為將抽象的函數具體化為一個可以存儲管理的對象，block可以很容易被建立，管理，回調，銷毀，也能很好的管理其執(zhí)行所需要的數據，再加上即用即走和對代碼邏輯上下文完整等優(yōu)點，被大多數開發(fā)者廣泛使用。雖然使用者很多，但還是有不少人對其實現和編譯器背后如何支持還有一些疑惑，通過閱讀本文相信你對block將會有一個比較清晰的認知。在解決一些棘手的內存問題的時候將會更加得心應手。

block的本質

首先寫一個簡單的block

int main(int argc, char * argv[]) {
    void(^blockA)(void) = ^{};
    blockA();
    return 0;
}

使用簡單的clang main.m -rewrite-objc得到C++的main.cpp文件
關注我們感興趣的部分，還是做個注釋吧（64bit），熟悉這些偏移量比較重要，對分析問題很有幫助，block基礎大小是32byte。

extern "C" _declspec(dllexport) void *_NSConcreteGlobalBlock[32];
extern "C" _declspec(dllexport) void *_NSConcreteStackBlock[32];
struct __block_impl {
  void *isa; //8byte，isa指針，很重要的標志，意味著block很可能是個OC的類
  int Flags;//4byte，包含的引用個數
  int Reserved;//4byte
  void *FuncPtr;//8byte，回調函數指針
};

struct __main_block_impl_0 {
  struct __block_impl impl;
  struct __main_block_desc_0* Desc;//8byte，block的描述，輔助工具
  //如果有捕獲外部變量的話會定義在這里
  ...
  __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, int flags=0) {
    impl.isa = &_NSConcreteStackBlock;
    impl.Flags = flags;
    impl.FuncPtr = fp;
    Desc = desc;
  }
};

static void __main_block_func_0(struct __main_block_impl_0 *__cself) {
//自定義block函數體
}

static struct __main_block_desc_0 {
  size_t reserved;
  size_t Block_size;
} __main_block_desc_0_DATA = { 0, sizeof(struct __main_block_impl_0)};//這里Block_size=32byte

int main(int argc, char * argv[]) {
    //定義函數指針，然后賦值上面靜態(tài)函數，具體的代碼實現被移到了上面的函數中
     void(*blockA)() = ((void (*)())&__main_block_impl_0((void *)__main_block_func_0, &__main_block_desc_0_DATA));
    //調用和傳參數
     ((void (*)(__block_impl *))((__block_impl *)blockA)->FuncPtr)((__block_impl *)blockA);
     return 0;
}

我們可以拷貝這些代碼來運行，但有幾點需要注意的不要引入OC頭文件，否則_NSConcreteStackBlock會重復定義，我們只需要定義同樣的全局的變量來替代它或者刪掉就可以了；main中第一句代碼會報錯taking the address of a temporary object of type '__main_block_impl_0'， 這是因為這里調用了構造函數 _main_block_impl_0，這會生成一個臨時返回值，在c++ 11語法里面這個返回值是個右值引用，是無法進行取地址運算的。所以這里改寫一下就可以運行了，代碼運行起來其調用過程就比較好辦了，這里就不具體細說了。

    __main_block_impl_0 block_struct = __main_block_impl_0((void *)__main_block_func_0, &__main_block_desc_0_DATA);
    void (*blockA)() = (void (*)())&block_struct;
    
    void (*block_func)(struct main_block_impl_0 *__cself) = (void (*)(struct __main_block_impl_0 *))((__block_impl *)blockA)->FuncPtr;
    block_func((struct __main_block_impl_0 *)(*blockA));
       

注意：我這里改寫的這個代碼是存在一些問題的，因為block_struct是棧上的，所以一旦賦值給強引用時會copy一份放到堆上（GlobalBlock除外），調用block的時候可能已經超出block_struct的生命周期了。

接著看代碼

在代碼中我們看到了OC類的標志isa指針，并且指向_NSConcreteStackBlock，但具體是不是那么回事還是需要證明一下。畢竟編譯和運行時還是有些不一樣。

在bockA();這句加斷點；在編譯器debug窗口左側有當前調用棧幀可見變量，找到blockA，發(fā)現 __isa=__NSGlobalBlock__和上面改寫代碼中的impl.isa = &_NSConcreteStackBlock還是有出入的，我們選擇相信運行時。

選中__isa右鍵菜單View Memery of "__isa"可以瀏覽當前內存的值，我這里isa指向的地址是0x1003b8048，然后可以看到這里值是70 94 59 0b 01 00 00 00(8byte)，小端機器，實際的數據是010B599470，觀察代碼void *_NSConcreteGlobalBlock[32]發(fā)現這是一個地址，對應的地址就是0x10B599470，管它是不是OC對象，我們在lldb下po 0x10B599470輸出一下是__NSGlobalBlock__，呵，可能有譜，再追蹤這個地址

屏幕快照 2018-05-03 18.16.44.png

可以看到以下內存數據前8個byte是010B5994F0，順便輸出一下也打印了__NSGlobalBlock__，再看發(fā)現這個地址就在附近，里面記錄的第一個數據是010780DE58，我們知道OC對象第一個數據就是isa指針，將其構建成地址0x10780de58，輸出一下，打印了NSObject，這里可以理出關系blockA.isa->__NSGlobalBlock__.isa->NSObject，也就是說__NSGlobalBlock__的元類是NSObject，這基本可以證明__NSGlobalBlock__應該是個OC類型。

但我們希望得到最直接的證明就是一直找superclass直至找到NSObject。

找到objc_class的定義，發(fā)現其繼承自objc_object

struct objc_class : objc_object {
    Class superclass;//Class就是objc_class *
    ...
}

struct objc_object {
private:
    isa_t isa;
}

objc_object只有一個isa_t的數據

union isa_t {
    Class cls;
    uintptr_t bits;//是個unsigned long
    ...//帶位域的struct，這里不關注
}

由此可見objc_class的前8byte是isa指針，第二個8byte是superclass指針。

我這里一次是0x010a6112a0(__NSGlobalBlock)，0x10a611110(NSBlock)，0x10780dea8(NSObject)

對照上面的NSObject，其地址0x10780de58，有點蒙，到底哪個對？其實都算對。

這里我定義了一個NSObject的對象，利用其運行時isa和superclass的數據，做了一個兩者的關系圖。

屏幕快照 2018-05-03 18.28.27.png

還記得這個繼承體系圖，和上面結果一致。

isa_superclass.jpg

從相關資料可以了解，OC中除了NSProxy外，其他的類都是NSObject的子類，包括元類，這個NSObject就是下圖中的0x10780dea8。

OK，至此證明block是個OC對象，其繼承自NSBlock，NSObject。

上面的環(huán)也可以解釋一些經典的問題，比如（寫本文的時候查資料時剛好遇到，就貼上來了）：

    Class cls1 = [NSObject class];//0x10780dea8
    id cls2 = (id)[NSObject class];//0x10780dea8
    BOOL r1 = [cls2 isKindOfClass:cls1];//isa找到0x10780de58,再找到0x10780dea8比較
    BOOL r2 = [cls2 isMemberOfClass:cls1];//isa找到0x10780de58比較

  //User不存在這個環(huán)，也就不會出現這個現象
    Class cls3 = [User class];
    id cls4 = (id)[User class];
    BOOL r3 = [cls4 isKindOfClass:cls3];
    BOOL r4 = [cls4 isMemberOfClass:cls3];

    NSLog(@"%d  %d  %d  %d",r1, r2, r3, r4);//結果是 1 0 0 0

之所以費力的證明Block是個OC對象，是因為這可以更好的認知Block，得到很多的信息和用法。我們或許可以像用普通的OC對象一樣使用Block，可以方便得被ARC管理，不用擔心內存泄露或者非法訪問。weak，autorelease等等也都可以使用，還可以放在集合里面，可以被別的對象持有，當然也可以持有別的對象，了解到這一點對于我們分析block的相關的內存管理和循環(huán)引用意義重大。

但在重寫的C++的代碼中我們看不到編譯器幫我們插入的release，retain這樣的代碼，所以我們不得不用別的辦法來了解Block具體是否被ARC管理的。

Block本身的內存管理

首先要明確一件事：Block本身內存的管理和Block捕獲的對象的內存管理是兩個問題。這里我們先討論前者。

前面遺留了一個問題就是，代碼里面isa指針明明指向了_NSConcreteStackBlock，怎么到了運行時的時候就變成了__NSGlobalBlock__？

我們再做一個實驗，將代碼改為

void afunc() {
    __unsafe_unretained void(^blockA)(void) = ^{};
    blockA();
}

int main(int argc, char * argv[]) {
    afunc();
    return 0;
}

在blockA()處下個斷點，查看debug數據，發(fā)現isa指針確實指向的是__NSGlobalBlock__，也就是說在這之前就被更新了，目前我還沒有找到這個更新時機。

我們發(fā)現調用blockA()可以成功，沒有crash，我嘗試取了一下retainCount發(fā)現是1，去掉__unsafe_unretained也一樣。

注意：通過kvc可以獲取對象的引用計數，如果一個函數來打印對象的引用計數，這函數的參數聲明是有講究的

void printRetainCount(__unsafe_unretained id o) {
    void *p = (__bridge void *)o;
    NSLog(@"%p:%d",p,[o valueForKey:@"retainCount"]);
}

參數需要用__unsafe_unretained來修飾，最好不要用強引用，這會導致引用計數器+1，更不能用weak，這會導致每次使用weak對象的時候，retainCount都會增加，這個坑一不小心就會忽略，導致獲取的數據可能不準確，關于這個問題具體情況以后有機會再討論。

修改代碼增加全局__weak void(^blockB)(void) = nil;，并在afunc()對其賦值，在main()中調用blockB()，發(fā)現也可以調用成功，并沒有crash。通過__NSGlobalBlock__這個名字大概可以猜測出這個是一個全局的block，其生命周期全局有效，即使主動調用copy，也不會入堆，似乎不受ARC控制。對照源碼可知，globalblock其實并不依賴外部數據，只要有代碼入口就可以使用，甚至不需要知道block，只有有函數入口地址就可以直接調用，而另外兩種都需要通過block去調用，而不能直接調用block內函數指針（當然要是自己準備各種參數也是可以的）。

將代碼修改為：

void afunc() {
    int a = 100;
    __unsafe_unretained void(^blockA)(void) = ^{
        int b = a;
    };
    blockA();
}

int main(int argc, char * argv[]) {
    afunc();
    return 0;
}

在blockA()處下個斷點，查看debug數據，發(fā)現isa指針指向的是__NSStackBlock__，去掉 __unsafe_unretained后isa指針變成了__NSMallocBlock__。

我們發(fā)現調用blockA()可以成功，沒有crash，我嘗試取了一下retainCount發(fā)現是1，去掉__unsafe_unretained也一樣，??，跟一般的OC對象不太一樣？

再次修改代碼和上面一下增加__weak void(^blockB)(void) = nil，在main中調用blockB()，發(fā)現其crash了，證明blockB已經無效了。再次將__unsafe_unretained修改為__autoreleasing，發(fā)現其可以調用成功，所以證明block此時被autoreleasepool接管了，看上去ARC還是有作用的。

那么在ARC下，如果增加一個強引用指向block會不會導致retainCount增加呢？通過實驗發(fā)現不會，依舊是1，這一點又和普通的對象不太一樣。

難道這就是真相，no，這無法解釋之前觀察到的各種現象。我多次運行，多次調用并打印block的地址，發(fā)現其地址都一樣。

Printing description of *(blockA).__FuncPtr:
(void (*)(NSString *, int)) __FuncPtr = 0x0000000100f66570 (Block`__afunc_block_invoke at main.m:58)

仔細一看，發(fā)現其打印的地址和__FuncPtr地址一樣，那么同理取的block的retainCount也就可有能不正確，去objc源碼中搜索了一下發(fā)現其實現為

-(NSUInteger)retainCount {
    return (_rc_ivar + 2) >> 1;                                             
}     

也就是說，只要對象沒有被釋放，那么其retainCount至少是1。換句話說，如果某個對象沒有_rc_ivar，或者_rc_ivar=0，那么其結果都是1，所以這里通過KVC取retainCount在block這里并不可靠，因為ARC機制下并不允許訪問retainCount，所以其可靠性在有些情況還是會受到質疑的，不足以作為判斷標準。但是我們發(fā)現一個問題，就是分配在棧上的block出了作用域已經無效了，那也就是說block應該在一定程度上受到ARC機制的約束，這需要進一步求證。

還記isa_a定義么，接下來我們去擼一下完整源碼：

union isa_t 
{
    isa_t() { }
    isa_t(uintptr_t value) : bits(value) { }

    Class cls;
    uintptr_t bits;

# if __arm64__
#   define ISA_MASK        0x0000000ffffffff8ULL
#   define ISA_MAGIC_MASK  0x000003f000000001ULL
#   define ISA_MAGIC_VALUE 0x000001a000000001ULL
    struct {
        uintptr_t nonpointer        : 1;
        uintptr_t has_assoc         : 1;
        uintptr_t has_cxx_dtor      : 1;
        uintptr_t shiftcls          : 33; // MACH_VM_MAX_ADDRESS 0x1000000000
        uintptr_t magic             : 6;
        uintptr_t weakly_referenced : 1;
        uintptr_t deallocating      : 1;
        uintptr_t has_sidetable_rc  : 1;
        uintptr_t extra_rc          : 19;
#       define RC_ONE   (1ULL<<45)
#       define RC_HALF  (1ULL<<18)
    };
}

我們這次只關注其中shiftcls和extra_rc，前者是存放isa指針存儲數據的真正空間，后者是存放對象額外引用計數的，如果這里19 bits還不夠的話，就使用sidetable來記錄。也就是說，絕大部分情況下，引用計數器是存在對象的isa里面的，所以我們只需要去查看isa的內存值，解析最后19bits的值就可以得到引用計數。

打個斷點，在這里選擇debug窗口左側的variables view窗口，選中某個block指針，右鍵 view memery of "*blockA"，可能不能瀏覽，所以view memery of "blockA"，我這里是內存地址0x16ee9f8f8存儲了以下數據

90 54 44 C0 01 00 00 00

將其構建出地址0x01c0555490，在Address中輸入該值，跳轉到新地址，我這里結果如下：

88 FF A7 B3 01 00 00 00    02 00 00 C3 00 00 00 00    70 65 F6 00 01 00 00 00

看到最后一個8個byte，有點眼熟，就是之前打印的__FuncPtr = 0x0000000100f66570。那前倆byte存的是啥呢？第一個byte明顯是一個指針，打印一下，就是__NSMallocBlock__，那剩下的8byte呢？從block的數據結構了解到其對應的就是

  int Flags;//4byte，包含的引用個數
  int Reserved;//4byte

后者是0，前者是有值而且會變化，我嘗試再給block一個強引用，發(fā)現02 00 00 C3變成了04 00 00 C3，再賦值就變成了06 00 00 C3，所以這個06應該就是引用計數器，而且也符合retainCount的運算邏輯，從內存布局上看，19bits的存儲位置應該在一個8-byte的末尾，也就是包含02這段空間，但只是不太了解為啥isa被分成了兩個64bits存儲。

同理我嘗試了僅僅在stack上的block，其數據位00 00 00 C2，計數器為0。

同理我嘗試了global的block數據位00 00 00 50，計數器為0。

結果符合預期，除了進入堆上block會受ARC約束，其他的block都不需要ARC參與就可以完成內存管理。

小結

1. Block如果不捕獲外界變量，就沒有上下文依賴，編譯器會將其標記為global類型（當然可能編譯器標記為stack，運行時優(yōu)化glabal常量）；否則編譯器會在創(chuàng)建時將其標記為stack，當運行時對象被強引用時或者主動調用copy會被標記為malloc類型。
2. global和stack的block都不需要ARC參與內存管理。malloc的block將受到ARC管理，包括autorelease和weak。

Block參數傳遞

前面的小節(jié)研究了Block的本質和其本身的內存管理，我們幾乎可以把他當做普通對象來使用，同時其擁有唯一的成員函數，其執(zhí)行所要依賴的數據來源有兩個，一個是當前上下文環(huán)境的各種變量，另外就是調用方的傳參。block傳參和函數傳參并沒有什么不同，這里就不做具體討論。

Block如何捕獲外界變量

之前為了重寫簡單我并沒有引入OC基礎框架，而要將一般的OC代碼轉成C++，比如以下代碼就引用了NSString：

typedef void (^ABlock)(void);

ABlock afunc() {
    NSString *a = @"this is a demo";
    void(^blockA)(void) = ^{
         NSString *b = a;
    };
    return blockA;
}

int main(int argc, char *argv[]) {
    ABlock aBlock = afunc();
    aBlock();
    return 0;
}

對于這類引用了OC類型的代碼，需要使用clang -rewrite-objc -fobjc-arc -fobjc-runtime=macosx-10.10 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk main.m可以將OC代碼轉成C++代碼。

這里需要指定編譯的sdk庫（我使用的是iPhoneSimulator.sdk），否則會出現“UIKit/UIKit.h” file not found，還需要指定-fobjc-arc開啟ARC的編譯開關和-fobjc-runtime=macosx-10.10，否則會出現“cannot create __weak reference in file using manual reference counting”類似的錯誤。

編譯真機的話需要指定支持的CPU架構和庫等（折騰了挺久才試出這些參數，??）clang -rewrite-objc -fobjc-arc -fobjc-runtime=ios-10.0 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk main.m

編譯器會根據捕獲的原始變量的不同情況，定義不同類型的變量來存儲這些數據。

根據變量定義類型，這里我分成以下幾類：

1. 以下是捕獲一個基本類型臨時變量i的c++代碼

struct __main_block_impl_0 {
  struct __block_impl impl;
  struct __main_block_desc_0* Desc;
  //如果有捕獲外部變量的話會定義在這里
  int i;
  __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, int _i, int flags=0) : i(_i) {
    impl.isa = &_NSConcreteStackBlock;
    impl.Flags = flags;
    impl.FuncPtr = fp;
    Desc = desc;
  }
};

可以看到，編譯器定義了一個int i來對應外界的int i，同時接收了外界i的值來初始化。

2. 同理如果是局部指針這里將定義為對應的指針，例如這里是 int *ip。
3. 如果需要捕獲的是一個局部OC對象，其實和2中情況一致，不同之處在于ARC會介這個對象的管理。
4. 對于全局變量，因為訪問是開放的，所以編譯器不需要做處理，直接使用該變量就行。

根據變量定義的附加修飾特性：

1. 對于局部static變量，因為訪問不開放，所以會被編譯器升級為指針，例如：static int staticInt = 100，會定義一個int *staticInt來捕獲staticInt的地址，以便以后修改。
2. 對于__weak修飾的對象引用，這個重點說明。

struct __main_block_impl_0 {
  struct __block_impl impl;
  struct __main_block_desc_0* Desc;
  NSString *__weak weakSelf;
  __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, NSString *__weak _weakSelf, int flags=0) : weakSelf(_weakSelf) {
    impl.isa = &_NSConcreteStackBlock;
    impl.Flags = flags;
    impl.FuncPtr = fp;
    Desc = desc;
  }
};

可以看到對于__weak修飾的引用，編譯器也在Block中定義一個一模一樣的引用，然后通過構造函數通過參數傳入初始化結構體（c++中struct和class絕大部分情況是等效的），這是意味著什么呢？我們知道所有函數參數傳遞就一種方式——copy，這里的參數捕獲間接套用了該性質。一句話來說，對象還是那個對象，但引用已經不是那個引用了。

屏幕快照 2018-05-14 17.21.39.png

這里我畫了一個簡圖，實際上每個weakSelf都是不一樣的，只是其指示的內容是同樣的。

3. __block修飾的對象，這里改寫為c++代碼出錯，我沒能解決這個問題。所以就只有推測了，其做法應該和局部的static變量捕獲差不多，都會定義一個同類型的指針或者引用，以便可以在block中訪問該變量修改變量。

小結

1. 參數捕獲和參數傳遞，前者發(fā)生在block定義初始化的時候，是對當前現場的一種保存，后者發(fā)生在調用的時候傳參，其存儲上的區(qū)別是前者是成員變量持續(xù)存儲，后者是臨時變量。相同之處就是獲取方式完全一致，都是函數參數傳遞。
2. 編譯器會對待不同類型的參數捕獲處理方式都一樣，全部淺拷貝；對于不同修飾參數則不太一樣，會根據不同的情況來決定是否升級為指針捕獲；OC對象將會引入ARC機制去管理。

Block循環(huán)引用及解決辦法

如果能明確認識到block就是個對象，那么造成循環(huán)引用的原因就不難理解了，block可以持有對象也可以被對象持有，如果兩者直接或者間接包含同一對象時就成了環(huán)，實際上就是object->block(->…)->object。

那么為什么用weak strong dance就可以解決這個問題呢？看下面這個典型例子。

__weak typeof(self) weakSelf = self;
void (^block)(void) = ^{
  __strong typeof(weakSelf) strongSelf = weakSelf;  
};

通過前面的C++的代碼分析，答案已經很清晰了，這里就再解釋一次：

我們知道block外部定義了一個weakSelf（為了方便說明，可以認為是weakSelf1），而在block內部并沒有直接使用這個weakSelf1(就是沒有使用這個weakSelf1這個硬編碼或者說其對應的地址)，而是另外定義了一個對應的構造函數參數__weak weakSelf（weakSelf2），通過指針copy傳參的方式，weakSelf2指向了weakSelf1指向的內容，同時block內部的成員變量 __weak weakSelf(weakSelf3)通過weakSelf賦值也指向了weakSelf1指向的內容。所以從始至終這些weakSelf都不是同一個東西。至于strongSelf就簡單了，對象賦值給強引用會導致retainCount+1，還記我之前文章里面的觀點么，ARC是用棧管理引用，用引用生命周期管理對象，所有strongSelf生命周期結束，自然retainCount-1。
所以在block還沒有執(zhí)行的時候，self的生命周期不受block影響，如果執(zhí)行的時候self已經被釋放， weakSelf3=nil，也不會導致問題，但是如果weakSelf3還有值，strongSelf就會導致retainCount+1。有很多人認為，無論如何必須等到block執(zhí)行完或者銷毀self才會釋放是不正確的。仔細對照block和delegate就會發(fā)現兩者在這方面其實本質是一樣的的，如果delegate不使用weak也一樣可能循環(huán)引用。還是那句話，內存中通信就一個招，拿到地址，所以無論是直接的delegate，block，target-action，還是間接的Notification，或者其他的玩法都一樣。

注意：__strong不能省略。

當然并不是說見到block就需要weak strong dance，對于以下情況就可以不使用（從調用方和回調方分析）

1. 如果能確定block的調用方并不會長期持有block，比如傳給B一個A持有的block，B并不存儲，而是立刻回調，常見的就是把block當函數參數傳遞。
2. 如果確定block調用方會在必要的時候去除強引用，比如：dispatch_async，其雖然會被隊列強引用，但在block回調的時候，_dispatch_call_block_and_release會在執(zhí)行完release，這也不會導致循環(huán)引用。
3. block創(chuàng)建方不會直接或間接強引用block。
4. 對于絕不可能持有block的對象，可以放心捕獲，比如NSString，NSDate，NSURL等等，但對于一些可能存儲block需要小心，比如：NSArray，NSDictionary，自定義的對象(self)。

如果你是創(chuàng)建方，不想去分析也不知道調用方干了什么，建議就無腦weak strong dance，幾乎可以就可以解決問題了。如果你是調用方，會麻煩一些，需要具體問題具體分析。

Block捕獲對象的內存管理

這分成三個方面，如果只是基本類型，那就不需要操心；如果是C指針，那指向對象的生命周期需要開發(fā)者手動管理；如果是個OC對象，內存管理由ARC代勞，只需要注意一些特殊情況就好。前兩者不做討論，研究一下后者。

typedef void(^ABlock)();
void pc(__unsafe_unretained id o) {
    void *p = (__bridge void *)o;
    NSLog(@"%@ %p：%@",o, p, [o valueForKey:@"retainCount"]);
}
@interface BlockDemo : NSObject
@end

@implementation BlockDemo
static int global = 1000;

- (ABlock)afunc:(NSString *)string {
    pc(self);
    pc(string);
    
    ABlock b;
    ABlock c;
    
    __weak typeof(self) weakSelf = self;
    b = ^{
        __strong typeof(weakSelf) strongSelf = weakSelf;
        pc(strongSelf);
        pc(string);
    };
    
    c = b;
    
    b();
    pc(self);
    pc(string);
    return b;
}
@end


int main(int argc, char * argv[]) {
    NSString *string = [[NSString alloc] initWithUTF8String:"this is a demo"];
    pc(string);
    BlockDemo *block = [BlockDemo new];
    ABlock a = [block afunc:string];
    a();    
}

此時輸出日志如下：

2018-05-15 11:44:46.626942+0800 Demo2[3175:1513369] this is a demo 0x1c403cc40：1

2018-05-15 11:44:46.627326+0800 Demo2[3175:1513369] <Block: 0x1c400e690> 0x1c400e690：1
2018-05-15 11:44:46.627515+0800 Demo2[3175:1513369] this is a demo 0x1c403cc40：2

2018-05-15 11:44:46.627588+0800 Demo2[3175:1513369] <Block: 0x1c400e690> 0x1c400e690：2
2018-05-15 11:44:46.627719+0800 Demo2[3175:1513369] this is a demo 0x1c403cc40：4

2018-05-15 11:44:46.627786+0800 Demo2[3175:1513369] <Block: 0x1c400e690> 0x1c400e690：1
2018-05-15 11:44:46.627810+0800 Demo2[3175:1513369] this is a demo 0x1c403cc40：4

2018-05-15 11:44:46.627995+0800 Demo2[3175:1513369] <Block: 0x1c400e690> 0x1c400e690：2
2018-05-15 11:44:46.628072+0800 Demo2[3175:1513369] this is a demo 0x1c403cc40：2

可以看到BlockDemo只在main中被持有+1，然后調用時被strongSelf持有+1，weakSelf并沒導致引用計數器增加，與輸出日志相符。

進入afunc:時，string引用計數為2，一個發(fā)生在main，一個發(fā)生在afunc:的參數中聲明中。調用b()時，retainCount=4，這是因為這是存在一個StackBlock和一個MallocBlock，這兩個都會有一個引用指向string。在afunc:函數末尾打印string是4也是同樣的原因；當afunc:執(zhí)行完后，StackBlock已經釋放，返回block給main中的a，此時調用a()，輸出2，其中引用來自于MallocBlock，符合預期。

c=b這句賦值，只引起block計數器增加，而不會導致捕獲OC對象引用計數器增加，符合預期。

我們在lldb設置倆符號斷點：

breakpoint set -n _Block_copy
breakpoint set -n _Block_release

可以發(fā)現_Block_copy和普通對象retain時機調用類似。

需要注意的問題

1. block捕獲變量防止循環(huán)引用容易漏掉一些情況，在捕獲時需要多注意，舉個例子，直接捕獲成員變量。

   假設在一個對象方法里面，比如ViewController
   void (^block)(void) = ^{
       //這里是等效于self->_name，編譯器編碼為self+offset(_name)，依然會導致強引用
        NSString *name = _name; 
   };
   

2. 直接修改捕獲的變量不能成功，因為里外的兩個array不是一個array，需要加上__block，變量捕獲通過函數傳參的方式實現，而傳參全是copy。

   NSArray *array = @[@1,@2];
   void (^block)(void) = ^{
       array = @[];
   };
   

   ?

附加內容

之前從宏觀層面了解了block和其捕獲對象的生命周期，但具體是怎樣還是不太清晰，有興趣的話可以看下面一段內容，具體了解block是怎么玩的，匯編較長，看起來也比較繞，沒興趣的話可以忽略，看看其中的一些要點。
源碼：

typedef void (^ABlock)(void);

ABlock afunc() {
    NSString *a = @"demo";
    void(^blockA)(void) = ^{
         NSString *b = a;
    };
    return blockA;
}

int main(int argc, char *argv[]) {
    ABlock aBlock = afunc();
    aBlock();
    return 0;
}

匯編：

    .section    __TEXT,__text,regular,pure_instructions
    .ios_version_min 11, 0
    .file   1 "/Users/Wei/File/program/Block" "/Users/Wei/File/program/Block/Block/main.m"
    .globl  _afunc                  ; -- Begin function afunc
    .p2align    2
_afunc:                                 ; @afunc
Lfunc_begin0:
    .loc    1 33 0                  ; /Users/Wei/File/program/Block/Block/main.m:33:0
    .cfi_startproc
; BB#0:
    sub sp, sp, #112            ; =112
    stp x29, x30, [sp, #96]     ; 8-byte Folded Spill
    add x29, sp, #96            ; =96
Lcfi0:
    .cfi_def_cfa w29, 16
Lcfi1:
    .cfi_offset w30, -8
Lcfi2:
    .cfi_offset w29, -16
Ltmp0:
    .loc    1 34 15 prologue_end    ; /Users/Wei/File/program/Block/Block/main.m:34:15
    adrp    x0, l__unnamed_cfstring_@PAGE
    add x0, x0, l__unnamed_cfstring_@PAGEOFF
    bl  _objc_retain
    stur    x0, [x29, #-8]
    add x0, sp, #40             ; =40
    .loc    1 36 11                 ; /Users/Wei/File/program/Block/Block/main.m:36:11
    add x30, x0, #32            ; =32
    .loc    1 36 27 is_stmt 0       ; /Users/Wei/File/program/Block/Block/main.m:36:27
    adrp    x8, __NSConcreteStackBlock@GOTPAGE
    ldr x8, [x8, __NSConcreteStackBlock@GOTPAGEOFF]
    str x8, [sp, #40]
    mov w9, #-1040187392
    str w9, [sp, #48]
    mov w9, #0
    str w9, [sp, #52]
    adrp    x8, ___afunc_block_invoke@PAGE
    add x8, x8, ___afunc_block_invoke@PAGEOFF
    str x8, [sp, #56]
    adrp    x8, ___block_descriptor_tmp@PAGE
    add x8, x8, ___block_descriptor_tmp@PAGEOFF
    str x8, [sp, #64]
    ldur    x8, [x29, #-8]
    str x0, [sp, #32]           ; 8-byte Folded Spill
    mov  x0, x8
    str x30, [sp, #24]          ; 8-byte Folded Spill
    bl  _objc_retain
    str x0, [sp, #72]
    .loc    1 36 11                 ; /Users/Wei/File/program/Block/Block/main.m:36:11
    ldr x0, [sp, #32]           ; 8-byte Folded Reload
    bl  _objc_retainBlock
    stur    x0, [x29, #-16]
    .loc    1 44 12 is_stmt 1       ; /Users/Wei/File/program/Block/Block/main.m:44:12
    ldur    x0, [x29, #-16]
    bl  _objc_retainBlock
    sub x8, x29, #16            ; =16
    mov x30, #0
    .loc    1 45 1                  ; /Users/Wei/File/program/Block/Block/main.m:45:1
    str x0, [sp, #16]           ; 8-byte Folded Spill
    mov  x0, x8
    mov  x1, x30
    str x30, [sp, #8]           ; 8-byte Folded Spill
    bl  _objc_storeStrong
    ldr x0, [sp, #24]           ; 8-byte Folded Reload
    ldr x1, [sp, #8]            ; 8-byte Folded Reload
    bl  _objc_storeStrong
    sub x0, x29, #8             ; =8
    ldr x1, [sp, #8]            ; 8-byte Folded Reload
    bl  _objc_storeStrong
    ldr x0, [sp, #16]           ; 8-byte Folded Reload
    ldp x29, x30, [sp, #96]     ; 8-byte Folded Reload
    add sp, sp, #112            ; =112
    b   _objc_autoreleaseReturnValue
Ltmp1:
Lfunc_end0:
    .cfi_endproc
                                        ; -- End function
    .p2align    2               ; -- Begin function __afunc_block_invoke
___afunc_block_invoke:                  ; @__afunc_block_invoke
Lfunc_begin1:
    .loc    1 36 0                  ; /Users/Wei/File/program/Block/Block/main.m:36:0
    .cfi_startproc
; BB#0:
    sub sp, sp, #48             ; =48
    stp x29, x30, [sp, #32]     ; 8-byte Folded Spill
    add x29, sp, #32            ; =32
Lcfi3:
    .cfi_def_cfa w29, 16
Lcfi4:
    .cfi_offset w30, -8
Lcfi5:
    .cfi_offset w29, -16
    stur    x0, [x29, #-8]//sp+24的位置
Ltmp2:
    .loc    1 36 28 prologue_end    ; /Users/Wei/File/program/Block/Block/main.m:36:28
    mov  x8, x0
    str x8, [sp, #16]
Ltmp3:
    .loc    1 37 20                 ; /Users/Wei/File/program/Block/Block/main.m:37:20
    ldr x8, [x0, #32] //x0是block首地址，x0+32是捕獲的第一個變量位置，就是NSString
    mov  x0, x8
    bl  _objc_retain
    mov x8, #0
    add x30, sp, #8             ; =8
    str x0, [sp, #8]  //將其存在了棧上sp+8的位置，就是b變量
Ltmp4:
    .loc    1 38 5                  ; /Users/Wei/File/program/Block/Block/main.m:38:5
    mov  x0, x30
    mov  x1, x8
    bl  _objc_storeStrong
    ldp x29, x30, [sp, #32]     ; 8-byte Folded Reload
    add sp, sp, #48             ; =48
    ret
Ltmp5:
Lfunc_end1:
    .cfi_endproc
                                        ; -- End function
    .p2align    2               ; -- Begin function __copy_helper_block_
___copy_helper_block_:                  ; @__copy_helper_block_
Lfunc_begin2:
    .loc    1 38 0                  ; /Users/Wei/File/program/Block/Block/main.m:38:0
    .cfi_startproc
; BB#0:
    sub sp, sp, #48             ; =48
    stp x29, x30, [sp, #32]     ; 8-byte Folded Spill
    add x29, sp, #32            ; =32
Lcfi6:
    .cfi_def_cfa w29, 16
Lcfi7:
    .cfi_offset w30, -8
Lcfi8:
    .cfi_offset w29, -16
    mov x8, #0
    stur    x0, [x29, #-8] //目標地址
    str x1, [sp, #16]  //block
Ltmp6:
    .loc    1 36 27 prologue_end    ; /Users/Wei/File/program/Block/Block/main.m:36:27
    ldr x0, [sp, #16]//block
    ldur    x1, [x29, #-8]//目標地址
    mov  x9, x1
    add x9, x9, #32    //目標地址         ; =32
    ldr x0, [x0, #32]  //對象a
    str x8, [x1, #32]
    str x0, [sp, #8]            ; 8-byte Folded Spill
    mov  x0, x9
    ldr x1, [sp, #8] //對象a           ; 8-byte Folded Reload
    bl  _objc_storeStrong
    ldp x29, x30, [sp, #32]     ; 8-byte Folded Reload
    add sp, sp, #48             ; =48
    ret
Ltmp7:
Lfunc_end2:
    .cfi_endproc
                                        ; -- End function
    .p2align    2               ; -- Begin function __destroy_helper_block_
___destroy_helper_block_:               ; @__destroy_helper_block_
Lfunc_begin3:
    .loc    1 36 0                  ; /Users/Wei/File/program/Block/Block/main.m:36:0
    .cfi_startproc
; BB#0:
    sub sp, sp, #32             ; =32
    stp x29, x30, [sp, #16]     ; 8-byte Folded Spill
    add x29, sp, #16            ; =16
Lcfi9:
    .cfi_def_cfa w29, 16
Lcfi10:
    .cfi_offset w30, -8
Lcfi11:
    .cfi_offset w29, -16
    mov x8, #0
    str x0, [sp, #8]
Ltmp8:
    .loc    1 36 27 prologue_end    ; /Users/Wei/File/program/Block/Block/main.m:36:27
    ldr x0, [sp, #8]
    add x0, x0, #32             ; =32
    mov  x1, x8
    bl  _objc_storeStrong
    ldp x29, x30, [sp, #16]     ; 8-byte Folded Reload
    add sp, sp, #32             ; =32
    ret
Ltmp9:
Lfunc_end3:
    .cfi_endproc
                                        ; -- End function
    .globl  _main                   ; -- Begin function main
    .p2align    2
_main:                                  ; @main
Lfunc_begin4:
    .loc    1 47 0                  ; /Users/Wei/File/program/Block/Block/main.m:47:0
    .cfi_startproc
; BB#0:
    sub sp, sp, #64             ; =64
    stp x29, x30, [sp, #48]     ; 8-byte Folded Spill
    add x29, sp, #48            ; =48
Lcfi12:
    .cfi_def_cfa w29, 16
Lcfi13:
    .cfi_offset w30, -8
Lcfi14:
    .cfi_offset w29, -16
    stur    wzr, [x29, #-4]
    stur    w0, [x29, #-8]
    stur    x1, [x29, #-16]
Ltmp10:
    .loc    1 50 16 prologue_end    ; /Users/Wei/File/program/Block/Block/main.m:50:16
    bl  _afunc
    .loc    1 50 12 is_stmt 0       ; /Users/Wei/File/program/Block/Block/main.m:50:12
    ; InlineAsm Start
    mov  x29, x29   ; marker for objc_retainAutoreleaseReturnValue
    ; InlineAsm End
    bl  _objc_retainAutoreleasedReturnValue
    str x0, [sp, #24]
    .loc    1 51 5 is_stmt 1        ; /Users/Wei/File/program/Block/Block/main.m:51:5
    ldr x0, [sp, #24]
    mov  x1, x0
    ldr x0, [x0, #16]
    str x0, [sp, #16]           ; 8-byte Folded Spill
    mov  x0, x1
    ldr x1, [sp, #16]           ; 8-byte Folded Reload
    blr x1
    mov x0, #0
    add x1, sp, #24             ; =24
    .loc    1 62 5                  ; /Users/Wei/File/program/Block/Block/main.m:62:5
    stur    wzr, [x29, #-4]
    .loc    1 63 1                  ; /Users/Wei/File/program/Block/Block/main.m:63:1
    str x0, [sp, #8]            ; 8-byte Folded Spill
    mov  x0, x1
    ldr x1, [sp, #8]            ; 8-byte Folded Reload
    bl  _objc_storeStrong
    ldur    w0, [x29, #-4]
    ldp x29, x30, [sp, #48]     ; 8-byte Folded Reload
    add sp, sp, #64             ; =64
    ret
Ltmp11:
Lfunc_end4:
    .cfi_endproc

我們需要從上層函數入手，只有了解了傳入的參數具體分析，才比較容易了解代碼功能，不然就頭疼了，這里就是先分析main函數。

main:

1. bl _afunc，沒有參數直接跳轉，從源碼可知返回了一個block對象在x0中，bl _objc_retainAutoreleasedReturnValue表明其被autoreleasepool管理。
2. 接下將x0存在了sp+24這里，再下一句沒有啥意義。
3. 將x0賦值給x1，挪出空間，加載x0+16的值到x0，找到最開始struct __block_impl的內存布局，發(fā)現這個地址存放的是回調函數的指針。
4. 接下來通過[sp, #16]中轉，將x1和x0內容互換，至此x0是block首地址，x1是回調函數地址；blr x1跳轉到x1；2，3，4步加一起就是源碼里面的aBlock()。
5. 最后那段就是在release之前的block對象。

_afunc:

最前面棧增長了112個byte，這里局部變量較多所以，棧分配的較大。

1. 直接看Ltmp0:，前面一個_objc_retain是引用了字符串"demo"

. stur x0, [x29, #-8]，將x0("demo")存在了x29-8這個位置，也就是sp+88的位置。

2. 然后x0=sp+40，x30=sp+72

3. 接下來兩句加載"__NSConcreteStackBlock"符號對應的地址，然后將其存在sp+40這個地址，而x0目前是指向這個地址的。

   struct __block_impl {
     void *isa; //8byte，isa指針，很重要的標志，意味著block很可能是個OC的類
     int Flags;//4byte，包含的引用個數
     int Reserved;//4byte
     void *FuncPtr;//8byte，回調函數指針
   };
   
   struct __main_block_impl_0 {
     struct __block_impl impl;
     struct __main_block_desc_0* Desc;//8byte，block的描述
     //如果有捕獲外部變量的話會定義在這里
     id a;
   };
   

   這里貼一個內存布局，sp+40就是__main_block_impl_0首地址，也是isa地址，這里就是“StackBlock”類似符號。

4. 接下來就簡單了，依次存儲了Flags（sp+48），Reserved(sp+52)各4個byte。

5. 存儲FuncPtr指針，就是匯編符號___afunc_block_invoke對應的地址，sp+56的8個byte。arm64指針占8個byte。

6. 存儲Desc，這也是個指針，存儲的是___block_descriptor_tmp對應的地址，其記錄了___copy_helper_block，___destory_helper_block和method signature，block size等信息，對應sp+64的8個byte。

7. 接下來加載x29-8的內容到x8就是"demo"字符串。然后將x0暫存在sp+32，同時將x0=x8，然后存儲x30到sp+24

8. 調用_objc_retain，參數x0，所以結果是retain了“demo”一次。之后將x0存儲在了sp+72這里，就是struct __main_block_impl_0 中的id a，id a是我隨意寫的，但實際定義也應該差不多的。需要注意的是，這里的調用是因為創(chuàng)建了一個StackBlock，其也是要使用"demo"這個數據的，所以retain了一次。但MallocBlock的引用計數則由___copy_helper_block來管理。）

9. 然后將sp+32的內容加載到x0，也就是sp+40即__main_block_impl_0的首地址。

10. 調用_objc_retainBlock，去蘋果源碼中找一下：

id objc_retainBlock(id x) {
    return (id)_Block_copy(x);
}

其調用了_Block_copy，這個函數在Block.h中聲明的，我沒有找到相關的實現源碼，不過可以證明的是對于block來說retain和copy效果一致。

11. 再次調用了_objc_retainBlock

    這里的兩次調用一次是賦值給blockA，一次是return blockA造成的。

12. 后面有三個_objc_storeStrong，x1=0，都是在做release操作，具體過程比較繁瑣，我就直接給結論了，其中第一個release一次blockA，第二release一次“demo”字符串(提示：sp+24存的是x30，x30=sp+40+32，這里存的是“demo”)，第三個也是release一次"demo"(sub x0, x29, #8，提示一下，x29=sp+112-96，所以這句也是x0=sp+24)

    通過這里的分析，對于Block捕獲對象，ARC怎么作用的，相應的數據結構：block retain會被copy，捕獲OC類型參數的時候會retain參數，參數的傳遞方式——拷貝。

___afunc_block_invoke:

1. ldr x8, [x0, #32]，x0是block的首地址，x0+32就是變量a的地址，mov x0,x8，bl _objc_retain，retain了a這個對象，和源碼功能一致。
2. 后面就是在release這個對象，源碼里面也確實沒有別的操作了。

___copy_helper_block:

這個這里找不到調用方，所以傳遞的參數就無法知道。先嘗試分析一下：看它使用了x0,x1倆寄存器，應該有倆參數。所以順序分析可能就不太好使了，但我們發(fā)現這里就只調用了_objc_storeStrong，這個函數就比較熟悉了，第一個參數是id *，第二個參數是id，那我們就倒著分析。x0=x9，x9=x9+32，x9=x1，x1=(x29-8)=x0，所以x0=x0+32，再看x1=(sp+8)=x0=[x0+32]=(sp+16)=x1，所以x1=[x1+32]（其中小括號是內存暫存，方括號是加載該內存地址的數據）。見到“+32”偏移量就熟悉了，這就是之前a的地址，整個函數的功能就是retain并且store一下block中捕獲的變量a，如果有多個引用將會有多次這種操作，但不適用于基本數據類型。

理論分析確實很麻煩，但這里提供另外一種辦法就是運行下斷點breakpoint set -n __copy_helper_block_，打印x0，x1

可以看到在_Block_copy中調用這個函數，打印一下

(lldb) po $x0
<__NSStackBlock__: 0x1c0250680>

(lldb) po $x1
<__NSStackBlock__: 0x16afeb8f8>

這里也可以通過直接瀏覽的方式

view_reg.png

在_Block_copy調用時其還是在棧block，不同的是雖然x0（目標地址）的isa還是指向StackBlock，但實際內容已經是MallocBlock，比如x0已經產生引用計數了。（我研究了一下_Block_copy匯編代碼，其會malloc一段新的內存，將數據填充過去，同時修改Flags的值，Reserved字段全被賦值為了0，x0是新地址，x1是舊地址，然后跳轉__copy_helper_block_，做OC參數的retain操作）

___destroy_helper_block:

這個調用_objc_storeStrong，x1=x8=0，很明顯是在做release。

總結一下：

1. 每一個block背后都有一個struct做數據支撐，與一般的對象的結構組織和行為模式基本一致。一般的對象是一份數據結構可以對應多個方法，而block卻是一個方法對應多個數據，導致其占用資源較多。
2. Block的OC類型參數捕獲時，如果只是棧Block，則直接插入retain和release解決對象引用的問題。如果Block對象被拷貝到堆上，則需要通過調用_Block_copy通過對應的的___copy_helper_block和___destroy_helper_block函數來支撐捕獲對象的生命周期管理。
3. __main_block_desc_0還會同時保存的方法簽名（這里是v8@?0）,還有block的大小，捕獲參數個數會造成這個大小的改變。

最后說一下Block零碎的東西

1. 在Block_private.h文件中發(fā)現，除了我們熟知的三種block意外還有三種運行時的block

   BLOCK_EXPORT void * _NSConcreteAutoBlock[32]
       __OSX_AVAILABLE_STARTING(__MAC_10_6, __IPHONE_3_2);
   BLOCK_EXPORT void * _NSConcreteFinalizingBlock[32]
       __OSX_AVAILABLE_STARTING(__MAC_10_6, __IPHONE_3_2);
   BLOCK_EXPORT void * _NSConcreteWeakBlockVariable[32]
       __OSX_AVAILABLE_STARTING(__MAC_10_6, __IPHONE_3_2);
   

   目前還不知道具體用途。

2. BLOCK_EXPORT size_t Block_size(void *aBlock);
   
   BLOCK_EXPORT const char * _Block_signature(void *aBlock)
       __OSX_AVAILABLE_STARTING(__MAC_10_7, __IPHONE_4_3);
       
   BLOCK_EXPORT const char * _Block_layout(void *aBlock)
       __OSX_AVAILABLE_STARTING(__MAC_10_7, __IPHONE_4_3);
   

   這三個函數我比較感興趣，但卻是在Block_private.h中，但不礙事，知道名字了，就好辦了。

   我們知道.h頭文件的一個重要作用就是編譯指示，啥意思呢？簡單來說就是告訴編譯器當前環(huán)境的其他編譯模塊有某些符號，到時候編譯器自己去尋找并鏈接。所以我們只需要在使用前做以下聲明就行

   extern const char *_Block_signature(id block);
   extern size_t Block_size(id block);
   extern const char* _Block_layout(id ablock);
   

   我調用了一下，發(fā)現_Block_layout輸出是個null，不清楚有啥作用。

   Block_size調用結果是40，因為捕獲了一個NSString*（8byte）+ Block基礎的32byte，正好。

   _Block_signature輸出 v20@?0@"NSString"8i16，我的Block原型是typedef void (^ABlock)(NSString *s, int i);

   其中v是void，20是總共需要內存大小，@?是Block的encode，0是第一個默認參數block結構體從偏移量0開始，@"NSString"8，則指NSString從偏移量8開始，最后是i從偏移量16開始占4位。

   有了這么詳細的簽名，動態(tài)調用或者動態(tài)替換實現就方便了，也許用它還能搞一波事情。

為什么要花這么多時間去分析匯編，了解的那么詳細。其實一般的情況下是用不上的，但是如果遇到了線上crash，棘手的內存問題，要debug，這時候這些知識就會很有用了，你了解的越多，你解決問題的方式就越多，就更容易解決問題。當然也不是說什么都需要去仔細了解，也不是了解的越多越好，這個就需要根據自己的興趣和需求去決定了。但是對于基礎知識，確實可以多時間和精力去完善之，有了這些才能高屋建瓴得心應手。

感謝閱讀。