摘錄 只供自己學習

1.typeof 和 __typeof，typeof 的區(qū)別?

__typeof __() 和 __typeof() 是 C語言 的編譯器特定擴展，因為標準 C 不包含這樣的運算符。 標準 C 
要求編譯器用雙下劃線前綴語言擴展（這也是為什么你不應該為自己的函數(shù)，變量等做這些）

typeof() 與前兩者完全相同的，只不過去掉了下劃線，同時現(xiàn)代的編譯器也可以理解。

所以這三個意思是相同的，但沒有一個是標準C，不同的編譯器會按需選擇符合標準的寫法

2.談談對UIResponder的理解

UIResponder類是專門用來響應用戶的操作處理各種事件的，包括觸摸事件(Touch Events)、運動事件(Motion Events)、
遠程控制事件(Remote Control Events)。我們知道UIApplication、UIView、UIViewController這幾個
類是直接繼承自UIResponder，所以這些類都可以響應事件。當然我們自定義的繼承自UIView的View以及自定義
的繼承自UIViewController的控制器都可以響應事件

3.loadView的作用？

loadView方法會在每次訪問UIViewController的view(比如controller.view、self.view)而且view為
nil時會被調用，此方法主要用來負責創(chuàng)建UIViewController的view(重寫loadView方法，并且不需要調用
[super loadView])

這里要提一下 [super loadView]，[super loadView]做了下面幾件事。
1.它會先去查找與UIViewController相關聯(lián)的xib文件，通過加載xib文件來創(chuàng)建UIViewController的view，
如果在初始化UIViewController指定了xib文件名，就會根據(jù)傳入的xib文件名加載對應的xib文件，如果沒有
明顯地傳xib文件名，就會加載跟UIViewController同名的xib文件
2.如果沒有找到相關聯(lián)的xib文件，就會創(chuàng)建一個空白的UIView，然后賦值給UIViewController的view屬性

在需要自定義UIViewController的view時，可以通過重寫loadView方法且不需要調用[super loadView]方法

4.使用 drawRect有什么影響？

drawRect 方法依賴 Core Graphics 框架來進行自定義的繪制 
   缺點：它處理 touch 事件時每次按鈕被點擊后，都會用 setNeddsDisplay 進行強制重繪；而且不止一次，
每次單點事件觸發(fā)兩次執(zhí)行。這樣的話從性能的角度來說，對 CPU 和內存來說都是欠佳的。特別是如果在我們的
界面上有多個這樣的UIButton 實例，那就會很糟糕了。這個方法的調用機制也是非常特別. 當你調用 
setNeedsDisplay 方法時, UIKit 將會把當前圖層標記為 dirty,但還是會顯示原來的內容,直到下一次的視
圖渲染周期,才會將標記為 dirty 的圖層重新建立 Core Graphics 上下文,然后將內存中的數(shù)據(jù)恢復出來, 
再使用 CGContextRef 進行繪制

5.keyWindow 和 delegate的window有何區(qū)別

delegate.window 程序啟動時設置的window對象。
keyWindow 這個屬性保存了[windows]數(shù)組中的[UIWindow]對象，該對象最近被發(fā)送了[makeKeyAndVisible]消息

一般情況下 delegate.window 和 keyWindow 是同一個對象，但不能保證keyWindow就是
delegate.window，因為keyWindow會因為makeKeyAndVisible而變化，例如，程序中添加了一個懸浮窗口，
這個時候keywindow就會變化

6.說一下 JS 和 OC 互相調用的幾種方式？

js調用oc的三種方式:
@根據(jù)網頁重定向截取字符串通過url scheme判斷
@替換方法.context[@"copyText"]
@注入對象:遵守協(xié)議JSExport,設置context[@

oc調用js代碼兩種方式
@通過webVIew調用 webView stringByEvaluatingJavaScriptFromString: 調用
@通過JSContext調用[context evaluateScript:]

7.在使用 WKWebView 時遇到過哪些問題？

白屏問題，Cookie 問題，在WKWebView上直接使用NSURLProtocol無法攔截請求，在WKWebView 上通過
loadRequ發(fā)起的post請求body數(shù)據(jù)被丟失，截屏問題等

白屏

在WKWebView上總體的內存占用比較大的時候 webContent進程會崩潰 從而出現(xiàn)白屏問題

@采用WKNavigationDelegate
在iOS9之后WKNavigationDelegate的一個函數(shù)
- (void)webViewWebContentProcessDidTerminate:(WKWebView *)webView API_AVAILABLE(macosx(10.11), ios(9.0));
當WKWebView總體內存占用過大，頁面即將白屏的時候，系統(tǒng)會調用上面的某種函數(shù)，我們在該函數(shù)里執(zhí)行
[webView reload]  （這個時候webView.URL取值尚不為nil）解決白屏問題
@并不是所有的白屏都會經過上述方法 也可能是webView.titile被置空了 可以在viewWillAppear的時候判斷
是否webView.titile是否被置空了 這個時候[webView reload]

Cookie 問題

WKWebView Cookie的問題在于WKWebView發(fā)起的請求不會自動帶上存儲于NSHTTPCookieStorage容器中的餅干

無法解決

WKProcessPool
可以實現(xiàn)多個WKWebView之間共享的Cookie數(shù)據(jù)。不過WKWebView WKProcessPool實例在應用殺進程重啟后會被重置，導致WKProcessPool中的Cookie，會話Cookie數(shù)據(jù)丟失，目前也無法實現(xiàn)WKProcessPool實例本地化保存

解決方法
a.WKWebView loadRequest前，在請求標頭中設置Cookie，解決首個請求Cookie帶不上的問題

WKWebView * webView =  [ WKWebView新] ;  
NSMutableURLRequest *請求=  [ NSMutableURLRequest requestWithURL ：[ NSURL URLWithString ： @ “ http://h5.qzone.qq.com/mqzone/index” ] ] ； 
[請求的addValue ： @ “SKEY = skeyValue” forHTTPHeaderField ： @ “曲奇” ] ;  
[ webView loadRequest ： request ] ;

b.通過document.cookie設置Cookie解決后續(xù)頁面（同域）Ajax，iframe請求的Cookie問題
document.cookie()無法跨域設置cookie

WKUserContentController * userContentController =  [ WKUserContentController新] ； 
WKUserScript * cookieScript =  [ [ WKUserScript alloc ] initWithSource ： @ “ document.cookie ='skey = skeyValue';” injectionTime ： WKUserScriptInjectionTimeAtDocumentStart for MainFrameOnly ： NO ] ;  
[ userContentController addUserScript ： cookieScript ] ;

但是無法解決302請求的Cookie問題
可以在

- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler

方法里面攔截302請求 在請求標頭中帶上cookie并重新加載請求

在WKWebView上直接使用NSURLProtocol無法攔截請求

WKWebView在獨立于應用進程之外的進程中執(zhí)行網絡請求，請求數(shù)據(jù)不通過主進程，因此，在WKWebView上直接使用NSURLProtocol無法攔截請求

+ [WKBrowsingContextController registerSchemeForCustomProtocol:]

通過注冊HTTP方案后WKWebView將可以使用NSURLProtocol攔截http（s）請求

Class cls = NSClassFromString(@"WKBrowsingContextController”); 
SEL sel = NSSelectorFromString(@"registerSchemeForCustomProtocol:"); 
if ([(id)cls respondsToSelector:sel]) { 
           // 注冊http(s) scheme, 把 http和https請求交給 NSURLProtocol處理 
           [(id)cls performSelector:sel withObject:@"http"]; 
           [(id)cls performSelector:sel withObject:@"https"]; 
}

有缺陷

在WKWebView 上通過loadRequ發(fā)起的post請求body數(shù)據(jù)被丟失

由于進程間的通信性能問題造成的

1.替換請求方案 生成新的post request2 同時,把request1的主體連接復制到request2的header中
2.通過[-WKWebView loadRequest:] 加載新的post請求request2
3.通過+ [WKBrowsingContextController registerSchemeForCustomProtocol：]注冊方案：post：// 
4.注冊NSURLProtocol攔截請求 替換新的請求方案 生成新的請求request3 將request2的body初始復制到request3的body中 并使用NSURLConnection加載request3 最后通過NSURLProtolClient將加載結果返回WKWebView

截屏問題

8.網絡七層協(xié)議

*   應用層：

    1.用戶接口、應用程序；

    2.Application典型設備：網關；

    3.典型協(xié)議、標準和應用：TELNET、FTP、HTTP

*   表示層：

    1.數(shù)據(jù)表示、壓縮和加密presentation

    2.典型設備：網關

    3.典型協(xié)議、標準和應用：ASCLL、PICT、TIFF、JPEG|MPEG

    4.表示層相當于一個東西的表示，表示的一些協(xié)議，比如圖片、聲音和視頻MPEG。

*   會話層：

    1.會話的建立和結束；

    2.典型設備：網關；

    3.典型協(xié)議、標準和應用：RPC、SQL、NFS、X WINDOWS、ASP

*   傳輸層：

    1.主要功能：端到端控制Transport；

    2.典型設備：網關；

    3.典型協(xié)議、標準和應用：TCP、UDP、SPX

*   網絡層：

    1.主要功能：路由、尋址Network；

    2.典型設備：路由器；

    3.典型協(xié)議、標準和應用：IP、IPX、APPLETALK、ICMP；

*   數(shù)據(jù)鏈路層：

    1.主要功能：保證無差錯的疏忽鏈路的data link；

    2.典型設備：交換機、網橋、網卡；

    3.典型協(xié)議、標準和應用：802.2、802.3ATM、HDLC、FRAME RELAY；

*   物理層：

    1.主要功能：傳輸比特流Physical；

    2.典型設備：集線器、中繼器

    3.典型協(xié)議、標準和應用：V.35、EIA/TIA-232.

9.Http 和 Https 的區(qū)別？Https為什么更加安全？

*   區(qū)別

    1.HTTPS 需要向機構申請 CA 證書，極少免費。

    2.HTTP 屬于明文傳輸，HTTPS基于 SSL 進行加密傳輸。

    3.HTTP 端口號為 80，HTTPS 端口號為 443 。

    4.HTTPS 是加密傳輸，有身份驗證的環(huán)節(jié)，更加安全。

*   安全

    SSL(安全套接層) TLS(傳輸層安全)

    以上兩者在傳輸層之上，對網絡連接進行加密處理，保障數(shù)據(jù)的完整性，更加的安全。

10.HTTPS的連接建立流程

HTTPS為了兼顧安全與效率，同時使用了對稱加密和非對稱加密。在傳輸?shù)倪^程中會涉及到三個密鑰：

服務器端的公鑰和私鑰，用來進行非對稱加密

客戶端生成的隨機密鑰，用來進行對稱加密

image

如上圖，HTTPS連接過程大致可分為八步:

1、客戶端訪問HTTPS連接。

客戶端會把安全協(xié)議版本號、客戶端支持的加密算法列表、隨機數(shù)C發(fā)給服務端。

2、服務端發(fā)送證書給客戶端

服務端接收密鑰算法配件后，會和自己支持的加密算法列表進行比對，如果不符合，則斷開連接。否則，服務端會在該算法列表中，選擇一種對稱算法（如AES）、一種公鑰算法（如具有特定秘鑰長度的RSA）和一種MAC算法發(fā)給客戶端。

服務器端有一個密鑰對，即公鑰和私鑰，是用來進行非對稱加密使用的，服務器端保存著私鑰，不能將其泄露，公鑰可以發(fā)送給任何人。

在發(fā)送加密算法的同時還會把數(shù)字證書和隨機數(shù)S發(fā)送給客戶端

3、客戶端驗證server證書

會對server公鑰進行檢查，驗證其合法性，如果發(fā)現(xiàn)發(fā)現(xiàn)公鑰有問題，那么HTTPS傳輸就無法繼續(xù)。

4、客戶端組裝會話秘鑰

如果公鑰合格，那么客戶端會用服務器公鑰來生成一個前主秘鑰(Pre-Master Secret，PMS)，并通過該前主秘鑰和隨機數(shù)C、S來組裝成會話秘鑰

5、客戶端將前主秘鑰加密發(fā)送給服務端

是通過服務端的公鑰來對前主秘鑰進行非對稱加密，發(fā)送給服務端

6、服務端通過私鑰解密得到前主秘鑰

服務端接收到加密信息后，用私鑰解密得到主秘鑰。

7、服務端組裝會話秘鑰

服務端通過前主秘鑰和隨機數(shù)C、S來組裝會話秘鑰。

至此，服務端和客戶端都已經知道了用于此次會話的主秘鑰。

8、數(shù)據(jù)傳輸

客戶端收到服務器發(fā)送來的密文，用客戶端密鑰對其進行對稱解密，得到服務器發(fā)送的數(shù)據(jù)。

同理，服務端收到客戶端發(fā)送來的密文，用服務端密鑰對其進行對稱解密，得到客戶端發(fā)送的數(shù)據(jù)。

11.解釋一下 三次握手 和 四次揮手

三次握手

1.由客戶端向服務端發(fā)送 SYN 同步報文。

2.當服務端收到 SYN 同步報文之后，會返回給客戶端 SYN 同步報文和 ACK 確認報文。

3.客戶端會向服務端發(fā)送 ACK 確認報文，此時客戶端和服務端的連接正式建立。

建立連接

1.這個時候客戶端就可以通過 Http 請求報文，向服務端發(fā)送請求

2.服務端接收到客戶端的請求之后，向客戶端回復 Http 響應報文。

四次揮手

當客戶端和服務端的連接想要斷開的時候，要經歷四次揮手的過程，步驟如下：

1.先由客戶端向服務端發(fā)送 FIN 結束報文。

2.服務端會返回給客戶端 ACK 確認報文 。此時，由客戶端發(fā)起的斷開連接已經完成。

3.服務端會發(fā)送給客戶端 FIN 結束報文 和 ACK 確認報文。

4.客戶端會返回 ACK 確認報文到服務端，至此，由服務端方向的斷開連接已經完成

12.TCP 和 UDP的區(qū)別

TCP：面向連接、傳輸可靠(保證數(shù)據(jù)正確性,保證數(shù)據(jù)順序)、用于傳輸大量數(shù)據(jù)(流模式)、速度慢，建立連接需要開銷較多(時間，系統(tǒng)資源)。

UDP：面向非連接、傳輸不可靠、用于傳輸少量數(shù)據(jù)(數(shù)據(jù)包模式)、速度快。

13.Cookie和Session

cookie

1.用戶與服務器的交互

cookie主要是用來記錄用戶狀態(tài)，區(qū)分用戶，狀態(tài)保存在客戶端。cookie功能需要瀏覽器的支持。如果瀏覽器不支持cookie（如大部分手機中的瀏覽器）或者把cookie禁用了，cookie功能就會失效。

image

a).首次訪問amazon時，客戶端發(fā)送一個HTTP請求到服務器端 。服務器端發(fā)送一個HTTP響應到客戶端，其中包含Set-Cookie頭部

b).客戶端發(fā)送一個HTTP請求到服務器端，其中包含Cookie頭部。服務器端發(fā)送一個HTTP響應到客戶端

c).隔段時間再去訪問時，客戶端會直接發(fā)包含Cookie頭部的HTTP請求。服務器端發(fā)送一個HTTP響應到客戶端

2.cookie的修改和刪除

在修改cookie的時候，只需要新cookie覆蓋舊cookie即可，在覆蓋的時候，由于Cookie具有不可跨域名性，注意name、path、domain需與原cookie一致

刪除cookie也一樣，設置cookie的過期時間expires為過去的一個時間點，或者maxAge = 0(Cookie的有效期,單位為秒)即可

3、cookie的安全

事實上，cookie的使用存在爭議，因為它被認為是對用戶隱私的一種侵害，而且cookie并不安全

HTTP協(xié)議不僅是無狀態(tài)的，而且是不安全的。使用HTTP協(xié)議的數(shù)據(jù)不經過任何加密就直接在網絡上傳播，有被截獲的可能。使用HTTP協(xié)議傳輸很機密的內容是一種隱患。

a).如果不希望Cookie在HTTP等非安全協(xié)議中傳輸，可以設置Cookie的secure屬性為true。瀏覽器只會在HTTPS和SSL等安全協(xié)議中傳輸此類Cookie。

b).此外，secure屬性并不能對Cookie內容加密，因而不能保證絕對的安全性。如果需要高安全性，需要在程序中對Cookie內容加密、解密，以防泄密。

c).也可以設置cookie為HttpOnly，如果在cookie中設置了HttpOnly屬性，那么通過js腳本將無法讀取到cookie信息，這樣能有效的防止XSS（跨站腳本攻擊）攻擊

Session

Session是服務器端使用的一種記錄客戶端狀態(tài)的機制，使用上比Cookie簡單一些，相應的也增加了服務器的存儲壓力。

Session是另一種記錄客戶狀態(tài)的機制，不同的是Cookie保存在客戶端瀏覽器中，而Session保存在服務器上。 客戶端瀏覽器訪問服務器的時候，服務器把客戶端信息以某種形式記錄在服務器上。這就是Session?？蛻舳藶g覽器再次訪問時只需要從該Session中查找該客戶的狀態(tài)就可以了。

image

*   如圖：

    當程序需要為某個客戶端的請求創(chuàng)建一個session時，服務器首先檢查這個客戶端的請求里是否已包含了一個session標識（稱為SessionId）

    如果已包含則說明以前已經為此客戶端創(chuàng)建過session，服務器就按照SessionId把這個session檢索出來，使用（檢索不到，會新建一個）

    如果客戶端請求不包含SessionId，則為此客戶端創(chuàng)建一個session并且生成一個與此session相關聯(lián)的SessionId，SessionId的值應該是一個既不會重復，又不容易被找到規(guī)律以仿造的字符串，這個SessionId將被在本次響應中返回給客戶端保存。

    保存這個SessionId的方式可以采用cookie，這樣在交互過程中瀏覽器可以自動的按照規(guī)則把這個標識發(fā)送給服務器。但cookie可以被人為的禁止，則必須有其他機制以便在cookie被禁止時仍然能夠把SessionId傳遞回服務器。

Cookie 和Session 的區(qū)別：

*   1、cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務器上。

*   2、cookie相比session不是很安全，別人可以分析存放在本地的cookie并進行cookie欺騙,考慮到安全應當使用session。

*   3、session會在一定時間內保存在服務器上。當訪問增多，會比較占用你服務器的性能,考慮到減輕服務器性能方面，應當使用cookie。

*   4、單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。而session存儲在服務端，可以無限量存儲

*   5、所以：將登錄信息等重要信息存放為session;其他信息如果需要保留，可以放在cookie中

## [#](https://ios.nobady.cn/Network.html#_7-dns%E6%98%AF%E4%BB%80%E4%B9%88)

14.DNS是什么

因特網上的主機，可以使用多種方式標識，比如主機名或IP地址。一種標識方法就是用它的主機名（hostname），比如·www.baidu.com、www.google.com、gaia.cs.umass.edu等。這方式方便人們記憶和接受，但是這種長度不一、沒有規(guī)律的字符串路由器并不方便處理。還有一種方式，就是直接使用定長的、有著清晰層次結構的IP地址，路由器比較熱衷于這種方式。為了折衷這兩種方式，我們需要一種能進行主機名到IP地址轉換的目錄服務。這就是域名系統(tǒng)（Domain Name System，DNS）的主要任務。

*   DNS是：

    1、一個由分層的DNS服務器實現(xiàn)的分布式數(shù)據(jù)庫

    2、一個使得主機能夠查詢分布式數(shù)據(jù)庫的應用層協(xié)議

*   DNS服務器通常是運行BIND軟件的UNIX機器，DNS協(xié)議運行在UDP上，使用53號端口

*   DNS通常是由其他應用層協(xié)議所使用的，包括HTTP、SMTP等。其作用則是：將用戶提供的主機名解析為IP地址

*   DNS的一種簡單設計就是在因特網上只使用一個DNS服務器，該服務器包含所有的映射。很明顯這種設計是有很大的問題的：

    單點故障：如果該DNS服務器崩潰，全世界的網絡隨之癱瘓

    通信容量：單個DNS服務器必須處理所有DNS查詢

    遠距離的集中式數(shù)據(jù)庫：單個DNS服務器必須面對所有用戶，距離過遠會有嚴重的時延。

    維護：該數(shù)據(jù)庫過于龐大，還需要對新添加的主機頻繁更新。

所以，DNS被設計成了一個分布式、層次數(shù)據(jù)庫

15.DNS解析過程

以www.163.com為例:

客戶端打開瀏覽器，輸入一個域名。比如輸入www.163.com，這時，客戶端會發(fā)出一個DNS請求到本地DNS服務器。本地DNS服務器一般都是你的網絡接入服務器商提供，比如中國電信，中國移動。

查詢www.163.com的DNS請求到達本地DNS服務器之后，本地DNS服務器會首先查詢它的緩存記錄，如果緩存中有此條記錄，就可以直接返回結果。如果沒有，本地DNS服務器還要向DNS根服務器進行查詢。

根DNS服務器沒有記錄具體的域名和IP地址的對應關系，而是告訴本地DNS服務器，你可以到域服務器上去繼續(xù)查詢，并給出域服務器的地址。

本地DNS服務器繼續(xù)向域服務器發(fā)出請求，在這個例子中，請求的對象是.com域服務器。.com域服務器收到請求之后，也不會直接返回域名和IP地址的對應關系，而是告訴本地DNS服務器，你的域名的解析服務器的地址。

最后，本地DNS服務器向域名的解析服務器發(fā)出請求，這時就能收到一個域名和IP地址對應關系，本地DNS服務器不僅要把IP地址返回給用戶電腦，還要把這個對應關系保存在緩存中，以備下次別的用戶查詢時，可以直接返回結果，加快網絡訪問

16.UIView動畫與核心動畫的區(qū)別?

核心動畫只作用在layer
核心動畫修改的值都是假象 它的真實位置沒有發(fā)生變化
當需要與用戶進行交互時用UIView動畫 不需要與用戶進行交互時兩個都可以

17.當我們要做一些基于 CALayer 的動畫時，有時需要設置 layer 的錨點來配合動畫，這時候我們需要注意什么

設置秒點可能會引起原來position的變化

// 為 layer 的動畫設置不同的 anchor point，但是又不想改變 view 原來的 position，則需要做一些轉換。
- (void)setAnchorPoint:(CGPoint)anchorPoint forView:(UIView *)view {
    // 分別計算原來錨點和將更新的錨點對應的坐標點，這些坐標點是相對該 view 內部坐標系的。
    CGPoint oldPoint = CGPointMake(view.bounds.size.width * view.layer.anchorPoint.x,
                                   view.bounds.size.height * view.layer.anchorPoint.y);
    CGPoint newPoint = CGPointMake(view.bounds.size.width * anchorPoint.x,
                                   view.bounds.size.height * anchorPoint.y);
    
    // 如果當前 view 有做過 transform，這里要同步計算。
    oldPoint = CGPointApplyAffineTransform(oldPoint, view.transform);
    newPoint = CGPointApplyAffineTransform(newPoint, view.transform);
    
    // position 是當前 view 的 anchor point 在其父 view 的位置。
    CGPoint position = view.layer.position;
    // anchor point 的改變會造成 position 的改變，從而影響 view 在其父 view 的位置，這里把這個位移給計算回來。
    position.x = position.x + newPoint.x - oldPoint.x;
    position.y = position.y + newPoint.y - oldPoint.y;
    
    view.translatesAutoresizingMaskIntoConstraints = YES;
    view.layer.anchorPoint = anchorPoint; // 設置了新的 anchor point 會改變位置。
    view.layer.position = position; // 通過在 position 上做逆向偏移，把位置給移回來。
}

18.如何計算圖片加載內存中所占的大小

圖片內存大小的計算公式 寬度 * 高度 * bytesPerPixel/8。

bytesPerPixel : 每個像素所占的字節(jié)數(shù)。

RGBA顏色空間下 每個顏色分量由32位組成

所以一般圖片的計算公式是 wxhx4

19.isa指針有哪兩種類型？

純指針，指向內存地址
NON_POINTER_ISA，除了內存地址，還存有一些其他信息

20.Objective-C 如何實現(xiàn)多重繼承？

Object-c的類沒有多繼承,只支持單繼承,如果要實現(xiàn)多繼承的話，可使用如下幾種方式間接實現(xiàn)
*   通過組合實現(xiàn)
    A和B組合，作為C類的組件

*   通過協(xié)議實現(xiàn)
    C類實現(xiàn)A和B類的協(xié)議方法

*   消息轉發(fā)實現(xiàn)
    forwardInvocation:方法

21.runtime 如何實現(xiàn) weak 屬性？

weak 此特質表明該屬性定義了一種「非擁有關系」(nonowning relationship)。為這種屬性設置新值時，設置方法既不持有新值（新指向的對象），也不釋放舊值（原來指向的對象）。

runtime 對注冊的類，會進行內存布局，從一個粗粒度的概念上來講，這時候會有一個 hash 表，這是一個全局表，表中是用 weak 指向的對象內存地址作為 key，用所有指向該對象的 weak 指針表作為 value。當此對象的引用計數(shù)為 0 的時候會 dealloc，假如該對象內存地址是 a，那么就會以 a 為 key，在這個 weak 表中搜索，找到所有以 a 為鍵的 weak 對象，從而設置為 nil。

runtime 如何實現(xiàn) weak 屬性具體流程大致分為 3 步：

1、初始化時：runtime 會調用 objc_initWeak 函數(shù)，初始化一個新的 weak 指針指向對象的地址。

2、添加引用時：objc_initWeak 函數(shù)會調用 objc_storeWeak() 函數(shù)，objc_storeWeak() 的作用是更新指針指向（指針可能原來指向著其他對象，這時候需要將該 weak 指針與舊對象解除綁定，會調用到 weak_unregister_no_lock），如果指針指向的新對象非空，則創(chuàng)建對應的弱引用表，將 weak 指針與新對象進行綁定，會調用到 weak_register_no_lock。在這個過程中，為了防止多線程中競爭沖突，會有一些鎖的操作。

3、釋放時：調用 clearDeallocating 函數(shù)，clearDeallocating 函數(shù)首先根據(jù)對象地址獲取所有 weak 指針地址的數(shù)組，然后遍歷這個數(shù)組把其中的數(shù)據(jù)設為 nil，最后把這個 entry 從 weak 表中刪除，最后清理對象的記錄

22.runtime如何通過selector找到對應的IMP地址？

每一個類對象中都一個對象方法列表（對象方法緩存）

類方法列表是存放在類對象中isa指針指向的元類對象中（類方法緩存）。

方法列表中每個方法結構體中記錄著方法的名稱,方法實現(xiàn),以及參數(shù)類型，其實selector本質就是方法名稱,通過這個方法名稱就可以在方法列表中找到對應的方法實現(xiàn)。

當我們發(fā)送一個消息給一個NSObject對象時，這條消息會在對象的類對象方法列表里查找。

當我們發(fā)送一個消息給一個類時，這條消息會在類的Meta Class對象的方法列表里查找。

23.怎么理解Objective-C是動態(tài)運行時語言

主要是將數(shù)據(jù)類型的確定由編譯時,推遲到了運行時 
簡單來說 運行時機制使我們直到運行時才去決定一個對象的類別 以及調用該類別對象指定方法
多態(tài): 不同對象以自己的方式響應相同的消息的能力叫做多態(tài)

24.對稱加密和非對稱加密的區(qū)別？

1、對稱加密又稱公開密鑰加密，加密和解密都會用到同一個密鑰，如果密鑰被攻擊者獲得，此時加密就失去了意義
常見的對稱加密算法有DES、3DES、AES、Blowfish、IDEA、RC5、RC6。
2、非對稱加密又稱共享密鑰加密，使用一對非對稱的密鑰，一把叫做私有密鑰，另一把叫做公有密鑰；公鑰加密只
能用私鑰來解密，私鑰加密只能用公鑰來解密。常見的公鑰加密算法有：RSA、ElGamal、背包算法、Rabin（RSA的特例）、
迪菲－赫爾曼密鑰交換協(xié)議中的公鑰加密算法、橢圓曲線加密算法）

25簡述 SSL 加密的過程用了哪些加密方法，為何這么作

SSL 加密，在過程中實際使用了 對稱加密 和 非對稱加密 的結合。主要的考慮是先使用 非對稱加密 進行連接，
這樣做是為了避免中間人攻擊秘鑰被劫持，但是 非對稱加密 的效率比較低。所以一旦建立了安全的連接之后，就
可以使用輕量的 對稱加密

26.iOS的簽名機制是怎么樣的

簽名機制：

先將應用內容通過摘要算法，得到摘要

再用私鑰對摘要進行加密得到密文

將源文本、密文、和私鑰對應的公鑰一并發(fā)布

驗證流程：

查看公鑰是否是私鑰方的

然后用公鑰對密文進行解密得到摘要

將APP用同樣的摘要算法得到摘要，兩個摘要進行比對，如果相等那么一切正常