1翅溺、UI渲染為什么要放在主線程中?

- UIKit不是線程安全的；
- UI操作涉及到渲染訪問各種View對象的屬性髓抑，如果是異步操作會(huì)有讀寫問題咙崎；
- 如果加鎖，性能損耗大（視圖層次深吨拍、屬性多）褪猛；
所以，主線程操作UI羹饰，是約定俗稱的開發(fā)規(guī)則

2伊滋、TCP三次握手和四次揮手

- 第一次握手：客戶端發(fā)送syn包（syn=j）到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)队秩，等待服務(wù)器確認(rèn)笑旺；
- 第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=j+1）馍资，同時(shí)自己也發(fā)送一個(gè)SYN包筒主，即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN+RECV狀態(tài)；
- 第三次握手：客戶端收到服務(wù)器的SYN+ACK包乌妙，向服務(wù)器發(fā)送確認(rèn)包ACK（ack=k+1）使兔，此發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)冠胯，完成三次狀態(tài)火诸。

- 第一次揮手：客戶端向服務(wù)器發(fā)送FIN包，表示自己沒有數(shù)據(jù)要發(fā)送了荠察；
- 第二次揮手：服務(wù)器收到FIN包置蜀，回復(fù)FIN ACK，表示收到了FIN包悉盆，不會(huì)在接收數(shù)據(jù)了盯荤；
- ??服務(wù)器在發(fā)完FIN ACK后，可能還有數(shù)據(jù)要發(fā)給客戶端焕盟，這個(gè)數(shù)據(jù)是不能停止發(fā)送的秋秤，有數(shù)據(jù)還是需要繼續(xù)發(fā)送；
- 第三次揮手：服務(wù)器發(fā)完了數(shù)據(jù)脚翘，也發(fā)出FIN包灼卢，告訴客戶端自己的數(shù)據(jù)發(fā)送完了，不再發(fā)送數(shù)據(jù)来农；
- 第四次揮手：客服戶收到服務(wù)器發(fā)送的FIN包鞋真，知道服務(wù)器沒有數(shù)據(jù)要發(fā)送了，回復(fù)FIN ACK沃于，此時(shí)斷開連接涩咖。

為什么要多次確認(rèn)呢？

TCP 是傳輸層的協(xié)議繁莹，是建立在物理層檩互、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層之上的協(xié)議咨演，
而底層的網(wǎng)絡(luò)是不可靠的闸昨，可能路由、網(wǎng)關(guān)薄风、網(wǎng)線出問題零院，客戶端沒法保證自己發(fā)出來的消息服務(wù)器一定能收到。
所以一定要反饋機(jī)制村刨，即 ACK告抄，這樣才能在不可靠的網(wǎng)絡(luò)層智商構(gòu)建可靠的傳輸層。

建連只需要交互三次嵌牺，斷連卻需要四次打洼，這是為什么呢龄糊？

- 建連的時(shí)候，只要雙方都告知對方自己準(zhǔn)備好了就可以募疮；
- 斷連的時(shí)候炫惩，一方提出要斷開連接，不再發(fā)數(shù)據(jù)阿浓，另一方不能立即斷開他嚷，
因?yàn)檫@一方可能還有數(shù)據(jù)要發(fā)送，直到數(shù)據(jù)全部發(fā)送完成后才能確認(rèn)斷開芭毙。

3筋蓖、GCD定時(shí)器和NSTimer有什么不同

- NSTimer需要一個(gè)運(yùn)行的Runloop 來處理其定時(shí)任務(wù), MainThread是一直啟動(dòng)并運(yùn)行的,所以在自定的線程如果使用NSTIme必須手動(dòng)開啟并運(yùn)行子線程的Runloop;
- NSTimer必須調(diào)用invalidate來停止其定時(shí)任務(wù),并且NSTimer 對其Target是強(qiáng)引用,要注意Target 與 - NSTimer間造成的循環(huán)引用造成的內(nèi)存泄漏(可以封裝成一個(gè)類方法來解決此問題);
- NSTimer的創(chuàng)建和 invalidate必須放在相同的線程中進(jìn)行

- GCDTimer 是基于GCD實(shí)現(xiàn)的,使用的時(shí)候只要我們把任務(wù)提交給相應(yīng)隊(duì)列就好;
- GCDTimer 在使用時(shí)要注意 dispatch_resume（obj） dispatch_suspend(obj) -dispatch_source_cancel(obj）API 的使用
- GCDTimer 在對文件資源定期進(jìn)行讀寫操作時(shí)很方便,其他與NSTimer使用場景差不多

4、https原理

必看文章一
必看文章二

• 4.1退敦、為什么用了HTTPS 就是安全的粘咖？HTTPS 的底層原理如何實(shí)現(xiàn)？用了 HTTPS 就一定安全嗎侈百？

??大家可能都聽說過 HTTPS 協(xié)議之所以是安全的瓮下，是因?yàn)镠TTPS協(xié)議會(huì)對傳輸?shù)臄?shù)據(jù)進(jìn)行加密，而加密過程是使用了非對稱加密實(shí)現(xiàn)钝域。
??但其實(shí)讽坏，HTTPS 在內(nèi)容傳輸?shù)募用苌鲜褂玫氖菍ΨQ加密，非對稱加密只作用在證書驗(yàn)證階段例证。

HTTPS 的實(shí)現(xiàn)原理.png

• 4.2震缭、證書驗(yàn)證階段：

1、瀏覽器發(fā)起 HTTPS 請求战虏；
2、服務(wù)端返回 HTTPS 證書党涕；
3烦感、客戶端驗(yàn)證證書是否合法，如果不合法則提示告警

• 4.3膛堤、數(shù)據(jù)傳輸階段:

1手趣、當(dāng)證書驗(yàn)證合法后，在本地生成隨機(jī)數(shù)肥荔；
2绿渣、通過公鑰加密隨機(jī)數(shù)，并把加密后的隨機(jī)數(shù)傳輸?shù)椒?wù)端燕耿；
3中符、服務(wù)端通過私鑰對隨機(jī)數(shù)進(jìn)行解密；
4誉帅、服務(wù)端通過客戶端傳入的隨機(jī)數(shù)構(gòu)造對稱加密算法淀散，對返回結(jié)果內(nèi)容進(jìn)行加密后傳輸

• 4.4右莱、數(shù)據(jù)傳輸階段

為什么數(shù)據(jù)傳輸是用對稱加密?
- HTTP 的應(yīng)用場景中通常端與端之間存在大量的交互，非對稱加密的加解密效率是非常低的;
- 另外档插，在 HTTPS 的場景中只有服務(wù)端保存了私鑰慢蜓，一對公私鑰只能實(shí)現(xiàn)單向的加解密
所以 HTTPS 中 ***內(nèi)容傳輸*** 加密采取的是對稱加密，而不是非對稱加密郭膛。

• 4.5晨抡、本地隨機(jī)數(shù)被竊取怎么辦?

??證書驗(yàn)證是采用非對稱加密實(shí)現(xiàn)，但是傳輸過程是采用對稱加密则剃，而其中對稱加密算法中重要的隨機(jī)數(shù)是由本地生成并且存儲(chǔ)于本地的耘柱，HTTPS 如何保證隨機(jī)數(shù)不會(huì)被竊取?
??其實(shí) HTTPS 并不包含對隨機(jī)數(shù)的安全保證，HTTPS 保證的只是傳輸過程安全忍级，而隨機(jī)數(shù)存儲(chǔ)于本地帆谍，本地的安全屬于另一安全范疇，應(yīng)對的措施有安裝殺毒軟件轴咱、反木馬汛蝙、瀏覽器升級修復(fù)漏洞等.

5、Charles抓包原理

??HTTPS 的數(shù)據(jù)是加密的朴肺，常規(guī)下抓包工具代理請求后抓到的包內(nèi)容是加密狀態(tài)窖剑，無法直接查看。但是戈稿，瀏覽器只會(huì)提示安全風(fēng)險(xiǎn)西土，如果用戶授權(quán)仍然可以繼續(xù)訪問網(wǎng)站，完成請求鞍盗。
??因此需了，只要我們自己的客戶端在授權(quán)的情況下，便可以組建中間人網(wǎng)絡(luò)般甲，而抓包工具便是作為中間人的代理肋乍。
??通常HTTPS抓包工具的使用方法是會(huì)生成一個(gè)證書，用戶需要手動(dòng)把證書安裝到客戶端中敷存，然后終端發(fā)起的所有請求通過該證書完成與抓包工具的交互墓造。
??然后抓包工具再轉(zhuǎn)發(fā)請求到服務(wù)器，最后把服務(wù)器返回的結(jié)果在控制臺(tái)輸出后再返回給終端锚烦，從而完成整個(gè)請求的閉環(huán)觅闽。

• 5.1、既然HTTPS不能防抓包涮俄，那 HTTPS 有什么意義?

??HTTPS可以防止用戶在不知情的情況下通信鏈路被監(jiān)聽蛉拙，對于主動(dòng)授信的抓包操作是不提供防護(hù)的，因?yàn)檫@個(gè)場景用戶是已經(jīng)對風(fēng)險(xiǎn)知情彻亲。
??要防止被抓包刘离，需要采用應(yīng)用級的安全防護(hù)室叉，例如采用私有的對稱加密，同時(shí)做好移動(dòng)端的防反編譯加固硫惕，防止本地算法被破解茧痕。

https 通信流程

Charles 抓包原理

6、說說你知道的線程鎖

常用：@synchronized恼除、NSLock踪旷、dispatch_semaphore
不常用：OSSpinLock、pthread_mutex豁辉、NSCondition令野、NSRecursiveLock等等

具體可以看看這篇文章：iOS 開發(fā)中的八種鎖

7、UITableView卡頓是如何優(yōu)化的

- 可通過Instruments測試FPS徽级，確保刷新幀率在 60+/s 
- 要想滾動(dòng)UITableView流暢气破，關(guān)鍵的在創(chuàng)建cell或者從緩存池取cell時(shí)，讓系統(tǒng)花費(fèi)最少的時(shí)間餐抢，

即盡可能的減少顯示cell的計(jì)算量现使。

主要目的是減少CPU的占用使用，圖像繪制的原理大體可以概括為CPU計(jì)算布局旷痕，GPU進(jìn)行圖像繪制碳锈，當(dāng)在下一幀到來之前CPU占用時(shí)間太長的話，留給

1欺抗、緩存行高
舉個(gè)簡單的栗子： 如果現(xiàn)在要顯示100個(gè)Cell售碳，當(dāng)前屏幕顯示5個(gè)。

- 全局刷新UITableView時(shí)：
會(huì)先調(diào)用100次tableView:heightForRowAtIndexPath绞呈，然后調(diào)用5次tableView:cellForRowAtIndexPath

- 滾動(dòng)屏幕時(shí)：
當(dāng)Cell滾入屏幕贸人，都會(huì)調(diào)用一次tableView:heightForRowAtIndexPath和tableView:cellForRowAtIndexPath

所以，要提前計(jì)算并緩存好高度佃声，因?yàn)閔eightForRowAtIndexPath:是調(diào)用最頻繁的方法

2艺智、不要?jiǎng)討B(tài)創(chuàng)建子視圖
Cell所有的子視圖都預(yù)先在初始化方法中創(chuàng)建。如果根據(jù)實(shí)際情況不需要顯示的可以設(shè)置hidden秉溉。
這樣能盡可能的減少Cell創(chuàng)建或從緩存池取時(shí)因?yàn)椴季肿涌丶牡臅r(shí)間。

3碗誉、所有的子視圖都必須指定背景顏色（可能會(huì)為你造成這種現(xiàn)象的原因）
相信很多程序員在開發(fā)時(shí)經(jīng)常會(huì)遇到這種情況,當(dāng)從某個(gè)控制器A跳轉(zhuǎn)到下一個(gè)控制器B時(shí),若B控制器的view未設(shè)置背景顏色,跳轉(zhuǎn)時(shí)會(huì)有卡頓現(xiàn)象召嘶。
cell也一樣,若控件未指定背景顏色,會(huì)影響tableView滾動(dòng)的流暢度。

4哮缺、所有的顏色都不要使用alpha
控件如有透明度,會(huì)顯示底部控件的部分輪廓,系統(tǒng)在顯示cell時(shí),需要計(jì)算各控件間的疊加面積,顏色的透明度等;
但如果所有控件顏色不透明,則不需要耗費(fèi)性能去計(jì)算,能節(jié)省大量時(shí)間.

5弄跌、異步繪制
如果Cell 比較復(fù)雜，可以設(shè)置cell圖層的屬性 self.layer.drawsAsynchronously = YES;

6尝苇、UITableview加載圖片的時(shí)候使用懶加載模式和異步加載模式