從兩道面試題說起

一提到block大家肯定都知道要說的是迴圈引用。在arc中，如果兩個物件相互持有對方，就會造成迴圈引用，導致記憶體無法釋放。在block中，最常用的場景則是，self持有block，block中又持有了self。例如下方一段**：

@property (nonatmaic, copy) block datachanged;
- (void)setupmodel;
self.model = model;
}複製**

上面的這段**就會造成迴圈引用。那我們怎麼破除呢？通常的做法都是使用weakself來處理，即：

- (void)setupmodel ;
self.model = model;
}複製**

或許你還看到另外一種不是很一樣的版本：

- (void)setupmodel ;
self.model = model;
}複製**

對比一下，多了乙個strongself。那為什麼又要多加乙個strongself呢？

考慮一下下面的**，

__weak __typeof__(self) weakself = self;
dispatch_group_async(_operationsgroup, _operationsqueue, ^);
複製**

在dosomething時，weakself不會被釋放，但是在dosomethingelse時，weakself有可能被釋放。

這個時候就遇到了野指標問題，回答了一開始的題目。

在這裡就需要用到strongself，使用__strong確保在block內，strongself不會被釋放。

要說明這麼問題我們需要先了解一下在ios中，顯示的流程。

假設我們使用imagewithcontentsoffile:方法從磁碟中載入一張，這個時候的並沒有解壓縮；

然後將生成的uiimage賦值給uiimageview；

接著乙個隱式的catransaction捕獲到了uiimageview圖層樹的變化；

在主線程的下乙個run loop到來時，core animation提交了這個隱式的transaction，這個過程可能會對進行copy操作，而受是否位元組對齊等因素的影響，這個copy操作可能會涉及以下部分或全部步驟：

在上面的步驟中，我們提到了的解壓縮是乙個非常耗時的cpu操作，並且它預設是在主線程中執行的。那麼當需要載入的比較多時，就會對我們應用的響應性造成嚴重的影響，尤其是在快速滑動的列表上，這個問題會表現得更加突出。

這裡順便提一下imagenamed:和imagewithcontentsoffile:的區別，這兩個api都需要解碼，並且工作流程都是一致的。不過imagenamed:會做快取處理，在下一次用到相同的資源時，就會從快取裡面讀取。而imagewithcontentsoffile:則不會。所以網上大多文章都會告訴你，多次使用的小使用imagenamed:載入，一次性使用的大使用imagewithcontentsoffile:載入。

對於上面引用的流程中最後提到，當有大量滑動時就會造成主線程的卡頓，原因就是解碼在主線程中操作的。那有什麼辦法避免呢？我在查詢關於這個問題的相關資料時，發現有些部落格給出了2種方案：

我們不使用imagenamed:載入，使用其他的方法，比如imagewithcontentsoffile:

我們自己解碼，可以把這個解碼過程放到子執行緒

其實第一種方式沒法避免卡頓。這就引出了為什麼sdwebimage中需要自己解碼。

在我們使用uiimage的時候，建立的通常不會直接載入到記憶體，而是在渲染的時候再進行解壓並載入到記憶體。這就會導致uiimage在渲染的時候效率上不是那麼高效。為了提高效率通過decodedimagewithimage方法把提前解壓載入到記憶體，這樣這張新就不再需要重複解壓了，提高了渲染效率。這是一種空間換時間的做法。

從兩道面試題說起

兩道SQL面試題

兩道概率面試題

python面試題兩道

從兩道面試題說起

兩道SQL面試題

兩道概率面試題

python面試題兩道

相關推薦