阿里-p6-一面

1.介紹下內存的幾大區域？

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

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

4.runloop內部實現邏輯？

5.你理解的多線程？

6.GCD執行原理？

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

8.YYAsyncLayer如何異步繪制？

9.優化你是從哪幾方面著手？

1.介紹下內存的幾大區域？

1.棧區(stack) 由編譯器自動分配并釋放，存放函數的參數值，局部變量等。棧是系統數據結構，對應線程/進程是唯一的。優點是快速高效，缺點時有限制，數據不靈活。［先進后出］

棧空間分靜態分配 和動態分配兩種。

堆區(heap) 由程序員分配和釋放，如果程序員不釋放，程序結束時，可能會由操作系統回收 ，比如在ios 中 alloc 都是存放在堆中。

優點是靈活方便，數據適應面廣泛，但是效率有一定降低。

雖然程序結束時所有的數據空間都會被釋放回系統，但是精確的申請內存，釋放內存匹配是良好程序的基本要素。

3.全局區(靜態區) (static) 全局變量和靜態變量的存儲是放在一起的，初始化的全局變量和靜態變量存放在一塊區域，未初始化的全局變量和靜態變量在相鄰的另一塊區域，程序結束后有系統釋放。

4.文字常量區 存放常量字符串，程序結束后由系統釋放；

5.代碼區 存放函數的二進制代碼

大致如圖：

例子代碼：

可能被追問的問題一：

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

局部變量是保存在棧區的

方法調用的實參也是保存在棧區的

2.堆區 (heap [hi?p]): 由程序員分配釋放，若程序員不釋放，會出現內存泄漏，賦值語句右側 使用 new 方法創建的對象，被創建對象的所有 成員變量！

3.BSS 段 : 程序結束后由系統釋放

4.數據段 : 程序結束后由系統釋放

5.代碼段:程序結束后由系統釋放

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

可能被追問的問題二：

比如申請后的系統是如何響應的？

棧：存儲每一個函數在執行的時候都會向操作系統索要資源，棧區就是函數運行時的內存，棧區中的變量由編譯器負責分配和釋放，內存隨著函數的運行分配，隨著函數的結束而釋放，由系統自動完成。

注意：只要棧的剩余空間大于所申請空間，系統將為程序提供內存，否則將報異常提示棧溢出。

堆：

1.首先應該知道操作系統有一個記錄空閑內存地址的鏈表。

2.當系統收到程序的申請時，會遍歷該鏈表，尋找第一個空間大于所申請空間的堆結點，然后將該結點從空閑結點鏈表中刪除，并將該結點的空間分配給程序。

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

可能被追問的問題三：

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

棧：棧是向低地址擴展的數據結構，是一塊連續的內存的區域。是棧頂的地址和棧的最大容量是系統預先規定好的，棧的大小是2M（也有的說是1M，總之是一個編譯時就確定的常數 ) ,如果申請的空間超過棧的剩余空間時，將提示overflow。因此，能從棧獲得的空間較小。

堆：堆是向高地址擴展的數據結構，是不連續的內存區域。這是由于系統是用鏈表來存儲的空閑內存地址的，自然是不連續的，而鏈表的遍歷方向是由低地址向高地址。堆的大小受限于計算機系統中有效的虛擬內存。由此可見，堆獲得的空間比較靈活，也比較大。

棧：由系統自動分配，速度較快，不會產生內存碎片

堆：是由alloc分配的內存，速度比較慢，而且容易產生內存碎片，不過用起來最方便

打個比喻來說：

使用棧就象我們去飯館里吃飯，只管點菜（發出申請）、付錢、和吃（使用），吃飽了就走，不必理會切菜、洗菜等準備工作和洗碗、刷鍋等掃尾工作，他的好處是快捷，但是自由度小。

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

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

實現代碼的高內聚低耦合，方便多人多團隊開發！

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

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

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

3.業務方的開發效率不夠高（只關心自己的組件，卻要編譯整個項目，與其他不相干的代碼糅合在一起）

先來看下，組件化之后的一個大概架構

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

組件間通信

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

首頁只需調用[MGJRouter openURL:@'mgj://detail?id=404']就可以打開相應的詳情頁。

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

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

目前還有一塊沒有做，就是參數這塊，雖然描述了短鏈，但真想要生成完整的 URL，還需要知道如何傳參數，這個正在開發中。

還有一種情況會稍微麻煩點，就是「組件A」要調用「組件B」的某個方法，比如在商品詳情頁要展示購物車的商品數量，就涉及到向購物車組件拿數據。

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

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

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

可以看到通過協議可以直接指定返回的數據類型。然后在購物車組件內再新建個類實現這個協議，假設這個類名為MGJCartImpl，接著就可以把它與協議關聯起來[ModuleManagerregisterClass:MGJCartImplforProtocol:@protocol(MGJCart)]，對于使用方來說，要拿到這個MGJCartImpl，需要調用[ModuleManagerclassForProtocol:@protocol(MGJCart)]。拿到之后再調用+ (NSInteger)orderCount就可以了。

那么，這個協議放在哪里比較合適呢？如果跟組件放在一起，使用時還是要先引入組件，如果有多個這樣的組件就會比較麻煩了。所以我們把這些公共的協議統一放到了PublicProtocolDomain.h下，到時只依賴這一個文件就可以了。

Android 也是采用類似的方式。

組件生命周期管理

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

先來看看現在的入口方法

其中[MGJApp startApp]主要負責一些 SDK 的初始化。[self trackLaunchTime]是我們打的一個點，用來監測從main方法開始到入口方法調用結束花了多長時間。其他的都由ModuleManager搞定，loadModuleFromPlist:pathForResource:方法會讀取 bundle 里的一個 plist 文件，這個文件的內容大概是這樣的

每個Module都實現了ModuleProtocol，其中有一個- (BOOL)applicaiton:didFinishLaunchingWithOptions:方法，如果實現了的話，就會被調用。

還有一個問題就是，系統的一些事件會有通知，比如applicationDidBecomeActive會有對應的UIApplicationDidBecomeActiveNotification，組件如果要做響應的話，只需監聽這個系統通知即可。但也有一些事件是沒有通知的，比如- application:didRegisterUserNotificationSettings:，這時組件如果也要做點事情，怎么辦？

一個簡單的解決方法是在AppDelegate的各個方法里，手動調一遍組件的對應的方法，如果有就執行。

殼工程

既然已經拆出去了，那拆出去的組件總得有個載體，這個載體就是殼工程，殼工程主要包含一些基礎組件和業務SDK，這也是主工程包含的一些內容，所以如果在殼工程可以正常運行的話，到了主工程也沒什么問題。不過這里存在版本同步問題，之后會說到。

遇到的問題

組件拆分

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

假如要把詳情頁遷出來，就會發現它依賴了一些其他部分的代碼，那最快的方式就是直接把代碼拷過來，改個名使用。比較簡單暴力。說起來比較簡單，做的時候也是挺有挑戰的，因為正常的業務并不會因為「組件化」而停止，所以開發同學們需要同時兼顧正常的業務和組件的拆分。

版本管理

我們的組件包括第三方庫都是通過 Cocoapods 來管理的，其中組件使用了私有庫。之所以選擇 Cocoapods，一個是因為它比較方便，還有就是用戶基數比較大，且社區也比較活躍（活躍到了會時不時地觸發 Github 的 rate limit，導致長時間 clone 不下來···見此），當然也有其他的管理方式，比如 submodule / subtree，在開發人員比較多的情況下，方便、靈活的方案容易占上風，雖然它也有自己的問題。主要有版本同步和更新/編譯慢的問題。

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

然后我們就想了個辦法，如果不在殼工程里指定基礎庫的版本，只在主工程里指定呢，理論上應該可行，只要不出現某個基礎庫要同時維護多個版本的情況。但實踐中發現，殼工程有時會莫名其妙地升不上去，在 podfile 里指定最新的版本又可以升上去，所以此路不通。

還有一個問題是pod update時間過長，經常會在Analyzing Dependency上卡 10 多分鐘，非常影響效率。后來排查下來是跟組件的 Podspec 有關，配置了 subspec，且依賴比較多。

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

持續集成

在剛開始，持續集成還不是很完善，業務方升級組件，直接把 podspec 扔到 private repo 里就完事了。這樣最簡單，但也經常會帶來編譯通不過的問題。而且這種隨意的版本升級也不太能保證質量。于是我們就搭建了一套持續集成系統，大概如此

每個組件升級之前都需要先通過編譯，然后再決定是否升級。這套體系看起來不復雜，但在實施過程中經常會遇到后端的并發問題，導致業務方要么集成失敗，要么要等不少時間。而且也沒有一個地方可以呈現當前版本的組件版本信息。還有就是業務方對于這種命令行的升級方式接受度也不是很高。

基于此，在經過了幾輪討論之后，有了新版的持續集成平臺，升級操作通過網頁端來完成。

大致思路是，業務方如果要升級組件，假設現在的版本是 0.1.7，添加了一些 feature 之后，殼工程測試通過，想集成到主工程里看看效果，或者其他組件也想引用這個最新的，就可以在后臺手動把版本升到 0.1.8-rc.1，這樣的話，原先依賴~> 0.1.7的組件，不會升到 0.1.8，同時想要測試這個組件的話，只要手動把版本調到 0.1.8-rc.1 就可以了。這個過程不會觸發 CI 的編譯檢查。

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

周邊設施

基礎組件及組件的文檔 / Demo / 單元測試

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

這就要求組件的負責人需要及時地更新 README / CHANGELOG / API，并且當發生 API 變更時，能夠快速通知到使用方。

公共 UI 組件

組件化之后還有一個問題就是資源的重復性，以前在一個工程里的時候，資源都可以很方便地拿到，現在獨立出去了，也不知道哪些是公用的，哪些是獨有的，索性都放到自己的組件里，這樣就會導致包變大。還有一個問題是每個組件可能是不同的產品經理在跟，而他們很可能只關注于自己關心的頁面長什么樣，而忽略了整體的樣式。公共

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

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

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

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

概述

類對象中有類方法和實例方法的列表，列表中記錄著方法的名詞、參數和實現，而selector本質就是方法名稱，runtime通過這個方法名稱就可以在列表中找到該方法對應的實現。

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

具體實現

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

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

而根據官方描述，第一種方法可能會更快一些

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

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

類方法（假設有一個類A）

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

實例方法

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

通過該傳入的參數不同，找到不同的方法列表，方法列表中保存著下面方法的結構體，結構體中包含這方法的實現，selector本質就是方法的名稱，通過該方法名稱，即可在結構體中找到相應的實現。

struct objc_method {SEL method_namechar *method_typesIMP method_imp}

而對于第二種方法而言，傳入的參數只有method，區分類方法和實例方法在于封裝method的函數

類方法

Method class_getClassMethod(Class cls, SEL name)

實例方法

Method class_getInstanceMethod(Class cls, SEL name)

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

實驗

這里有一個叫Test的類，在初始化方法里，調用了兩次getIMPFromSelector:方法，第一個aaa方法是不存在的，test1和test2分別為實例方法和類方法

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

大家注意圖中紅色標注的地址出現了8次：0x1102db280，這個是在調用class_getMethodImplementation()方法時，無法找到對應實現時返回的相同的一個地址，無論該方法是在實例方法或類方法，無論是否對一個實例調用該方法，返回的地址都是相同的，但是每次運行該程序時返回的地址并不相同，而對于另一種方法，如果找不到對應的實現，則返回0，在圖中我做了藍色標記。

還有一點有趣的是class_getClassMethod()的第一個參數無論傳入objc_getClass()還是objc_getMetaClass()，最終調用method_getImplementation()都可以成功的找到類方法的實現。

而class_getInstanceMethod()的第一個參數如果傳入objc_getMetaClass()，再調用method_getImplementation()時無法找到實例方法的實現卻可以找到類方法的實現。

4.runloop內部實現邏輯？

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

其內部代碼整理如下 ：

可以看到，實際上 RunLoop 就是這樣一個函數，其內部是一個 do-while 循環。當你調用 CFRunLoopRun() 時，線程就會一直停留在這個循環里；直到超時或被手動停止，該函數才會返回。

RunLoop 的底層實現

從上面代碼可以看到，RunLoop 的核心是基于 mach port 的，其進入休眠時調用的函數是 mach_msg()。為了解釋這個邏輯，下面稍微介紹一下 OSX/iOS 的系統架構。

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

應用層包括用戶能接觸到的圖形應用，例如 Spotlight、Aqua、SpringBoard 等。

應用框架層即開發人員接觸到的 Cocoa 等框架。

核心框架層包括各種核心框架、OpenGL 等內容。

Darwin 即操作系統的核心，包括系統內核、驅動、Shell 等內容，這一層是開源的，其所有源碼都可以在opensource.apple.com里找到。

我們在深入看一下 Darwin 這個核心的架構：

其中，在硬件層上面的三個組成部分：Mach、BSD、IOKit (還包括一些上面沒標注的內容)，共同組成了 XNU 內核。

XNU 內核的內環被稱作 Mach，其作為一個微內核，僅提供了諸如處理器調度、IPC (進程間通信)等非常少量的基礎服務。

BSD 層可以看作圍繞 Mach 層的一個外環，其提供了諸如進程管理、文件系統和網絡等功能。

IOKit 層是為設備驅動提供了一個面向對象(C++)的一個框架。

Mach

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

API，但是這些API非常基礎，如果沒有這些API的話，其他任何工作都無法實施。在 Mach

中，所有的東西都是通過自己的對象實現的，進程、線程和虛擬內存都被稱為'對象'。和其他架構不同， Mach

的對象間不能直接調用，只能通過消息傳遞的方式實現對象間的通信。'消息'是 Mach 中最基礎的概念，消息在兩個端口 (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 消息實際上就是一個二進制數據包 (BLOB)，其頭部定義了當前端口 local_port 和目標端口 remote_port，

發送和接受消息是通過同一個 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);

為了實現消息的發送和接收，mach_msg()

函數實際上是調用了一個 Mach 陷阱 (trap)，即函數mach_msg_trap()，陷阱這個概念在 Mach

中等同于系統調用。當你在用戶態調用 mach_msg_trap() 時會觸發陷阱機制，切換到內核態；內核態中內核實現的 mach_msg()

函數會完成實際的工作，如下圖：

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

RunLoop

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

消息過來，內核會將線程置于等待狀態。例如你在模擬器里跑起一個 iOS 的 App，然后在 App 靜止時點擊暫停，你會看到主線程調用棧是停留在

mach_msg_trap() 這個地方。

關于具體的如何利用 mach port 發送信息，可以看看NSHipster 這一篇文章，或者這里的中文翻譯 。

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

蘋果用 RunLoop 實現的功能

首先我們可以看一下 App 啟動后 RunLoop 的狀態：

可以看到，系統默認注冊了5個Mode:

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

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

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

4: GSEventReceiveRunLoopMode: 接受系統事件的內部 Mode，通常用不到。

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

你可以在這里看到更多的蘋果內部的 Mode，但那些 Mode 在開發中就很難遇到了。

5.你理解的多線程？

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

2.生命周期是如何管理？

3.你更傾向于哪種？追問至現在常用的兩種你的看法是？

第一種：pthread

.特點：

1）一套通用的多線程API

2）適用于UnixLinuxWindows等系統

3）跨平臺可移植

4）使用難度大

b.使用語言：c語言

c.使用頻率：幾乎不用

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

第二種：NSThread

a.特點：

1）使用更加面向對象

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

b.使用語言：OC語言

c.使用頻率：偶爾使用

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

第三種：GCD

a.特點：

1）旨在替代NSThread等線程技術

2）充分利用設備的多核（自動）

b.使用語言：C語言

c.使用頻率：經常使用

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

第四種：NSOperation

a.特點：

1）基于GCD（底層是GCD）

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

3）使用更加面向對象

b.使用語言：OC語言

c.使用頻率：經常使用

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

多線程的原理

同一時間，CPU只能處理1條線程，只有1條線程在工作（執行）

多線程并發（同時）執行，其實是CPU快速地在多條線程之間調度（切換）

如果CPU調度線程的時間足夠快，就造成了多線程并發執行的假象

思考：如果線程非常非常多，會發生什么情況？

CPU會在N多線程之間調度，CPU會累死，消耗大量的CPU資源

每條線程被調度執行的頻次會降低（線程的執行效率降低）

多線程的優點

能適當提高程序的執行效率

能適當提高資源利用率（CPU、內存利用率）

多線程的缺點

開啟線程需要占用一定的內存空間（默認情況下，主線程占用1M，子線程占用512KB），如果開啟大量的線程，會占用大量的內存空間，降低程序的性能

線程越多，CPU在調度線程上的開銷就越大

程序設計更加復雜：比如線程之間的通信、多線程的數據共享

你更傾向于哪一種？

傾向于GCD：

GCD

技術是一個輕量的，底層實現隱藏的神奇技術，我們能夠通過GCD和block輕松實現多線程編程，有時候，GCD相比其他系統提供的多線程方法更加有效，當然，有時候GCD不是最佳選擇，另一個多線程編程的技術

NSOprationQueue 讓我們能夠將后臺線程以隊列方式依序執行，并提供更多操作的入口，這和 GCD 的實現有些類似。

這種類似不是一個巧合，在早期，MacOX

與 iOS 的程序都普遍采用Operation

Queue來進行編寫后臺線程代碼，而之后出現的GCD技術大體是依照前者的原則來實現的，而隨著GCD的普及，在iOS 4 與 MacOS X

10.6以后，Operation Queue的底層實現都是用GCD來實現的。

那這兩者直接有什么區別呢？

1.GCD是底層的C語言構成的API，而NSOperationQueue及相關對象是Objc的對象。在GCD中，在隊列中執行的是由block構成的任務，這是一個輕量級的數據結構；而Operation作為一個對象，為我們提供了更多的選擇；

2.在NSOperationQueue中，我們可以隨時取消已經設定要準備執行的任務(當然，已經開始的任務就無法阻止了)，而GCD沒法停止已經加入queue的block(其實是有的，但需要許多復雜的代碼)；

3.NSOperation能夠方便地設置依賴關系，我們可以讓一個Operation依賴于另一個Operation，這樣的話盡管兩個Operation處于同一個并行隊列中，但前者會直到后者執行完畢后再執行；

4.我們能將KVO應用在NSOperation中，可以監聽一個Operation是否完成或取消，這樣子能比GCD更加有效地掌控我們執行的后臺任務；

5.在NSOperation中，我們能夠設置NSOperation的priority優先級，能夠使同一個并行隊列中的任務區分先后地執行，而在GCD中，我們只能區分不同任務隊列的優先級，如果要區分block任務的優先級，也需要大量的復雜代碼；

6.我們能夠對NSOperation進行繼承，在這之上添加成員變量與成員方法，提高整個代碼的復用度，這比簡單地將block任務排入執行隊列更有自由度，能夠在其之上添加更多自定制的功能。

總的來說，Operation

queue

提供了更多你在編寫多線程程序時需要的功能，并隱藏了許多線程調度，線程取消與線程優先級的復雜代碼，為我們提供簡單的API入口。從編程原則來說，一般我們需要盡可能的使用高等級、封裝完美的API，在必須時才使用底層API。但是我認為當我們的需求能夠以更簡單的底層代碼完成的時候，簡潔的GCD或許是個更好的選擇，而Operation

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

傾向于：NSOperation

NSOperation相對于GCD：

1，NSOperation擁有更多的函數可用，具體查看api。NSOperationQueue 是在GCD基礎上實現的，只不過是GCD更高一層的抽象。

2，在NSOperationQueue中，可以建立各個NSOperation之間的依賴關系。

3，NSOperationQueue支持KVO。可以監測operation是否正在執行（isExecuted）、是否結束（isFinished），是否取消（isCanceld）

4，GCD 只支持FIFO 的隊列，而NSOperationQueue可以調整隊列的執行順序（通過調整權重）。NSOperationQueue可以方便的管理并發、NSOperation之間的優先級。

使用NSOperation的情況：各個操作之間有依賴關系、操作需要取消暫停、并發管理、控制操作之間優先級，限制同時能執行的線程數量.讓線程在某時刻停止/繼續等。

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

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

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

5.你理解的多線程？

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

2.生命周期是如何管理？

3.你更傾向于哪種？追問至現在常用的兩種你的看法是？

第一種：pthread

.特點：

1）一套通用的多線程API

2）適用于UnixLinuxWindows等系統

3）跨平臺可移植

4）使用難度大

b.使用語言：c語言

c.使用頻率：幾乎不用

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

第二種：NSThread

a.特點：

1）使用更加面向對象

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

b.使用語言：OC語言

c.使用頻率：偶爾使用

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

第三種：GCD

a.特點：

1）旨在替代NSThread等線程技術

2）充分利用設備的多核（自動）

b.使用語言：C語言

c.使用頻率：經常使用

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

第四種：NSOperation

a.特點：

1）基于GCD（底層是GCD）

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

3）使用更加面向對象

b.使用語言：OC語言

c.使用頻率：經常使用

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

多線程的原理

同一時間，CPU只能處理1條線程，只有1條線程在工作（執行）

多線程并發（同時）執行，其實是CPU快速地在多條線程之間調度（切換）

如果CPU調度線程的時間足夠快，就造成了多線程并發執行的假象

思考：如果線程非常非常多，會發生什么情況？

CPU會在N多線程之間調度，CPU會累死，消耗大量的CPU資源

每條線程被調度執行的頻次會降低（線程的執行效率降低）

多線程的優點

能適當提高程序的執行效率

能適當提高資源利用率（CPU、內存利用率）

多線程的缺點

開啟線程需要占用一定的內存空間（默認情況下，主線程占用1M，子線程占用512KB），如果開啟大量的線程，會占用大量的內存空間，降低程序的性能

線程越多，CPU在調度線程上的開銷就越大

程序設計更加復雜：比如線程之間的通信、多線程的數據共享

你更傾向于哪一種？

傾向于GCD：

GCD

技術是一個輕量的，底層實現隱藏的神奇技術，我們能夠通過GCD和block輕松實現多線程編程，有時候，GCD相比其他系統提供的多線程方法更加有效，當然，有時候GCD不是最佳選擇，另一個多線程編程的技術

NSOprationQueue 讓我們能夠將后臺線程以隊列方式依序執行，并提供更多操作的入口，這和 GCD 的實現有些類似。

這種類似不是一個巧合，在早期，MacOX

與 iOS 的程序都普遍采用Operation

Queue來進行編寫后臺線程代碼，而之后出現的GCD技術大體是依照前者的原則來實現的，而隨著GCD的普及，在iOS 4 與 MacOS X

10.6以后，Operation Queue的底層實現都是用GCD來實現的。

那這兩者直接有什么區別呢？

1.GCD是底層的C語言構成的API，而NSOperationQueue及相關對象是Objc的對象。在GCD中，在隊列中執行的是由block構成的任務，這是一個輕量級的數據結構；而Operation作為一個對象，為我們提供了更多的選擇；

2.在NSOperationQueue中，我們可以隨時取消已經設定要準備執行的任務(當然，已經開始的任務就無法阻止了)，而GCD沒法停止已經加入queue的block(其實是有的，但需要許多復雜的代碼)；

3.NSOperation能夠方便地設置依賴關系，我們可以讓一個Operation依賴于另一個Operation，這樣的話盡管兩個Operation處于同一個并行隊列中，但前者會直到后者執行完畢后再執行；

4.我們能將KVO應用在NSOperation中，可以監聽一個Operation是否完成或取消，這樣子能比GCD更加有效地掌控我們執行的后臺任務；

5.在NSOperation中，我們能夠設置NSOperation的priority優先級，能夠使同一個并行隊列中的任務區分先后地執行，而在GCD中，我們只能區分不同任務隊列的優先級，如果要區分block任務的優先級，也需要大量的復雜代碼；

6.我們能夠對NSOperation進行繼承，在這之上添加成員變量與成員方法，提高整個代碼的復用度，這比簡單地將block任務排入執行隊列更有自由度，能夠在其之上添加更多自定制的功能。

總的來說，Operation

queue

提供了更多你在編寫多線程程序時需要的功能，并隱藏了許多線程調度，線程取消與線程優先級的復雜代碼，為我們提供簡單的API入口。從編程原則來說，一般我們需要盡可能的使用高等級、封裝完美的API，在必須時才使用底層API。但是我認為當我們的需求能夠以更簡單的底層代碼完成的時候，簡潔的GCD或許是個更好的選擇，而Operation

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

傾向于：NSOperation

NSOperation相對于GCD：

1，NSOperation擁有更多的函數可用，具體查看api。NSOperationQueue 是在GCD基礎上實現的，只不過是GCD更高一層的抽象。

2，在NSOperationQueue中，可以建立各個NSOperation之間的依賴關系。

3，NSOperationQueue支持KVO。可以監測operation是否正在執行（isExecuted）、是否結束（isFinished），是否取消（isCanceld）

4，GCD 只支持FIFO 的隊列，而NSOperationQueue可以調整隊列的執行順序（通過調整權重）。NSOperationQueue可以方便的管理并發、NSOperation之間的優先級。

使用NSOperation的情況：各個操作之間有依賴關系、操作需要取消暫停、并發管理、控制操作之間優先級，限制同時能執行的線程數量.讓線程在某時刻停止/繼續等。

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

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

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

6.GCD執行原理？

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

而我們程序員需要關心的是什么呢？我們只關心的是向隊列中添加任務，隊列調度即可。

如果隊列中存放的是同步任務，則任務出隊后，底層線程池中會提供一條線程供這個任務執行，任務執行完畢后這條線程再回到線程池。這樣隊列中的任務反復調度，因為是同步的，所以當我們用currentThread打印的時候，就是同一條線程。

如果隊列中存放的是異步的任務，（注意異步可以開線程），當任務出隊后，底層線程池會提供一個線程供任務執行，因為是異步執行，隊列中的任務不需等待當前任務執行完畢就可以調度下一個任務，這時底層線程池中會再次提供一個線程供第二個任務執行，執行完畢后再回到底層線程池中。

這樣就對線程完成一個復用，而不需要每一個任務執行都開啟新的線程，也就從而節約的系統的開銷，提高了效率。在iOS7.0的時候，使用GCD系統通常只能開5~8條線程，iOS8.0以后，系統可以開啟很多條線程，但是實在開發應用中，建議開啟線程條數：3~5條最為合理。

通過案例明白GCD的執行原理

案例一：

分析：

首先執行任務1，這是肯定沒問題的，只是接下來，程序遇到了同步線程，那么它會進入等待，等待任務2執行完，然后執行任務3。但這是隊列，有任務來，當然會將任務加到隊尾，然后遵循FIFO原則執行任務。那么，現在任務2就會被加到最后，任務3排在了任務2前面，問題來了：

任務3要等任務2執行完才能執行，任務2又排在任務3后面，意味著任務2要在任務3執行完才能執行，所以他們進入了互相等待的局面。【既然這樣，那干脆就卡在這里吧】這就是死鎖。

案例二：

分析：

首先執行任務1，接下來會遇到一個同步線程，程序會進入等待。等待任務2執行完成以后，才能繼續執行任務3。從dispatch_get_global_queue可以看出，任務2被加入到了全局的并行隊列中，當并行隊列執行完任務2以后，返回到主隊列，繼續執行任務3。

案例三：

案例四：

分析：

首先，將【任務1、異步線程、任務5】加入Main

Queue中，異步線程中的任務是：【任務2、同步線程、任務4】。所以，先執行任務1，然后將異步線程中的任務加入到Global

Queue中，因為異步線程，所以任務5不用等待，結果就是2和5的輸出順序不一定。然后再看異步線程中的任務執行順序。任務2執行完以后，遇到同步線程。將同步線程中的任務加入到Main

Queue中，這時加入的任務3在任務5的后面。當任務3執行完以后，沒有了阻塞，程序繼續執行任務4。

案例五：

分析：

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

【異步線程、任務4、死循環、任務5】。

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

【任務1、同步線程、任務3】。第一個就是異步線程，任務4不用等待，

所以結果任務1和任務4順序不一定。任務4完成后，程序進入死循環，

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

繼續執行任務1后面的同步線程。同步線程中，將任務2加入到了主線程，

并且，任務3等待任務2完成以后才能執行。這時的主線程，已經被死循環阻塞了。

所以任務2無法執行，當然任務3也無法執行，在死循環后的任務5也不會執行。

7.怎么防止別人動態在你程序生成代碼？

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

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

1.本地數據加密

iOS應用防反編譯加密技術之一：對NSUserDefaults，sqlite存儲文件數據加密，保護帳號和關鍵信息

2.URL編碼加密

iOS應用防反編譯加密技術之二：對程序中出現的URL進行編碼加密，防止URL被靜態分析

3.網絡傳輸數據加密

iOS應用防反編譯加密技術之三：對客戶端傳輸數據提供加密方案，有效防止通過網絡接口的攔截獲取數據

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

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

5.程序結構混排加密

iOS應用防反編譯加密技術之五：對應用程序邏輯結構進行打亂混排，保證源碼可讀性降到最低

6.借助第三方APP加固，例如：網易云易盾

8.YYAsyncLayer如何異步繪制？

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

YYKitDemo

對于列表主要對兩個代理方法的優化，一個與繪制顯示有關，另一個與計算布局有關：

Objective-C

1

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

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

常規邏輯可能覺得應該先調用tableView : cellForRowAtIndexPath :返回UITableViewCell對象，事實上調用順序是先返回UITableViewCell的高度，是因為UITableView繼承自UIScrollView，滑動范圍由屬性contentSize來確定，UITableView的滑動范圍需要通過每一行的UITableViewCell的高度計算確定，復雜cell如果在列表滾動過程中計算可能會造成一定程度的卡頓。

假設有20條數據，當前屏幕顯示5條，tableView : heightForRowAtIndexPath :方法會先執行20次返回所有高度并計算出滑動范圍，tableView : cellForRowAtIndexPath :執行５次返回當前屏幕顯示的cell個數。

從圖中簡單看下流程，從網絡請求返回JSON數據，將Cell的高度以及內部視圖的布局封裝為Layout對象，Cell顯示之前在異步線程計算好所有布局對象，并存入數組，每次調用tableView: heightForRowAtIndexPath :只需要從數組中取出，可避免重復的布局計算。同時在調用tableView: cellForRowAtIndexPath :對Cell內部視圖異步繪制布局，以及圖片的異步繪制解碼，這里就要說到今天的主角YYAsyncLayer。

YYAsyncLayer

首先介紹里面幾個類：

YYAsyncLayer：繼承自CALayer，繪制、創建繪制線程的部分都在這個類。

YYTransaction：用于創建RunloopObserver監聽MainRunloop的空閑時間，并將YYTranaction對象存放到集合中。

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

AsyncDisplay.png

上圖是整體異步繪制的實現思路，后面一步步說明。現在假設需要繪制Label，其實是繼承自UIView，重寫+ (Class)layerClass，在需要重新繪制的地方調用下面方法，比如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，監聽MainRunloop在kCFRunLoopCommonModes（包含kCFRunLoopDefaultMode、UITrackingRunLoopMode）下的kCFRunLoopBeforeWaiting和kCFRunLoopExit的狀態，也就是說在一次Runloop空閑時去執行更新顯示的操作。

kCFRunLoopBeforeWaiting：Runloop將要進入休眠。

kCFRunLoopExit：即將退出本次Runloop。

Objective-C

staticvoidYYTransactionSetup(){staticdispatch_once_tonceToken;dispatch_once(&onceToken,^{transactionSet=[NSMutableSetnew];CFRunLoopRefrunloop=CFRunLoopGetMain();CFRunLoopObserverRefobserver;observer=CFRunLoopObserverCreate(CFAllocatorGetDefault(),kCFRunLoopBeforeWaiting|kCFRunLoopExit,true,// repeat0xFFFFFF,// after CATransaction(2000000)YYRunLoopObserverCallBack,NULL);CFRunLoopAddObserver(runloop,observer,kCFRunLoopCommonModes);CFRelease(observer);});}

下面是RunloopObserver的回調方法，從transactionSet取出transaction對象執行SEL的方法，分發到每一次Runloop執行，避免一次Runloop執行時間太長。

Objective-CstaticvoidYYRunLoopObserverCallBack(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時提交大量并發任務到后臺線程導致線程被鎖住、休眠的情況，創建與程序當前激活CPU數量（activeProcessorCount）相同的串行隊列，并限制MAX_QUEUE_COUNT，將隊列存放在數組中。

YYAsyncLayer.m有一個方法YYAsyncLayerGetDisplayQueue來獲取這個隊列用于繪制（這部分YYKit中有獨立的工具YYDispatchQueuePool）。創建隊列中有一個參數是告訴隊列執行任務的服務質量quality of service，在iOS8+之后相比之前系統有所不同。

iOS8之前隊列優先級：

DISPATCH_QUEUE_PRIORITY_HIGH 2高優先級DISPATCH_QUEUE_PRIORITY_DEFAULT 0默認優先級DISPATCH_QUEUE_PRIORITY_LOW (-2)低優先級DISPATCH_QUEUE_PRIORITY_BACKGROUND INT16_MIN后臺優先級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_hreturnYYDispatchQueueGetForQOS(NSQualityOfServiceUserInitiated);#else#define MAX_QUEUE_COUNT 16staticintqueueCount;staticdispatch_queue_tqueues[MAX_QUEUE_COUNT];//存放隊列的數組staticdispatch_once_tonceToken;staticint32_tcounter=0;dispatch_once(&onceToken,^{//程序激活的處理器數量queueCount=(int)[NSProcessInfoprocessInfo].activeProcessorCount;queueCount=queueCountMAX_QUEUE_COUNT?MAX_QUEUE_COUNT: queueCount);if([UIDevicecurrentDevice].systemVersion.floatValue>=8.0){for(NSUIntegeri=0;i

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

這里有必要了解關于后臺的繪制任務何時會被取消，下面兩種情況需要取消，并調用了YYSentinel的increase方法，使value值增加（線程安全）：

在視圖調用setNeedsDisplay時說明視圖的內容需要被更新，將當前的繪制任務取消，需要重新顯示。

以及視圖被釋放調用了dealloc方法。

在YYAsyncLayer.h中定義了YYAsyncLayerDisplayTask類，有三個block屬性用于繪制的回調操作，從命名可以看出分別是將要繪制，正在繪制，以及繪制完成的回調，可以從block傳入的參數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繪制的代碼，主要是一些邏輯判斷以及繪制函數，在異步執行之前通過YYAsyncLayerGetDisplayQueue創建的隊列，這里通過YYSentinel判斷當前的value是否等于之前的值，如果不相等，說明繪制任務被取消了，繪制過程會多次判斷是否取消，如果是則return，保證被取消的任務能及時退出，如果繪制完畢則設置圖片到layer.contents。

Objective-Cif(async){//異步if(task.willDisplay)task.willDisplay(self);YYSentinel*sentinel=_sentinel;int32_tvalue=sentinel.value;NSLog(@' --- %d ---',value);//判斷當前計數是否等于之前計數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.優化你是從哪幾方面著手？

一、首頁啟動速度

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

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

在合適的時機開始后臺任務（例如在用戶指引節目就可以開始準備加載的數據）

盡量減小包的大小

優化方法：

量化啟動時間

啟動速度模塊化

輔助工具（友盟，聽云，Flurry）

二、頁面瀏覽速度

json的處理（iOS 自帶的NSJSONSerialization，Jsonkit，SBJson）

數據的分頁（后端數據多的話，就要分頁返回，例如網易新聞，或者 微博記錄）

數據壓縮（大數據也可以壓縮返回，減少流量，加快反應速度）

內容緩存（例如網易新聞的最新新聞列表都是要緩存到本地，從本地加載，可以緩存到內存，或者數據庫，根據情況而定）

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

算法的優化（核心算法的優化，例如有些app 有個 聯系人姓名用漢語拼音的首字母排序）

三、操作流暢度優化：

Tableview 優化（tableview cell的加載優化）

ViewController加載優化（不同view之間的跳轉，可以提前準備好數據）

四、數據庫的優化：

數據庫設計上面的重構

查詢語句的優化

分庫分表（數據太多的時候，可以分不同的表或者庫）

五、服務器端和客戶端的交互優化：

客戶端盡量減少請求

服務端盡量做多的邏輯處理

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

通信協議的優化。（減少報文的大小）

電量使用優化（盡量不要使用后臺運行）

六、非技術性能優化

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

界面交互的規范（每個模塊的界面的交互盡量統一，符合操作習慣）

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

code review（堅持code Review 持續重構代碼。減少代碼的邏輯復雜度）

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

以上問題加參考答案，部分自己回答(群友回答)＋網上博客參考，回答的不好勿噴！

僅供學習使用！ 謝謝！

來自：http://www.cocoachina.com/ios/20171129/21362.html