這篇文章可能有點(diǎn)長(zhǎng)，所以分了三篇文章記錄。內(nèi)容來自網(wǎng)上的面試題以及自己面試過程中遇到的問題總結(jié)，也會(huì)定期更新，不合理的地方歡迎指正。

• 更多技術(shù)題合集：

iOS技術(shù)題大全（上）

iOS技術(shù)題大全（中）

iOS技術(shù)題大全（下）

提升iOS開發(fā)技能學(xué)習(xí)網(wǎng)址：docs.qq.com/doc/DVWlQam9Qd3B1cEF2

為自己的面試，為自己的跳槽，加油吧 iOS開發(fā)

一、分類和擴(kuò)展

• 分類和擴(kuò)展有什么區(qū)別？

category

1、分類給類添加方法
2、不能通過正常模式給類添加屬性，但是可以通過 runtime 添加
3、如果在分類中通過@property定義屬性，那么只會(huì)對(duì)屬性的 getter setter 方法進(jìn)行聲明，不會(huì)實(shí)現(xiàn)。同時(shí)也不會(huì)生成帶下劃線的成員變量
4、在運(yùn)行時(shí)才會(huì)編譯代碼

extension

1、擴(kuò)展可以看成是特殊的分類 匿名分類
2、可以給類添加屬性，私有
3、可以給類添加方法，也是私有
4、在編譯時(shí)期就會(huì)編譯，與 .h 文件中的@interface和.m文件里的@implement一起形成了一個(gè)完整的類
5、擴(kuò)展一般用來隱藏類的信息，所以使用擴(kuò)展的前提是要有類的源碼！所以針對(duì)系統(tǒng)自帶的類，是無法使用擴(kuò)展的。

為什么分類可以添加方法，而不能添加成員變量？？？

因?yàn)樵谶\(yùn)行時(shí)，類的內(nèi)部布局早已經(jīng)確定，如果添加實(shí)例變量，會(huì)破壞類的內(nèi)部布局。

• 分類的結(jié)構(gòu)體里面有哪些成員？

category 是一個(gè)指向類結(jié)構(gòu)體的指針，其結(jié)構(gòu)體的定義如下：

typedef struct objc_category *Category;

struct objc_category {
    char *category_name                          OBJC2_UNAVAILABLE; // 分類名
    char *class_name                             OBJC2_UNAVAILABLE; // 分類所屬的類名
    struct objc_method_list *instance_methods    OBJC2_UNAVAILABLE; // 實(shí)例方法列表
    struct objc_method_list *class_methods       OBJC2_UNAVAILABLE; // 類方法列表
    struct objc_protocol_list *protocols         OBJC2_UNAVAILABLE; // 分類所實(shí)現(xiàn)的協(xié)議列表
}

可以 與 objc_class 的結(jié)構(gòu)體進(jìn)行對(duì)比：

struct objc_class {
    Class isa  OBJC_ISA_AVAILABILITY;
#if !__OBJC2__
    Class super_class                       OBJC2_UNAVAILABLE;  // 父類
    const char *name                        OBJC2_UNAVAILABLE;  // 類名
    long version                            OBJC2_UNAVAILABLE;  // 類的版本信息，默認(rèn)為0
    long info                               OBJC2_UNAVAILABLE;  // 類信息，供運(yùn)行期使用的一些位標(biāo)識(shí)
    long instance_size                      OBJC2_UNAVAILABLE;  // 該類的實(shí)例變量大小
    struct objc_ivar_list *ivars            OBJC2_UNAVAILABLE;  // 該類的成員變量鏈表
    struct objc_method_list **methodLists   OBJC2_UNAVAILABLE;  // 方法定義的鏈表
    struct objc_cache *cache                OBJC2_UNAVAILABLE;  // 方法緩存
    struct objc_protocol_list *protocols    OBJC2_UNAVAILABLE;  // 協(xié)議鏈表
#endif
} OBJC2_UNAVAILABLE;

經(jīng)過對(duì)比，發(fā)現(xiàn)少了一個(gè) struct objc_ivar_list *ivars 成員變量列表?。?！這也就說明了 分類是不能添加成員變量的。

• 分類加載和方法調(diào)用順序

  1、 加載：先加載原始類的 load() 方法 ，再去加載 分類中的 load() 方法，如果有多個(gè)分類，則按照編譯順序加載

  2、調(diào)用：先調(diào)用分類中的方法，再去調(diào)用原始類中的方法，如果要是重名，則會(huì)覆蓋原始類中的方法（因?yàn)樵诜椒斜碇?，分類的方法?huì)排在原始類中同名方法的前面）。

二、atomic的實(shí)現(xiàn)機(jī)制；為什么不能保證絕對(duì)的線程安全（最好可以結(jié)合場(chǎng)景來說）？

• atomic

atomic

1、會(huì)對(duì)屬性的 setter/getter 方法進(jìn)行加鎖，這僅僅只能保證在 操作 setter/getter 方法是安全的。不能保證其他線程的安全
2、例如 : 線程1調(diào)用了某一屬性的setter方法并進(jìn)行到了一半,線程2調(diào)用其getter方法,那么會(huì)執(zhí)行完setter操作后,在執(zhí)行g(shù)etter操作,線程2會(huì)獲取到線程1 setter后的完整的值.
3、當(dāng)幾個(gè)線程同時(shí)調(diào)用同一屬性的setter、getter方法時(shí),會(huì)get到一個(gè)完整的值,但get到的值不可控。

例如 : 線程1 調(diào)用getter ，線程2 調(diào)用setter，線程3 調(diào)用setter，這3個(gè)線程并行同時(shí)開始,線程1會(huì)get到一個(gè)值,但是這個(gè)值不可控,可能是線程2,線程3 set之前的原始值,可能是線程2 set的值,也可能是線程3 set的值

• atomic是線程安全的嗎?

不是,很多文章談到atomic和nonatomic的區(qū)別時(shí),都說atomic是線程安全,其實(shí)這個(gè)說法是不準(zhǔn)確的.atomic只是對(duì)屬性的getter/setter方法進(jìn)行了加鎖操作,這種安全僅僅是set/get 的讀寫安全,并非真正意義上的線程安全,因?yàn)榫€程安全還有讀寫之外的其他操作

比如:如果當(dāng)一個(gè)線程正在get或set時(shí),又有另一個(gè)線程同時(shí)在進(jìn)行release操作,可能會(huì)直接crash

• nonatomic

nonatomic

系統(tǒng)生成的getter/setter方法沒有加鎖線程不安全,但更快當(dāng)多個(gè)線程同時(shí)訪問同一個(gè)屬性,會(huì)出現(xiàn)無法預(yù)料的結(jié)果

• atomic的seter getter內(nèi)部實(shí)現(xiàn)

- (void)setCurrentImage:(UIImage *)currentImage
{
    @synchronized(self) {
        if (_currentImage != currentImage) {
            [_currentImage release];
            _currentImage = [currentImage retain];

        }
    }
}

- (UIImage *)currentImage
{
    @synchronized(self) {
        return _currentImage;
    }
}

• nonatomic的seter getter內(nèi)部實(shí)現(xiàn)

- (void)setCurrentImage:(UIImage *)currentImage
{
    if (_currentImage != currentImage) {
        [_currentImage release];
        _currentImage = [currentImage retain];

    }
}
- (UIImage *)currentImage
{
    return _currentImage;
}

三、被weak修飾的對(duì)象在被釋放的時(shí)候會(huì)發(fā)生什么？是如何實(shí)現(xiàn)的？知道sideTable么？里面的結(jié)構(gòu)可以畫出來么？

參考：http://m.itdecent.cn/p/b93d61418f17
這個(gè)問題在 數(shù)據(jù)結(jié)構(gòu)&&算法里面做了解答

四、關(guān)聯(lián)對(duì)象有什么應(yīng)用，系統(tǒng)如何管理關(guān)聯(lián)對(duì)象？其被釋放的時(shí)候需要手動(dòng)將其指針置空么？

我們?cè)?iOS 開發(fā)中經(jīng)常需要使用分類（Category），為已經(jīng)存在的類添加屬性的需求，但是使用 @property 并不能在分類中正確創(chuàng)建實(shí)例變量和存取方法。這時(shí)候就會(huì)用到關(guān)聯(lián)對(duì)象。

分類中的 @property

@interface DKObject : NSObject

@property (nonatomic, strong) NSString *property;

@end

在使用上述代碼時(shí)會(huì)做三件事：

• 生成帶下劃線的實(shí)例變量 _property
• 生成 getter 方法 - property
• 生成 setter 方法 - setProperty:

@implementation DKObject {
    NSString *_property;
}

- (NSString *)property {
    return _property;
}

- (void)setProperty:(NSString *)property {
    _property = property;
}

@end

這些代碼都是編譯器為我們生成的，雖然你看不到它，但是它確實(shí)在這里，我們既然可以在類中使用 @property 生成一個(gè)屬性，那么為什么在分類中不可以呢？

我們來做一個(gè)小實(shí)驗(yàn)：創(chuàng)建一個(gè) DKObject 的分類 Category，并添加一個(gè)屬性 categoryProperty：

@interface DKObject (Category)

@property (nonatomic, strong) NSString *categoryProperty;

@end

看起來還是很不錯(cuò)的，不過 Build 一下這個(gè) Demo，會(huì)發(fā)現(xiàn)有這么一個(gè)警告：

image

在這里的警告告訴我們 categoryProperty 屬性的存取方法需要自己手動(dòng)去實(shí)現(xiàn)，或者使用 @dynamic 在運(yùn)行時(shí)實(shí)現(xiàn)這些方法。

換句話說，分類中的 @property 并沒有為我們生成實(shí)例變量以及存取方法，而需要我們手動(dòng)實(shí)現(xiàn)。

使用關(guān)聯(lián)對(duì)象

Q：我們?yōu)槭裁匆褂藐P(guān)聯(lián)對(duì)象？

A：因?yàn)樵诜诸愔?@property 并不會(huì)自動(dòng)生成實(shí)例變量以及存取方法，所以一般使用關(guān)聯(lián)對(duì)象為已經(jīng)存在的類添加『屬性』。

以下是與關(guān)聯(lián)對(duì)象有關(guān)的 API，并在分類中實(shí)現(xiàn)一個(gè)偽屬性：

#import "DKObject+Category.h"
#import <objc/runtime.h>

@implementation DKObject (Category)

- (NSString *)categoryProperty {
    return objc_getAssociatedObject(self, _cmd);
}

- (void)setCategoryProperty:(NSString *)categoryProperty {
    objc_setAssociatedObject(self, @selector(categoryProperty), categoryProperty, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

@end

這里的 _cmd 代指當(dāng)前方法的選擇子，也就是 @selector(categoryProperty)。

我們使用了兩個(gè)方法 objc_getAssociatedObject 以及 objc_setAssociatedObject 來模擬『屬性』的存取方法，而使用關(guān)聯(lián)對(duì)象模擬實(shí)例變量。

在這里有必要解釋兩個(gè)問題：

• 為什么向方法中傳入 @selector(categoryProperty)？
• OBJC_ASSOCIATION_RETAIN_NONATOMIC 是干什么的？

關(guān)于第一個(gè)問題，我們需要看一下這兩個(gè)方法的原型：

id objc_getAssociatedObject(id object, const void *key);
void objc_setAssociatedObject(id object, const void *key, id value, objc_AssociationPolicy policy);

@selector(categoryProperty) 也就是參數(shù)中的key，其實(shí)可以使用靜態(tài)指針 static void *類型的參數(shù)來代替，不過在這里，筆者強(qiáng)烈推薦使用 @selector(categoryProperty) 作為 key 傳入。因?yàn)檫@種方法省略了聲明參數(shù)的代碼，并且能很好地保證 key 的唯一性。

OBJC_ASSOCIATION_RETAIN_NONATOMIC 又是什么呢？如果我們使用 Command 加左鍵查看它的定義：

typedef OBJC_ENUM(uintptr_t, objc_AssociationPolicy) {
    OBJC_ASSOCIATION_ASSIGN = 0,           /**< Specifies a weak reference to the associated object. */
    OBJC_ASSOCIATION_RETAIN_NONATOMIC = 1, /**< Specifies a strong reference to the associated object. 
                                            *   The association is not made atomically. */
    OBJC_ASSOCIATION_COPY_NONATOMIC = 3,   /**< Specifies that the associated object is copied. 
                                            *   The association is not made atomically. */
    OBJC_ASSOCIATION_RETAIN = 01401,       /**< Specifies a strong reference to the associated object.
                                            *   The association is made atomically. */
    OBJC_ASSOCIATION_COPY = 01403          /**< Specifies that the associated object is copied.
                                            *   The association is made atomically. */
};

從這里的注釋我們能看到很多東西，也就是說不同的 objc_AssociationPolicy 對(duì)應(yīng)了不通的屬性修飾符：

而我們?cè)诖a中實(shí)現(xiàn)的屬性 categoryProperty 就相當(dāng)于使用了 nonatomic 和 strong 修飾符。

在obj dealloc時(shí)候會(huì)調(diào)用object_dispose，檢查有無關(guān)聯(lián)對(duì)象，有的話_object_remove_assocations刪除

五、KVO的底層實(shí)現(xiàn)？如何取消系統(tǒng)默認(rèn)的KVO并手動(dòng)觸發(fā)（給KVO的觸發(fā)設(shè)定條件：改變的值符合某個(gè)條件時(shí)再觸發(fā)KVO）？

實(shí)現(xiàn)原理：

image

• 當(dāng)某個(gè)類的對(duì)象第一次被觀察時(shí)，系統(tǒng)就會(huì)在運(yùn)行期動(dòng)態(tài)地創(chuàng)建該類的一個(gè)派生類，在這個(gè)派生類中重寫基類中任何被觀察屬性的 setter 方法。
• 派生類在被重寫的 setter 方法中實(shí)現(xiàn)真正的通知機(jī)制，就如前面手動(dòng)實(shí)現(xiàn)鍵值觀察那樣。這么做是基于設(shè)置屬性會(huì)調(diào)用 setter 方法，而通過重寫就獲得了 KVO 需要的通知機(jī)制。當(dāng)然前提是要通過遵循 KVO 的屬性設(shè)置方式來變更屬性值，如果僅是直接修改屬性對(duì)應(yīng)的成員變量，是無法實(shí)現(xiàn) KVO 的。
• 同時(shí)派生類還重寫了 class 方法以“欺騙”外部調(diào)用者它就是起初的那個(gè)類。然后系統(tǒng)將這個(gè)對(duì)象的 isa 指針指向這個(gè)新誕生的派生類，因此這個(gè)對(duì)象就成為該派生類的對(duì)象了，因而在該對(duì)象上對(duì) setter 的調(diào)用就會(huì)調(diào)用重寫的 setter，從而激活鍵值通知機(jī)制。此外，派生類還重寫了 dealloc 方法來釋放資源。

KVO與Notification之間的區(qū)別：

• notification是需要一個(gè)發(fā)送notification的對(duì)象，一般是notificationCenter，來通知觀察者。

• KVO是直接通知到觀察對(duì)象，并且邏輯非常清晰，實(shí)現(xiàn)步驟簡(jiǎn)單。

六、Autoreleasepool所使用的數(shù)據(jù)結(jié)構(gòu)是什么？AutoreleasePoolPage結(jié)構(gòu)體了解么？

每創(chuàng)建一個(gè)池子，會(huì)在首部創(chuàng)建一個(gè) 哨兵 對(duì)象,作為標(biāo)記

最外層池子的頂端會(huì)有一個(gè)next指針。當(dāng)鏈表容量滿了，就會(huì)在鏈表的頂端，并指向下一張表。

Autorelease對(duì)象什么時(shí)候釋放？

這個(gè)問題拿來做面試題，問過很多人，沒有幾個(gè)能答對(duì)的。很多答案都是“當(dāng)前作用域大括號(hào)結(jié)束時(shí)釋放”，顯然木有正確理解Autorelease機(jī)制。

在沒有手加Autorelease Pool的情況下，Autorelease對(duì)象是在當(dāng)前的runloop迭代結(jié)束時(shí)釋放的，而它能夠釋放的原因是系統(tǒng)在每個(gè)runloop迭代中都加入了自動(dòng)釋放池Push和Pop

例子：

__weak id reference = nil;
- (void)viewDidLoad {
    [super viewDidLoad];    NSString *str = [NSString stringWithFormat:@"sunnyxx"];    // str是一個(gè)autorelease對(duì)象，設(shè)置一個(gè)weak的引用來觀察它
    reference = str;
}
- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];    
    NSLog(@"%@", reference); 
    // Console: sunnyxx
}
- (void)viewDidAppear:(BOOL)animated {
    [super viewDidAppear:animated];    
    NSLog(@"%@", reference); 
    // Console: (null)
}

當(dāng)然，我們也可以手動(dòng)干預(yù)Autorelease對(duì)象的釋放時(shí)機(jī)：

- (void)viewDidLoad
{
    [super viewDidLoad];
    @autoreleasepool {        NSString *str = [NSString stringWithFormat:@"sunnyxx"];
    }    NSLog(@"%@", str); 
// Console: (null)
}

Autorelease原理

AutoreleasePoolPage

ARC下，我們使用@autoreleasepool{}來使用一個(gè)AutoreleasePool，隨后編譯器將其改寫成下面的樣子：

void *context = objc_autoreleasePoolPush();
// {}中的代碼objc_autoreleasePoolPop(context);

而這兩個(gè)函數(shù)都是對(duì)AutoreleasePoolPage的簡(jiǎn)單封裝，所以自動(dòng)釋放機(jī)制的核心就在于這個(gè)類。

AutoreleasePoolPage是一個(gè)C++實(shí)現(xiàn)的類

image

• AutoreleasePool并沒有單獨(dú)的結(jié)構(gòu)，而是由若干個(gè)AutoreleasePoolPage以雙向鏈表的形式組合而成（分別對(duì)應(yīng)結(jié)構(gòu)中的parent指針和child指針）。
• AutoreleasePool是按線程一一對(duì)應(yīng)的（結(jié)構(gòu)中的thread指針指向當(dāng)前線程）。
• AutoreleasePoolPage每個(gè)對(duì)象會(huì)開辟4096字節(jié)內(nèi)存（也就是虛擬內(nèi)存一頁的大?。松厦娴膶?shí)例變量所占空間，剩下的空間全部用來儲(chǔ)存autorelease對(duì)象的地址。
• 上面的id *next指針作為游標(biāo)指向棧頂最新add進(jìn)來的autorelease對(duì)象的下一個(gè)位置。
• 一個(gè)AutoreleasePoolPage的空間被占滿時(shí)，會(huì)新建一個(gè)AutoreleasePoolPage對(duì)象，連接鏈表，后來的autorelease對(duì)象在新的page加入。

所以，若當(dāng)前線程中只有一個(gè)AutoreleasePoolPage對(duì)象，并記錄了很多autorelease對(duì)象地址時(shí)內(nèi)存如下圖：

image

圖中的情況，這一頁再加入一個(gè)autorelease對(duì)象就要滿了（也就是next指針馬上指向棧頂），這時(shí)就要執(zhí)行上面說的操作，建立下一頁page對(duì)象，與這一頁鏈表連接完成后，新page的next指針被初始化在棧底（begin的位置），然后繼續(xù)向棧頂添加新對(duì)象。

所以，向一個(gè)對(duì)象發(fā)送- autorelease消息，就是將這個(gè)對(duì)象加入到當(dāng)前AutoreleasePoolPage的棧頂next指針指向的位置

釋放時(shí)刻

每當(dāng)進(jìn)行一次objc_autoreleasePoolPush調(diào)用時(shí)，runtime向當(dāng)前的AutoreleasePoolPage中add進(jìn)一個(gè)哨兵對(duì)象，值為0（也就是個(gè)nil），那么這一個(gè)page就變成了下面的樣子：

image

objc_autoreleasePoolPush的返回值正是這個(gè)哨兵對(duì)象的地址，被objc_autoreleasePoolPop(哨兵對(duì)象)作為入?yún)?，于是?/p>

1.根據(jù)傳入的哨兵對(duì)象地址找到哨兵對(duì)象所處的page

2.在當(dāng)前page中，將晚于哨兵對(duì)象插入的所有autorelease對(duì)象都發(fā)送一次- release消息，并向回移動(dòng)next指針到正確位置

3.補(bǔ)充2：從最新加入的對(duì)象一直向前清理，可以向前跨越若干個(gè)page，直到哨兵所在的page（在一個(gè)page中，是從高地址向低地址清理）

剛才的objc_autoreleasePoolPop執(zhí)行后，最終變成了下面的樣子：

image

嵌套的AutoreleasePool

知道了上面的原理，嵌套的AutoreleasePool就非常簡(jiǎn)單了，pop的時(shí)候總會(huì)釋放到上次push的位置為止，多層的pool就是多個(gè)哨兵對(duì)象而已，就像剝洋蔥一樣，每次一層，互不影響。

七、class_ro_t 和 class_rw_t 的區(qū)別？

Class的結(jié)構(gòu)

image

class_rw_t

class_rw_t里面的methods、properties、protocols是二維數(shù)組，是可讀可寫的，包含了類的初始內(nèi)容、分類的內(nèi)容

image

class_ro_t

class_ro_t里面的baseMethodList、baseProtocols、ivars、baseProperties是一維數(shù)組，是只讀的，包含了類的初始內(nèi)容

image

收錄文章來源