1.蘋果推送的原理

1.1由App向iOS設備發(fā)送一個注冊通知，用戶需要同意系統(tǒng)發(fā)送推送。

1.2iOS向APNs遠程推送服務器發(fā)送App的Bundle Id和設備的UDID。

1.3APNs根據(jù)設備的UDID和App的Bundle Id生成deviceToken再發(fā)回給App。

1.4App再將deviceToken發(fā)送給遠程推送服務器(自己的服務器), 由服務器保存在數(shù)據(jù)庫中。

1.5當自己的服務器想發(fā)送推送時, 在遠程推送服務器中輸入要發(fā)送的消息并選擇發(fā)給哪些用戶的deviceToken，由遠程推送服務器發(fā)送給APNs。

1.6APNs根據(jù)deviceToken發(fā)送給對應的用戶。

原文地址:http://www.itdecent.cn/p/75161fc153cd

2.CALayer和UIView的區(qū)別

2.1每個 UIView 內部都有一個 CALayer 在背后提供內容的繪制和顯示，并且 UIView 的尺寸樣式都由內部的 Layer 所提供。兩者都有樹狀層級結構，layer 內部有 SubLayers，View 內部有 SubViews.但是 Layer 比 View 多了個AnchorPoint

2.2在 View顯示的時候，UIView 做為 Layer 的 CALayerDelegate,View 的顯示內容由內部的 CALayer 的 display

2.3CALayer 是默認修改屬性支持隱式動畫的，在給 UIView 的 Layer 做動畫的時候，View 作為 Layer 的代理，Layer? 通過 actionForLayer:forKey:向 View請求相應的 action(動畫行為)

2.4layer 內部維護著三分 layer tree,分別是 presentLayer Tree(動畫樹),modeLayer Tree(模型樹), Render Tree (渲染樹),在做 iOS動畫的時候，我們修改動畫的屬性，在動畫的其實是 Layer 的 presentLayer的屬性值,而最終展示在界面上的其實是提供 View的modelLayer

2.5兩者最明顯的區(qū)別是 View可以接受并處理事件，而 Layer 不可以

原文地址:http://www.itdecent.cn/p/079e5cf0f014

3.UI視圖之間的事件傳遞和響應

3.1我們點擊屏幕產(chǎn)生觸摸事件，系統(tǒng)將這個事件加入到一個由UIApplication管理的事件隊列中，UIApplication會從消息隊列里取事件分發(fā)下去，首先傳給UIWindow

3.2在UIWindow中就會調用hitTest:withEvent:方法去返回一個最終響應的視圖

3.3在hitTest:withEvent:方法中就回去調用pointInside: withEvent:去判斷當前點擊的point是否在UIWindow范圍內，如果是的話，就會去遍歷它的子視圖來查找最終響應的子視圖

3.4遍歷的方式是使用倒序的方式來遍歷子視圖，也就是說最后添加的子視圖會最先遍歷，在每一個視圖中都回去調用它的hitTest:withEvent:方法，可以理解為是一個遞歸調用

3.5最終會返回一個響應視圖，如果返回視圖有值，那么這個視圖就作為最終響應視圖，結束整個事件傳遞；如果沒有值，那么就會將UIWindow作為響應者

原文地址：http://www.itdecent.cn/p/2c16077b50f8

4.tableView的優(yōu)化

4.1懶加載創(chuàng)建tebleview

4.2復用cell,設置唯一標識符

4.3圖片圓角:a.直接讓美工把圖片切成圓角進行顯示，這是效率最高的一種方案;b.很多情況下用戶上傳圖片進行顯示，可以讓服務端處理圓角;c.使用代碼手動生成圓角Image設置到要顯示的View上，利用UIBezierPath（CoreGraphics框架）畫出來圓角圖片

4.4避免快速滑動,開啟過多線程

4.5異步加載圖片[imageView sd_setImageWithURL:url completed:^(UIImage*image,NSError*error, SDImageCacheType cacheType,NSURL*imageURL) {imageView.image = image;}];

4.6優(yōu)化cell高度,將高度提前計算好存入Model中

4.7盡量避免圖片透明,使用不透明視圖, 如非必要, 可以設置opaque為yes,用以減少復雜圖層合成

4.8cellForRowAtIndexPath不要做耗時操作,讀取文件/寫入文件,盡量不要去添加和移除view;

4.9盡量設置layer的大小值為整形值

4.10使用ShadowPath指定layer陰影效果路徑;當我們需要圓角效果時，可以使用一張中間透明圖片蒙上去

5.iOS中如何使用socket

建立Socket連接至少需要一對套接字，分別運行于服務端（ServerSocket）和客戶端（ClientSocket）。套接字直接的連接過程氛圍三個步驟：5.1服務器監(jiān)聽:服務端Socket始終處于等待連接狀態(tài)，實時監(jiān)聽是否有客戶端請求連接。5.2客戶端請求:客戶端Socket提出連接請求，指定服務端Socket的地址和端口號，這時就可以向對應的服務端提出Socket連接請求。5.3連接確認:當服務端Socket監(jiān)聽到客戶端Socket提出的連接請求時作出響應，建立一個新的進程，把服務端Socket的描述發(fā)送給客戶端，該描述得到客戶端確認后就可建立起Socket連接。而服務端Socket則繼續(xù)處于監(jiān)聽狀態(tài)，繼續(xù)接收其他客戶端Socket的請求。

原文地址:http://www.itdecent.cn/p/8e599ca5dfe8參考文章:http://www.itdecent.cn/p/cf30e90c8269

6.AFNetWorking的實現(xiàn)原理

在ios開發(fā)中，一般情況下，簡單的向某個web站點簡單的頁面提交請求并獲取服務器的響應，用xcode自帶的NSURLConnection是能勝任的。但是，在絕大部分下我們所需要訪問的web頁面則是屬于那種受到權限保護的頁面，并不是有一個簡單的URL可以訪問的。這就涉及到了Session和Cookie的處理了，在此時使用NSURLConnection也是能夠達到要求的，只是其中處理起來的復雜度和難度就提升了。 ?為了更好的處理向Web站點的請求，包括處理Session，Cookie等細節(jié)問題，使用AFNetworking則是更好的選擇，他可以用于發(fā)送HTTP請求，接收HTTP的響應，但是不會緩存服務器的響應，不能執(zhí)行HTML頁面中的JAvascript代碼,同時，AFNetworking還內置支持JSON，plist文件和XML文件的解析，使用比較方便。 擴展：1、Session：中文有譯作時域的，就是只某個客戶端在訪問服務器起到停止訪問這一段的時間間隔被稱為時域。 2、Cookie：由服務器發(fā)送給客服端，把Cookie的key：value值儲存在本地文件夾下，當下次請求的時候能夠直接發(fā)送Cookie獲得權限驗證

原文地址:https://blog.csdn.net/lcg910978041/article/details/51485062

7.runtime的原理和作用

7.1原理:a.runtime是一套比較底層的純C語言API, 屬于1個C語言庫, 包含了很多底層的C語言API。在我們平時編寫的OC代碼中, 程序運行過程時, 其實最終都是轉成了runtime的C語言代碼, runtime算是OC的幕后工作者。b.RunTime簡稱運行時,就是系統(tǒng)在運行的時候的一些機制，其中最主要的是消息機制。c.對于C語言，函數(shù)的調用在編譯的時候會決定調用哪個函數(shù)，編譯完成之后直接順序執(zhí)行，無任何二義性。d.OC的函數(shù)調用成為消息發(fā)送。屬于動態(tài)調用過程。在編譯的時候并不能決定真正調用哪個函數(shù)（事實證明，在編 譯階段，OC可以調用任何函數(shù)，即使這個函數(shù)并未實現(xiàn)，只要申明過就不會報錯。而C語言在編譯階段就會報錯)。e.只有在真正運行的時候才會根據(jù)函數(shù)的名稱找到對應的函數(shù)來調用。

7.2作用:a. 動態(tài)的添加對象的成員變量和方法,修改屬性值和方法b. 動態(tài)交換兩個方法的實現(xiàn)c. 實現(xiàn)分類也可以添加屬性d. 實現(xiàn)NSCoding的自動歸檔和解檔e. 實現(xiàn)字典轉模型的自動轉換f. 動態(tài)創(chuàng)建一個類(比如KVO的底層實現(xiàn))

原文地址:http://www.itdecent.cn/p/462b88edbe5c

8.MVC，MVP，MVVM設計模式區(qū)別及優(yōu)缺點

MVC優(yōu)點：a.耦合性低，視圖層和業(yè)務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼。b.重用性高c.生命周期成本低d.MVC使開發(fā)和維護用戶接口的技術含量降低e.可維護性高，分離視圖層和業(yè)務邏輯層也使得WEB應用更易于維護和修改f.部署快

MVC缺點：a.不適合小型，中等規(guī)模的應用程序，花費大量時間將MVC應用到規(guī)模并不是很大的應用程序通常會得不償失。b.視圖與控制器間過于緊密連接，視圖與控制器是相互分離，但卻是聯(lián)系緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。c.視圖對模型數(shù)據(jù)的低效率訪問，依據(jù)模型操作接口的不同，視圖可能需要多次調用才能獲得足夠的顯示數(shù)據(jù)。對未變化數(shù)據(jù)的不必要的頻繁訪問，也將損害操作性能。

MVP特點：a.M、V、P之間雙向通信。b.View 與 Model 不通信，都通過 Presenter 傳遞。Presenter完全把Model和View進行了分離，主要的程序邏輯在Presenter里實現(xiàn)。c.View 非常薄，不部署任何業(yè)務邏輯，稱為”被動視圖”（Passive View），即沒有任何主動性，而 Presenter非常厚，所有邏輯都部署在那里。d.Presenter與具體的View是沒有直接關聯(lián)的，而是通過定義好的接口進行交互，從而使得在變更View時候可以保持Presenter的不變，這樣就可以重用。不僅如此，還可以編寫測試用的View，模擬用戶的各種操作，從而實現(xiàn)對Presenter的測試–從而不需要使用自動化的測試工具。

MVP優(yōu)點：a.模型與視圖完全分離，我們可以修改視圖而不影響模型；b.可以更高效地使用模型，因為所有的交互都發(fā)生在一個地方——Presenter內部；c.我們可以將一個Presenter用于多個視圖，而不需要改變Presenter的邏輯。這個特性非常的有用，因為視圖的變化總是比模型的變化頻繁；d.如果我們把邏輯放在Presenter中，那么我們就可以脫離用戶接口來測試這些邏輯（單元測試）。

MVP缺點：視圖和Presenter的交互會過于頻繁，使得他們的聯(lián)系過于緊密。也就是說，一旦視圖變更了，presenter也要變更。

MVVM模式和MVC模式類似，主要目的是分離視圖（View）和模型（Model），有幾大優(yōu)點：a.低耦合，視圖（View）可以獨立于Model變化和修改，一個ViewModel可以綁定到不同的”View”上，當View變化的時候Model可以不變，當Model變化的時候View也可以不變。b.可重用性，可以把一些視圖邏輯放在一個ViewModel里面，讓很多view重用這段視圖邏輯。c.獨立開發(fā)，開發(fā)人員可以專注于業(yè)務邏輯和數(shù)據(jù)的開發(fā)（ViewModel），設計人員可以專注于頁面設計，使用Expression Blend可以很容易設計界面并生成xml代碼。d.可測試，界面向來是比較難于測試的，而現(xiàn)在測試可以針對ViewModel來寫。

原文地址:https://blog.csdn.net/weixin_34294649/article/details/86753644