Ios教程網 >> IOS編程開發 >> IOS開發基礎 >> alloc、init你弄懂50%了嗎？

alloc、init你弄懂50%了嗎？

編輯：IOS開發基礎

前言

這是一篇我記錄對alloc、init分析思考的筆記。如果讀者想看懂我的第二個思考，可能需要您至少了解內存的分段分頁管理，如果您對其一點都不知道，可以先看這篇軟文簡單了解一下。另外很重要的一點是，請先思考。

思考1.對象為什麼要alloc，init又是干嘛的？

很多人都知道，初始化一個對象應該這麼寫:

MyClass* myObj = [MyClass alloc] init];

那麼有沒有思考過為什麼呢？其實我這麼寫也是完全可以的：

MyClass *myObj = [MyClass alloc];
myObj = [myObj init];

我們來看看這干了啥。

alloc allocates a chunk of memory to hold the object, and returns the pointer.

就是說alloc分配了一坨內存給對象，讓它不釋放，並且把地址返回給指針。

MyClass *myObj = [MyClass alloc];

那麼這樣過後myobj為什麼不能被使用呢？這是因為這片內存還沒有被正確的初始化。

舉個栗子，萬達要修房子，他們第一步一定是要先向政府搞到一塊地，第二步才能在這塊地上動工修樓。

這裡操作系統就是政府，alloc就是去爭地，init就是在地上修房子。沒有調用init，房子都沒有修好，別人怎麼買房進去住？所以我們需要用init來初始化這片內存：

-init{
     self=[super init]; // 1.
     if(self){          // 2.
         ....
     }
     return self;       // 3.
}

第一步需要初始化父類的信息，比如實例變量等等。可以理解成王思聰在修房子前要詢問他老爸的意見，他老爸說想娛樂會所，他沒有意見的話就會修成娛樂會所，他如果有意見，就可以悄悄的在第二步裡面改為修成LOL俱樂部。第三步就不說了。

最後提醒一下，不要這樣寫:

MyClass* myObj = [MyClass alloc];
myObj=[myObj init];

因為你可能會忘記在第二行加init，並且代碼也會增長。

思考2.關於alloc的思考

在思考1中我們說了：alloc分配了一坨內存給對象，讓它不釋放，並且把地址返回給指針。這裡主要有兩個問題：

調用alloc後內存是直接映射到堆還是只分配給了虛擬內存？
這一坨內存到底是多大？

我們依次來展開。

可能有些讀者不明白第一個問題是什麼意思，這裡需要額外講一些關於內存的東西，其實這是iOS開發很重要的東西，不管是面試還是學習都可能會用到。

>額外的東西

iOS裡的內存是有分類的，它分成Clean Memory和Dirty Memory。顧名思義，Clean Memory是可以被操作系統回收的，Dirty Memory是不可被操作系統回收的。

Clean Memory:在閃存中有備份，能再次讀取重建。如：

Code(代碼段)，framework，memory-mapped files

Dirty Memory:所有非Clean Memory，如：

被分配了的堆空間，image cache

舉個栗子，在這樣的代碼中：

- (void)dirtyOrCleanMemory
{
    NSString *str1 = [NSString stringWithString:@"Welcome!"];// 1.
    NSString *str2 = @"Welcome"; // 2.
    char *buf = malloc(100 * 1024 * 1024); // 3.分配100M內存給buf
    for (int i = 0; i < 3 * 1024 * 1024; ++i) {
        buf[i] = rand();
    } // 4.buf的前3M內存被賦值
}

對每行分析：

1.Dirty Memory。

因為stringWithString:是在堆上分配內存的，如果我們不回收它的話，系統會一直占用這塊內存。

2.Clean Memory。

因為用這樣的方法創建的是一個常量字符串，常量字符串是放在只讀數據段的，如果這塊內存被釋放了，而我們又訪問它的時候，操作系統可以在只讀數據段中把值再讀取出來重建這塊內存。(ps:所以用這種方法創建的string是沒有引用計數的。)

接下來的知識就是引出思考問題1、2比較重要的點了：

3.Clean Memory。

這個時候buf指向的100M內存區域是Clean Memory的，因為操作系統是很懶的，只有當我們要用到這塊區域的時候才會映射到物理內存，沒有使用的時候只會分配一塊虛擬內存給buf。讀起來很繞口，上張圖：

可以看到虛擬內存和物理內存沒有映射關系，所以是Clean Memory的。

4.Dirty & Clean Memory混合。

前3M是Dirty Memory，後97M是Clean Memory。這句for語句執行完成後，buf的前3M內存被賦值，也就是buf的前3M被使用了，所以這個時候的映射關系是這樣的：

額外的東西Done.

回到主線

調用alloc後內存是直接映射到堆(物理內存)還是只分配給了虛擬內存？
一坨內存的一坨是多大？

這個時候我們的第一個問題讀者應該能明白了。那麼我們怎麼驗證alloc是直接映射到堆上還是只分配給虛擬內存呢？這個問題讓我想了好些天，最後xo哥想到了一劑良藥來驗證，那就是用instrument來推反。

使用instrument來證反

我們假設的論點是：對象收到alloc消息後只在虛擬內存分配空間。

這裡需要一丁點代碼。

1.我們隨便新建個工程。

2.然後做個model類：

#import @interface XOModel : NSObject
{
    int a1;
    NSString *a2;
}
@end

3.在controller裡給view加一個點擊事件：

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
    for (int i = 0; i < 100000; ++i) {
        XOModel *model = [XOModel alloc]; // 注意這句只有alloc
        [self.array addObject:model];
    }
}

4.打開instrument的alloction，運行觸發一下點擊事件，查看如下：

(圖解：Persistent bytes表示所有的這類東西在堆裡的大小，Persistent表示所有的這類東西的個數.)

我們發現發現在Persistent bytes(堆)裡實實在在地分配給了XOModel 3.05MB的空間。

我們再觸發一下點擊事件：

發現堆分配給了XOModel的大小空間變成了原來的兩倍6.10MB。

結論過渡：如果對象收到alloc消息只在虛擬內存分配空間，那麼persistent bytes(堆)裡是不會分配給XOModel大小的，也就是說這裡的persistent bytes大小應該是0。所以問題1的結論如下：

結論：alloc不只分配在虛擬內存，同時會在物理內存建立映射。

對象的內存分配

最後剩下我們的最後一個問題：類對象收到alloc消息後，操作系統會分配出來的一坨內存是多大？

3.05M的大小是100000個XOModel對象的總和，那麼一個XOModel的實例對象，操作系統會給他分配多大的空間呢？很簡單嘛，3.05M/100000就得到了，等等，難道你真准備這樣去算？好吧，其實一開始我真這樣想過，但是這肯定是算不出准確答案的，關鍵是你要去思考。

這裡有兩種辦法，我采用的第二種辦法。

第一種驗證方法還是instrument

我們可以修改一下觸發的代碼，然後重新刷新instrument查看XOModel大小，具體操作同上，不重復了：

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
    for (int i = 0; i < 1; ++i) { // 修改處
        XOModel *model = [XOModel alloc]; // 注意這句只有alloc
        [self.array addObject:model];
    }
}

第二種驗證辦法借用runtime

我們可以借助runtime來查看一個類對象所需要的內存大小。值得一提的是我最開始用的方法是class_getInstanceSize，原型如下：

/**
 * Returns the size of instances of a class.
 *
 * @param cls A class object.
 *
 * @return The size in bytes of instances of the class \e cls, or \c 0 if \e cls is \c Nil.
 */
OBJC_EXPORT size_t class_getInstanceSize(Class cls)
     __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);

貌似是我們需要的函數，但是我發現這個方法有bug，返回的size和instruments的值不同，後來又發現有人遇到同樣的問題，所以摘抄了另一種方法，代碼如下：

#import #import ...
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
    XOModel *model = [XOModel alloc];
    [self.array addObject:model];
    NSLog(@"Size of %@: %zd", NSStringFromClass([XOModel class]), malloc_size((__bridge const void *) model));
}

再貼下XOModel代碼：

#import @interface XOModel : NSObject
{
    int a1;
    NSString *a2;
}
@end

在iPhone 6(或其他64位)的機子上運行，輸出如下：

AllocTest[38470:2551068] Size of XOModel: 32

“啊咧，我一個int，一個指針你分給我32個字節，操作系統你是腦子進屎了嗎？”

我們再修改一下XOModel代碼，不要實例變量：

#import @interface XOModel : NSObject
{
}
@end

輸出如下：

AllocTest[38630:2562602] Size of XOModel: 16

“我靠，我什麼東西都沒有，操作系統你還要分給我16個字節，是不是傻？”

智慧的操作系統這樣做當然是有它自己的原因滴，這裡我們需要知道三個東西：

任何類對象都有一個isa指針，需要分配內存。
32位機子上指針大小為4字節，64位機子為8字節。
字節對齊。

第一點就不說了，不知道的話您多半也沒耐心看到現在了。

第二點貼個文檔圖，iOS7過後部分蘋果機就開始從32位操作系統轉到64位了，所以部分數據類型的大小也有變化，這裡我們主要關注例子中的指針：

現在，基於這兩點對樣例分析。

第一個樣例(類對象中一個int，一個NSString指針，一個isa指針)，64位操作系統上應該是4+8+8=20，然而輸出是32，不對。

第二個樣例(類對象中只有一個isa指針)，64位操作系統上應該是8，然而輸出是16，還是不對。why？

字節對齊

字節對齊我了解得也不是太多，簡單點講目的就是為了提高存取效率，概念就不展開了，可以看這個，我這裡就直接講原理了。先貼一份蘋果的文檔:

When allocating any small blocks of memory, remember that the granularity for blocks allocated by the malloc library is 16 bytes. Thus, the smallest block of memory you can allocate is 16 bytes and any blocks larger than that are a multiple of 16. For example, if you call malloc and ask for 4 bytes, it returns a block whose size is 16 bytes; if you request 24 bytes, it returns a block whose size is 32 bytes. Because of this granularity, you should design your data structures carefully and try to make them multiples of 16 bytes whenever possible.

有點長，簡單的意思就是：

當我們分配一塊內存的時候，假設需要的內存小於16個字節，操作系統會直接分配16個字節；加入需要的內存大於16個字節，操作系統會分配a*16個字節。舉個栗子，如果你調用malloc並且需要4個字節，系統會給你一塊16個字節的內存塊；如果你調用malloc並且需要24個字節，系統會給你一塊32個字節的內存塊。

現在再看我們的栗子，就可以直接上圖了：

第一個例子不對齊應該是20字節，對齊就是32字節。