最近在優化項目雖說小優化一直在持續,大版本的優化也進行了兩個版本了但是bug列表依舊血淋淋的擺在那裡。有的看一眼也能找到問題所在但是有的就是想破頭也不知道問題在哪裡,畢竟整個項目經過了N個人的手代碼風格迥異閱讀起來也會有不小的困難,因此在這分享一下解決這些個bug之間遇到的問題和一些看似實用的方法。 ...
最近在優化項目雖說小優化一直在持續,大版本的優化也進行了兩個版本了但是bug列表依舊血淋淋的擺在那裡。有的看一眼也能找到問題所在但是有的就是想破頭也不知道問題在哪裡,畢竟整個項目經過了N個人的手代碼風格迥異閱讀起來也會有不小的困難,因此在這分享一下解決這些個bug之間遇到的問題和一些看似實用的方法。
首先是字典中插入nil
和數組中插入nil
以及數組的越界問題
有人就會說在插入之前和取數組元素之前判斷一下不就解決問題了嗎?
那麼你在字典中插入數據可能就是類似這樣的寫法:
NSMutableDictionary *mDict = [NSMutableDictionary dictionary]; [mDict setObject:(string ? : @"") forKey:@"key"];
也許大家會有這種想法:何必在這這麼判斷呢?寫一個公共方法或者巨集不就比這個簡潔嗎,事實確實如此,然而代碼中過多的使用巨集會在預處理階段消耗大量的時間從而削弱用戶體驗,也不知道是什麼原因導致在swift
中直接就取消了巨集這個東西
同樣的在數組中添加元素也是類似的寫法:
NSMutableArray *marr = [NSMutableArray array]; [marr addObject:(string ? : @"")];
獲取數組中的元素可能會是這樣子的:
if (index < marr.count) { NSString *elem = marr[index]; } else { NSLog(@"越界了"); }
上面這樣寫在實際項目中完全沒有問題,而且也是最簡單最暴力的寫法,然而人類的創造力是無限的,當然了作為程式員的我們更是有著一顆想要通過自己的雙手去改變世界的心(然而也只是想想並沒有什麼卵用),自然而然的就會衍生出各種各樣的寫法,比如將獲取數組元素修改為下麵這個樣子:
@interface NSArray (NHAdd) - (id)objectOrNilAtIndex:(NSUInteger) index; @end @implementation NSArray (NHAdd) - (id)objectOrNilAtIndex:(NSUInteger) index { return index < self.count ? self[index] : nil; } @end
看到這裡我相信大家都鬆了一口氣,再也不用寫上面無聊反覆的判斷了,只要在獲取數組元素的時候調用上面分類的方法一切崩潰問題都會迎刃而解。
然而現實總是殘酷的,殘酷的現實如下:
- 調用上面分類的方法那麼就意味著我們再也不能像這樣
marr[2]
來獲取數組的元素,只能通過調用objectOrNilAtIndex:2
來獲取元素,在某種意義上來說會降低代碼的可讀性,當然了蘋果也是推薦我們使用更為簡單直觀的方法來實現功能。
- 筆者在一開始就說過如果一個項目是經過了N個人的✋,那麼由於當時的大環境影響不可能在每個取數組元素的地方都是這麼寫的,那麼在沒有處理過的地方就有可能會crash掉,那麼就有人會說把相應的地方替換一下不就可以了嗎?世上無難事只怕有心人,替換當然是可以的,但前提是你得給我一年的時間