4月10號跟公司提了辭職。說好不會立馬走，留一兩個月的緩沖期給公司。這樣一來，立馬辭職投簡歷找工作的計劃也就擱淺了。那么就趁這段時間，把自己已經(jīng)忘掉的基礎(chǔ)知識重新?lián)炱饋恚購?fù)習(xí)一下，整理成文檔以供自己查看吧。這些知識點是從網(wǎng)上各個地方看到的，非原創(chuàng)，僅是總結(jié)。

1.TCP和UDP的區(qū)別于聯(lián)系

TCP為傳輸控制層協(xié)議，為面向連接、可靠的、點到點的通信；

UDP為用戶數(shù)據(jù)報協(xié)議，非連接的不可靠的點到多點的通信；

TCP側(cè)重可靠傳輸，UDP側(cè)重快速傳輸。

2.TCP連接的三次握手

第一次握手：客戶端發(fā)送syn包（syn=j）到服務(wù)器，并進入SYN_SEND狀態(tài)，等待服務(wù)器確認；

第二次握手：服務(wù)器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發(fā)送一個SYN包，即SYN+ACK包，此時服務(wù)器進入SYN+RECV狀態(tài)；

第三次握手：客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認包ACK（ack=k+1），此發(fā)送完畢，客戶端和服務(wù)器進入ESTABLISHED狀態(tài)，完成三次狀態(tài)。

3.Scoket連接和HTTP連接的區(qū)別

1.HTTP協(xié)議是基于TCP連接的，是應(yīng)用層協(xié)議，主要解決如何包裝數(shù)據(jù)。Socket是對TCP/IP協(xié)議的封裝，Socket本身并不是協(xié)議，而是一個調(diào)用接口（API），通過Socket，我們才能使用TCP/IP協(xié)議。

2.HTTP連接：短連接，客戶端向服務(wù)器發(fā)送一次請求，服務(wù)器響應(yīng)后連接斷開，節(jié)省資源。服務(wù)器不能主動給客戶端響應(yīng)（除非采用HTTP長連接技術(shù)），iPhone主要使用類NSURLConnection。

3.Socket連接：長連接，客戶端跟服務(wù)器端直接使用Socket進行連接，沒有規(guī)定連接后斷開，因此客戶端和服務(wù)器段保持連接通道，雙方可以主動發(fā)送數(shù)據(jù)，一般多用于游戲.Socket默認連接超時時間是30秒，默認大小是8K（理解為一個數(shù)據(jù)包大小）。

4.HTTP協(xié)議的特點，關(guān)于HTTP請求GET和POST的區(qū)別

GET和POST的區(qū)別：

HTTP超文本傳輸協(xié)議，是短連接，是客戶端主動發(fā)送請求，服務(wù)器做出響應(yīng)，服務(wù)器響應(yīng)之后，鏈接斷開。HTTP是一個屬于應(yīng)用層面向?qū)ο蟮膮f(xié)議，HTTP有兩類報文：請求報文和響應(yīng)報文。

HTTP請求報文：一個HTTP請求報文由請求行、請求頭部、空行和請求數(shù)據(jù)4部分組成。

HTTP響應(yīng)報文：由三部分組成：狀態(tài)行、消息報頭、響應(yīng)正文。

GET請求：參數(shù)在地址后拼接，沒有請求數(shù)據(jù)，不安全（因為所有參數(shù)都拼接在地址后面），不適合傳輸大量數(shù)據(jù)（長度有限制，為1024個字節(jié)）。

GET提交、請求的數(shù)據(jù)會附在URL之后，即把數(shù)據(jù)放置在HTTP協(xié)議頭中。

以？分割URL和傳輸數(shù)據(jù)，多個參數(shù)用&連接。如果數(shù)據(jù)是英文字母或數(shù)字，原樣發(fā)送，

如果是空格，轉(zhuǎn)換為+，如果是中文/其他字符，則直接把字符串用BASE64加密。

POST請求：參數(shù)在請求數(shù)據(jù)區(qū)放著，相對GET請求更安全，并且數(shù)據(jù)大小沒有限制。把提交的數(shù)據(jù)放置在HTTP包的包體中.

GET提交的數(shù)據(jù)會在地址欄顯示出來，而POST提交，地址欄不會改變。

傳輸數(shù)據(jù)的大小：

GET提交時，傳輸數(shù)據(jù)就會受到URL長度限制，POST由于不是通過URL傳值，理論上書不受限。

安全性：

POST的安全性要比GET的安全性高；

通過GET提交數(shù)據(jù)，用戶名和密碼將明文出現(xiàn)在URL上，比如登陸界面有可能被瀏覽器緩存。

HTTPS：安全超文本傳輸協(xié)議（Secure Hypertext Transfer Protocol），它是一個安全通信通道，基于HTTP開發(fā)，用于客戶計算機和服務(wù)器之間交換信息，使用安全套結(jié)字層（SSI）進行信息交換，即HTTP的安全版。

5.ASIHttpRequest、AFNetWorking之間的區(qū)別

ASIHttpRequest功能強大，主要是在MRC下實現(xiàn)的，是對系統(tǒng)CFNetwork API進行了封裝，支持HTTP協(xié)議的CFHTTP，配置比較復(fù)雜，并且ASIHttpRequest框架默認不會幫你監(jiān)聽網(wǎng)絡(luò)改變，如果需要讓ASIHttpRequest幫你監(jiān)聽網(wǎng)絡(luò)狀態(tài)改變，并且手動開始這個功能。

AFNetWorking構(gòu)建于NSURLConnection、NSOperation以及其他熟悉的Foundation技術(shù)之上。擁有良好的架構(gòu)，豐富的API及模塊構(gòu)建方式，使用起來非常輕松。它基于NSOperation封裝的，AFURLConnectionOperation子類。

ASIHttpRequest是直接操作對象ASIHttpRequest是一個實現(xiàn)了NSCoding協(xié)議的NSOperation子類；AFNetWorking直接操作對象的AFHttpClient，是一個實現(xiàn)NSCoding和NSCopying協(xié)議的NSObject子類。

同步請求：ASIHttpRequest直接通過調(diào)用一個startSynchronous方法；AFNetWorking默認沒有封裝同步請求，如果開發(fā)者需要使用同步請求，則需要重寫getPath:paraments:success:failures方法，對于AFHttpRequestOperation進行同步處理。

性能對比：AFNetworking請求優(yōu)于ASIHttpRequest；

6.XML數(shù)據(jù)解析方式各有什么不同，JSON解析有哪些框架？

1.XML數(shù)據(jù)解析的兩種解析方式：DOM解析和SAX解析；

2.DOM解析必須完成DOM樹的構(gòu)造，在處理規(guī)模較大的XML文檔時就很耗內(nèi)存，占用資源較多，讀入整個XML文檔并構(gòu)建一個駐留內(nèi)存的樹結(jié)構(gòu)（節(jié)點樹），通過遍歷樹結(jié)構(gòu)可以檢索任意XML節(jié)點，讀取它的屬性和值，通常情況下，可以借助XPath查詢XML節(jié)點；

3.SAX與DOM不同，它是事件驅(qū)動模型，解析XML文檔時每遇到一個開始或者結(jié)束標(biāo)簽、屬性或者一條指令時，程序就產(chǎn)生一個事件進行相應(yīng)的處理，一邊讀取XML文檔一邊處理，不必等整個文檔加載完才采取措施，當(dāng)在讀取解析過程中遇到需要處理的對象，會發(fā)出通知進行處理。因此，SAX相對于DOM來說更適合操作大的XML文檔。

4.JSON解析：性能比較好的主要是第三方的JSONKIT和iOS自帶的JSON解析類，其中自帶的JSON解析性能最高，但只能用于iOS5之后。

6.SVN的使用

SVN=版本控制+備份服務(wù)器，可以把SVN當(dāng)成備份服務(wù)器，并且可以幫助你記住每次上服務(wù)器的檔案內(nèi)容，并自動賦予每次變更的版本；

SVN的版本控制：所有上傳版本都會幫您記錄下來，也有版本分支及合并等功能。SVN可以讓不同的開發(fā)者存取同樣的檔案，并且利用SVN Server作為檔案同步的機制，即您有檔案更新時，無需將檔案寄送給您的開發(fā)成員。SVN的存放檔案方式是采用差異備份的方式，即會備份到不同的地方，節(jié)省硬盤空間，也可以對非文字文件進行差異備份。

SVN的重要性：備份工作檔案的重要性、版本控管的重要性、伙伴間的數(shù)據(jù)同步的重要性、備份不同版本是很耗費硬盤空間的；

防止沖突：

1.防止代碼沖突：不要多人同時修改同一文件，例如：A、B都修改同一個文件，先讓A修改，然后提交到服務(wù)器，然后B更新下來，再進行修改；

2.服務(wù)器上的項目文件Xcodeproj，僅讓一個人管理提交，其他人只更新，防止文件發(fā)生沖突。

7.如何進行網(wǎng)絡(luò)消息推送

1.一種是Apple自己提供的通知服務(wù)（APNS服務(wù)器）、一種是用第三方推送機制。

2.首先應(yīng)用發(fā)送通知，系統(tǒng)彈出提示框詢問用戶是否允許，當(dāng)用戶允許后向蘋果服務(wù)器(APNS)請求deviceToken，并由蘋果服務(wù)器發(fā)送給自己的應(yīng)用，自己的應(yīng)用將DeviceToken發(fā)送自己的服務(wù)器，自己服務(wù)器想要發(fā)送網(wǎng)絡(luò)推送時將deviceToken以及想要推送的信息發(fā)送給蘋果服務(wù)器，蘋果服務(wù)器將信息發(fā)送給應(yīng)用。

3.推送信息內(nèi)容，總?cè)萘坎怀^256個字節(jié)；

4.iOS SDK本身提供的APNS服務(wù)器推送，它可以直接推送給目標(biāo)用戶并根據(jù)您的方式彈出提示。

5.優(yōu)點：不論應(yīng)用是否開啟，都會發(fā)送到手機端；

6.缺點：消息推送機制是蘋果服務(wù)端控制，個別時候可能會有延遲，因為蘋果服務(wù)器也有隊列來處理所有的消息請求；

7.第三方推送機制，普遍使用Socket機制來實現(xiàn)，幾乎可以達到即時的發(fā)送到目標(biāo)用戶手機端，適用于即時通訊類應(yīng)用。

8.優(yōu)點：實時的，取決于心跳包的節(jié)奏；

9.缺點：iOS系統(tǒng)的限制，應(yīng)用不能長時間的后臺運行，所以應(yīng)用關(guān)閉的情況下這種推送機制不可用。

8.對NSUserDefaults的理解

NSUserDefaults：系統(tǒng)提供的一種存儲數(shù)據(jù)的方式，主要用于保存少量的數(shù)據(jù)，默認存儲到library下的Preferences文件夾。

9.SDWebImage原理

調(diào)用類別的方法：

從內(nèi)存中（字典）找圖片（當(dāng)這個圖片在本次程序加載過），找到直接使用；

從沙盒中找，找到直接使用，緩存到內(nèi)存。

從網(wǎng)絡(luò)上獲取，使用，緩存到內(nèi)存，緩存到沙盒。

10.OC中是否有二維數(shù)組，如何實現(xiàn)二維數(shù)組？

OC中沒有二維數(shù)組，可通過嵌套數(shù)組實現(xiàn)二維數(shù)組。

11.LayoutSubViews在什么時候被調(diào)用？

當(dāng)View本身的frame改變時，會調(diào)用這個方法。

12.單例模式理解與使用

單例模式是一種常用設(shè)計模式，單例模式是一個類在系統(tǒng)中只有一個實例對象。通過全局的一個入口點對這個實例對象進行訪問；

iOS中單例模式的實現(xiàn)方式一般分為兩種：非ARC和ARC+GCD。

13.對沙盒的理解

每個iOS應(yīng)用都被限制在“沙盒”中，沙盒相當(dāng)于一個加了僅主人可見權(quán)限的文件夾，及時在應(yīng)用程序安裝過程中，系統(tǒng)為每個單獨的應(yīng)用程序生成它的主目錄和一些關(guān)鍵的子目錄。蘋果對沙盒有幾條限制:

1.應(yīng)用程序在自己的沙盒中運作，但是不能訪問任何其他應(yīng)用程序的沙盒；

2.應(yīng)用之間不能共享數(shù)據(jù)，沙盒里的文件不能被復(fù)制到其他應(yīng)用程序的文件夾中，也不能把其他應(yīng)用文件夾復(fù)制到沙盒中；

3.蘋果禁止任何讀寫沙盒以外的文件，禁止應(yīng)用程序?qū)?nèi)容寫到沙盒以外的文件夾中；

4.沙盒目錄里有三個文件夾：Documents——存儲；應(yīng)用程序的數(shù)據(jù)文件，存儲用戶數(shù)據(jù)或其他定期備份的信息；Library下有兩個文件夾，Caches存儲應(yīng)用程序再次啟動所需的信息，

Preferences包含應(yīng)用程序的偏好設(shè)置文件，不可在這更改偏好設(shè)置；temp存放臨時文件即應(yīng)用程序再次啟動不需要的文件。

獲取沙盒根目錄的方法，有幾種方法：用NSHomeDirectory獲取。

獲取Document路徑：NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,NSUserDomainMask,YES).

14.XIB與Storyboards的優(yōu)缺點

優(yōu)點：

XIB：在編譯前就提供了可視化界面，可以直接拖控件，也可以直接給控件添加約束，更直觀一些，而且類文件中就少了創(chuàng)建控件的代碼，確實簡化不少，通常每個XIB對應(yīng)一個類。

Storyboard：在編譯前提供了可視化界面，可拖控件，可加約束，在開發(fā)時比較直觀，而且一個storyboard可以有很多的界面，每個界面對應(yīng)一個類文件，通過storybard，可以直觀地看出整個App的結(jié)構(gòu)。

缺點：

XIB：需求變動時，需要修改XIB很大，有時候甚至需要重新添加約束，導(dǎo)致開發(fā)周期變長。XIB載入相比純代碼自然要慢一些。對于比較復(fù)雜邏輯控制不同狀態(tài)下顯示不同內(nèi)容時，使用XIB是比較困難的。當(dāng)多人團隊或者多團隊開發(fā)時，如果XIB文件被發(fā)動，極易導(dǎo)致沖突，而且解決沖突相對要困難很多。

Storyboard：需求變動時，需要修改storyboard上對應(yīng)的界面的約束，與XIB一樣可能要重新添加約束，或者添加約束會造成大量的沖突，尤其是多團隊開發(fā)。對于復(fù)雜邏輯控制不同顯示內(nèi)容時，比較困難。當(dāng)多人團隊或者多團隊開發(fā)時，大家會同時修改一個storyboard，導(dǎo)致大量沖突，解決起來相當(dāng)困難。

15.隊列和多線程的使用原理

在iOS中隊列分為以下幾種：

串行隊列：隊列中的任務(wù)只會順序執(zhí)行；

dispatch_queue_t q = dispatch_queue_create("...", DISPATCH_QUEUE_SERIAL);

并行隊列： 隊列中的任務(wù)通常會并發(fā)執(zhí)行；

dispatch_queue_t q = dispatch_queue_create("......",DISPATCH_QUEUE_CONCURRENT);

全局隊列：是系統(tǒng)的，直接拿過來（GET）用就可以；與并行隊列類似；

dispatch_queue_t q = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

主隊列：每一個應(yīng)用程序?qū)?yīng)唯一主隊列，直接GET即可；在多線程開發(fā)中，使用主隊列更新UI；

dispatch_queue_t q = dispatch_get_main_queue();

15.屬性readwrite，readonly，assign，retain，copy，nonatomic 各是什么作用，在那種情況下用?

(1) readwrite 是可讀可寫特性;需要生成getter方法和setter方法時

(2) readonly 是只讀特性 只會生成getter方法 不會生成setter方法 ;不希望屬性在類外改變

(3) assign 是賦值特性，setter方法將傳入?yún)?shù)賦值給實例變量;僅設(shè)置變量時;

(4) retain 表示持有特性，setter方法將傳入?yún)?shù)先保留，再賦值，傳入?yún)?shù)的retaincount會+1;

(5) copy 表示賦值特性，setter方法將傳入對象復(fù)制一份;需要完全一份新的變量時。

(6) nonatomic 非原子操作，決定編譯器生成的setter getter是否是原子操作，atomic表示多線程安全，一般使用nonatomic

16.iOS應(yīng)用生命周期

應(yīng)用程序的狀態(tài)

Not running未運行：程序沒啟動。

Inactive未激活：程序在前臺運行，不過沒有接收到事件。在沒有事件處理情況下程序通常停留在這個狀態(tài)。

Active激活：程序在前臺運行而且接收到了事件。這也是前臺的一個正常的模式。

Backgroud后臺：程序在后臺而且能執(zhí)行代碼，大多數(shù)程序進入這個狀態(tài)后會在在這個狀態(tài)上停留一會。時間到之后會進入掛起狀態(tài)(Suspended)。有的程序經(jīng)過特殊的請求后可以長期處于Backgroud狀態(tài)。

Suspended掛起：程序在后臺不能執(zhí)行代碼。系統(tǒng)會自動把程序變成這個狀態(tài)而且不會發(fā)出通知。當(dāng)掛起時，程序還是停留在內(nèi)存中的，當(dāng)系統(tǒng)內(nèi)存低時，系統(tǒng)就把掛起的程序清除掉，為前臺程序提供更多的內(nèi)存。

1、application didFinishLaunchingWithOptions：當(dāng)應(yīng)用程序啟動時執(zhí)行，應(yīng)用程序啟動入口，只在應(yīng)用程序啟動時執(zhí)行一次。若用戶直接啟動，lauchOptions內(nèi)無數(shù)據(jù),若通過其他方式啟動應(yīng)用，lauchOptions包含對應(yīng)方式的內(nèi)容。

2、applicationWillResignActive：在應(yīng)用程序?qū)⒁苫顒訝顟B(tài)切換到非活動狀態(tài)時候，要執(zhí)行的委托調(diào)用，如 按下 home 按鈕，返回主屏幕，或全屏之間切換應(yīng)用程序等。

3、applicationDidEnterBackground：在應(yīng)用程序已進入后臺程序時，要執(zhí)行的委托調(diào)用。

4、applicationWillEnterForeground：在應(yīng)用程序?qū)⒁M入前臺時(被激活)，要執(zhí)行的委托調(diào)用，剛好與applicationWillResignActive 方法相對應(yīng)。

5、applicationDidBecomeActive：在應(yīng)用程序已被激活后，要執(zhí)行的委托調(diào)用，剛好與applicationDidEnterBackground 方法相對應(yīng)。

6、applicationWillTerminate：在應(yīng)用程序要完全推出的時候，要執(zhí)行的委托調(diào)用，這個需要要設(shè)置UIApplicationExitsOnSuspend的鍵值。

初次啟動：

iOS_didFinishLaunchingWithOptions

iOS_applicationDidBecomeActive

按下home鍵：

iOS_applicationWillResignActive

iOS_applicationDidEnterBackground

點擊程序圖標(biāo)進入：

iOS_applicationWillEnterForeground

iOS_applicationDidBecomeActive

當(dāng)應(yīng)用程序進入后臺時,應(yīng)該保存用戶數(shù)據(jù)或狀態(tài)信息，所有沒寫到磁盤的文件或信息，在進入后臺時，最后都寫到磁盤去，因為程序可能在后臺被殺死。釋放盡可能釋放的內(nèi)存。

- (void)applicationDidEnterBackground:(UIApplication *)application

方法有大概5秒的時間讓你完成這些任務(wù)。如果超過時間還有未完成的任務(wù)，你的程序就會被終止而且從內(nèi)存中清除。

如果還需要長時間的運行任務(wù)，可以在該方法中調(diào)用

[application beginBackgroundTaskWithExpirationHandler:^{

NSLog(@"begin Background Task With Expiration Handler");

}];

程序終止

程序只要符合以下情況之一，只要進入后臺或掛起狀態(tài)就會終止：

①iOS4.0以前的系統(tǒng)

②app是基于iOS4.0之前系統(tǒng)開發(fā)的。

③設(shè)備不支持多任務(wù)

④在Info.plist文件中，程序包含了 UIApplicationExitsOnSuspend 鍵。

系統(tǒng)常常是為其他app啟動時由于內(nèi)存不足而回收內(nèi)存最后需要終止應(yīng)用程序，但有時也會是由于app很長時間才響應(yīng)而終止。如果app當(dāng)時運行在后臺并且沒有暫停，系統(tǒng)會在應(yīng)用程序終止之前調(diào)用app的代理的方法 - (void)applicationWillTerminate:(UIApplication *)application，這樣可以讓你可以做一些清理工作。你可以保存一些數(shù)據(jù)或app的狀態(tài)。這個方法也有5秒鐘的限制。超時后方法會返回程序從內(nèi)存中清除。

注意：用戶可以手工關(guān)閉應(yīng)用程序。