阿里-p6-一面

1.介紹下內(nèi)存的幾大區(qū)域擦耀？

2.你是如何組件化解耦的？

3.runtime如何通過selector找到對應(yīng)的IMP地址

4.runloop內(nèi)部實現(xiàn)邏輯畜伐？

5.你理解的多線程？

6.GCD執(zhí)行原理？

7.怎么防止別人反編譯你的app敷鸦？

8.YYAsyncLayer如何異步繪制？

9.優(yōu)化你是從哪幾方面著手？

1.介紹下內(nèi)存的幾大區(qū)域扒披？

1.棧區(qū)(stack) 由編譯器自動分配并釋放值依，存放函數(shù)的參數(shù)值，局部變量等碟案。棧是系統(tǒng)數(shù)據(jù)結(jié)構(gòu)愿险，對應(yīng)線程/進程是唯一的。優(yōu)點是快速高效价说，缺點時有限制辆亏，數(shù)據(jù)不靈活。［先進后出］

棻钅浚空間分靜態(tài)分配 和動態(tài)分配兩種扮叨。

堆區(qū)(heap) 由程序員分配和釋放，如果程序員不釋放领迈，程序結(jié)束時彻磁，可能會由操作系統(tǒng)回收 ，比如在ios 中 alloc 都是存放在堆中狸捅。

優(yōu)點是靈活方便衷蜓，數(shù)據(jù)適應(yīng)面廣泛，但是效率有一定降低尘喝。

雖然程序結(jié)束時所有的數(shù)據(jù)空間都會被釋放回系統(tǒng)磁浇，但是精確的申請內(nèi)存，釋放內(nèi)存匹配是良好程序的基本要素瞧省。

3.全局區(qū)(靜態(tài)區(qū)) (static) 全局變量和靜態(tài)變量的存儲是放在一起的扯夭，初始化的全局變量和靜態(tài)變量存放在一塊區(qū)域，未初始化的全局變量和靜態(tài)變量在相鄰的另一塊區(qū)域鞍匾，程序結(jié)束后有系統(tǒng)釋放交洗。

4.文字常量區(qū) 存放常量字符串，程序結(jié)束后由系統(tǒng)釋放橡淑；

5.代碼區(qū) 存放函數(shù)的二進制代碼

大致如圖：

例子代碼：

可能被追問的問題一：

1.棧區(qū) (stack [st?k]): 由編譯器自動分配釋放

局部變量是保存在棧區(qū)的

方法調(diào)用的實參也是保存在棧區(qū)的

2.堆區(qū) (heap [hi?p]): 由程序員分配釋放构拳，若程序員不釋放，會出現(xiàn)內(nèi)存泄漏梁棠，賦值語句右側(cè) 使用 new 方法創(chuàng)建的對象置森，被創(chuàng)建對象的所有 成員變量！

3.BSS 段 : 程序結(jié)束后由系統(tǒng)釋放

4.數(shù)據(jù)段 : 程序結(jié)束后由系統(tǒng)釋放

5.代碼段:程序結(jié)束后由系統(tǒng)釋放

程序編譯鏈接 后的二進制可執(zhí)行代碼

可能被追問的問題二：

比如申請后的系統(tǒng)是如何響應(yīng)的符糊？

棧：存儲每一個函數(shù)在執(zhí)行的時候都會向操作系統(tǒng)索要資源凫海，棧區(qū)就是函數(shù)運行時的內(nèi)存，棧區(qū)中的變量由編譯器負責(zé)分配和釋放男娄，內(nèi)存隨著函數(shù)的運行分配行贪，隨著函數(shù)的結(jié)束而釋放漾稀，由系統(tǒng)自動完成。

注意：只要棧的剩余空間大于所申請空間建瘫，系統(tǒng)將為程序提供內(nèi)存崭捍，否則將報異常提示棧溢出。

堆：

1.首先應(yīng)該知道操作系統(tǒng)有一個記錄空閑內(nèi)存地址的鏈表啰脚。

2.當系統(tǒng)收到程序的申請時殷蛇，會遍歷該鏈表，尋找第一個空間大于所申請空間的堆結(jié)點橄浓，然后將該結(jié)點從空閑結(jié)點鏈表中刪除粒梦，并將該結(jié)點的空間分配給程序。

3 .由于找到的堆結(jié)點的大小不一定正好等于申請的大小贮配，系統(tǒng)會自動的將多余的那部分重新放入空閑鏈表中

可能被追問的問題三：

比如：申請大小的限制是怎樣的谍倦？

棧：棧是向低地址擴展的數(shù)據(jù)結(jié)構(gòu)，是一塊連續(xù)的內(nèi)存的區(qū)域泪勒。是棧頂?shù)牡刂泛蜅５淖畲笕萘渴窍到y(tǒng)預(yù)先規(guī)定好的昼蛀，棧的大小是2M（也有的說是1M，總之是一個編譯時就確定的常數(shù) ) ,如果申請的空間超過棧的剩余空間時圆存，將提示overflow叼旋。因此，能從棧獲得的空間較小沦辙。

堆：堆是向高地址擴展的數(shù)據(jù)結(jié)構(gòu)夫植，是不連續(xù)的內(nèi)存區(qū)域。這是由于系統(tǒng)是用鏈表來存儲的空閑內(nèi)存地址的油讯，自然是不連續(xù)的详民，而鏈表的遍歷方向是由低地址向高地址。堆的大小受限于計算機系統(tǒng)中有效的虛擬內(nèi)存陌兑。由此可見沈跨，堆獲得的空間比較靈活，也比較大兔综。

棧：由系統(tǒng)自動分配饿凛，速度較快，不會產(chǎn)生內(nèi)存碎片

堆：是由alloc分配的內(nèi)存软驰，速度比較慢涧窒，而且容易產(chǎn)生內(nèi)存碎片，不過用起來最方便

打個比喻來說：

使用棧就象我們?nèi)ワ堭^里吃飯锭亏，只管點菜（發(fā)出申請）纠吴、付錢、和吃（使用）慧瘤，吃飽了就走呜象，不必理會切菜膳凝、洗菜等準備工作和洗碗、刷鍋等掃尾工作恭陡，他的好處是快捷，但是自由度小上煤。

使用堆就象是自己動手做喜歡吃的菜肴休玩，比較麻煩，但是比較符合自己的口味劫狠，而且自由度大拴疤。

2.你是如何組件化解耦的？

實現(xiàn)代碼的高內(nèi)聚低耦合独泞，方便多人多團隊開發(fā)呐矾！

一般需要解耦的項目都會多多少少出現(xiàn)，一下幾個情況：

耦合比較嚴重（因為沒有明確的約束懦砂，「組件」間引用的現(xiàn)象會比較多）

2.容易出現(xiàn)沖突（尤其是使用 Xib蜒犯，還有就是 Xcode Project，雖說有腳本可以改善）

3.業(yè)務(wù)方的開發(fā)效率不夠高（只關(guān)心自己的組件荞膘，卻要編譯整個項目罚随，與其他不相干的代碼糅合在一起）

先來看下，組件化之后的一個大概架構(gòu)

「組件化」顧名思義就是把一個大的 App 拆成一個個小的組件羽资，相互之間不直接引用淘菩。那如何做呢？

組件間通信

以 iOS 為例屠升，由于之前就是采用的 URL 跳轉(zhuǎn)模式潮改，理論上頁面之間的跳轉(zhuǎn)只需 open 一個 URL 即可。所以對于一個組件來說腹暖，只要定義「支持哪些 URL」即可汇在，比如詳情頁，大概可以這么做的

首頁只需調(diào)用[MGJRouter openURL:@"mgj://detail?id=404"]就可以打開相應(yīng)的詳情頁微服。

那問題又來了趾疚，我怎么知道有哪些可用的 URL？為此以蕴，我們做了一個后臺專門來管理糙麦。

然后可以把這些短鏈生成不同平臺所需的文件，iOS 平臺生成 .{h,m} 文件丛肮，Android 平臺生成 .java 文件赡磅，并注入到項目中。這樣開發(fā)人員只需在項目中打開該文件就知道所有的可用 URL 了宝与。

目前還有一塊沒有做焚廊，就是參數(shù)這塊冶匹，雖然描述了短鏈，但真想要生成完整的 URL咆瘟，還需要知道如何傳參數(shù)嚼隘，這個正在開發(fā)中。

還有一種情況會稍微麻煩點袒餐，就是「組件A」要調(diào)用「組件B」的某個方法飞蛹，比如在商品詳情頁要展示購物車的商品數(shù)量，就涉及到向購物車組件拿數(shù)據(jù)灸眼。

類似這種同步調(diào)用卧檐，iOS 之前采用了比較簡單的方案，還是依托于MGJRouter焰宣，不過添加了新的方法- (id)objectForURL:霉囚，注冊時也使用新的方法進行注冊

使用時NSNumber *orderCount = [MGJRouter objectForURL:@"mgj://cart/ordercount"]這樣就拿到了購物車里的商品數(shù)。

稍微復(fù)雜但更具通用性的方法是使用「協(xié)議」 <-> 「類」綁定的方式匕积，還是以購物車為例盈罐，購物車組件可以提供這么個 Protocol

可以看到通過協(xié)議可以直接指定返回的數(shù)據(jù)類型。然后在購物車組件內(nèi)再新建個類實現(xiàn)這個協(xié)議闸天，假設(shè)這個類名為MGJCartImpl暖呕，接著就可以把它與協(xié)議關(guān)聯(lián)起來[ModuleManagerregisterClass:MGJCartImplforProtocol:@protocol(MGJCart)]，對于使用方來說苞氮，要拿到這個MGJCartImpl湾揽，需要調(diào)用[ModuleManagerclassForProtocol:@protocol(MGJCart)]。拿到之后再調(diào)用+ (NSInteger)orderCount就可以了笼吟。

那么库物，這個協(xié)議放在哪里比較合適呢？如果跟組件放在一起贷帮，使用時還是要先引入組件戚揭，如果有多個這樣的組件就會比較麻煩了。所以我們把這些公共的協(xié)議統(tǒng)一放到了PublicProtocolDomain.h下撵枢，到時只依賴這一個文件就可以了民晒。

Android 也是采用類似的方式。

組件生命周期管理

理想中的組件可以很方便地集成到主客中锄禽，并且有跟AppDelegate一致的回調(diào)方法潜必。這也是ModuleManager做的事情。

先來看看現(xiàn)在的入口方法

其中[MGJApp startApp]主要負責(zé)一些 SDK 的初始化沃但。[self trackLaunchTime]是我們打的一個點磁滚，用來監(jiān)測從main方法開始到入口方法調(diào)用結(jié)束花了多長時間。其他的都由ModuleManager搞定，loadModuleFromPlist:pathForResource:方法會讀取 bundle 里的一個 plist 文件垂攘，這個文件的內(nèi)容大概是這樣的

每個Module都實現(xiàn)了ModuleProtocol维雇，其中有一個- (BOOL)applicaiton:didFinishLaunchingWithOptions:方法，如果實現(xiàn)了的話晒他，就會被調(diào)用吱型。

還有一個問題就是，系統(tǒng)的一些事件會有通知仪芒，比如applicationDidBecomeActive會有對應(yīng)的UIApplicationDidBecomeActiveNotification唁影，組件如果要做響應(yīng)的話，只需監(jiān)聽這個系統(tǒng)通知即可掂名。但也有一些事件是沒有通知的，比如- application:didRegisterUserNotificationSettings:哟沫，這時組件如果也要做點事情饺蔑，怎么辦？

一個簡單的解決方法是在AppDelegate的各個方法里嗜诀，手動調(diào)一遍組件的對應(yīng)的方法猾警，如果有就執(zhí)行。

殼工程

既然已經(jīng)拆出去了隆敢，那拆出去的組件總得有個載體发皿，這個載體就是殼工程，殼工程主要包含一些基礎(chǔ)組件和業(yè)務(wù)SDK拂蝎，這也是主工程包含的一些內(nèi)容穴墅，所以如果在殼工程可以正常運行的話，到了主工程也沒什么問題温自。不過這里存在版本同步問題玄货，之后會說到。

遇到的問題

組件拆分

由于之前的代碼都是在一個工程下的悼泌，所以要單獨拿出來作為一個組件就會遇到不少問題松捉。首先是組件的劃分，當時在定義組件粒度時也花了些時間討論馆里，究竟是粒度粗點好隘世，還是細點好。粗點的話比較有利于拆分鸠踪，細點的話靈活度比較高丙者。最終還是選擇粗一點的粒度，先拆出來再說慢哈。

假如要把詳情頁遷出來蔓钟，就會發(fā)現(xiàn)它依賴了一些其他部分的代碼，那最快的方式就是直接把代碼拷過來卵贱，改個名使用滥沫。比較簡單暴力侣集。說起來比較簡單，做的時候也是挺有挑戰(zhàn)的兰绣，因為正常的業(yè)務(wù)并不會因為「組件化」而停止世分，所以開發(fā)同學(xué)們需要同時兼顧正常的業(yè)務(wù)和組件的拆分。

版本管理

我們的組件包括第三方庫都是通過 Cocoapods 來管理的缀辩，其中組件使用了私有庫臭埋。之所以選擇 Cocoapods，一個是因為它比較方便臀玄，還有就是用戶基數(shù)比較大瓢阴，且社區(qū)也比較活躍（活躍到了會時不時地觸發(fā) Github 的 rate limit，導(dǎo)致長時間 clone 不下來···見此）健无，當然也有其他的管理方式荣恐，比如 submodule / subtree，在開發(fā)人員比較多的情況下累贤，方便叠穆、靈活的方案容易占上風(fēng)，雖然它也有自己的問題臼膏。主要有版本同步和更新/編譯慢的問題硼被。

假如基礎(chǔ)組件做了個 API 接口升級，這個升級會對原有的接口做改動渗磅，自然就會升一個中位的版本號嚷硫，比如原先是 1.6.19，那么現(xiàn)在就變成 1.7.0 了夺溢。而我們在 Podfile 里都是用~指定的论巍，這樣就會出現(xiàn)主工程的 pod 版本升上去了，但是殼工程沒有同步到风响，然后群里就會各種反饋編譯不過嘉汰，而且這個編譯不過的長尾有時能拖上兩三天。

然后我們就想了個辦法状勤，如果不在殼工程里指定基礎(chǔ)庫的版本鞋怀，只在主工程里指定呢，理論上應(yīng)該可行持搜，只要不出現(xiàn)某個基礎(chǔ)庫要同時維護多個版本的情況密似。但實踐中發(fā)現(xiàn)，殼工程有時會莫名其妙地升不上去葫盼，在 podfile 里指定最新的版本又可以升上去残腌，所以此路不通。

還有一個問題是pod update時間過長，經(jīng)常會在Analyzing Dependency上卡 10 多分鐘抛猫，非常影響效率蟆盹。后來排查下來是跟組件的 Podspec 有關(guān)，配置了 subspec闺金，且依賴比較多逾滥。

然后就是 pod update 之后的編譯，由于是源碼編譯败匹，所以這塊的時間花費也不少寨昙，接下去會考慮 framework 的方式。

持續(xù)集成

在剛開始掀亩，持續(xù)集成還不是很完善舔哪，業(yè)務(wù)方升級組件，直接把 podspec 扔到 private repo 里就完事了槽棍。這樣最簡單尸红，但也經(jīng)常會帶來編譯通不過的問題。而且這種隨意的版本升級也不太能保證質(zhì)量刹泄。于是我們就搭建了一套持續(xù)集成系統(tǒng)，大概如此

每個組件升級之前都需要先通過編譯怎爵，然后再決定是否升級特石。這套體系看起來不復(fù)雜，但在實施過程中經(jīng)常會遇到后端的并發(fā)問題鳖链，導(dǎo)致業(yè)務(wù)方要么集成失敗姆蘸，要么要等不少時間。而且也沒有一個地方可以呈現(xiàn)當前版本的組件版本信息芙委。還有就是業(yè)務(wù)方對于這種命令行的升級方式接受度也不是很高逞敷。

基于此，在經(jīng)過了幾輪討論之后灌侣，有了新版的持續(xù)集成平臺推捐，升級操作通過網(wǎng)頁端來完成。

大致思路是侧啼，業(yè)務(wù)方如果要升級組件牛柒，假設(shè)現(xiàn)在的版本是 0.1.7，添加了一些 feature 之后痊乾，殼工程測試通過皮壁，想集成到主工程里看看效果，或者其他組件也想引用這個最新的哪审，就可以在后臺手動把版本升到 0.1.8-rc.1蛾魄，這樣的話，原先依賴~> 0.1.7的組件，不會升到 0.1.8滴须，同時想要測試這個組件的話舌狗，只要手動把版本調(diào)到 0.1.8-rc.1 就可以了。這個過程不會觸發(fā) CI 的編譯檢查描馅。

當測試通過后轨蛤，就可以把尾部的-rc.n去掉，然后點擊「集成」氛驮，就會走 CI 編譯檢查箭窜，通過的話，會在主工程的 podfile 里寫上固定的版本號 0.1.8嘹狞。也就是說岂膳，podfile 里所有的組件版本號都是固定的。

周邊設(shè)施

基礎(chǔ)組件及組件的文檔 / Demo / 單元測試

無線基礎(chǔ)的職能是為集團提供解決方案磅网，只是在蘑菇街 App 里能 work 是遠遠不夠的谈截，所以就需要提供入口，知道有哪些可用組件涧偷，并且如何使用簸喂，就像這樣（目前還未實現(xiàn)）

這就要求組件的負責(zé)人需要及時地更新 README / CHANGELOG / API，并且當發(fā)生 API 變更時燎潮，能夠快速通知到使用方喻鳄。

公共 UI 組件

組件化之后還有一個問題就是資源的重復(fù)性，以前在一個工程里的時候确封，資源都可以很方便地拿到除呵，現(xiàn)在獨立出去了，也不知道哪些是公用的爪喘，哪些是獨有的颜曾，索性都放到自己的組件里，這樣就會導(dǎo)致包變大秉剑。還有一個問題是每個組件可能是不同的產(chǎn)品經(jīng)理在跟泛豪，而他們很可能只關(guān)注于自己關(guān)心的頁面長什么樣，而忽略了整體的樣式秃症。公共

UI 組件就是用來解決這些問題的候址，這些組件甚至可以跨 App 使用。（目前還未實現(xiàn)）

參考答案一：http://blog.csdn.net/GGGHub/article/details/52713642

參考答案二：http://limboy.me/tech/2016/03/10/mgj-components.html

3.runtime如何通過selector找到對應(yīng)的IMP地址种柑？

概述

類對象中有類方法和實例方法的列表岗仑，列表中記錄著方法的名詞、參數(shù)和實現(xiàn)聚请，而selector本質(zhì)就是方法名稱荠雕，runtime通過這個方法名稱就可以在列表中找到該方法對應(yīng)的實現(xiàn)稳其。

這里聲明了一個指向struct objc_method_list指針的指針，可以包含類方法列表和實例方法列表

具體實現(xiàn)

在尋找IMP的地址時炸卑，runtime提供了兩種方法

IMP class_getMethodImplementation(Class cls, SEL name);IMP method_getImplementation(Method m)

而根據(jù)官方描述既鞠，第一種方法可能會更快一些

@note c class_getMethodImplementation may be faster than c method_getImplementation(class_getInstanceMethod(cls, name)).

對于第一種方法而言，類方法和實例方法實際上都是通過調(diào)用class_getMethodImplementation()來尋找IMP地址的盖文，不同之處在于傳入的第一個參數(shù)不同

類方法（假設(shè)有一個類A）

class_getMethodImplementation(objc_getMetaClass("A"),@selector(methodName));

實例方法

class_getMethodImplementation([A class],@selector(methodName));

通過該傳入的參數(shù)不同嘱蛋，找到不同的方法列表，方法列表中保存著下面方法的結(jié)構(gòu)體五续，結(jié)構(gòu)體中包含這方法的實現(xiàn)洒敏，selector本質(zhì)就是方法的名稱，通過該方法名稱疙驾，即可在結(jié)構(gòu)體中找到相應(yīng)的實現(xiàn)凶伙。

struct objc_method {SEL method_namechar *method_typesIMP method_imp}

而對于第二種方法而言，傳入的參數(shù)只有method它碎，區(qū)分類方法和實例方法在于封裝method的函數(shù)

類方法

Method class_getClassMethod(Class cls, SEL name)

實例方法

Method class_getInstanceMethod(Class cls, SEL name)

最后調(diào)用IMP method_getImplementation(Method m)獲取IMP地址

實驗

這里有一個叫Test的類函荣，在初始化方法里，調(diào)用了兩次getIMPFromSelector:方法扳肛，第一個aaa方法是不存在的傻挂，test1和test2分別為實例方法和類方法

然后我同時實例化了兩個Test的對象，打印信息如下

大家注意圖中紅色標注的地址出現(xiàn)了8次：0x1102db280挖息，這個是在調(diào)用class_getMethodImplementation()方法時踊谋，無法找到對應(yīng)實現(xiàn)時返回的相同的一個地址，無論該方法是在實例方法或類方法旋讹，無論是否對一個實例調(diào)用該方法，返回的地址都是相同的轿衔，但是每次運行該程序時返回的地址并不相同沉迹，而對于另一種方法，如果找不到對應(yīng)的實現(xiàn)害驹，則返回0鞭呕，在圖中我做了藍色標記。

還有一點有趣的是class_getClassMethod()的第一個參數(shù)無論傳入objc_getClass()還是objc_getMetaClass()宛官，最終調(diào)用method_getImplementation()都可以成功的找到類方法的實現(xiàn)葫松。

而class_getInstanceMethod()的第一個參數(shù)如果傳入objc_getMetaClass()，再調(diào)用method_getImplementation()時無法找到實例方法的實現(xiàn)卻可以找到類方法的實現(xiàn)底洗。

4.runloop內(nèi)部實現(xiàn)邏輯腋么？

蘋果在文檔里的說明，RunLoop 內(nèi)部的邏輯大致如下:

其內(nèi)部代碼整理如下 ：

可以看到亥揖，實際上 RunLoop 就是這樣一個函數(shù)珊擂，其內(nèi)部是一個 do-while 循環(huán)圣勒。當你調(diào)用 CFRunLoopRun() 時，線程就會一直停留在這個循環(huán)里摧扇；直到超時或被手動停止圣贸，該函數(shù)才會返回。

RunLoop 的底層實現(xiàn)

從上面代碼可以看到扛稽，RunLoop 的核心是基于 mach port 的吁峻，其進入休眠時調(diào)用的函數(shù)是 mach_msg()。為了解釋這個邏輯在张，下面稍微介紹一下 OSX/iOS 的系統(tǒng)架構(gòu)用含。

蘋果官方將整個系統(tǒng)大致劃分為上述4個層次：

應(yīng)用層包括用戶能接觸到的圖形應(yīng)用，例如 Spotlight瞧掺、Aqua耕餐、SpringBoard 等。

應(yīng)用框架層即開發(fā)人員接觸到的 Cocoa 等框架辟狈。

核心框架層包括各種核心框架肠缔、OpenGL 等內(nèi)容。

Darwin 即操作系統(tǒng)的核心哼转，包括系統(tǒng)內(nèi)核明未、驅(qū)動、Shell 等內(nèi)容壹蔓，這一層是開源的趟妥，其所有源碼都可以在opensource.apple.com里找到。

我們在深入看一下 Darwin 這個核心的架構(gòu)：

其中佣蓉，在硬件層上面的三個組成部分：Mach披摄、BSD、IOKit (還包括一些上面沒標注的內(nèi)容)勇凭，共同組成了 XNU 內(nèi)核疚膊。

XNU 內(nèi)核的內(nèi)環(huán)被稱作 Mach，其作為一個微內(nèi)核虾标，僅提供了諸如處理器調(diào)度寓盗、IPC (進程間通信)等非常少量的基礎(chǔ)服務(wù)。

BSD 層可以看作圍繞 Mach 層的一個外環(huán)璧函，其提供了諸如進程管理傀蚌、文件系統(tǒng)和網(wǎng)絡(luò)等功能。

IOKit 層是為設(shè)備驅(qū)動提供了一個面向?qū)ο?C++)的一個框架蘸吓。

Mach

本身提供的 API 非常有限善炫，而且蘋果也不鼓勵使用 Mach 的

API，但是這些API非晨饧蹋基礎(chǔ)销部，如果沒有這些API的話摸航，其他任何工作都無法實施。在 Mach

中舅桩，所有的東西都是通過自己的對象實現(xiàn)的酱虎，進程、線程和虛擬內(nèi)存都被稱為"對象"擂涛。和其他架構(gòu)不同读串， Mach

的對象間不能直接調(diào)用，只能通過消息傳遞的方式實現(xiàn)對象間的通信撒妈。"消息"是 Mach 中最基礎(chǔ)的概念恢暖，消息在兩個端口 (port)

之間傳遞，這就是 Mach 的 IPC (進程間通信) 的核心狰右。

Mach 的消息定義是在頭文件的杰捂，很簡單：

typedef struct {

mach_msg_header_t header;

mach_msg_body_t body;

} mach_msg_base_t;

typedef struct {

mach_msg_bits_t msgh_bits;

mach_msg_size_t msgh_size;

mach_port_t msgh_remote_port;

mach_port_t msgh_local_port;

mach_port_name_t msgh_voucher_port;

mach_msg_id_t msgh_id;

} mach_msg_header_t;

一條 Mach 消息實際上就是一個二進制數(shù)據(jù)包 (BLOB)，其頭部定義了當前端口 local_port 和目標端口 remote_port棋蚌，

發(fā)送和接受消息是通過同一個 API 進行的嫁佳，其 option 標記了消息傳遞的方向：

mach_msg_return_t mach_msg(

mach_msg_header_t *msg,

mach_msg_option_t option,

mach_msg_size_t send_size,

mach_msg_size_t rcv_size,

mach_port_name_t rcv_name,

mach_msg_timeout_t timeout,

mach_port_name_t notify);

為了實現(xiàn)消息的發(fā)送和接收，mach_msg()

函數(shù)實際上是調(diào)用了一個 Mach 陷阱 (trap)谷暮，即函數(shù)mach_msg_trap()蒿往，陷阱這個概念在 Mach

中等同于系統(tǒng)調(diào)用。當你在用戶態(tài)調(diào)用 mach_msg_trap() 時會觸發(fā)陷阱機制湿弦，切換到內(nèi)核態(tài)瓤漏；內(nèi)核態(tài)中內(nèi)核實現(xiàn)的 mach_msg()

函數(shù)會完成實際的工作，如下圖：

這些概念可以參考維基百科:System_call颊埃、Trap_(computing)蔬充。

RunLoop

的核心就是一個 mach_msg() (見上面代碼的第7步)，RunLoop 調(diào)用這個函數(shù)去接收消息班利，如果沒有別人發(fā)送 port

消息過來娃惯，內(nèi)核會將線程置于等待狀態(tài)。例如你在模擬器里跑起一個 iOS 的 App肥败，然后在 App 靜止時點擊暫停，你會看到主線程調(diào)用棧是停留在

mach_msg_trap() 這個地方愕提。

關(guān)于具體的如何利用 mach port 發(fā)送信息馒稍，可以看看NSHipster 這一篇文章，或者這里的中文翻譯 浅侨。

關(guān)于Mach的歷史可以看看這篇很有趣的文章：Mac OS X 背后的故事（三）Mach 之父 Avie Tevanian纽谒。

蘋果用 RunLoop 實現(xiàn)的功能

首先我們可以看一下 App 啟動后 RunLoop 的狀態(tài)：

可以看到，系統(tǒng)默認注冊了5個Mode:

1. kCFRunLoopDefaultMode: App的默認 Mode如输，通常主線程是在這個 Mode 下運行的鼓黔。

2. UITrackingRunLoopMode: 界面跟蹤 Mode央勒，用于 ScrollView 追蹤觸摸滑動，保證界面滑動時不受其他 Mode 影響澳化。

3. UIInitializationRunLoopMode: 在剛啟動 App 時第進入的第一個 Mode崔步，啟動完成后就不再使用。

4: GSEventReceiveRunLoopMode: 接受系統(tǒng)事件的內(nèi)部 Mode缎谷，通常用不到井濒。

5: kCFRunLoopCommonModes: 這是一個占位的 Mode，沒有實際作用列林。

你可以在這里看到更多的蘋果內(nèi)部的 Mode瑞你，但那些 Mode 在開發(fā)中就很難遇到了。

5.你理解的多線程希痴？

可能會追問者甲，每種多線程基于什么語言？

生命周期是如何管理砌创？

你更傾向于哪種虏缸？追問至現(xiàn)在常用的兩種你的看法是？

第一種：pthread

.特點：

一套通用的多線程API

適用于UnixLinuxWindows等系統(tǒng)

跨平臺可移植

使用難度大

b.使用語言：c語言

c.使用頻率：幾乎不用

d.線程生命周期：由程序員進行管理

第二種：NSThread

a.特點：

1）使用更加面向?qū)ο?/p>

2）簡單易用纺铭，可直接操作線程對象

b.使用語言：OC語言

c.使用頻率：偶爾使用

d.線程生命周期：由程序員進行管理

第三種：GCD

a.特點：

1）旨在替代NSThread等線程技術(shù)

2）充分利用設(shè)備的多核（自動）

b.使用語言：C語言

c.使用頻率：經(jīng)常使用

d.線程生命周期：自動管理

第四種：NSOperation

a.特點：

基于GCD（底層是GCD）

比GCD多了一些更簡單實用的功能

使用更加面向?qū)ο?/p>

使用語言：OC語言

使用頻率：經(jīng)常使用

線程生命周期：自動管理

多線程的原理

同一時間寇钉，CPU只能處理1條線程，只有1條線程在工作（執(zhí)行）

多線程并發(fā)（同時）執(zhí)行舶赔，其實是CPU快速地在多條線程之間調(diào)度（切換）

如果CPU調(diào)度線程的時間足夠快扫倡，就造成了多線程并發(fā)執(zhí)行的假象

思考：如果線程非常非常多，會發(fā)生什么情況竟纳？

CPU會在N多線程之間調(diào)度撵溃，CPU會累死，消耗大量的CPU資源

每條線程被調(diào)度執(zhí)行的頻次會降低（線程的執(zhí)行效率降低）

多線程的優(yōu)點

能適當提高程序的執(zhí)行效率

能適當提高資源利用率（CPU锥累、內(nèi)存利用率）

多線程的缺點

開啟線程需要占用一定的內(nèi)存空間（默認情況下缘挑，主線程占用1M，子線程占用512KB）桶略，如果開啟大量的線程语淘，會占用大量的內(nèi)存空間，降低程序的性能

線程越多际歼，CPU在調(diào)度線程上的開銷就越大

程序設(shè)計更加復(fù)雜：比如線程之間的通信惶翻、多線程的數(shù)據(jù)共享

你更傾向于哪一種？

傾向于GCD：

GCD

技術(shù)是一個輕量的鹅心，底層實現(xiàn)隱藏的神奇技術(shù)吕粗，我們能夠通過GCD和block輕松實現(xiàn)多線程編程，有時候旭愧，GCD相比其他系統(tǒng)提供的多線程方法更加有效颅筋，當然宙暇，有時候GCD不是最佳選擇，另一個多線程編程的技術(shù)

NSOprationQueue 讓我們能夠?qū)⒑笈_線程以隊列方式依序執(zhí)行议泵，并提供更多操作的入口占贫，這和 GCD 的實現(xiàn)有些類似。

這種類似不是一個巧合肢簿，在早期靶剑，MacOX

與 iOS 的程序都普遍采用Operation

Queue來進行編寫后臺線程代碼，而之后出現(xiàn)的GCD技術(shù)大體是依照前者的原則來實現(xiàn)的池充，而隨著GCD的普及桩引，在iOS 4 與 MacOS X

10.6以后，Operation Queue的底層實現(xiàn)都是用GCD來實現(xiàn)的收夸。

那這兩者直接有什么區(qū)別呢坑匠？

1. ? ?GCD是底層的C語言構(gòu)成的API，而NSOperationQueue及相關(guān)對象是Objc的對象卧惜。在GCD中厘灼，在隊列中執(zhí)行的是由block構(gòu)成的任務(wù)，這是一個輕量級的數(shù)據(jù)結(jié)構(gòu)咽瓷；而Operation作為一個對象设凹，為我們提供了更多的選擇；

2. ? ?在NSOperationQueue中茅姜，我們可以隨時取消已經(jīng)設(shè)定要準備執(zhí)行的任務(wù)(當然闪朱，已經(jīng)開始的任務(wù)就無法阻止了)，而GCD沒法停止已經(jīng)加入queue的block(其實是有的钻洒，但需要許多復(fù)雜的代碼)奋姿；

3. ? ?NSOperation能夠方便地設(shè)置依賴關(guān)系，我們可以讓一個Operation依賴于另一個Operation素标，這樣的話盡管兩個Operation處于同一個并行隊列中称诗，但前者會直到后者執(zhí)行完畢后再執(zhí)行；

4. ? ?我們能將KVO應(yīng)用在NSOperation中头遭，可以監(jiān)聽一個Operation是否完成或取消寓免，這樣子能比GCD更加有效地掌控我們執(zhí)行的后臺任務(wù)；

5. ? ?在NSOperation中计维，我們能夠設(shè)置NSOperation的priority優(yōu)先級袜香，能夠使同一個并行隊列中的任務(wù)區(qū)分先后地執(zhí)行，而在GCD中享潜，我們只能區(qū)分不同任務(wù)隊列的優(yōu)先級，如果要區(qū)分block任務(wù)的優(yōu)先級嗅蔬，也需要大量的復(fù)雜代碼剑按；

6. ? ?我們能夠?qū)SOperation進行繼承疾就，在這之上添加成員變量與成員方法，提高整個代碼的復(fù)用度艺蝴，這比簡單地將block任務(wù)排入執(zhí)行隊列更有自由度猬腰，能夠在其之上添加更多自定制的功能。

總的來說猜敢，Operation

queue

提供了更多你在編寫多線程程序時需要的功能姑荷，并隱藏了許多線程調(diào)度，線程取消與線程優(yōu)先級的復(fù)雜代碼缩擂，為我們提供簡單的API入口鼠冕。從編程原則來說，一般我們需要盡可能的使用高等級胯盯、封裝完美的API懈费，在必須時才使用底層API。但是我認為當我們的需求能夠以更簡單的底層代碼完成的時候博脑，簡潔的GCD或許是個更好的選擇憎乙，而Operation

queue 為我們提供能更多的選擇。

傾向于：NSOperation

NSOperation相對于GCD：

1叉趣，NSOperation擁有更多的函數(shù)可用泞边，具體查看api。NSOperationQueue 是在GCD基礎(chǔ)上實現(xiàn)的疗杉，只不過是GCD更高一層的抽象阵谚。

2，在NSOperationQueue中乡数，可以建立各個NSOperation之間的依賴關(guān)系椭蹄。

3，NSOperationQueue支持KVO净赴∩兀可以監(jiān)測operation是否正在執(zhí)行（isExecuted）、是否結(jié)束（isFinished）玖翅，是否取消（isCanceld）

4翼馆，GCD 只支持FIFO 的隊列，而NSOperationQueue可以調(diào)整隊列的執(zhí)行順序（通過調(diào)整權(quán)重）金度。NSOperationQueue可以方便的管理并發(fā)应媚、NSOperation之間的優(yōu)先級。

使用NSOperation的情況：各個操作之間有依賴關(guān)系猜极、操作需要取消暫停中姜、并發(fā)管理、控制操作之間優(yōu)先級，限制同時能執(zhí)行的線程數(shù)量.讓線程在某時刻停止/繼續(xù)等丢胚。

使用GCD的情況：一般的需求很簡單的多線程操作翩瓜，用GCD都可以了，簡單高效携龟。

從編程原則來說兔跌，一般我們需要盡可能的使用高等級、封裝完美的API峡蟋，在必須時才使用底層API坟桅。

當需求簡單，簡潔的GCD或許是個更好的選擇蕊蝗，而Operation queue 為我們提供能更多的選擇仅乓。

6.GCD執(zhí)行原理？

GCD有一個底層線程池匿又，這個池中存放的是一個個的線程方灾。之所以稱為“池”，很容易理解出這個“池”中的線程是可以重用的碌更，當一段時間后這個線程沒有被調(diào)用胡話裕偿，這個線程就會被銷毀。注意：開多少條線程是由底層線程池決定的（線程建議控制再3~5條）痛单，池是系統(tǒng)自動來維護嘿棘，不需要我們程序員來維護（看到這句話是不是很開心？）

而我們程序員需要關(guān)心的是什么呢旭绒？我們只關(guān)心的是向隊列中添加任務(wù)鸟妙，隊列調(diào)度即可。

如果隊列中存放的是同步任務(wù)挥吵，則任務(wù)出隊后重父，底層線程池中會提供一條線程供這個任務(wù)執(zhí)行，任務(wù)執(zhí)行完畢后這條線程再回到線程池忽匈。這樣隊列中的任務(wù)反復(fù)調(diào)度房午，因為是同步的，所以當我們用currentThread打印的時候丹允，就是同一條線程郭厌。

如果隊列中存放的是異步的任務(wù)，（注意異步可以開線程）雕蔽，當任務(wù)出隊后折柠，底層線程池會提供一個線程供任務(wù)執(zhí)行，因為是異步執(zhí)行批狐，隊列中的任務(wù)不需等待當前任務(wù)執(zhí)行完畢就可以調(diào)度下一個任務(wù)扇售，這時底層線程池中會再次提供一個線程供第二個任務(wù)執(zhí)行，執(zhí)行完畢后再回到底層線程池中。

這樣就對線程完成一個復(fù)用承冰，而不需要每一個任務(wù)執(zhí)行都開啟新的線程嘱根，也就從而節(jié)約的系統(tǒng)的開銷，提高了效率巷懈。在iOS7.0的時候，使用GCD系統(tǒng)通常只能開5~8條線程慌洪，iOS8.0以后顶燕，系統(tǒng)可以開啟很多條線程，但是實在開發(fā)應(yīng)用中冈爹，建議開啟線程條數(shù)：3~5條最為合理涌攻。

通過案例明白GCD的執(zhí)行原理

案例一：

分析：

首先執(zhí)行任務(wù)1，這是肯定沒問題的频伤，只是接下來恳谎，程序遇到了同步線程，那么它會進入等待憋肖，等待任務(wù)2執(zhí)行完因痛，然后執(zhí)行任務(wù)3。但這是隊列岸更，有任務(wù)來鸵膏，當然會將任務(wù)加到隊尾，然后遵循FIFO原則執(zhí)行任務(wù)怎炊。那么谭企，現(xiàn)在任務(wù)2就會被加到最后，任務(wù)3排在了任務(wù)2前面评肆，問題來了：

任務(wù)3要等任務(wù)2執(zhí)行完才能執(zhí)行债查，任務(wù)2又排在任務(wù)3后面，意味著任務(wù)2要在任務(wù)3執(zhí)行完才能執(zhí)行瓜挽，所以他們進入了互相等待的局面盹廷。【既然這樣秸抚，那干脆就卡在這里吧】這就是死鎖速和。

案例二：

分析：

首先執(zhí)行任務(wù)1，接下來會遇到一個同步線程剥汤，程序會進入等待颠放。等待任務(wù)2執(zhí)行完成以后，才能繼續(xù)執(zhí)行任務(wù)3吭敢。從dispatch_get_global_queue可以看出碰凶，任務(wù)2被加入到了全局的并行隊列中，當并行隊列執(zhí)行完任務(wù)2以后，返回到主隊列欲低，繼續(xù)執(zhí)行任務(wù)3辕宏。

案例三：

案例四：

分析：

首先，將【任務(wù)1砾莱、異步線程瑞筐、任務(wù)5】加入Main

Queue中，異步線程中的任務(wù)是：【任務(wù)2腊瑟、同步線程聚假、任務(wù)4】。所以，先執(zhí)行任務(wù)1，然后將異步線程中的任務(wù)加入到Global

Queue中咆疗，因為異步線程奋单，所以任務(wù)5不用等待，結(jié)果就是2和5的輸出順序不一定。然后再看異步線程中的任務(wù)執(zhí)行順序。任務(wù)2執(zhí)行完以后，遇到同步線程菜秦。將同步線程中的任務(wù)加入到Main

Queue中，這時加入的任務(wù)3在任務(wù)5的后面舶掖。當任務(wù)3執(zhí)行完以后喷户，沒有了阻塞，程序繼續(xù)執(zhí)行任務(wù)4访锻。

案例五：

分析：

和上面幾個案例的分析類似褪尝，先來看看都有哪些任務(wù)加入了Main Queue：

【異步線程、任務(wù)4期犬、死循環(huán)河哑、任務(wù)5】。

在加入到Global Queue異步線程中的任務(wù)有：

【任務(wù)1龟虎、同步線程璃谨、任務(wù)3】。第一個就是異步線程鲤妥，任務(wù)4不用等待佳吞，

所以結(jié)果任務(wù)1和任務(wù)4順序不一定。任務(wù)4完成后棉安，程序進入死循環(huán)底扳，

Main Queue阻塞。但是加入到Global Queue的異步線程不受影響贡耽，

繼續(xù)執(zhí)行任務(wù)1后面的同步線程衷模。同步線程中鹊汛，將任務(wù)2加入到了主線程，

并且阱冶，任務(wù)3等待任務(wù)2完成以后才能執(zhí)行刁憋。這時的主線程，已經(jīng)被死循環(huán)阻塞了木蹬。

所以任務(wù)2無法執(zhí)行至耻，當然任務(wù)3也無法執(zhí)行，在死循環(huán)后的任務(wù)5也不會執(zhí)行镊叁。

7.怎么防止別人動態(tài)在你程序生成代碼有梆？

（這題是聽錯了面試官的意思）

面試官意思是怎么防止別人反編譯你的app？

1.本地數(shù)據(jù)加密

iOS應(yīng)用防反編譯加密技術(shù)之一：對NSUserDefaults意系，sqlite存儲文件數(shù)據(jù)加密，保護帳號和關(guān)鍵信息

2.URL編碼加密

iOS應(yīng)用防反編譯加密技術(shù)之二：對程序中出現(xiàn)的URL進行編碼加密饺汹，防止URL被靜態(tài)分析

3.網(wǎng)絡(luò)傳輸數(shù)據(jù)加密

iOS應(yīng)用防反編譯加密技術(shù)之三：對客戶端傳輸數(shù)據(jù)提供加密方案蛔添，有效防止通過網(wǎng)絡(luò)接口的攔截獲取數(shù)據(jù)

4.方法體，方法名高級混淆

iOS應(yīng)用防反編譯加密技術(shù)之四：對應(yīng)用程序的方法名和方法體進行混淆兜辞，保證源碼被逆向后無法解析代碼

5.程序結(jié)構(gòu)混排加密

iOS應(yīng)用防反編譯加密技術(shù)之五：對應(yīng)用程序邏輯結(jié)構(gòu)進行打亂混排迎瞧，保證源碼可讀性降到最低

6.借助第三方APP加固，例如：網(wǎng)易云易盾

8.YYAsyncLayer如何異步繪制逸吵？

YYAsyncLayer是異步繪制與顯示的工具凶硅。為了保證列表滾動流暢，將視圖繪制扫皱、以及圖片解碼等任務(wù)放到后臺線程足绅，

YYKitDemo

對于列表主要對兩個代理方法的優(yōu)化，一個與繪制顯示有關(guān)韩脑，另一個與計算布局有關(guān)：

Objective-C

1-(CGFloat)tableView:(UITableView*)tableViewheightForRowAtIndexPath:(NSIndexPath*)indexPath;

2-(UITableViewCell*)tableView:(UITableView*)tableViewcellForRowAtIndexPath:(NSIndexPath*)indexPath;

常規(guī)邏輯可能覺得應(yīng)該先調(diào)用tableView : cellForRowAtIndexPath :返回UITableViewCell對象氢妈，事實上調(diào)用順序是先返回UITableViewCell的高度，是因為UITableView繼承自UIScrollView段多，滑動范圍由屬性contentSize來確定首量，UITableView的滑動范圍需要通過每一行的UITableViewCell的高度計算確定，復(fù)雜cell如果在列表滾動過程中計算可能會造成一定程度的卡頓进苍。

假設(shè)有20條數(shù)據(jù)加缘，當前屏幕顯示5條，tableView : heightForRowAtIndexPath :方法會先執(zhí)行20次返回所有高度并計算出滑動范圍觉啊，tableView : cellForRowAtIndexPath :執(zhí)行５次返回當前屏幕顯示的cell個數(shù)拣宏。

從圖中簡單看下流程，從網(wǎng)絡(luò)請求返回JSON數(shù)據(jù)杠人，將Cell的高度以及內(nèi)部視圖的布局封裝為Layout對象蚀浆，Cell顯示之前在異步線程計算好所有布局對象缀程，并存入數(shù)組，每次調(diào)用tableView: heightForRowAtIndexPath :只需要從數(shù)組中取出市俊，可避免重復(fù)的布局計算杨凑。同時在調(diào)用tableView: cellForRowAtIndexPath :對Cell內(nèi)部視圖異步繪制布局，以及圖片的異步繪制解碼摆昧，這里就要說到今天的主角YYAsyncLayer撩满。

YYAsyncLayer

首先介紹里面幾個類：

YYAsyncLayer：繼承自CALayer，繪制绅你、創(chuàng)建繪制線程的部分都在這個類伺帘。

YYTransaction：用于創(chuàng)建RunloopObserver監(jiān)聽MainRunloop的空閑時間，并將YYTranaction對象存放到集合中忌锯。

YYSentinel：提供獲取當前值的value（只讀）屬性伪嫁，以及- (int32_t)increase自增加的方法返回一個新的value值，用于判斷異步繪制任務(wù)是否被取消的工具偶垮。

AsyncDisplay.png

上圖是整體異步繪制的實現(xiàn)思路张咳，后面一步步說明。現(xiàn)在假設(shè)需要繪制Label似舵，其實是繼承自UIView脚猾，重寫+ (Class)layerClass，在需要重新繪制的地方調(diào)用下面方法砚哗，比如setter龙助，layoutSubviews。

Objective-C

+(Class)layerClass{

returnYYAsyncLayer.class;

}

-(void)setText:(NSString*)text{

_text=text.copy;

[[YYTransactiontransactionWithTarget:selfselector:@selector(contentsNeedUpdated)]commit];

}

-(void)layoutSubviews{

[superlayoutSubviews];

[[YYTransactiontransactionWithTarget:selfselector:@selector(contentsNeedUpdated)]commit];

}

YYTransaction有selector蛛芥、target的屬性提鸟，selector其實就是contentsNeedUpdated方法，此時并不會立即在后臺線程去更新顯示仅淑，而是將YYTransaction對象本身提交保存在transactionSet的集合中沽一，上圖中所示。

Objective-C

+(YYTransaction*)transactionWithTarget:(id)targetselector:(SEL)selector{

if(!target||!selector)returnnil;

YYTransaction*t=[YYTransactionnew];

t.target=target;

t.selector=selector;

returnt;

}

-(void)commit{

if(!_target||!_selector)return;

YYTransactionSetup();

[transactionSetaddObject:self];

}

同時在YYTransaction.m中注冊一個RunloopObserver漓糙，監(jiān)聽MainRunloop在kCFRunLoopCommonModes（包含kCFRunLoopDefaultMode铣缠、UITrackingRunLoopMode）下的kCFRunLoopBeforeWaiting和kCFRunLoopExit的狀態(tài)，也就是說在一次Runloop空閑時去執(zhí)行更新顯示的操作昆禽。

kCFRunLoopBeforeWaiting：Runloop將要進入休眠蝗蛙。

kCFRunLoopExit：即將退出本次Runloop。

Objective-C

staticvoidYYTransactionSetup(){

staticdispatch_once_tonceToken;

dispatch_once(&onceToken,^{

transactionSet=[NSMutableSetnew];

CFRunLoopRefrunloop=CFRunLoopGetMain();

CFRunLoopObserverRefobserver;

observer=CFRunLoopObserverCreate(CFAllocatorGetDefault()

kCFRunLoopBeforeWaiting|kCFRunLoopExit,

true,// repeat

0xFFFFFF,// after CATransaction(2000000)

YYRunLoopObserverCallBack,NULL);

CFRunLoopAddObserver(runloop,observer,kCFRunLoopCommonModes);

CFRelease(observer);

});

}

下面是RunloopObserver的回調(diào)方法醉鳖，從transactionSet取出transaction對象執(zhí)行SEL的方法捡硅，分發(fā)到每一次Runloop執(zhí)行，避免一次Runloop執(zhí)行時間太長盗棵。

Objective-C

staticvoidYYRunLoopObserverCallBack(CFRunLoopObserverRefobserver,CFRunLoopActivityactivity,void*info){

if(transactionSet.count==0)return;

NSSet*currentSet=transactionSet;

transactionSet=[NSMutableSetnew];

[currentSetenumerateObjectsUsingBlock:^(YYTransaction*transaction,BOOL*stop){

#pragma clang diagnostic push

#pragma clang diagnostic ignored "-Warc-performSelector-leaks"

[transaction.targetperformSelector:transaction.selector];

#pragma clang diagnostic pop

}];

}

接下來是異步繪制壮韭，這里用了一個比較巧妙的方法處理北发，當使用GCD時提交大量并發(fā)任務(wù)到后臺線程導(dǎo)致線程被鎖住、休眠的情況喷屋，創(chuàng)建與程序當前激活CPU數(shù)量（activeProcessorCount）相同的串行隊列琳拨，并限制MAX_QUEUE_COUNT，將隊列存放在數(shù)組中屯曹。

YYAsyncLayer.m有一個方法YYAsyncLayerGetDisplayQueue來獲取這個隊列用于繪制（這部分YYKit中有獨立的工具YYDispatchQueuePool）狱庇。創(chuàng)建隊列中有一個參數(shù)是告訴隊列執(zhí)行任務(wù)的服務(wù)質(zhì)量quality of service，在iOS8+之后相比之前系統(tǒng)有所不同恶耽。

iOS8之前隊列優(yōu)先級：

DISPATCH_QUEUE_PRIORITY_HIGH 2高優(yōu)先級

DISPATCH_QUEUE_PRIORITY_DEFAULT 0默認優(yōu)先級

DISPATCH_QUEUE_PRIORITY_LOW (-2)低優(yōu)先級

DISPATCH_QUEUE_PRIORITY_BACKGROUND INT16_MIN后臺優(yōu)先級

iOS8+之后：

QOS_CLASS_USER_INTERACTIVE 0x21, 用戶交互(希望盡快完成密任，不要放太耗時操作)

QOS_CLASS_USER_INITIATED 0x19, 用戶期望(不要放太耗時操作)

QOS_CLASS_DEFAULT 0x15, 默認(用來重置對列使用的)

QOS_CLASS_UTILITY 0x11, 實用工具(耗時操作，可以使用這個選項)

QOS_CLASS_BACKGROUND 0x09, 后臺

QOS_CLASS_UNSPECIFIED 0x00, 未指定

Objective-C

/// Global display queue, used for content rendering.

staticdispatch_queue_tYYAsyncLayerGetDisplayQueue(){

#ifdef YYDispatchQueuePool_h

returnYYDispatchQueueGetForQOS(NSQualityOfServiceUserInitiated);

#else

#define MAX_QUEUE_COUNT 16

staticintqueueCount;

staticdispatch_queue_tqueues[MAX_QUEUE_COUNT];//存放隊列的數(shù)組

staticdispatch_once_tonceToken;

staticint32_tcounter=0;

dispatch_once(&onceToken,^{

//程序激活的處理器數(shù)量

queueCount=(int)[NSProcessInfoprocessInfo].activeProcessorCount;

queueCount=queueCountMAX_QUEUE_COUNT?MAX_QUEUE_COUNT: queueCount);

if([UIDevicecurrentDevice].systemVersion.floatValue>=8.0){

for(NSUIntegeri=0;i

接下來是關(guān)于繪制部分的代碼偷俭，對外接口YYAsyncLayerDelegate代理中提供- (YYAsyncLayerDisplayTask *)newAsyncDisplayTask方法用于回調(diào)繪制的代碼浪讳，以及是否異步繪制的BOOl類型屬性displaysAsynchronously，同時重寫CALayer的display方法來調(diào)用繪制的方法- (void)_displayAsync:(BOOL)async涌萤。

這里有必要了解關(guān)于后臺的繪制任務(wù)何時會被取消淹遵，下面兩種情況需要取消，并調(diào)用了YYSentinel的increase方法形葬，使value值增加（線程安全）：

在視圖調(diào)用setNeedsDisplay時說明視圖的內(nèi)容需要被更新，將當前的繪制任務(wù)取消暮的，需要重新顯示笙以。

以及視圖被釋放調(diào)用了dealloc方法。

在YYAsyncLayer.h中定義了YYAsyncLayerDisplayTask類冻辩，有三個block屬性用于繪制的回調(diào)操作猖腕，從命名可以看出分別是將要繪制，正在繪制恨闪，以及繪制完成的回調(diào)倘感，可以從block傳入的參數(shù)BOOL(^isCancelled)(void)判斷當前繪制是否被取消。

Objective-C

@property(nullable,nonatomic,copy)void(^willDisplay)(CALayer*layer);

@property(nullable,nonatomic,copy)void(^display)(CGContextRefcontext,CGSizesize,BOOL(^isCancelled)(void));

@property(nullable,nonatomic,copy)void(^didDisplay)(CALayer*layer,BOOLfinished);

下面是部分- (void)_displayAsync:(BOOL)async繪制的代碼咙咽，主要是一些邏輯判斷以及繪制函數(shù)老玛，在異步執(zhí)行之前通過YYAsyncLayerGetDisplayQueue創(chuàng)建的隊列，這里通過YYSentinel判斷當前的value是否等于之前的值钧敞，如果不相等蜡豹，說明繪制任務(wù)被取消了，繪制過程會多次判斷是否取消溉苛，如果是則return镜廉，保證被取消的任務(wù)能及時退出，如果繪制完畢則設(shè)置圖片到layer.contents愚战。

Objective-C

if(async){//異步

if(task.willDisplay)task.willDisplay(self);

YYSentinel*sentinel=_sentinel;

int32_tvalue=sentinel.value;

NSLog(@" --- %d ---",value);

//判斷當前計數(shù)是否等于之前計數(shù)

BOOL(^isCancelled)()=^BOOL(){

returnvalue!=sentinel.value;

};

CGSizesize=self.bounds.size;

BOOLopaque=self.opaque;

CGFloatscale=self.contentsScale;

CGColorRefbackgroundColor=(opaque&&self.backgroundColor)?CGColorRetain(self.backgroundColor): NULL;

if(size.width

9.優(yōu)化你是從哪幾方面著手娇唯？

一齐遵、首頁啟動速度

啟動過程中做的事情越少越好（盡可能將多個接口合并）

不在UI線程上作耗時的操作（數(shù)據(jù)的處理在子線程進行，處理完通知主線程刷新節(jié)目）

在合適的時機開始后臺任務(wù)（例如在用戶指引節(jié)目就可以開始準備加載的數(shù)據(jù)）

盡量減小包的大小

優(yōu)化方法：

量化啟動時間

啟動速度模塊化

輔助工具（友盟塔插，聽云梗摇，F(xiàn)lurry）

二、頁面瀏覽速度

json的處理（iOS 自帶的NSJSONSerialization佑淀，Jsonkit留美，SBJson）

數(shù)據(jù)的分頁（后端數(shù)據(jù)多的話，就要分頁返回伸刃，例如網(wǎng)易新聞谎砾，或者 微博記錄）

數(shù)據(jù)壓縮（大數(shù)據(jù)也可以壓縮返回，減少流量捧颅，加快反應(yīng)速度）

內(nèi)容緩存（例如網(wǎng)易新聞的最新新聞列表都是要緩存到本地景图，從本地加載，可以緩存到內(nèi)存碉哑，或者數(shù)據(jù)庫挚币，根據(jù)情況而定）

延時加載tab（比如app有5個tab，可以先加載第一個要顯示的tab扣典，其他的在顯示時候加載妆毕，按需加載）

算法的優(yōu)化（核心算法的優(yōu)化，例如有些app 有個 聯(lián)系人姓名用漢語拼音的首字母排序）

三贮尖、操作流暢度優(yōu)化：

Tableview 優(yōu)化（tableview cell的加載優(yōu)化）

ViewController加載優(yōu)化（不同view之間的跳轉(zhuǎn)笛粘，可以提前準備好數(shù)據(jù)）

四、數(shù)據(jù)庫的優(yōu)化：

數(shù)據(jù)庫設(shè)計上面的重構(gòu)

查詢語句的優(yōu)化

分庫分表（數(shù)據(jù)太多的時候湿硝，可以分不同的表或者庫）

五薪前、服務(wù)器端和客戶端的交互優(yōu)化：

客戶端盡量減少請求

服務(wù)端盡量做多的邏輯處理

服務(wù)器端和客戶端采取推拉結(jié)合的方式（可以利用一些同步機制）

通信協(xié)議的優(yōu)化。（減少報文的大泄匦薄）

電量使用優(yōu)化（盡量不要使用后臺運行）

六示括、非技術(shù)性能優(yōu)化

產(chǎn)品設(shè)計的邏輯性（產(chǎn)品的設(shè)計一定要符合邏輯，或者邏輯盡量簡單痢畜，否則會讓程序員抓狂垛膝，有時候用了好大力氣，才可以完成一個小小的邏輯設(shè)計問題）

界面交互的規(guī)范（每個模塊的界面的交互盡量統(tǒng)一丁稀，符合操作習(xí)慣）

代碼規(guī)范（這個可以隱形帶來app 性能的提高繁涂，比如 用if else 還是switch ，或者是用二驰！還是 ＝＝）

code review（堅持code Review 持續(xù)重構(gòu)代碼扔罪。減少代碼的邏輯復(fù)雜度）

日常交流（經(jīng)常分享一些代碼，或者邏輯處理中的坑）

以上問題加參考答案桶雀，部分自己回答(群友回答)＋網(wǎng)上博客參考矿酵，回答的不好勿噴唬复！

僅供學(xué)習(xí)使用！ 謝謝全肮！