1.strut和class的區(qū)別？
swift中，class是引用類型，struct是值類型。值類型在傳遞和賦值時將進(jìn)行復(fù)制，而引用類型則只會使用引用對象的一個"指向"。所以他們兩者之間的區(qū)別就是兩個類型的區(qū)別。
class有這幾個功能struct沒有的：
class可以繼承，這樣子類可以使用父類的特性和方法
類型轉(zhuǎn)換可以在runtime的時候檢查和解釋一個實(shí)例的類型
可以用deinit來釋放資源
一個類可以被多次引用
struct也有這樣幾個優(yōu)勢：
結(jié)構(gòu)較小，適用于復(fù)制操作，相比于一個class的實(shí)例被多次引用更加安全。
無須擔(dān)心內(nèi)存memory leak或者多線程沖突問題
順便提一下，array在swift中是用struct實(shí)現(xiàn)的。Apple重寫過一次array，然后復(fù)制就是深度拷貝了。猜測復(fù)制是類似參照那樣，通過棧上指向堆上位置的指針來實(shí)現(xiàn)的。而對于它的復(fù)制操作，也是在相對空間較為寬裕的堆上來完成的，所以性能上還是不錯的。
2.介紹一下觀察者模式？（這個回答應(yīng)該包括三個部分：首先這個設(shè)計(jì)模式為了解決什么問題，其次通過什么方案來解決，最后才是當(dāng)前體系下的具體實(shí)現(xiàn)方案。）
觀察者模式(Observer Pattern)：定義對象間的一種一對多依賴關(guān)系，使得每當(dāng)一個對象狀態(tài)發(fā)生改變時，其相關(guān)依賴對象皆得到通知并被自動更新。
在IOS中典型的推模型實(shí)現(xiàn)方式為NSNotificationCenter和KVO。
NSNotificationCenter
1.觀察者Observer，通過NSNotificationCenter的addObserver:selector:name:object接口來注冊對某一類型通知感興趣。在注冊時候一定要注意，NSNotificationCenter不會對觀察者進(jìn)行引用計(jì)數(shù)+1的操作，我們在程序中釋放觀察者的時候，一定要去報從center中將其注銷了。
2.通知中心NSNotificationCenter，通知的樞紐。
3.被觀察的對象，通過postNotificationName:object:userInfo:發(fā)送某一類型通知，廣播改變。
4.通知對象NSNotification，當(dāng)有通知來的時候，Center會調(diào)用觀察者注冊的接口來廣播通知，同時傳遞存儲著更改內(nèi)容的NSNotification對象。
KVO
KVO的全稱是Key-Value Observer，即鍵值觀察。是一種沒有中心樞紐的觀察者模式的實(shí)現(xiàn)方式。一個主題對象管理所有依賴于它的觀察者對象，并且在自身狀態(tài)發(fā)生改變的時候主動通知觀察者對象。
1.注冊觀察者
[object addObserver:self forKeyPath:property options:NSKeyValueObservingOptionNew context:]。
2.更改主題對象屬性的值，即觸發(fā)發(fā)送更改的通知。
3.在制定的回調(diào)函數(shù)中，處理收到的更改通知。
4.注銷觀察者 [object removeObserver:self forKeyPath:property]。
3.在一個https連接的網(wǎng)站里，輸入賬號密碼點(diǎn)擊登錄后，到服務(wù)器返回這個請求前，中間經(jīng)歷了什么？（這里面可以談的東西就很多了，TCP/IP下有非常多的協(xié)議。不需要什么都能說的清楚，但是對于整個網(wǎng)絡(luò)連接模型的理解可以看出基本功）
1.客戶端會打包一個請求，包括url，端口啊，你的賬號密碼等等。賬號密碼登陸應(yīng)該用的是Post方式，所以相關(guān)的用戶信息會被加載到body里面。這個請求應(yīng)該包含三個方面：網(wǎng)絡(luò)地址，協(xié)議，資源路徑。注意，這里是HTTPS，就是HTTP + SSL / TLS，在HTTP上又加了一層處理加密信息的模塊（相當(dāng)于是個鎖）。
2.一般會先請求DNS服務(wù)器。DNS服務(wù)器負(fù)責(zé)將你的網(wǎng)絡(luò)地址解析成IP地址，這個IP地址對應(yīng)網(wǎng)上一臺機(jī)器。這其中可能發(fā)生Hosts Hijack和ISP failure的問題。
3.協(xié)議是獲取資源的方式HTTP，F(xiàn)TP，UDP，不同協(xié)議有不同的格式，有些是process-to-process的，有些是host-to-host的。
4.客戶端會和服務(wù)器的端口之間建立一個socket連接，socket一般都是以file descriptor的方式解析請求。
5.服務(wù)器端接收到請求。服務(wù)器端會有一套數(shù)字證書（相當(dāng)于是個鑰匙），這個證書會先返回給客戶端。客戶端會解析證書，相當(dāng)于用鑰匙（證書）把鎖（內(nèi)容）鎖上（生成私匙），接著再傳送加密信息。
6.服務(wù)器端接收到加密信息（私匙）之后，會進(jìn)行解密，并把要返回的數(shù)據(jù)進(jìn)行對稱加密返回到客戶端。假如路徑不對，會出現(xiàn)404的錯誤。
7.一般訪問服務(wù)器之前可能會訪問一下proxy。這玩意是個代理，有時候當(dāng)防火墻用，有時候當(dāng)cache使。如果后臺是reverse-proxy結(jié)構(gòu)，那么實(shí)際上有多個web服務(wù)器藏在proxy之后按需處理請求，而你訪問的永遠(yuǎn)是proxy，這樣可以解決過載問題。
8.有時候訪問完web服務(wù)器后還要訪問一下file服務(wù)器，主要是請求數(shù)據(jù)庫里的一些信息。
9.服務(wù)器將相應(yīng)打包，直接或通過proxy（大多數(shù)時候）返回給客戶端?？蛻舳藭脛倓偵傻乃匠走M(jìn)行解密，將內(nèi)容顯示在瀏覽器上。
HTTPS加密過程詳解請去https原理：證書傳遞、驗(yàn)證和數(shù)據(jù)加密、解密過程解析
4.在一個app中間有一個button，在你手觸摸屏幕點(diǎn)擊后，到這個button收到點(diǎn)擊事件，中間發(fā)生了什么？（runloop和響應(yīng)鏈需要說的清楚。有時還會順便問問UIResponder、UIControl、UIView的關(guān)系。）
響應(yīng)鏈大概有以下幾個步驟
1.設(shè)備將touch到的UITouch和UIEvent對象打包, 放到當(dāng)前活動的Application的事件隊(duì)列中
2.單例的UIApplication會從事件隊(duì)列中取出觸摸事件并傳遞給單例UIWindow
3.UIWindow使用hitTest:withEvent:方法查找touch操作的所在的視圖view
RunLoop這邊我大概講一下
1.主線程的RunLoop被喚醒
2.通知Observer，處理Timer和Source 0
3.Springboard接受touch event之后轉(zhuǎn)給App進(jìn)程
4.RunLoop處理Source 1，Source1 就會觸發(fā)回調(diào)，并調(diào)用_UIApplicationHandleEventQueue() 進(jìn)行應(yīng)用內(nèi)部的分發(fā)。
5.RunLoop處理完畢進(jìn)入睡眠，此前會釋放舊的autorelease pool并新建一個autorelease pool
深挖請去深入理解RunLoop
UIResponder是UIView的父類，UIView是UIControl的父類。
內(nèi)容摘自簡書：http://www.lxweimin.com/p/c687110e552c
