聊一聊京東七鮮一面總結
文末本文轉載自微信公眾號「Swift社區」，作者朱浦睿 。轉載本文請聯系Swift社區公眾號。
1. http 鏈接到斷開的過程?
第一步：TCP建立連接：三次握手
HTTP 是應用層協議，他的工作還需要數據層協議的支持，最常與它搭配的就是 TCP 協議(應用層、數據層是 OSI 七層模型中的，以后有機會會說到的)。TCP 協議稱為數據傳輸協議，是可靠傳輸，面向連接的，并且面向字節流的。
面向連接：通信之前先建立連接，確保雙方在線?？煽總鬏敚涸诰W絡正常的情況下，數據不會丟失。面向字節流：傳輸靈活，但是 TCP 的傳輸存在粘包問題，沒有明顯的數據約定。
在正式發送請求之前，需要先建立 TCP 連接。建立 TCP 連接的過程簡單地來說就是客戶端和服務端之間發送三次消息來確保連接的建立，這個過程稱為三次握手。
第二步：瀏覽器發送請求命令
TCP 連接建立完成后，客戶端就可以向服務端發送請求報文來請求了
請求報文分為請求行、請求頭、空行、請求體，服務端通過請求行和請求頭中的內容獲取客戶端的信息，通過請求體中的數據獲取客戶端的傳遞過來的數據。
第三步：應答響應
在接收到客戶端發來的請求報文并確認完畢之后。服務端會向客戶端發送響應報文
響應報文是有狀態行、響應頭、空行和響應體組成，服務端通過狀態行和響應頭告訴客戶端請求的狀態和如何對數據處理等信息，真正的數據則在響應體中傳輸給客戶端。
第四步：斷開 TCP 連接
當請求完成后，還需要斷開 tcp 連接，斷開的過程
斷開的過程簡單地說就算客戶端和服務端之間發送四次信息來確保連接的斷開，所以稱為四次揮手。
延伸：
一、單向請求 HTTP 請求是單向的，是只能由客戶端發起請求，由服務端響應的請求-響應模式。(如果你需要雙向請求，可以用 socket)
二、基于 TCP 協議 HTTP 是應用層協議，所以其數據傳輸部分是基于 TCP 協議實現的。
三、無狀態 HTTP 請求是無狀態的，即沒有記憶功能，不能獲取之前請求或響應的內容。起初這種簡單的模式，能夠加快處理速度，保證協議的穩定，但是隨著應用的發展，這種無狀態的模式會使我們的業務實現變得麻煩，比如說需要保存用戶的登錄狀態，就得專門使用數據庫來實現。于是乎，為了實現狀態的保持，引入了 Cookie 技術來管理狀態。
四、無連接 HTTP 協議不能保存連接狀態，每次連接只處理一個請求，用完即斷，從而達到節約傳輸時間、提高并發性。在 TCP 連接斷開之后，客戶端和服務端就像陌生人一樣，下次再發送請求，就得重新建立連接了。有時候，當我們需要發送一段頻繁的請求時，這種無連接的狀態反而會耗費更多的請求時間(因為建立和斷開連接本身也需要時間)，于是乎，HTTP1.1 中提出了持久連接的概念，可以在請求頭中設置 Connection: keep-alive 來實現。
2. 深拷貝、淺拷貝
深拷貝、淺拷貝實例說明?
深拷貝：是對對象本身的拷貝;淺拷貝：是對指針的拷貝;
在 oc 中父類的指針可以指向子類的對象，這是多態的一個特性 聲明一個 NSString 對象，讓它指向一個 NSMutableString 對象，這一點是完全可以的，因為 NSMutableString 的父類就是 NSString。NSMutableString 是一個可以改變的對象，如果我們用 strong 修飾，NSString 對象強引用了 NSMutableString 對象。假如我們在其他的地方修改了這個 NSMutableString 對象，那么 NSString 的值會隨之改變。
關于copy修飾相關
1、對 NSString 進行 copy -> 這是一個淺拷貝，但是因為是不可變對象，后期值也不會改變;
2、對 NSString 進行 mutableCopy -> 這是一個深拷貝，但是拷貝出來的是一個可變的對象 NSMutableString;
3、對 NSMutableString 進行 copy -> 這是一個深拷貝，拷貝出來一個不可變的對象;
4、對 NSmutableString 進行 mutableCopy -> 這是一個深拷貝，拷貝出來一個可變的對象;
總結：
對對象進行 mutableCopy，不管對象是可變的還是不可變的都是深拷貝，并且拷貝出來的對象都是可變的;
對對象進行 copy，copy 出來的都是不可變的。
對于系統的非容器類對象，我們可以認為，如果對一不可變對象復制，copy 是指針復制(淺拷貝)和 mutableCopy 就是對象復制(深拷貝)。如果是對可變對象復制，都是深拷貝，但是 copy 返回的對象是不可變的。
指 NSArray，NSDictionary 等。對于容器類本身，上面討論的結論也是適用的，需要探討的是復制后容器內對象的變化。
- //copy返回不可變對象，mutablecopy返回可變對象
- NSArray *array1 = [NSArray arrayWithObjects:@"a",@"b",@"c",nil];
- NSArray *arrayCopy1 = [array1 copy];
- //arrayCopy1是和array同一個NSArray對象（指向相同的對象），包括array里面的元素也是指向相同的指針
- NSLog(@"array1 retain count: %d",[array1 retainCount]);
- NSLog(@"array1 retain count: %d",[arrayCopy1 retainCount]);
- NSMutableArray *mArrayCopy1 = [array1 mutableCopy];
mArrayCopy1 是 array1 的可變副本，指向的對象和 array1 不同，但是其中的元素和 array1 中的元素指向的是同一個對象。
mArrayCopy1 還可以修改自己的對象 [mArrayCopy1 addObject:@"de"];
[mArrayCopy1 removeObjectAtIndex:0]; array1 和 arrayCopy1 是指針復制，而 mArrayCopy1 是對象復制，mArrayCopy1 還可以改變期內的元素：刪除或添加。但是注意的是，容器內的元素內容都是指針復制。
- NSArray *mArray1 = [NSArray arrayWithObjects:[NSMutableString stringWithString:@"a"],@"b",@"c",nil];
- NSArray *mArrayCopy2 = [mArray1 copy];
- NSMutableArray *mArrayMCopy1 = [mArray1 mutableCopy];
- NSMutableString *testString = [mArray1 objectAtIndex:0];
- [testString appendString:@" tail"];
- NSLog(@"%@-%@-%@",mArray1,mArrayMCopy1,mArrayCopy2);
- 結果：mArray1,mArrayMCopy1,mArrayCopy2三個數組的首元素都發生了變化！
3. load 和 initialize 區別
load 方法和 initialize 方法區別，以及在子類、父類、分類中調用順序?
+(void)load
1、+load 方法加載順序：父類> 子類> 分類 (load 方法都會加載)注意：(如果分類中有 A, B,順序要看 A, B 加入工程中順序) ，可能結果：( 父類> 子類> 分類A> 分類B ) 或者( 父類> 子類> 分類B> 分類A )
2、+load 方法不會被覆蓋(比如有父類，子類，分類A，分類B,這四個 load 方法都會加載)。
3、+load 方法調用在 main函數前
+(void)initialize
1、分類 (子類沒有 initialize 方法，父類存在或者沒有 1initialize 方法)
2、分類> 子類 (多個分類就看編譯順序，只有存在一個)
3、父類> 子類 (分類沒有 initialize 方法)
4、父類 (子類，分類都沒有 initialize 方法)
總結 +initialize：
1、當調用子類的 + initialize 方法時候,先調用父類的,如果父類有分類, 那么分類的 + initialize 會覆蓋掉父類的
2、分類的 + initialize 會覆蓋掉父類的
3、子類的 + initialize 不會覆蓋分類的
4、父類的 + initialize 不一定會調用, 因為有可能父類的分類重寫了它
5、發生在main函數后。
4. 同名方法調用順序
同名方法在子類、父類、分類的調用順序?
load,initialize方法調用源碼分析[1]
注意：+load 方法是根據方法地址直接調用，并不是經過 objc_msgSend 函數調用(通過 isa 和 superclass 找方法)，所以不會存在方法覆蓋的問題。
5. 事件響應鏈
事件響應鏈(同一個控制器有三個view，如何判斷是否擁有相同的父視圖)
iOS 系統檢測到手指觸摸( Touch )操作時會將其打包成一個 UIEvent 對象，并放入當前活動 Application 的事件隊列，單例的 UIApplication 會從事件隊列中取出觸摸事件并傳遞給單例的 UIWindow 來處理，UIWindow 對象首先會使用 hitTest:withEvent: 方法尋找此次 Touch 操作初始點所在的視圖(View)，即需要將觸摸事件傳遞給其處理的視圖，這個過程稱之為 hit-test view。
UIAppliction --> UIWiondw -->遞歸找到最適合處理事件的控件-->控件調用 touches 方法-->判斷是否實現 touches 方法-->沒有實現默認會將事件傳遞給上一個響應者-->找到上一個響應者。
UIResponder 是所有響應對象的基類，在 UIResponder 類中定義了處理上述各種事件的接口。我們熟悉的 UIApplication、 UIViewController、 UIWindow 和所有繼承自 UIView 的 UIKit 類都直接或間接的繼承自 UIResponder，所以它們的實例都是可以構成響應者鏈的響應者對象。
- UIResponder *nextResponder = gView.nextResponder;
- NSMutableString *p = [NSMutableString stringWithString:@"--"];
- while (nextResponder) {
- NSLog(@"%@%@", p, NSStringFromClass([nextResponder class]));
- [p appendString:@"--"];
- nextResponder = nextResponder.nextResponder;
- }
如果有父視圖則 nextResponder 指向父視圖如果是控制器根視圖則指向控制器;
控制器如果在導航控制器中則指向導航控制器的相關顯示視圖最后指向導航控制器;
如果是根控制器則指向 UIWindow;
UIWindow 的 nexResponder 指向 UIApplication 最后指向 AppDelegate。
6.TCP丟包
TCP 會不會丟包?該怎么處理?網絡斷開會斷開鏈接還是一直等待，如果一直網絡斷開呢?
TCP 在不可靠的網絡上實現可靠的傳輸，必然會有丟包。TCP 是一個“流”協議，一個詳細的包將會被 TCP 拆分為好幾個包上傳，也是將會把小的封裝成大的上傳，這就是說 TCP 粘包和拆包難題。
TCP丟包總結[2]
7.自動釋放池
自動釋放池創建和釋放的時機，在子線程是什么時候創建釋放的?
默認主線程的運行循環(runloop)是開啟的，子線程的運行循環(runloop)默認是不開啟的，也就意味著子線程中不會創建 autoreleasepool，所以需要我們自己在子線程中創建一個自動釋放池。(子線程里面使用的類方法都是 autorelease,就會沒有池子可釋放，也就意味著后面沒有辦法進行釋放，造成內存泄漏。)
在主線程中如果產生事件那么 runloop 才回去創建 autoreleasepool，通過這個道理我們就知道為什么子線程中不會創建自動釋放池了，因為子線程的 runloop 默認是關閉的，所以他不會自動創建 autoreleasepool，需要我們手動添加。
如果你生成一個子線程的時候，要在線程開始執行的時候，盡快創建一個自動釋放池，否則會內存泄露。因為子線程無法訪問主線程的自動釋放池。
8.計算機編譯流程
源文件： 載入.h、.m、.cpp 等文件
預處理： 替換宏，刪除注釋，展開頭文件，產生 .i 文件
編譯： 將 .i 文件轉換為匯編語言，產生 .s 文件
匯編： 將匯編文件轉換為機器碼文件，產生 .o 文件
鏈接： 對 .o 文件中引用其他庫的地方進行引用，生成最后的可執行文件
dyld加載流程[3]
作者：朱浦睿、林一、怪物先生
參考資料
[1]load,initialize方法調用源碼分析: https://www.jianshu.com/p/e5c89e9045cf
[2]TCP丟包總結: https://blog.csdn.net/weixin_41563161/article/details/105310459
[3]dyld加載流程: https://www.jianshu.com/p/db765ff4e36a
