1、UI渲染爲什麼要放在主線程中?
- UI操作涉及到渲染訪問各種View對象的屬性，如果是異步操作會有讀寫問題；
- 如果加鎖，性能損耗大（視圖層次深、屬性多）；
所以，主線程操作UI，是約定俗稱的開發規則
2、TCP三次握手和四次揮手
- 第一次握手：客戶端發送syn包（syn=j）到服務器，並進入SYN_SEND狀態，等待服務器確認；
- 第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包，即SYN+ACK包，此時服務器進入SYN+RECV狀態；
- 第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK（ack=k+1），此發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次狀態。
- 第一次揮手：客戶端向服務器發送FIN包，表示自己沒有數據要發送了；
- 第二次揮手：服務器收到FIN包，回覆FIN ACK，表示收到了FIN包，不會在接收數據了；
- ⚠️服務器在發完FIN ACK後，可能還有數據要發給客戶端，這個數據是不能停止發送的，有數據還是需要繼續發送；
- 第三次揮手：服務器發完了數據，也發出FIN包，告訴客戶端自己的數據發送完了，不再發送數據；
- 第四次揮手：客服戶收到服務器發送的FIN包，知道服務器沒有數據要發送了，回覆FIN ACK，此時斷開連接。
爲什麼要多次確認呢？
TCP 是傳輸層的協議，是建立在物理層、數據鏈路層、網絡層之上的協議，
而底層的網絡是不可靠的，可能路由、網關、網線出問題，客戶端沒法保證自己發出來的消息服務器一定能收到。
所以一定要反饋機制，即 ACK，這樣才能在不可靠的網絡層智商構建可靠的傳輸層。
建連只需要交互三次，斷連卻需要四次，這是爲什麼呢？
- 建連的時候，只要雙方都告知對方自己準備好了就可以；
- 斷連的時候，一方提出要斷開連接，不再發數據，另一方不能立即斷開，
因爲這一方可能還有數據要發送，直到數據全部發送完成後才能確認斷開。
3、GCD定時器和NSTimer有什麼不同
- NSTimer需要一個運行的Runloop 來處理其定時任務, MainThread是一直啓動並運行的,所以在自定的線程如果使用NSTIme必須手動開啓並運行子線程的Runloop;
- NSTimer必須調用invalidate來停止其定時任務,並且NSTimer 對其Target是強引用,要注意Target 與 - NSTimer間造成的循環引用造成的內存泄漏(可以封裝成一個類方法來解決此問題);
- NSTimer的創建和 invalidate必須放在相同的線程中進行
- GCDTimer 是基於GCD實現的,使用的時候只要我們把任務提交給相應隊列就好;
- GCDTimer 在使用時要注意 dispatch_resume（obj） dispatch_suspend(obj) -dispatch_source_cancel(obj）API 的使用
- GCDTimer 在對文件資源定期進行讀寫操作時很方便,其他與NSTimer使用場景差不多
4、https原理
-
4.1、爲什麼用了HTTPS 就是安全的？HTTPS 的底層原理如何實現？用了 HTTPS 就一定安全嗎？
大家可能都聽說過 HTTPS 協議之所以是安全的，是因爲HTTPS協議會對傳輸的數據進行加密，而加密過程是使用了非對稱加密實現。
但其實，HTTPS 在內容傳輸的加密上使用的是對稱加密，非對稱加密只作用在證書驗證階段。
-
4.2、證書驗證階段：
1、瀏覽器發起 HTTPS 請求；
2、服務端返回 HTTPS 證書；
3、客戶端驗證證書是否合法，如果不合法則提示告警
-
4.3、數據傳輸階段:
1、當證書驗證合法後，在本地生成隨機數；
2、通過公鑰加密隨機數，並把加密後的隨機數傳輸到服務端；
3、服務端通過私鑰對隨機數進行解密；
4、服務端通過客戶端傳入的隨機數構造對稱加密算法，對返回結果內容進行加密後傳輸
-
4.4、數據傳輸階段
爲什麼數據傳輸是用對稱加密?
- HTTP 的應用場景中通常端與端之間存在大量的交互，非對稱加密的加解密效率是非常低的;
- 另外，在 HTTPS 的場景中只有服務端保存了私鑰，一對公私鑰只能實現單向的加解密
所以 HTTPS 中 ***內容傳輸*** 加密採取的是對稱加密，而不是非對稱加密。
-
4.5、本地隨機數被竊取怎麼辦?
證書驗證是採用非對稱加密實現，但是傳輸過程是採用對稱加密，而其中對稱加密算法中重要的隨機數是由本地生成並且存儲於本地的，HTTPS 如何保證隨機數不會被竊取?
其實 HTTPS 並不包含對隨機數的安全保證，HTTPS 保證的只是傳輸過程安全，而隨機數存儲於本地，本地的安全屬於另一安全範疇，應對的措施有安裝殺毒軟件、反木馬、瀏覽器升級修復漏洞等.
5、Charles抓包原理
HTTPS 的數據是加密的，常規下抓包工具代理請求後抓到的包內容是加密狀態，無法直接查看。但是，瀏覽器只會提示安全風險，如果用戶授權仍然可以繼續訪問網站，完成請求。
因此，只要我們自己的客戶端在授權的情況下，便可以組建中間人網絡，而抓包工具便是作爲中間人的代理。
通常HTTPS抓包工具的使用方法是會生成一個證書，用戶需要手動把證書安裝到客戶端中，然後終端發起的所有請求通過該證書完成與抓包工具的交互。
然後抓包工具再轉發請求到服務器，最後把服務器返回的結果在控制檯輸出後再返回給終端，從而完成整個請求的閉環。
-
5.1、既然HTTPS不能防抓包，那 HTTPS 有什麼意義?
HTTPS可以防止用戶在不知情的情況下通信鏈路被監聽，對於主動授信的抓包操作是不提供防護的，因爲這個場景用戶是已經對風險知情。
要防止被抓包，需要採用應用級的安全防護，例如採用私有的對稱加密，同時做好移動端的防反編譯加固，防止本地算法被破解。
6、說說你知道的線程鎖
常用：@synchronized、NSLock、dispatch_semaphore
不常用：OSSpinLock、pthread_mutex、NSCondition、NSRecursiveLock等等
具體可以看看這篇文章：iOS 開發中的八種鎖
7、UITableView卡頓是如何優化的
- 可通過Instruments測試FPS，確保刷新幀率在 60+/s
- 要想滾動UITableView流暢，關鍵的在創建cell或者從緩存池取cell時，讓系統花費最少的時間，
即儘可能的減少顯示cell的計算量。
1、緩存行高
舉個簡單的栗子： 如果現在要顯示100個Cell，當前屏幕顯示5個。
- 全局刷新UITableView時：
會先調用100次tableView:heightForRowAtIndexPath，然後調用5次tableView:cellForRowAtIndexPath
- 滾動屏幕時：
當Cell滾入屏幕，都會調用一次tableView:heightForRowAtIndexPath和tableView:cellForRowAtIndexPath
所以，要提前計算並緩存好高度，因爲heightForRowAtIndexPath:是調用最頻繁的方法
2、不要動態創建子視圖
Cell所有的子視圖都預先在初始化方法中創建。如果根據實際情況不需要顯示的可以設置hidden。
這樣能儘可能的減少Cell創建或從緩存池取時因爲佈局子控件所消耗的時間。
3、所有的子視圖都必須指定背景顏色（可能會爲你造成這種現象的原因）
相信很多程序員在開發時經常會遇到這種情況,當從某個控制器A跳轉到下一個控制器B時,若B控制器的view未設置背景顏色,跳轉時會有卡頓現象。
cell也一樣,若控件未指定背景顏色,會影響tableView滾動的流暢度。
4、所有的顏色都不要使用alpha
控件如有透明度,會顯示底部控件的部分輪廓,系統在顯示cell時,需要計算各控件間的疊加面積,顏色的透明度等;
但如果所有控件顏色不透明,則不需要耗費性能去計算,能節省大量時間.
5、異步繪製
如果Cell 比較複雜，可以設置cell圖層的屬性 self.layer.drawsAsynchronously = YES;
6、UITableview加載圖片的時候使用懶加載模式和異步加載模式