從兩道面試題說起

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

@property (nonatmaic, copy) block datachanged;

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

- (void)setupmodel ;

self.model = model;
}複製**

- (void)setupmodel ;

self.model = model;
}複製**

考慮一下下面的**，

__weak __typeof__(self) weakself = self;

dispatch_group_async(_operationsgroup, _operationsqueue, ^);
複製**

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

在這裡就需要用到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:

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

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

兩道SQL面試題

第一是.關於加班時間的問題 公司規定一周內最多只能加班和12個小時，多餘的要去掉，去掉的規則是 某天加班超過1h的才能去，而且是依次大致平均的去，最小單位是1小時 舉例 日期 工號 加班小時 周一 a001 6 周二 a001 2 週三 a001 1 周四 a001 5 周五 a001 7 共計加班...

兩道概率面試題

問題一 一根一公尺長的繩子，隨機斷成三段 求最短的一段的期望長度以及最長的一段的期望長度。分析 這道題實際是一道純粹的概率題，沒有太多技巧。自己有推導，但是概率論忘得差不多了，退出來的概率有點詭異 以後補充一下知識，再推導。先放一下 陳利人 給出的答案吧，比較簡略 有時間，我會補充乙個詳細的。問題二...

python面試題兩道

給乙個字串 123456789 在任意字元中間插入 四種運算子，使最後的計算結果等於50。例如你可以如此插入 1 56 7 89，使這個式子的最終結果等於50。輸出所有可能的式子結果。def make 50 self list str list self spr sum 50 for a in sp...