第一章：熟悉 Objective-C
第1條：瞭解 Objective-C 語言的起源
第2條：在類的頭文件中儘量少引入其他頭文件
背景：
使用 #import "ClassName.h" 可以引入其他文件的所有接口細節。
問題：
- .h頭文件中，在編譯一個使用了某類的文件時，不需要知道這個類的全部細節，只需要知道有這個類就好。
- A頭文件中引入B頭文件，C頭文件引入A頭文件，就會一起引入B頭文件的所有內容。此過程若持續下去，則要引入許多根本用不到的內容，這當然會增加編譯時間。
解決辦法：
使用
@class ClassName“向前聲明”(forward declaring)，只聲明有這個類，沒有具體細節，可以解決上述問題。除非確實有必要，否則不要引入頭文件。一般來說，應在某個類的頭文件中使用向前聲明來提及別的類，並在實現文件中引入那些類的頭文件。這樣做可以儘量降低類之間的耦合（coupling）。
繼承 和 遵從協議 不能使用向前聲明。 有時無法使用向前聲明，比如要聲明某個類遵循一項協議。這種情況下，儘量把“該類遵循某協議”的這條聲明移至“分類”中。如果不行的話，就把協議單獨放在一個頭文件中，然後將其引入。
向前聲明的作用：
- 防止引入根本用不到的內容，減少頭文件細節引用。
- 解決兩個類相互引用的問題。
將引入頭文件的時機儘量延後，只在確有需要時才引入，這樣可以減少類的使用者所需引入頭文件的數量。
第3條：多用字面量語法，少用與之等價的方法
使用字面量語法（literal syntax）可以縮減源代碼的長度，使其更爲易讀。
第4條：多用類型常量，少用 #define 預處理指令
問題：
#define 定義的常量沒有類型信息，編譯器只會在編譯前據此執行查找與替換操作。即使有人重新定義了常量值，編譯器也不會產生警告信息，這將導致應用程序中的常量值不一致。
解決辦法：
- 在實現文件中使用 static const 來定義“只在編譯單元內可見的變量”。由於此類常量不在全局符號表中，所以無須爲其名稱加前綴。代碼實現如下：
// .h 文件
@interface 類名: 父類名
...
@end
// .m 文件
// 類內使用
static const 類型 常量名 = 常量值;
@implementation 類名
...
@end
- 在頭文件中使用 extern 來聲明的全局變量，並在相關實現文件中定義其值。這種常量要出現在全局符號表中，所以其名稱應加以區分，通常用與之相關的類名做前綴。
// .h 文件
// 類外可用聲明
extern 類名 const 常量名;
@interface 類名: 父類名
...
@end
// .m 文件
// 類外可用聲明
類名 const 常量名 = 常量;
@implementation 類名
...
@end
常量名稱常用命名法是：
- 只在類內使用，在前面加字母
k。 - 類外也可使用，以類名最爲前綴。
第5條：用枚舉表示狀態、選項、狀態碼
- 使用枚舉，給這些值起個易懂的名字。
- 將枚舉值定義爲2的冪，多枚舉選項可以同時使用，可以通過按位或操作進行組合。
- 定義枚舉時，指明其底層數據類型，便於處理。
- 在處理枚舉類型的
switch語句中不要實現default分支，便於加入新枚舉後，編譯器報錯，知道需要修改的地方。
第二章：對象、消息、運行期
第6條：理解 “屬性” 這一概念
第7條：在對象內部儘量直接訪問實例變量
第8條：理解 “對象等同性” 這一概念
==操作符比較的是兩個指針本身，不是其所指的對象。NSObject協議中聲明的isEqual方法判斷兩個對象的等同性。isEqual默認實現是：當且僅當其 “指針值” 完全相等時，這兩個對象才相等。- 特定類具有等同性的判定方法。
NSString:isEqualToString:NSArray:isEqualToArray:NSDIctionary:isEqualToDictionary:若比較的對象不是對應的類型，就會拋出異常，崩潰。 - 等同性判定的執行深度取決於受測對象。 對象個數相同的數組比較，對應位置上的對象均相等，數組就相等，這叫做“深度等同性判定”。 爲了性能，建議儘可能的降低深度。
- 容器中可變類的等同性判定 將某對象放入容器後，又修改其內容，那麼後面的行爲將很難預料，建議不要這麼做。
第9條：以 “類族模式” 隱藏實現細節
類族模式：使用繼承，實現多種職能的子類，父類通過設定不同的類型來創建某種子類，執行其相應的職能。 作用：將實現細節隱藏在一套簡單的公共接口後面。 需要注意的是，創建的實例的真實類型是什麼，需要我們知道
新增 Cocoa 中 NSArray 這樣的類族的子類，需要遵守以下幾條規則：
- 子類應該繼承自類族中的抽象基類。
- 子類應該定義自己的數據存儲方式。
NSArray本身只是包在其他隱藏對象外面的殼，它僅僅定義了所有數組都需具備的一些接口。 - 子類應當覆寫超類文檔中指明需要覆寫的方法。 在每個抽象的基類中，都有一些子類必須覆寫的方法。
第10條：在既有類中使用關聯對象存放自定義數據
在對象中存放相關信息：
- 從對象所屬的類中繼承一個子類，然後修改這個子類對象。
- 通過“關聯對象”的特性，給某對象關聯許多其他對象，這些對象通過“鍵”來區分。
關聯對象方法：
以給定的鍵和存儲策略爲某對象設置關聯對象值
objc_setAssociatedObject(id _Nonnull object, const void * _Nonnull key, id _Nullable value, objc_AssociationPolicy policy)參數說明：
object關聯的源對象。key關聯的key。通常使用靜態全局變量做鍵。value關聯key所對應的值。傳nil可以清除現有的關聯。policy關聯的存儲策略，也就是對應的內存管理語義，是一個枚舉值。
objc_AssociationPolicy枚舉值如下表： | 關聯類型 | 等效的 @property 屬性 | | --- | --- | OBJC_ASSOCIATION_ASSIGN | assign | OBJC_ASSOCIATION_RETAIN_NONATOMIC | nonatomic, retain | OBJC_ASSOCIATION_COPY_NONATOMIC | nonatomic, copy | OBJC_ASSOCIATION_RETAIN | retain | OBJC_ASSOCIATION_COPY | copy |
根據給定的鍵從某對象中獲取對應的關聯對象值。
objc_getAssociatedObject(id _Nonnull object, const void * _Nonnull key)移除指定對象的全部關聯對象。
objc_removeAssociatedObjects(id _Nonnull object)
注：只有在其他方法都行不通時才考慮使用它。若是濫用，則很快就會令代碼失控，使其難於調試。
第11條：理解 objc_msgSend 的作用
OC方法調用
代碼：
id returnValue = [someObject messageName: paramter];
代碼說明：
someObject接受者。messageName選擇子。選擇子和參數合起來稱爲“消息”
底層C語言代碼實現：
id returnValue = objc_msgSend(someObject, @selector(messageName:), paramter);
消息發送機制核心函數
原型代碼：
void objc_msgSend(id self, SEL cmd, ...)
這是個“參數個數可變函數”，能接受兩個或者兩個以上的參數。 參數說明：
self接受者。cmd選擇子（方法的名字）。- 後續參數爲消息中的那些參數，順序不變。
具體實現：
注：OC 方法調用需要很多步驟，較爲耗時。objc_msgSend 會將匹配結果緩存在“快速映射表”，每個類都有這樣一塊緩存。雖然還是不如“靜態綁定的函數調用操作”那麼迅速，但是也不會慢很多。
邊界情況：
objc_msgSend_stret待發送的消息要返回結構體，就交由此函數處理。objc_msgSend_fpret待發送的消息要返回浮點數，就交由此函數處理。objc_msgSendSuper要給超類發消息，就交由此函數處理。如：[super message:parameter]。
尾調用優化
Objective-C 對象的每個方法都可以看做簡單的 C 函數，其原型如下：
<return_type> Class_selector(id self, SEL _cmd, ...)
這個原型和 objc_msgSend 函數很像，是爲了利用 “尾調用優化” 技術。令 “跳至方法實現” 這一操作跟簡單些。
使用範圍：某函數的最後一項操作僅僅是調用另一個函數而不會將其返回值另作他用。 步驟：編譯器會生成調轉至另一函數所需的指令碼，不會向調用堆棧中推人新的 “棧幀”。 不優化後果：
- 每次調用
Objective-C方法之前，都需要爲調用objc_msgSend函數準備 “棧幀”，可以在 “棧蹤跡” 中看到。 - 過早的發生 “棧溢出” 現象。
第12條：理解消息轉發機制
消息轉發： 第一階段：動態方法解析： 徵詢接收者(所屬的類)，看其是否能動態添加方法，以處理當前這個 “未知的選擇子”。 第二階段： 1. 備援的接收者： 請接收者看看有沒有其他對象(備援的接收者)能處理這條消息。 2. 完整的消息轉發機制： 運行期系統會把與消息有關的全部細節都封裝到
NSInvocation對象中，再給接收者最後一次機會，令其設法解決當前還未處理的這條消息。
動態方法解析
是否能新增一個實例方法來處理選擇子，調用方法如下：
// 實例方法
+ (BOOL)resolveInstanceMethod:(SEL)selector
// 類方法
+ (BOOL)resolveClassMethod:(SEL)selector
使用前提：相關方法的實現代碼已經寫好，只等運行的時候動態插入到類裏面。
動態添加方法函數如下：
BOOL class_addMethod(Class cls, SEL name, IMP imp, const char *types)參數說明：
cls添加方法的類name被添加方法的名字imp函數指針，指向待添加的方法(C語言實現)。type待添加方法的 “類型編碼” 。
備援接收者
是否有其他對象處理這條消息，調用方法如下：
- (id)forwardingTargetForSelector:(SEL)selector
若找到備援對象，該方法返回備援對象，反之，返回 nil。
注意：我們無法操作經由這一步所轉發的消息。
完整的消息轉發機制
創建 NSInvocation 對象，此對象包含 選擇子 、目標 及 參數。
消息派發調用方法如下：
- (void)forwardInvocation:(NSInvocation *)invocation
若發現某調用操作不應由本類處理，則向上尋找，直至 NSObject。如果最後調用了 NSObject 的方法，那麼該方法還會繼續調用 doesNotRecognizeSelector: 以拋出異常，表明選擇子最終未能得到處理。
總結：
消息轉發全流程如下圖：
接收者在每一步中均有機會處理消息。步驟越往後，處理消息的代價就越大。
消息轉發代碼：https://github.com/AlonerOwl/Runtime/tree/master/Runtime/MessageSend
第13條：用 ”方法調配(method swizzling)技術“ 調試 ”黑盒方法“
函數指針(IMP)：id (*IMP)(id, SEL, ...)
方法表：函數指針所組成的一個集合。
操作類的方法表：
- 新增選擇子
第12條已經說過了。BOOL class_addMethod(Class cls, SEL name, IMP imp, const char *types) - 改變某選擇子所對應的方法實現
- 交換兩個選擇子所映射到的指針，也就是交換兩個方法實現。
方法交換函數：
參數：兩個待交換的方法實現 獲取方法實現函數：func method_exchangeImplementations(_ m1: Method, _ m2: Method)Method class_getInstanceMethod(Class cls, SEL name)
這個方法可以爲那些 “完全不知道具體實現” 的黑盒方法增加日誌記錄功能，這非常有助於程序調試。 若是濫用，反而會令代碼變的不易讀懂且難於維護。
method swizzling代碼：https://github.com/AlonerOwl/Runtime/tree/master/Runtime/MethodSwizzling