iOS之武功祕籍①：OC對象原理-上(alloc & init & new)

iOS之武功祕籍 文章彙總

寫在前面

春節的夜晚,十分的難以入睡,夢醒時分,翻開祕籍最新objc4-818.2源碼,有個小夥在漸漸的發着呆......

1、探索的線索和方向

拿到祕籍的那一刻,腦子就一直在高速的運轉着,要怎麼才能學好呢?

咱們想着手開始探索"武林絕學"(iOS的底層)，但又不知道從哪裏開始，怎麼辦呢？

那就從main函數入手！

咱們先開啓上帝視角！來觀察一個粗略的加載流程.進行準備工做：

• 在main函數中直接打斷點,而後咱們這時打印一下堆棧信息瞧瞧(bt - lldb 調試指令打印堆棧信息)

嗯哼,咱們都知道main函數是很是之早的,可是結果告訴咱們在main函數以前,系統還作了其餘的!!那麼在main函數以前還有什麼呢?來咱們來瞧瞧

• 添加三個符號斷點libSystem_initializer、libdispatch_init、_objc_init

咱們按上圖操做依次添加好libSystem_initializer、libdispatch_init、_objc_init符號斷點 而後咱們來運行一下程序看看:

此時會來到咱們下的第一個符號斷點libSystem_initializer,經過堆棧信息咱們會看到程序會來到很是著名的dyld,通過一系列流程後在來到libSystem_initailizer.這也就從dyld來到了libSystem庫.

接下來會來到咱們的第二個符號斷點libdispatch_init,也就來到了libdispatch庫了 而libdispatch是GCD的源碼,咱們後續在研究這個. 過掉這個斷點來到咱們下的第三個符號斷點_objc_init,也就來到了libobjc的底層,它是整個一個runtime的一些源碼.

過完以上三個斷點纔會來到咱們熟悉的main函數.

過掉main函數的斷點就會來到咱們熟悉的了

走完這些流程,可能有些小可愛會問?咦,你這咋有這麼詳細的堆棧信息呢?

只需關閉 Xcode 左側 Debug 區域最下面的第一個按鈕就行 show only stack frames with debug symbols and between libraries

到此咱們來總結一波. 經過以上的堆棧信息,咱們能夠總結一個簡單的加載流程:

• dyld啓動加載動態庫、共享內存、全局C++對象的構造函數的調用、一系列的初始化、dyld註冊回調函數
• libsystem 的初始化 libSystem_initializer
• libdispatch_init 隊列環境的準備
• 從_os_object_init 過渡到 _objc_init
• 以及_dyld_objc_notify_register 鏡像文件的映射
• 類-分類-屬性-協議-SEL-方法 的加載
• 展開分析 Runtime 各個部分的原理
• main函數的啓動

這裏面的分析角度和思惟都是比較有意思的,爲了讓你們有比較好的體驗感.接下來,咱們先從你們都比較熟悉的OC對象開始分析吧.

2、alloc原理初探 一 OC對象的alloc

咱們要研究對象，確定要從建立開始研究的！下面我有一個很是有意思的提問，小夥伴們不妨花個十秒鐘思考一下！來代碼以下:

%@ 打印對象 %p 打印地址 &p 指針地址

問題:

• 1.這裏p1對象是否建立完成
• 2.p一、p二、p3以及p4是否爲同一個對象

不知道你腦海中的答案是否和上面的打印一致:

• 從上面能夠得出咱們建立了四個臨時對象p一、p二、p三、p4
• p一、p二、p3這三個對象的指針是不一樣的可是他們所指向的內存是同一片,而p4對象的指針和他所指向的內存地址都和p一、p二、p3不一樣(爲何呢? - 看完本編你就知道爲何了)
  • 遺留問題:
  • ①.p一、p二、p3對象和地址打印都一致， 爲什麼&p打印不一致?
  • ②.p4的地址爲何和p一、p二、p3都不同?
• 從反向能夠證實alloc纔是建立對象-開闢內存
• init只是一個初始化構造函數.
• new又alloc出了另外一內存空間

嗯哼,alloc出來就已經把對象的內存地址肯定了,那麼是怎麼肯定的呢?下面開始探索

• 如今咱們跳進這個萬惡之源(經過Command+單擊->Jump to Defintion的方式進入)
• 發現跳不進去查看實現,怎麼辦，請來到 objc4官方源碼或objc4小編配好可運行的源碼,接下來幾天都會動不動就進去了！！我但願每個小夥伴都不要只在這外面蹭一蹭，深層交流纔有意義
• 沒有註釋
• 沒有源碼實現
• 更加不知道下一步流程

發現進不去了,怎麼辦？看不到具體的源碼實現！ 不少時候咱們常常也會遇到這樣的狀況，就是想作一些事，就是碰壁，無從下手！你們請注意這裏：我要開始裝逼咯！

3、alloc底層探索思路(底層探索分析的三種方法)

下面介紹三種方式來查看他的實現.

方法一:符號斷點直接定位

添加alloc符號斷點(在前面 探索的線索和方向 已經介紹了怎麼加符號斷點)

• 先將alloc符號斷點先置灰(alloc函數在不少地方被調用，在到達咱們目標位置前，先置灰)

• Xcode開啓運行,程序到達[TCJPerson alloc]斷點後，開啓alloc符號斷點

• 點擊 Xcode日誌欄的繼續運行按鈕

結果以下

• [NSObject alloc] 成功看到所在連接庫libobjc.A.dylib
• 其底層調用的就是 _objc_rootAlloc函數

方法二:代碼跟蹤 - control + step into

• ①關掉以前的相關符號斷點,來到研究對象斷點處

• ②按住鍵盤control鍵+鼠標點擊 Xcode日誌欄的step into按鈕

進去後能夠看到objc_alloc

• ③若是你是用真機的請繼續第二部的操做,後來到

• ④若是你是用模擬器的話,在第二部後須要添加objc_alloc符號斷點後,點擊 Xcode日誌欄的繼續運行按鈕

• ⑤無論你是真機仍是模擬器最終都來到了libobjc.A.dylib,進而也看到了底層objc_alloc

• ⑥和方法一不謀而合

方式三：彙編進入分析

• ①關閉其餘的符號斷點,來到研究對象斷點

• ②Xcode 工具欄 選擇 Debug --> Debug Workflow --> Always Show Disassembly,這個 選項表示 始終顯示反彙編 ，即 經過彙編 跟流程

• ③在彙編顯示16行處添加斷點到objc_alloc

• ④若是你是用真機操做,按住control鍵和step into鍵結果以下: 以後繼續按住control鍵和step into鍵獲得:

• ⑤若是你是用模擬器的話,在第三步添加符號斷點後,按住control鍵和step into鍵結果如:以後須要添加objc_alloc符號斷點後,點擊 Xcode日誌欄的繼續運行按鈕

• 嗯哼libobjc.A.dylib - objc_alloc: 也就輕鬆獲得！

此時此刻，還有誰！就這些東西能難倒咱們？不存在的

4、alloc流程分析

①.彙編配合源碼跟流程

經過前面 alloc底層探索思路(底層探索分析的三種方法) 的介紹,咱們知道了三種探索底層實現的方法,那咱們來玩一玩. 咱們打開準備好的可編譯的objc4源碼 咱們剛剛前面查到了alloc流程,咱們在源碼裏面搜索一下: 在源碼裏面看到了alloc方法,個人天,好高興啊,來到這裏就有底層的實現.咱們點擊_objc_rootAlloc方法來到: 繼續點擊callAlloc方法來到: 到這的源碼可能就會讓你頭暈目眩，不想看了

原本看源碼就枯燥，還有這麼多if-else邏輯岔路口，就會有不少人關閉了Xcode.

看啥很差看源碼，是嫌本身頭髮太旺盛嗎？

別急，我這裏已經幫你掉過頭髮了（捋過思路了）

那麼他到底走的是哪個流程呢?咱們來驗證一下

彙編和源碼同步輔導來跟流程

• 在咱們的第一份代碼裏面加入咱們剛剛捋過的三個符號斷點_objc_rootAlloc、callAlloc、_objc_rootAllocWithZone.
• 先關閉符號斷點,來到咱們的研究對象斷點處
• 打開咱們剛剛下的三個符號斷點,來到第一個符號斷點_objc_rootAlloc:
• 過掉此_objc_rootAlloc斷點來到了_objc_rootAllocWithZone斷點:

來咱們根據剛剛看的源碼來捋個草圖: 根據源碼咱們知道在callAlloc的時候出現了分叉:objc_msgSend和_objc_rootAllocWithZone,那麼他究竟是往那個分叉走的呢?根據剛剛咱們的走的彙編,咱們獲得的是走的_objc_rootAllocWithZone. 而咱們跑彙編跟流程的時候,只斷了兩下即:_objc_rootAlloc直接來到了_objc_rootAllocWithZone.而後callAlloc這個斷點變沒有斷住?爲何呢?請看下文

②.編譯器優化

咱們先來看下面的例子(使用真機調試,看彙編):

運行程序獲得彙編代碼:

看到結果有些小夥伴可能會問?爲何有w和x呢? 這涉及到寄存器的知識.w表明32位,x表明64位.那爲何咱們跑到真機上還有w呢?這考慮到兼容問題,例如咱們存儲一個int = 10類型的數據,在32位下就能存儲,不須要用64位.

寄存器 - 其寄存器的做用就是進行數據的臨時存儲

• ARM64擁有31個64位的通用寄存器 x0 到 x30,這些寄存器一般用來存放通常性的數據，稱爲通用寄存器（有時也有特定用途）
  • 好比x0 ~ x7 用來存儲參數,x0主要用來存儲參數和接收返回值.
  • 那麼w0 到 w28 這些是32位的. 由於64位CPU能夠兼容32位.因此能夠只使用64位寄存器的低32位.
  • 好比 w0 就是 x0的低32位!
• 一般，CPU會先將內存中的數據存儲到通用寄存器中，而後再對通用寄存器中的數據進行運算

咱們剛剛在 int a = 10處打了一個斷點,那麼哪一個表明他呢,咱們打印一下:

接下來又來到 mov w9, #0x14:

接下來來到add w9, w9, w10即: 10 + 20 放到 w9 裏面:

在正常開發過程當中咱們都是Debug模式下,想要提升編譯速度，可將Debug環境也選中Fastest，Smallest[-OS]模式:

• target ->BuildSettings: 搜索:optimization

咱們發現Optimization Level中，Release環境下，已自動選擇Fastest，Smallest[-OS]

• 接下來咱們將Debug模式下也選中Fastest，Smallest[-OS]模式:

在Fastest，Smallest[-OS]模式下，會發現彙編頁面展現的代碼已精簡不少: 咱們直接讀取一下:

那麼Fastest，Smallest[-OS]表明什麼意思呢?就是按照最快最小的路徑來執行.

在下來咱們看源碼的過程當中都會看到有不少的過程都會被優化掉 - 這就是編譯器的強大. 這也就是咱們在發佈版本的時候要調到Release版本(如今蘋果在咱們發版的時候會自動幫咱們選擇Release環境,早期的時候須要咱們手動設置選擇). 由於Release環境下，系統自動選擇Fastest，Smallest[-OS]模式，完成編譯器優化,節省性能.

③.alloc源碼流程

咱們先來看下面的代碼

接下來我先給出他們各自調用alloc方法後的堆棧詳情圖:

看到上面的調用堆棧圖,咱們不難發現如下問題:

• 問題一:無論我是NSObject類,仍是自定義的TCJPerson類調用alloc方法爲何最開始走的是objc_alloc
• 問題二:NSObject沒有走alloc方法
• 問題三:自定義的TCJPerson類爲何走了兩次callAlloc

③.1 objc_alloc 方法

爲何首先會來到objc_alloc?

第一處解釋:源碼中的Calls [cls alloc]告訴咱們,當咱們調用alloc方法時底層是調用objc_alloc

第二處解釋:咱們一塊兒來看看彙編代碼: 彙編代碼也告訴咱們首先調用的是objc_alloc.

第三處解釋:須要藉助llvm源碼來幫助咱們.

• 打開llvm源碼文件(用Xcode打開比較慢,可用Visual Studio Code即VSCode打開)，搜索alloc,找到CGObjC.cpp文件
• 能夠看到這裏有明確標註，[self alloc] -> objc_alloc(self)
• 函數中顯示，當接收到alloc名稱的selector時，調用EmitObjCAlloc函數.繼續全局搜索EmitObjCAlloc:

由此能夠得出當咱們調用alloc方法時會調用 objc_alloc，其實這部分是由系統在llvm底層幫咱們轉發到objc_alloc的.llvm在咱們編譯啓動時，就已經處理好了.

咱們來驗證一下:

• 首先來到咱們的研究對象斷點處:

• 接着在objc4源碼中的objc_alloc方法實現處打下斷點:

• 結果都來到了objc_alloc方法,接着調用callAlloc方法.

• 那麼問題一問題二的答案咱們相信你們都知道了吧.

③.2 callAlloc 方法

①static ALWAYS_INLINE id 中的 ALWAYS_INLINE說明 inline 是一種下降函數調用成本的方法，其本質是在調用聲明爲 inline 的函數時，會直接把函數的實現替換過去，這樣減小了調用函數的成本. 是一種以空間換時間的作法.

#define ALWAYS_INLINE inline __attribute__((always_inline)) ALWAYS_INLINE宏會強制開啓inline

②if (slowpath(checkNil && !cls))判斷

#define fastpath(x) (__builtin_expect(bool(x), 1)) #define slowpath(x) (__builtin_expect(bool(x), 0))

這兩個宏使用__builtin_expect函數

__builtin_expect(EXP, N) __builtin_expect是gcc引入的

• 做用： 容許程序員將最有可能執行的分支告訴編譯器.編譯器能夠對代碼進行優化，以減小指令跳轉帶來的性能降低.即性能優化
• 函數： __builtin_expect(EXP, N) 表示 EXP==N的機率很大

fastpath:定義中__builtin_expect((x),1)表示 x 的值爲真的可能性更大；即 執行if 裏面語句的機會更大 slowpath:定義中的__builtin_expect((x),0)表示 x 的值爲假的可能性更大。即執行 else 裏面語句的機會更大

在平常的開發中，也能夠經過設置來優化編譯器，達到性能優化的目的，設置的路徑爲：Build Setting --> Optimization Level --> Debug --> 將None 改成 fastest 或者 smallest(前面有介紹)

③if (fastpath(!cls->ISA()->hasCustomAWZ()))判斷 跟進hasCustomAWZ()實現可發現: 而FAST_CACHE_HAS_DEFAULT_AWZ的定義爲:

判斷的主要依據:仍是看緩存中是否有默認的alloc/allocWithZone方法(這個值會存儲在metaclass中).

而對於NSObject類而言就有少量不一樣了:由於NSObject的初始化，系統在llvm編譯時就已經初始化好了.所以緩存中就有alloc/allocWithZone方法了.即hasCustomAWZ()爲false那麼!cls->ISA()->hasCustomAWZ()就爲true:

而咱們自定義的TCJPerson類初次建立是沒有默認的alloc/allocWithZone實現的。因此繼續向下執行進入到msgSend消息發送流程，調用[NSObject alloc]方法,即就是alloc方法,接着會來到_objc_rootAlloc,後再次來callAlloc,而此次由於調用的是NSObject類的,因此緩存中存在alloc/allocWithZone實現,接着走_objc_rootAllocWithZone方法.

自定義類第一次進入callAlloc走msgSend消息發送流程: 第二次進入callAlloc走_objc_rootAllocWithZone:

到這也就解釋了問題三:自定義的TCJPerson類爲何走了兩次callAlloc.

③.3 alloc 方法

③.4 _objc_rootAlloc 方法

③.5 callAlloc 方法(自定義類二次進入)

調用 NSObject的[NSObject alloc]不會來到③.3-③.4-③.5這個流程,只有自定義的類TCJPerson調用[TCJPerson alloc]纔會來到③.3-③.4-③.5這個流程

③.6 _objc_rootAllocWithZone 方法

③.7 _class_createInstanceFromZone 方法 (alloc的核心方法)

①hasCxxCtor()

hasCxxCtor()是判斷當前class或者superclass是否有.cxx_construct 構造方法的實現

②hasCxxDtor()

hasCxxDtor()是判斷判斷當前class或者superclass是否有.cxx_destruct 析構方法的實現

③canAllocNonpointer()

canAllocNonpointer()是具體標記某個類是否支持優化的isa,便是對 isa 的類型的區分，若是一個類和它父類的實例不能使用 isa_t 類型的 isa 的話，返回值爲 false.在 Objective-C 2.0 中，大部分類都是支持的.

④size = cls->instanceSize(extraBytes)

instanceSize(extraBytes) 計算須要開闢的內存大小，傳入的extraBytes 爲 0

跳轉至instanceSize的源碼實現

經過斷點調試，會執行到cache.fastInstanceSize方法

繼續跟斷點，進入align16源碼實現(16字節對齊算法):

既然提到了內存對齊(後面文章會詳細講解),那咱們就來預熱一下:

內存字節對齊原則

在解釋爲何須要16字節對齊以前，首先須要瞭解內存字節對齊的原則，主要有如下三點:

• 數據成員對齊規則：struct 或者 union 的數據成員，第一個數據成員放在offset爲0的地方，之後每一個數據成員存儲的起始位置要從該成員大小或者成員的子成員大小（只要該成員有子成員，好比數據、結構體等）的整數倍開始（例如int在32位機中是4字節，則要從4的整數倍地址開始存儲）
• 數據成員爲結構體：若是一個結構裏有某些結構體成員，則結構體成員要從其內部最大元素大小的整數倍地址開始存儲（例如：struct a裏面存有struct b，b裏面有char、int、double等元素，則b應該從8的整數倍開始存儲）
• 結構體的總體對齊規則：結構體的總大小，即sizeof的結果，必須是其內部最大成員的整數倍，不足的要補齊.

爲何須要16字節對齊

• 提升性能,加快存儲速度: 一般內存是由一個個字節組成，cpu在存儲數據時，是以固定字節塊爲單位進行存取的.這是一個以空間換時間的一種優化方式，這樣不用考慮字節未對齊的數據，極大節省了計算資源，提高了存取速度。
• 更安全 因爲在一個對象中，第一個屬性isa佔8字節，固然一個對象可能還有其餘屬性，當無其餘屬性時，會預留8字節，即16字節對齊.由於蘋果公司如今採用的16字節對齊(早期是8字節對齊--objc4-756.2及之前版本),若是不預留，就至關於這個對象的isa和其餘對象的isa緊挨着，在CPU存取時它以16字節爲單位長度去訪問的,這樣會訪問到相鄰對象,容易形成訪問混亂,那麼16字節對齊後，能夠加快CPU讀取速度，同時使訪問更安全，不會產生訪問混亂的狀況

下面以align16(size_t 8)->(8 + size_t(15)) & ~size_t(15)爲例，圖解16字節對齊算法的計算過程，以下所示

• 首先將原始的內存 8 與 size_t(15)相加，獲得 8 + 15 = 23其二進制:0000 0000 0001 0111
• 將 size_t(15) 即 15的二進制:0000 0000 0000 1111進行~（取反）操做其取反二進制爲:1111 1111 1111 0000，~（取反）的規則是：1變爲0，0變爲1
• 最後將 23的二進制 與 15的取反結果的二進制 進行 &（與）操做，&（與）的規則是：都是1爲1，反之爲0，最後的結果爲0000 0000 0001 0000即16(十進制)，即內存的大小是以16的倍數增長的.

⑤calloc()

用來動態開闢內存，返回地址指針.沒有具體實現代碼，接下來的文章會講到malloc源碼

（這裏的zone基本是不會走的，蘋果廢棄了zone開闢空間，而且這裏zone的入參傳入的也是nil）

根據size = cls->instanceSize(extraBytes)計算的內存大小，向內存中申請大小爲size的內存，並賦值給obj.

• 執行前打印obj只有cls類名,執行後打印，已爲成功申請內存的首地址了.
• 但並非咱們想象中的格式<TCJPerson: 0x0000000101906140>,這是由於這一步只是單純的完成內存申請，返回首地址.
• 而類和地址的關聯:是在接下來咱們要說的obj->initInstanceIsa(cls, hasCxxDtor)完成

⑥obj->initInstanceIsa(cls, hasCxxDtor) 類與isa關聯

已知zone=false，fast=true，則(!zone && fast)=true

內部調用initIsa(cls, true, hasCxxDtor) 初始化isa指針,並將isa指針指向申請的內存地址，在將指針與cls類進行關聯(具體的isa結構和綁定關係，後續會做爲單獨章節進行講解)

通過initIsa後,打印obj,此時發現地址與類完成綁定:

在_class_createInstanceFromZone中，主要作了3件事，1.計算對象所需的空間大小；2.根據計算大小開闢空間,返回地址指針；3.初始化isa，使其與當前對象關聯

到此處一個TCJPerson對象就建立完成了.

5、init源碼分析

那麼init 作了什麼? init什麼也不作，就是給開發者使用工廠設計模式提供一個接口

補充： 關於子類中if (self = [super init])爲何要這麼寫——子類先繼承父類的屬性，再判斷是否爲空，如若爲空不必進行一系列操做了直接返回nil.

就是一個初始化的構造方法！提供構造能力：好比array初始化 字典 還有button 這就是給工廠設計!

6、new源碼分析

那麼 new 又作了什麼？

• 底層就是調用了 alloc 下層的 callAlloc 建立對象
• 而後調用了 init 的初始化方法
• new 方法也就是爲了方便直接！

可是通常在開發過程當中不建議使用new，主要是由於有時會重寫init方法作一些自定義的操做.

寫在後面

最後咱們來一塊兒解答前面最開始留下的兩個問題:

• ①.p一、p二、p3對象和地址打印都一致， 爲什麼&p打印不一致?
• ②.p4的地址爲何和p一、p二、p3都不同?

解答:

問題1：p一、p二、p3對象和地址打印都一致， 爲什麼&p打印不一致? 其實說白了alloc就作到了對象指針的肯定，咱們開闢內存真正的傢伙就是alloc. 他們的指針都是同一個，可是由於都是不一樣對象接受而已，因此執行不一樣的地址,即&p打印的是他們自身的地址 問題二:p4的地址爲何和p一、p二、p3都不同? 由於p一、p二、p3是同一個alloc開闢出來的，而p4是new出來的，new會單獨調用alloc. 因此他們打印確定不同.

總結:

• 對象的開闢內存交由 alloc 方法封裝
• init 只是一種工廠設計方案，爲了方便子類重寫：自定義實現，提供一些初始化就伴隨的東西
• new 封裝了 alloc 和init
• 這一篇文章裏面也涉及了一些探索的思路和方法：
  • 源碼跟入
  • 彙編分析
  • 符號斷點設置
• 和諧學習,不急不躁.我仍是我,顏色不同的煙火.