很多iOS開發(fā)者在剛接觸block時都遇到過一個問題在block里明明可以讀外部的局部變量但一賦值就報錯提示Variable is not assignable (missing __block type specifier)。報錯信息已經告訴你解法了——加上__block修飾符但那時候大部分人只是機械地加上并不知道這背后發(fā)生了什么。我在早期也是這樣直到后來因為一個block的循環(huán)引用問題排查了兩天才痛下決心把__block變量的內存布局研究明白。這篇文章就把這些底層的知識整理出來。它不是一個API使用手冊而是一份從編譯器視角、從內存布局視角重新看待__block變量的指南。讀完你可以清楚地回答__block變量到底存在哪里為什么加上__block就能改值block從?？截惖蕉训臅r候__block變量經歷了什么以及ARC下__block變量的循環(huán)引用問題到底怎么回事。這篇文章適合所有正在使用Objective-C的開發(fā)者尤其是對block的理解還停留在會寫、會用層面、遇到內存問題卻說不出原因的人。讀完我相信你會對block和__block有完全不同的認識。1. 從block里為什么改不了外部變量說起——捕獲機制的真相1.1 block捕獲普通局部變量時做了什么先回到最基礎的問題為什么不加__block就改不了外部局部變量很多人只知道結論但不清楚根因。我用一個最簡單的例子說明int a 10; void (^block)(void) ^{ // 這里可以讀a但不能寫a NSLog(%d, a); }; block();在C語言層面block本質上是一個結構體編譯器會把這個block改寫成一個類似這樣的結構struct __block_impl { void *isa; int flags; int reserved; void *FuncPtr; }; struct __main_block_impl_0 { struct __block_impl impl; struct __main_block_desc_0 *Desc; int a; // 捕獲進來的變量注意是值拷貝 };也就是說當block捕獲一個普通局部變量a時它不是去持有a的引用而是把這個變量的值復制了一份作為block結構體的一個成員變量。你可以理解為block只是給這個值拍了一張照片照片放在block自己的結構體里。之后你在block內部讀取a讀的其實是block結構體里的那個成員不是外部棧上那個a。所以在block內部給a賦值就相當于嘗試修改block結構體里那個被拷貝的成員而這個成員在編譯時是作為const拷貝進來的編譯器直接就不允許你這樣做。1.2 不同變量的捕獲規(guī)則差異這個捕獲規(guī)則不是對所有變量都一樣的這點很多人容易混淆。我整理一下變量類型block內部能否修改捕獲方式普通局部變量否值拷貝block持有副本static局部變量是指針拷貝block持有變量地址全局變量是直接訪問不需要捕獲__block局部變量是通過特殊結構體間接訪問static局部變量之所以可以修改是因為編譯器改成傳遞這個變量的指針地址block內部通過指針去操作原始變量。全局變量更簡單全局區(qū)地址固定block內部直接按符號訪問。那__block呢它走的是另一條完全不同的路——編譯器不是把a的值拷貝進block結構體而是創(chuàng)建一個額外的結構體對象來包裝這個變量然后再把結構體指針傳給block。這條路就是本文的核心。2. 編譯器眼里的__block變量__Block_byref結構體逐字段拆解2.1 用clang -rewrite-objc偷看底層想真正搞清楚__block的內存布局最直觀的方式是讓編譯器把Objective-C代碼改寫為C代碼看看它到底生成了什么。先準備這樣一段代碼int main() { __block int a 10; void (^block)(void) ^{ a 20; NSLog(%d, a); }; block(); return 0; }然后在終端執(zhí)行clang -rewrite-objc main.m會生成一個main.cpp文件。核心內容在這里我做了一些精簡和整理// 這是編譯器為 __block int a 生成的結構體 struct __Block_byref_a_0 { void *__isa; __Block_byref_a_0 *__forwarding; int __flags; int __size; int a; // 原始變量 }; // block的結構體 struct __main_block_impl_0 { struct __block_impl impl; struct __main_block_desc_0 *Desc; __Block_byref_a_0 *a; // 指向上面結構體的指針 };看到這張結構圖很多事情就清楚了帶__block的變量a并沒有被直接拷進block而是生成一個__Block_byref_a_0結構體block結構體里只是保存了這個結構體的指針。2.2 四個字段各司其職__Block_byref_a_0結構體里每個字段都有自己的職責我逐個拆開講__isa這個字段在Objective-C對象里本來是指向類對象的指針在__block變量結構體里它通常為0或者指向NULL。這個字段的存在是為了讓結構體在布局上和Objective-C對象兼容但實際使用中我們不依賴它。__forwarding這個是最關鍵的字段指向真正存儲變量的結構體。為什么需要一個額外的跳轉后面我專門用一節(jié)來講這里先記住它是用來解決block從?？截惖蕉阎笞兞繗w屬問題的。__flags標志位用來標記這個變量有沒有被拷貝到堆上以及變量是不是對象類型等信息。具體位含義在不同平臺略有差異一般情況下我們不需要手動操作它。__size結構體大小。這個字段非常重要因為block在拷貝或釋放時需要知道__Block_byref結構體到底占多少字節(jié)才能正確執(zhí)行內存操作。a這才是真正的原始變量。我們的__block int a在內存里的本體就是結構體里的這個字段。block在訪問a的時候不是直接訪問而是會走一段類似這樣的代碼// block內部對a的賦值會被改寫成 (a-__forwarding-a) 20;也就是說通過block持有的__Block_byref_a_0 *a指針先找到__forwarding再通過__forwarding找到真正的變量。前面提到的拍照比喻在這里不適用了更準確的理解是block拿著一個地址通過這個地址去訪問一個間接層再通過間接層里記錄的指針找到真正的變量的位置。2.3 descriptor里的拷貝與銷毀函數如果你繼續(xù)往下看重寫生成的代碼還會發(fā)現(xiàn)一個__main_block_desc_0結構體里面除了常規(guī)的reserved和size字段之外多了兩個函數指針struct __main_block_desc_0 { size_t reserved; size_t Block_size; void (*copy)(struct __main_block_impl_0 *, struct __main_block_impl_0 *); void (*dispose)(struct __main_block_impl_0 *); };這兩個函數指針是干什么的當一個block從棧上被拷貝到堆上時copy函數會被調用它的職責是如果block捕獲了__block變量、對象變量或其他需要特殊內存管理的變量就要把這些變量也做相應的拷貝或引用計數調整。dispose函數則在block從堆上釋放時被調用負責釋放相關資源。這里要特別說明如果__block變量只是一個int、float這樣的普通數據類型copy和dispose函數可能是個空的實現(xiàn)或者非常簡單的邏輯但如果__block變量持有了Objective-C對象那么copy函數就要負責把對象正確retaindispose函數負責release。所以不要小看這兩個函數指針它們是ARC內存管理在block生命周期里的關鍵入口。3. __forwarding指針棧與堆之間的導航員3.1 為什么要拐一道彎__forwarding的設計在整個__block內存布局里是最精妙的地方也最不容易理解。我當年第一次看到這個字段時也是一頭霧水搞不懂為什么明明直接持有一個變量還要搞一個中間指針繞來繞去。答案在于block和__block變量最初都誕生在棧上它們的生命周期本來只屬于當前函數作用域。但是block經常需要被存儲到堆上或者被傳遞到其他地方使用比如作為一個屬性被持有、被異步操作引用。這時候block會被從?？截惖蕉选栴}是__block變量該怎么辦如果__block變量留在棧上而block去了堆上那么block訪問__block變量時就可能訪問到已經被銷毀的?？臻g。如果直接把__block變量也一并拷貝到堆上那么原來代碼里訪問棧上的a的地方和block里訪問堆上的a的地方就變成了兩個不同的變量——這顯然不符合__block的語義因為__block存在的意義就是讓block內外共享同一個變量。__forwarding就是把這個矛盾解決掉的機制。3.2 從棧拷貝到堆時發(fā)生了什么我畫一個完整的過程描述幫助你建立畫面感。第一步代碼運行在棧上創(chuàng)建__Block_byref_a_0結構體棧上的結構體的__forwarding指向自己。此時block也在棧上block結構體里保存指向這個結構體的指針。第二步block被拷貝到堆上?？截惖挠|發(fā)時機可能是手動執(zhí)行[block copy]在ARC下把block賦值給一個strong屬性或變量block作為參數傳入某些會copy它的APIblock被放入NSArray、NSDictionary等容器拷貝發(fā)生時copy函數不僅會把block結構體本身從棧復制到堆也會把__Block_byref_a_0結構體從棧復制到堆。關鍵來了在拷貝完成后棧上的__Block_byref_a_0的__forwarding指針會被更新指向堆上的那個新拷貝的結構體。也就是說整個流程下來棧上的結構體變成了一個代理它的__forwarding指向堆上的真實結構體。而堆上的結構體的__forwarding指向自己。之后不管是從block內部訪問還是從外部原始代碼位置訪問表達式最終都通過__forwarding-a來定位變量所以訪問到的都是堆上那一份這就保證了共享語義。我用一個代碼片段來模擬這個過程的核心變化__block int a 0; // 棧上結構體 S 創(chuàng)建S-__forwarding S void (^block)(void) ^{ a; // 實際是 (a-__forwarding-a) }; // 這里block被拷貝假設拷貝到堆上的結構體為 H // 拷貝完成后S-__forwarding HH-__forwarding H // 此時從任何路徑訪問 a都會訪問到 H-a如果沒有__forwarding這層跳轉當block被拷貝到堆上時你很難保證外部引用和block內部引用指向同一個變量。棧上的結構體不能動了因為其他代碼可能還在用它的地址直接改block里的指針也只能影響block自己的訪問路徑。__forwarding的存在讓所有路徑都歸一化到通過__forwarding找到真正存儲位置這個統(tǒng)一的訪問方式上問題就迎刃而解了。3.3 沒有__forwarding會怎樣這里做一個假設推演如果沒有__forwardingblock被拷貝到堆上后堆上的block和棧上的__block變量結構體就會脫節(jié)。如果函數返回棧上結構體被銷毀堆上的block訪問到一個懸空的指針輕則值錯亂重則崩潰。即便你非常小心地保證在函數返回前一定使用完block但block一旦被拷貝到堆上就脫離了函數的生命周期控制你根本沒法保證它什么時候會被執(zhí)行。所以__forwarding不是可選的優(yōu)化而是保證block和__block內存安全的基本機制。4. 堆上的內存布局與生命周期驗證4.1 用代碼實測各階段變量地址理論講再多不如跑一段代碼來驗證。我寫了一個小例子在不同階段打印變量的地址你可以直接跑一下親眼看內存地址怎么變。#import Foundation/Foundation.h void testBlockVariableAddress() { __block int a 0; int *stackA a; NSLog(1. block執(zhí)行前a的地址: %p, stackA); void (^block)(void) ^{ int *innerA a; NSLog(2. block內部a的地址: %p, innerA); a; NSLog(3. 修改后的a值: %d, a); }; block(); // 此時block還在棧上block內部地址和外部應該一致 void (^heapBlock)(void) [block copy]; // 拷貝到堆上 NSLog(4. 拷貝后外部a的地址: %p, a); heapBlock(); }從實際執(zhí)行結果來看前三個日志打印的地址通常是一致的或者至少通過__forwarding訪問到的都是同一個結構體。第4步打印的地址在block從前沒有被使用過、現(xiàn)在被拷貝到堆上的場景里外部a訪問到的是棧結構體但棧結構體的__forwarding指向堆上的結構體所以值仍然是共享的。如果你在block內部打印a經過__forwarding跳轉后它指向的就是堆上結構體里的變量地址。這個地址的變化過程其實就證明了前面說的__forwarding跳轉機制。4.2 block copy前后內存布局對比我用一張文字化的表格來展示copy前后內存布局的變化階段棧上堆上訪問結果copy前存在block結構體和__Block_byref結構體__forwarding指向自身無訪問棧上結構體變量copy后block結構體可能還在__Block_byref結構體的__forwarding指向堆上存在block結構體和__Block_byref結構體__forwarding指向自身訪問堆上結構體變量棧結構體銷毀后已不存在仍存在通過棧上殘留指針或block內部指針經__forwarding訪問堆上變量這里有一個非常重要的點block被拷貝到堆上時它捕獲的對象類型變量和__block變量的所有權處理是不完全一樣的。普通對象變量被捕獲時如果block被拷貝對象會被retain而__block變量結構體被拷貝時取決于結構體內部變量的類型如果是對象也會被retain如果是普通類型則只是值拷貝。4.3 __block變量的釋放時機__block變量結構體跟隨block的生命周期。block在堆上時__block變量結構體也在堆上block被釋放時相關聯(lián)的__block變量結構體也會被釋放。也就是說__block變量的生命周期從跟隨棧幀變成了跟隨block。這是理解循環(huán)引用的基礎。如果多個block同時捕獲同一個__block變量每個block拷貝時都會重新拷貝一份__Block_byref結構體嗎答案是否定的。系統(tǒng)會盡量復用已經存在的堆上結構體通過引用計數來管理。這一點在多個block共享同一個__block變量的場景里特別重要不要假設每個block都有自己獨立的__Block_byref結構體。5. 內存管理中的連環(huán)坑與規(guī)避方案5.1 ARC下__block對象變量的循環(huán)引用問題這是很多開發(fā)者會踩的坑也是最容易搞混的地方。在ARC下__block修飾一個對象類型變量時當block從棧拷貝到堆__Block_byref結構體里的對象指針會被強引用。也就是說只要堆上的block還存在這個對象就不會被釋放?？紤]這樣一個場景typedef void (^MyBlock)(void); implementation MyObject - (void)setupBlock { __block MyObject *weakSelf self; // 注意這里用__block而不是__weak MyBlock block ^{ NSLog(%, weakSelf); }; // 如果block被長期持有 self.block block; }這里的問題是self持有blockblock持有的__Block_byref結構體里強引用了weakSelf而weakSelf指向的就是self本身。這形成了一個完整的循環(huán)引用鏈導致self無法被釋放。很多人在這個場景里誤以為__block就是用來打破循環(huán)引用的這其實是把__block和__weak搞混了。正確的做法是__weak MyObject *weakSelf self; // 真正的打破循環(huán)引用的方式 MyBlock block ^{ NSLog(%, weakSelf); }; self.block block;__weak不會retain對象block持有的只是對象的弱引用不參與引用計數循環(huán)引用自然就斷開了。5.2 __block與__weak/__strong的真實關系我還見過一些人把__block和__weak、__strong放在一起比較問哪個更好。這其實是兩個完全不同維度的修飾符。__block是存儲類型修飾符核心作用是改變變量被block捕獲時的存儲方式讓變量可以在block內部被修改。__weak和__strong是所有權修飾符核心作用是控制對象的引用計數。一個變量可以同時使用__block和__weak嗎可以。比如__block __weak MyObject *obj self;這種情況下obj這個變量本身存儲在__Block_byref結構體里但結構體里對obj的引用是弱引用不會影響對象的釋放。實際開發(fā)中這種寫法偶爾會出現(xiàn)在需要在block內把弱引用重新賦值給某個臨時變量、又希望在block執(zhí)行期間對對象的生命周期做精細控制的場景。不過大多數情況下__weak block內部轉成__strong的寫法已經足夠了。5.3 嵌套block中的__block變量傳遞嵌套block是另一個容易出問題的地方。當一個__block變量被外層block捕獲然后外層block內部又創(chuàng)建了一個新的內層block內層block也捕獲了這個變量這時候內存布局會怎么變化我遇到過這種場景外層block被拷貝到堆上然后內層block也可能被拷貝。如果內層block又被單獨拷貝了一份__Block_byref結構體那整個共享關系是不是就被破壞了答案是不會。因為__forwarding機制保證了所有路徑最終都指向堆上的同一個結構體。內層block捕獲的不再是棧上那個__Block_byref結構體的地址而是通過外層block訪問到的堆上結構體的地址。所以只要理解了__forwarding是全局唯一的訪問入口嵌套block的問題就迎刃而解了。不過嵌套block場景下還有一個需要注意的點如果你在block內部對__block變量做修改而這個block在異步執(zhí)行另外一段代碼也在同時修改同一個變量就會產生數據競爭。__block不提供任何線程安全機制它只是一個存儲和共享的解決方案。多線程環(huán)境下使用__block變量需要自己加鎖或者使用原子操作否則會有數據競爭和未定義行為。5.4 block被多次copy時的行為還有一個容易忽略的行為對同一個block多次執(zhí)行copy操作并不會每次都重新生成一份新的__Block_byref結構體。系統(tǒng)內部會通過引用計數來管理堆上的block結構多次copy只是增加引用計數不會導致__block變量結構體被復制多份。這解決了一個潛在的性能問題也避免了一個邏輯問題如果每次copy都復制一份__Block_byref結構體那么不同block copy之間就變成了不同的變量徹底違背了__block的共享語義。6. 實戰(zhàn)經驗總結與調試技巧6.1 用lldb查看__block變量真實地址在Xcode里斷點調試時直接在lldb里打印a有時候看到的是__Block_byref結構體的地址你會覺得它和外面代碼打印的a不一樣這是因為編譯器在斷點環(huán)境下可能會對訪問做了一些優(yōu)化或者重寫。需要留意的是你在lldb里看到的是一個中間結構體的地址真正的業(yè)務變量是通過__forwarding跳轉之后才能訪問到的對象。如果要在lldb里手動查看__block變量的底層結構可以這樣做(lldb) frame variable -L這個命令會輸出當前棧幀里所有變量的內存地址包括編譯器的重寫情況。如果你的代碼里有__block int a你可能會看到類似這樣的輸出0x00007ffeefbff958: (__block int) a 20地址前綴是0x7ffe開頭的就是棧地址0x6000開頭的是堆地址。當你看到a的地址從棧變成堆就說明block被拷貝了__block結構體也跟著去了堆上。6.2 從崩潰日志里識別__block野指針如果你在處理block相關的崩潰時崩潰棧里出現(xiàn)__Block_byref相關的符號或者EXC_BAD_ACCESS時地址指向一個棧地址就要高度懷疑是不是block被釋放了但還有地方在訪問。一個常見場景是這樣的block被某個對象持有但持有對象已經被釋放了block本身也已經被釋放了然后某個定時器或者異步回調還在調用這個block的指針。這時候如果block里捕獲了__block變量訪問__forwarding-a就會讀到已經被回收的內存產生野指針。排查這類問題的時候建議優(yōu)先檢查block被持有的鏈條block被誰持有持有的對象生命周期是不是覆蓋到了block的調用時機block捕獲的__block變量是否被多個對象共享如果共享釋放順序是什么樣的把這三條鏈路理清楚了block相關崩潰的排查就完成了一大半。6.3 從工程角度如何優(yōu)雅使用__block雖然__block機制很強大但我的實際經驗是盡量少用。__block在大多數場景里的真實需求是在block內部修改外部變量但這種需求往往可以通過設計來規(guī)避。比如把需要修改的狀態(tài)封裝成一個可變對象block內部只修改對象的屬性就不再需要__block修飾屬性本身了。又比如用局部變量在block前面處理完邏輯再把結果傳遞給block需要用的參數。這樣做的優(yōu)點是后續(xù)的內存管理邏輯更簡單可讀性更高。當然在需要真正共享狀態(tài)的場景下__block是繞不開的。比如一個網絡請求返回的數據需要在多次回調里累加到同一個變量里比如一個計數器需要被多個block共享用__block就是最自然的寫法。這時候只要把生命周期和循環(huán)引用這兩個問題處理干凈用__block完全沒問題。6.4 我踩過的最后一個坑分享一個我自己犯過的錯誤。有一段時間我在寫一個音頻處理工具用__block來保存中間數據指針然后在一個異步block里訪問。當時想當然地認為block會被拷貝到堆上所以__block變量也會在堆上應該是安全的。結果忽略了block底層是存儲在一個局部變量里的在ARC下block從棧拷貝到堆的時機并不總是立即發(fā)生的。在某些場景下block仍然停留在棧上而棧上空間在函數返回后就失效了異步再去訪問就出現(xiàn)了玄學崩潰。從那以后我養(yǎng)成了一個習慣凡是block可能被異步調用的我一定顯式地調用一次copy或者通過強引用屬性讓ARC幫我們處理確保block和__block結構體都穩(wěn)定地在堆上。這些經驗分享出來是想提醒你__block不僅僅是加一個修飾符那么簡單它背后是一套完整的內存管理和共享機制。理解了它的設計原理再遇到block相關的內存問題會從容得多。