本篇源于對一個監(jiān)聽鍵盤通知的處理。
監(jiān)聽鍵盤高度代碼十分簡單：
// 添加監(jiān)聽
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(keyboardChange:)
name:UIKeyboardWillChangeFrameNotification object:nil];
// 處理事件
- (void)keyboardChange:(NSNotification*)notifiction{
CGFloat during = [notifiction.userInfo[UIKeyboardAnimationDurationUserInfoKey] floatValue];
CGRect begin = [notifiction.userInfo[UIKeyboardFrameBeginUserInfoKey] CGRectValue];
CGRect end = [notifiction.userInfo[UIKeyboardFrameEndUserInfoKey] CGRectValue];
CGFloat diff = end.origin.y - begin.origin.y;
if (diff == 0)
return;
}
else if (diff < 0) {
// 上升 鍵盤的高度包含了安全區(qū)高度
// code...
} else {
// 下降
// code...
}
}
問題是：是否需要銷毀監(jiān)聽？
看到的很多帖子都寫了[[NSNotificationCenter defaultCenter] removeObserver:self]; 這樣的代碼赐稽。
然而，我們看文檔里的說法：
意思就是iOS 9.0 往后浑侥，這樣的方式不用主動去取消監(jiān)聽姊舵，系統(tǒng)會自動清除這個監(jiān)聽者在下次發(fā)出這個通知的時候。猜想寓落，這里系統(tǒng)對observer采用了弱引用的方式括丁，當(dāng)前的viewcontroller 銷毀后，系統(tǒng)保存的observe就變成了nil零如，這樣躏将，先去判斷是否是nil，如果是nil就移除即可考蕾。
這里不是想說代碼應(yīng)該怎樣去寫祸憋，而是引出者如何查文檔的問題，因為筆者發(fā)現(xiàn)一個問題：
很多開發(fā)者竟然認為注釋就是文檔肖卧。比如我們進入系統(tǒng)的這個類蚯窥，看到如下內(nèi)容，然后就認為這個類沒什么文檔塞帐，只有最下面綠色的那兩行說明拦赠。
當(dāng)光標(biāo)放到方法的最后時，注意光標(biāo)的位置（左邊箭頭）葵姥，真正的文檔在右邊就會顯示：
右邊紅框中的內(nèi)容才是真正的文檔荷鼠。可以看到有很多文字性的說明榔幸，這才是我們需要去看的地方允乐。點擊右下角的Open in Developer Documentation可以打開獨立的文檔窗口，可以更方便的查看削咆。
一牍疏、查看文檔：
1.在線文檔
1.1>舊版在線文檔：文檔地址
雖然蘋果明確說明了該文檔已經(jīng)過期，但左側(cè)的結(jié)構(gòu)更方便查找拨齐，往往結(jié)合新版的使用鳞陨，作為查找的備選方案。
1.2>新版在線文檔：文檔地址
2.本地文檔
打開Xcode瞻惋，按Command + shift + 0 厦滤，即可看到本地文檔援岩。
二、如何使用文檔
三窄俏、如何保持進步
正如本文一開始的遇到的問題一樣，開發(fā)中經(jīng)常會這樣的小問題碘菜，通常會選擇簡單的百度一下去解決，而忽略了文檔（有時候文檔也寫的不清晰限寞，這就需要仔細去寫代碼測試辨別）忍啸，就跟著別人的帖子寫了很多不必要的代碼，甚至是錯誤的代碼履植。
仔細想想计雌，這其實是一個開發(fā)者不探索代碼原理的必然結(jié)果：
只要別人的代碼有用，拷貝過來改改就行了玫霎，中間有什么問題等出了再說凿滤。而不去探究別人代碼的邏輯、思路庶近。長此以往翁脆，水平就被固化了，也難有進步鼻种。
如何保持進步反番？答案也很簡單： 保持好奇心并持續(xù)探索。遇到疑問就去查叉钥，去探究罢缸，去分析，去追根問底投队。
要做到這些并不容易，需要毅力和耐心敷鸦，以及長時間的積累息楔。
有時候我們會感覺到自己基礎(chǔ)不好轧膘，然而又說不上來哪里不好，往往就是這一步做的不夠谎碍。
在經(jīng)過上述一段時間的沉淀后，就會對系統(tǒng)級別的API就有了理解蟆淀，對原理也清楚了許多澡匪。寫代碼也更有底氣，甚至有點隨心所欲起來褒链。注意，到這里其實已經(jīng)有了很大的成長甫匹，也為后續(xù)拓寬打下了基礎(chǔ)（原理往往都是類似的）。
再往后就會有對寫法兵迅、結(jié)構(gòu)的疑問，這時往往就摸到了設(shè)計模式的邊緣恍箭，去研究不同的設(shè)計模式刻恭，去理解扯夭，去設(shè)計鳍贾，去比較，在設(shè)計模式上去沉淀交洗。
再往后就需要去嘗試其他的技術(shù)棧骑科，比如 js、node构拳、java纵散、c++等， 去感受其他語言的設(shè)計隐圾。通過學(xué)習(xí)其他技術(shù)棧提升自己的對原有技術(shù)棧的理解伍掀。有人肯定覺得奇怪，我的回答是不要懷疑暇藏，做就是了蜜笤，很快你就會理解這一點。
再往后盐碱，筆者還沒達到那樣的高度把兔。可以隱約感受到的是去學(xué)習(xí)大量優(yōu)秀開源庫瓮顽、開源框架的源碼县好，在架構(gòu)上去沉淀。
以上就是筆者自己學(xué)習(xí)的一個過程暖混，體會最深的就是一個東西不管多難多復(fù)雜都不要緊缕贡，一定要有持續(xù)探究的勇氣和耐心。
筆者曾經(jīng)寫過一段時間的Vue，學(xué)習(xí)的方法就是上面這樣晾咪，一步一步從教程和文檔中沉淀收擦，很快就發(fā)現(xiàn)和公司中其他原本寫前端的人寫出的代碼的差異。明顯可以看出自己的代碼更加”官方“谍倦，而其他人的野路子就很多塞赂。不是說野路子不好，有些問題的確需要一些野路子去處理昼蛀。 但是宴猾，往往這些遇到的問題都是早已有了解決方法〉鹦基礎(chǔ)的東西就像是公式鳍置，業(yè)務(wù)的東西就像是做題。當(dāng)公式靈活掌握后送淆，業(yè)務(wù)這些東西早已不是問題。
以上便是筆者的一點點心得怕轿，記錄了從遇到問題到反思的過程偷崩，希望可以給讀者帶來一點點啟發(fā)。
