|
作者：故胤道長 卓同學(xué)昨天寫了一篇文章《4道過濾菜鳥的iOS面試題》。我手癢決定默寫一個參考答案。后來發(fā)現(xiàn)不認(rèn)真回答被大家噴成狗，所以決定積極改造，重新做人。下面就是修編之后的答案。 1. struct和class的區(qū)別 swift中，class是引用類型，struct是值類型。值類型在傳遞和賦值時將進(jìn)行復(fù)制，而引用類型則只會使用引用對象的一個"指向"。所以他們兩者之間的區(qū)別就是兩個類型的區(qū)別。 class有這幾個功能struct沒有的： struct也有這樣幾個優(yōu)勢： 順便提一下，array在swift中是用struct實(shí)現(xiàn)的。Apple重寫過一次array，然后復(fù)制就是深度拷貝了。要是多次拷貝且不進(jìn)行修改的話，所有arrays指向的都是同一個物理地址，只是指針移動，所以性能上還是不錯的。當(dāng)然要是修改的話，array就會重新拷貝一份，這個時候開銷就有點(diǎn)大了。 下面引用貓神OneV的博客： 1 2 3 4 5 6 | var arr = [0,0,0]
var newArr = arr
arr[0] = 1
//Check arr and newArr
arr //[1, 0, 0]
newArr // before beta3:[1, 0, 0], after beta3:[0, 0, 0]
|
所以可以猜測其實(shí)在背后 Array和 Dictionary的行為并不是像其他 struct 那樣簡單的在棧上分配，而是類似參照那樣，通過棧上指向堆上位置的指針來實(shí)現(xiàn)的。而對于它的復(fù)制操作，也是在相對空間較為寬裕的堆上來完成的。當(dāng)然，現(xiàn)在還無法（或者說很難）拿到最后的匯編碼，所以這只是一個猜測而已。 補(bǔ)充： C語言中，struct與的class的區(qū)別： struct只是作為一種復(fù)雜數(shù)據(jù)類型定義，不能用于面向?qū)ο缶幊獭?/p> C++中，struct和class的區(qū)別： 對于成員訪問權(quán)限以及繼承方式，class中默認(rèn)的是private的，而struct中則是public的。class還可以用于表示模板類型，struct則不行。 2. 介紹一下觀察者模式 觀察者模式(Observer Pattern)：定義對象間的一種一對多依賴關(guān)系，使得每當(dāng)一個對象狀態(tài)發(fā)生改變時，其相關(guān)依賴對象皆得到通知并被自動更新。 在IOS中典型的推模型實(shí)現(xiàn)方式為NSNotificationCenter和KVO。 
NSNotificationCenter 觀察者Observer，通過NSNotificationCenter的addObserver:selector:name:object接口來注冊對某一類型通知感興趣。在注冊時候一定要注意，NSNotificationCenter不會對觀察者進(jìn)行引用計(jì)數(shù)+1的操作，我們在程序中釋放觀察者的時候，一定要去報(bào)從center中將其注銷了。 通知中心NSNotificationCenter，通知的樞紐。 被觀察的對象，通過postNotificationName:object:userInfo:發(fā)送某一類型通知，廣播改變。 通知對象NSNotification，當(dāng)有通知來的時候，Center會調(diào)用觀察者注冊的接口來廣播通知，同時傳遞存儲著更改內(nèi)容的NSNotification對象。
KVO KVO的全稱是Key-Value Observer，即鍵值觀察。是一種沒有中心樞紐的觀察者模式的實(shí)現(xiàn)方式。一個主題對象管理所有依賴于它的觀察者對象，并且在自身狀態(tài)發(fā)生改變的時候主動通知觀察者對象。 [object addObserver:self forKeyPath:property options:NSKeyValueObservingOptionNew context:]。 更改主題對象屬性的值，即觸發(fā)發(fā)送更改的通知。 在制定的回調(diào)函數(shù)中，處理收到的更改通知。 注銷觀察者 [object removeObserver:self forKeyPath:property]。
3.在一個HTTPS連接的網(wǎng)站里，輸入賬號密碼點(diǎn)擊登錄后，到服務(wù)器返回這個請求前，中間經(jīng)歷了什么 這個非常得深非常得廣，我來大概說一下。 
HTTPS加密流程 客戶端會打包一個請求，包括url，端口啊，你的賬號密碼等等。賬號密碼登陸應(yīng)該用的是Post方式，所以相關(guān)的用戶信息會被加載到body里面。這個請求應(yīng)該包含三個方面：網(wǎng)絡(luò)地址，協(xié)議，資源路徑。注意，這里是HTTPS，就是HTTP + SSL / TLS，在HTTP上又加了一層處理加密信息的模塊（相當(dāng)于是個鎖）。 一般會先請求DNS服務(wù)器。DNS服務(wù)器負(fù)責(zé)將你的網(wǎng)絡(luò)地址解析成IP地址，這個IP地址對應(yīng)網(wǎng)上一臺機(jī)器。這其中可能發(fā)生Hosts Hijack和ISP failure的問題。 協(xié)議是獲取資源的方式HTTP，F(xiàn)TP，UDP，不同協(xié)議有不同的格式，有些是process-to-process的，有些是host-to-host的。 客戶端會和服務(wù)器的端口之間建立一個socket連接，socket一般都是以file descriptor的方式解析請求。 服務(wù)器端接收到請求。服務(wù)器端會有一套數(shù)字證書（相當(dāng)于是個鑰匙），這個證書會先返回給客戶端?？蛻舳藭馕鲎C書，相當(dāng)于用鑰匙（證書）把鎖（內(nèi)容）鎖上（生成私匙），接著再傳送加密信息。 服務(wù)器端接收到加密信息（私匙）之后，會進(jìn)行解密，并把要返回的數(shù)據(jù)進(jìn)行對稱加密返回到客戶端。假如路徑不對，會出現(xiàn)404的錯誤。 一般訪問服務(wù)器之前可能會訪問一下proxy。這玩意是個代理，有時候當(dāng)防火墻用，有時候當(dāng)cache使。如果后臺是reverse-proxy結(jié)構(gòu)，那么實(shí)際上有多個web服務(wù)器藏在proxy之后按需處理請求，而你訪問的永遠(yuǎn)是proxy，這樣可以解決過載問題。 有時候訪問完web服務(wù)器后還要訪問一下file服務(wù)器，主要是請求數(shù)據(jù)庫里的一些信息。 服務(wù)器將相應(yīng)打包，直接或通過proxy（大多數(shù)時候）返回給客戶端。客戶端會用剛剛生成的私匙進(jìn)行解密，將內(nèi)容顯示在瀏覽器上。 HTTPS加密過程詳解請去https原理：證書傳遞、驗(yàn)證和數(shù)據(jù)加密、解密過程解析
4.在一個app中間有一個button，在你手觸摸屏幕點(diǎn)擊后，到這個button收到點(diǎn)擊事件，中間發(fā)生了什么 響應(yīng)鏈大概有以下幾個步驟： 設(shè)備將touch到的UITouch和UIEvent對象打包, 放到當(dāng)前活動的Application的事件隊(duì)列中 單例的UIApplication會從事件隊(duì)列中取出觸摸事件并傳遞給單例UIWindow UIWindow使用hitTest:withEvent:方法查找touch操作的所在的視圖view
RunLoop這邊我大概講一下： 主線程的RunLoop被喚醒 通知Observer，處理Timer和Source 0 Springboard接受touch event之后轉(zhuǎn)給App進(jìn)程 RunLoop處理Source 1，Source1 就會觸發(fā)回調(diào)，并調(diào)用_UIApplicationHandleEventQueue() 進(jìn)行應(yīng)用內(nèi)部的分發(fā)。 RunLoop處理完畢進(jìn)入睡眠，此前會釋放舊的autorelease pool并新建一個autorelease pool
深挖請去：深入理解RunLoop UIResponder是UIView的父類，UIView是UIControl的父類。 聲明一下，第3題依然有很大缺陷，不過因?yàn)樯钔诘牡胤教?，本文不可能完全兼顧，只能拋磚引玉。另外文章的目的是以面試題為引進(jìn)行學(xué)習(xí)，所以寫得有點(diǎn)多，可能與面試技巧和時間有沖突。
|
