1.蘋果推送的原理
1.1由App向iOS設(shè)備發(fā)送一個注冊通知，用戶需要同意系統(tǒng)發(fā)送推送。
1.2iOS向APNs遠程推送服務(wù)器發(fā)送App的Bundle Id和設(shè)備的UDID。
1.3APNs根據(jù)設(shè)備的UDID和App的Bundle Id生成deviceToken再發(fā)回給App辐董。
1.4App再將deviceToken發(fā)送給遠程推送服務(wù)器(自己的服務(wù)器), 由服務(wù)器保存在數(shù)據(jù)庫中。
1.5當(dāng)自己的服務(wù)器想發(fā)送推送時, 在遠程推送服務(wù)器中輸入要發(fā)送的消息并選擇發(fā)給哪些用戶的deviceToken，由遠程推送服務(wù)器發(fā)送給APNs逝慧。
1.6APNs根據(jù)deviceToken發(fā)送給對應(yīng)的用戶昔脯。
原文地址:http://www.reibang.com/p/75161fc153cd
2.CALayer和UIView的區(qū)別
2.1每個 UIView 內(nèi)部都有一個 CALayer 在背后提供內(nèi)容的繪制和顯示，并且 UIView 的尺寸樣式都由內(nèi)部的 Layer 所提供笛臣。兩者都有樹狀層級結(jié)構(gòu)云稚，layer 內(nèi)部有 SubLayers，View 內(nèi)部有 SubViews.但是 Layer 比 View 多了個AnchorPoint
2.2在 View顯示的時候沈堡，UIView 做為 Layer 的 CALayerDelegate,View 的顯示內(nèi)容由內(nèi)部的 CALayer 的 display
2.3CALayer 是默認修改屬性支持隱式動畫的静陈，在給 UIView 的 Layer 做動畫的時候，View 作為 Layer 的代理诞丽，Layer? 通過 actionForLayer:forKey:向 View請求相應(yīng)的 action(動畫行為)
2.4layer 內(nèi)部維護著三分 layer tree,分別是 presentLayer Tree(動畫樹),modeLayer Tree(模型樹), Render Tree (渲染樹),在做 iOS動畫的時候鲸拥，我們修改動畫的屬性，在動畫的其實是 Layer 的 presentLayer的屬性值,而最終展示在界面上的其實是提供 View的modelLayer
2.5兩者最明顯的區(qū)別是 View可以接受并處理事件僧免，而 Layer 不可以
原文地址:http://www.reibang.com/p/079e5cf0f014
3.UI視圖之間的事件傳遞和響應(yīng)
3.1我們點擊屏幕產(chǎn)生觸摸事件刑赶，系統(tǒng)將這個事件加入到一個由UIApplication管理的事件隊列中，UIApplication會從消息隊列里取事件分發(fā)下去懂衩，首先傳給UIWindow
3.2在UIWindow中就會調(diào)用hitTest:withEvent:方法去返回一個最終響應(yīng)的視圖
3.3在hitTest:withEvent:方法中就回去調(diào)用pointInside: withEvent:去判斷當(dāng)前點擊的point是否在UIWindow范圍內(nèi)撞叨，如果是的話，就會去遍歷它的子視圖來查找最終響應(yīng)的子視圖
3.4遍歷的方式是使用倒序的方式來遍歷子視圖浊洞，也就是說最后添加的子視圖會最先遍歷牵敷，在每一個視圖中都回去調(diào)用它的hitTest:withEvent:方法，可以理解為是一個遞歸調(diào)用
3.5最終會返回一個響應(yīng)視圖法希，如果返回視圖有值枷餐，那么這個視圖就作為最終響應(yīng)視圖，結(jié)束整個事件傳遞铁材；如果沒有值尖淘，那么就會將UIWindow作為響應(yīng)者
原文地址：http://www.reibang.com/p/2c16077b50f8
4.tableView的優(yōu)化
4.1懶加載創(chuàng)建tebleview
4.2復(fù)用cell,設(shè)置唯一標(biāo)識符
4.3圖片圓角:a.直接讓美工把圖片切成圓角進行顯示，這是效率最高的一種方案;b.很多情況下用戶上傳圖片進行顯示著觉，可以讓服務(wù)端處理圓角;c.使用代碼手動生成圓角Image設(shè)置到要顯示的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盡量避免圖片透明,使用不透明視圖, 如非必要, 可以設(shè)置opaque為yes,用以減少復(fù)雜圖層合成
4.8cellForRowAtIndexPath不要做耗時操作,讀取文件/寫入文件,盡量不要去添加和移除view;
4.9盡量設(shè)置layer的大小值為整形值
4.10使用ShadowPath指定layer陰影效果路徑;當(dāng)我們需要圓角效果時，可以使用一張中間透明圖片蒙上去
5.iOS中如何使用socket
建立Socket連接至少需要一對套接字饼丘，分別運行于服務(wù)端（ServerSocket）和客戶端（ClientSocket）趁桃。套接字直接的連接過程氛圍三個步驟：5.1服務(wù)器監(jiān)聽:服務(wù)端Socket始終處于等待連接狀態(tài)，實時監(jiān)聽是否有客戶端請求連接肄鸽。5.2客戶端請求:客戶端Socket提出連接請求卫病，指定服務(wù)端Socket的地址和端口號，這時就可以向?qū)?yīng)的服務(wù)端提出Socket連接請求典徘。5.3連接確認:當(dāng)服務(wù)端Socket監(jiān)聽到客戶端Socket提出的連接請求時作出響應(yīng)蟀苛，建立一個新的進程，把服務(wù)端Socket的描述發(fā)送給客戶端逮诲，該描述得到客戶端確認后就可建立起Socket連接帜平。而服務(wù)端Socket則繼續(xù)處于監(jiān)聽狀態(tài)幽告，繼續(xù)接收其他客戶端Socket的請求。
原文地址:http://www.reibang.com/p/8e599ca5dfe8參考文章:http://www.reibang.com/p/cf30e90c8269
6.AFNetWorking的實現(xiàn)原理
在ios開發(fā)中裆甩，一般情況下冗锁，簡單的向某個web站點簡單的頁面提交請求并獲取服務(wù)器的響應(yīng)，用xcode自帶的NSURLConnection是能勝任的嗤栓。但是冻河，在絕大部分下我們所需要訪問的web頁面則是屬于那種受到權(quán)限保護的頁面，并不是有一個簡單的URL可以訪問的茉帅。這就涉及到了Session和Cookie的處理了叨叙，在此時使用NSURLConnection也是能夠達到要求的，只是其中處理起來的復(fù)雜度和難度就提升了担敌。 ?為了更好的處理向Web站點的請求摔敛，包括處理Session，Cookie等細節(jié)問題全封，使用AFNetworking則是更好的選擇，他可以用于發(fā)送HTTP請求桃犬，接收HTTP的響應(yīng)刹悴，但是不會緩存服務(wù)器的響應(yīng)，不能執(zhí)行HTML頁面中的JAvascript代碼,同時攒暇，AFNetworking還內(nèi)置支持JSON土匀，plist文件和XML文件的解析，使用比較方便形用。 擴展：1就轧、Session：中文有譯作時域的，就是只某個客戶端在訪問服務(wù)器起到停止訪問這一段的時間間隔被稱為時域田度。 2妒御、Cookie：由服務(wù)器發(fā)送給客服端，把Cookie的key：value值儲存在本地文件夾下镇饺，當(dāng)下次請求的時候能夠直接發(fā)送Cookie獲得權(quán)限驗證
原文地址:https://blog.csdn.net/lcg910978041/article/details/51485062
7.runtime的原理和作用
7.1原理:a.runtime是一套比較底層的純C語言API, 屬于1個C語言庫, 包含了很多底層的C語言API乎莉。在我們平時編寫的OC代碼中, 程序運行過程時, 其實最終都是轉(zhuǎn)成了runtime的C語言代碼, runtime算是OC的幕后工作者。b.RunTime簡稱運行時,就是系統(tǒng)在運行的時候的一些機制奸笤，其中最主要的是消息機制惋啃。c.對于C語言，函數(shù)的調(diào)用在編譯的時候會決定調(diào)用哪個函數(shù)监右，編譯完成之后直接順序執(zhí)行边灭，無任何二義性。d.OC的函數(shù)調(diào)用成為消息發(fā)送健盒。屬于動態(tài)調(diào)用過程绒瘦。在編譯的時候并不能決定真正調(diào)用哪個函數(shù)（事實證明称簿，在編 譯階段，OC可以調(diào)用任何函數(shù)椭坚，即使這個函數(shù)并未實現(xiàn)予跌，只要申明過就不會報錯。而C語言在編譯階段就會報錯)善茎。e.只有在真正運行的時候才會根據(jù)函數(shù)的名稱找到對應(yīng)的函數(shù)來調(diào)用券册。
7.2作用:a. 動態(tài)的添加對象的成員變量和方法,修改屬性值和方法b. 動態(tài)交換兩個方法的實現(xiàn)c. 實現(xiàn)分類也可以添加屬性d. 實現(xiàn)NSCoding的自動歸檔和解檔e. 實現(xiàn)字典轉(zhuǎn)模型的自動轉(zhuǎn)換f. 動態(tài)創(chuàng)建一個類(比如KVO的底層實現(xiàn))
原文地址:http://www.reibang.com/p/462b88edbe5c
8.MVC，MVP垂涯，MVVM設(shè)計模式區(qū)別及優(yōu)缺點
MVC優(yōu)點：a.耦合性低烁焙，視圖層和業(yè)務(wù)層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼耕赘。b.重用性高c.生命周期成本低d.MVC使開發(fā)和維護用戶接口的技術(shù)含量降低e.可維護性高骄蝇，分離視圖層和業(yè)務(wù)邏輯層也使得WEB應(yīng)用更易于維護和修改f.部署快
MVC缺點：a.不適合小型，中等規(guī)模的應(yīng)用程序操骡，花費大量時間將MVC應(yīng)用到規(guī)模并不是很大的應(yīng)用程序通常會得不償失九火。b.視圖與控制器間過于緊密連接，視圖與控制器是相互分離册招，但卻是聯(lián)系緊密的部件岔激，視圖沒有控制器的存在，其應(yīng)用是很有限的是掰，反之亦然虑鼎，這樣就妨礙了他們的獨立重用。c.視圖對模型數(shù)據(jù)的低效率訪問键痛，依據(jù)模型操作接口的不同炫彩，視圖可能需要多次調(diào)用才能獲得足夠的顯示數(shù)據(jù)。對未變化數(shù)據(jù)的不必要的頻繁訪問絮短，也將損害操作性能江兢。
MVP特點：a.M、V戚丸、P之間雙向通信划址。b.View 與 Model 不通信，都通過 Presenter 傳遞限府。Presenter完全把Model和View進行了分離夺颤，主要的程序邏輯在Presenter里實現(xiàn)。c.View 非常薄胁勺，不部署任何業(yè)務(wù)邏輯世澜，稱為”被動視圖”（Passive View），即沒有任何主動性署穗，而 Presenter非常厚寥裂，所有邏輯都部署在那里嵌洼。d.Presenter與具體的View是沒有直接關(guān)聯(lián)的，而是通過定義好的接口進行交互封恰，從而使得在變更View時候可以保持Presenter的不變麻养，這樣就可以重用。不僅如此诺舔，還可以編寫測試用的View鳖昌，模擬用戶的各種操作，從而實現(xiàn)對Presenter的測試–從而不需要使用自動化的測試工具低飒。
MVP優(yōu)點：a.模型與視圖完全分離许昨，我們可以修改視圖而不影響模型；b.可以更高效地使用模型褥赊，因為所有的交互都發(fā)生在一個地方——Presenter內(nèi)部糕档；c.我們可以將一個Presenter用于多個視圖，而不需要改變Presenter的邏輯拌喉。這個特性非常的有用速那，因為視圖的變化總是比模型的變化頻繁；d.如果我們把邏輯放在Presenter中尿背，那么我們就可以脫離用戶接口來測試這些邏輯（單元測試）琅坡。
MVP缺點：視圖和Presenter的交互會過于頻繁，使得他們的聯(lián)系過于緊密残家。也就是說，一旦視圖變更了售躁，presenter也要變更坞淮。
MVVM模式和MVC模式類似，主要目的是分離視圖（View）和模型（Model）陪捷，有幾大優(yōu)點：a.低耦合回窘，視圖（View）可以獨立于Model變化和修改，一個ViewModel可以綁定到不同的”View”上市袖，當(dāng)View變化的時候Model可以不變啡直，當(dāng)Model變化的時候View也可以不變。b.可重用性苍碟，可以把一些視圖邏輯放在一個ViewModel里面酒觅，讓很多view重用這段視圖邏輯。c.獨立開發(fā)微峰，開發(fā)人員可以專注于業(yè)務(wù)邏輯和數(shù)據(jù)的開發(fā)（ViewModel）舷丹，設(shè)計人員可以專注于頁面設(shè)計，使用Expression Blend可以很容易設(shè)計界面并生成xml代碼蜓肆。d.可測試颜凯，界面向來是比較難于測試的谋币，而現(xiàn)在測試可以針對ViewModel來寫。
原文地址:https://blog.csdn.net/weixin_34294649/article/details/86753644
