1.崩潰bug之UITableView+FDTemplateLayoutCell：
? ? ? 最近在項目開發(fā)中诗鸭，在使用UITableView時溢豆，程序直接崩潰烦粒。當然項目中，使用到?UITableView+FDTemplateLayoutCell來緩存tableView高度始锚。(git地址：FDtemplateLayoutCell地址)刽酱。崩潰日志如下：
FDTemplateLayoutCell崩潰信息位置：
當看到這個日志后，立馬就知道是因為XYBugTableCell沒有注冊上才導致崩潰的瞧捌，于是就查找在加載VC的時候 到底有沒有注冊Cell棵里。
發(fā)現(xiàn)cell也注冊了。再看下cell注冊也沒有問題的姐呐。但是為啥就會崩潰呢殿怜。于是開始查找原因。首先曙砂，難道是FDTemplateLayoutCell庫的問題头谜？為了驗證這個問題，先不用這個庫鸠澈，直接在返回高度固定高度柱告。
發(fā)現(xiàn)直接返回固定高度截驮，程序一切運行OK。這樣看來真的是這個庫有問題了呢际度。oh my god葵袭，我怎么有點不相信了呢。在項目中乖菱，其他的地方也用到這個呢坡锡，都沒有問題。于是窒所，找一個正常運行的VC來作對比鹉勒。兩個VC中，tableView寫法一樣的吵取，但唯獨一點不同的是：
可以看出禽额，唯一不同的是，設(shè)置tableFooterView的位置皮官。于是绵疲，像上圖一樣，改下設(shè)置tableFooterView的位置來驗證下臣疑。果然，程序神一般的運行成功了徙菠。好奇怪讯沈，為啥會有這種結(jié)果呢？難道是偶然事件婿奔？于是缺狠，在重新設(shè)置到原來的位置，程序還是崩潰萍摊。反復驗證幾次挤茄，真的是設(shè)置tableFooterView的位置不當，而造成的程序崩潰冰木，并不是FDTemplateLayoutCell的原因穷劈。
雖然崩潰解決了，但是原因在哪里呢踊沸？當給tableView設(shè)置tableFooterView的發(fā)生了什么歇终？于是，來打斷點測試下逼龟。在tableView的UITableViewDelegate,UITableViewDataSource代理中评凝，打上斷點，如下：
運行程序腺律，正常走到23斷點處奕短，繼續(xù)放開23斷點宜肉。此時，會發(fā)現(xiàn)程序不會直接走25斷點翎碑，而是走31谬返、35、39斷點杈女，也是tableView的代理方法朱浴。這一點說明，在設(shè)置tableFooterView的時候达椰，系統(tǒng)會自動調(diào)用reload方法翰蠢，去刷新tableView。因此啰劲，當走到39斷點時梁沧，F(xiàn)DTemplateLayoutCell會去根據(jù)標識符獲取cell，而此刻還沒有走到25斷點處蝇裤，所以tableView的cell還沒有注冊上廷支，此刻去獲取cell，就會報錯栓辜，導致程序的崩潰恋拍。
解決方案：先注冊cell，在設(shè)置tableFooterView藕甩。
2.崩潰bug之xib(estimatedRowHeight)：
? ? ? ?相信現(xiàn)在好多開發(fā)者都用xib開發(fā)施敢，但是有時候xib開發(fā)遇到的bug，真的讓人無從下手狭莱。主要還沒有崩潰日志僵娃。在項目開發(fā)中，就遇到這么一個問題腋妙。在xib中默怨，直接添加一個tableView，拉屬性等等操作骤素。然后運行程序匙睹，一切OK(此刻是iOS11系統(tǒng))。說明在iOS11系統(tǒng)下济竹，沒有問題垃僚。然后切換到iOS10系統(tǒng)，運行程序规辱，發(fā)現(xiàn)直接崩潰谆棺，崩潰日志如下：
直接崩潰到main函數(shù)里。控制臺也沒有崩潰信息改淑。難道xib加載tableView和系統(tǒng)有關(guān)碍岔？在切換到iOS11系統(tǒng)，依舊沒有問題朵夏。有點郁悶蔼啦。于是，用純代碼寫tableView的初始化來驗證下仰猖。發(fā)現(xiàn)不論在iOS10 還是iOS11系統(tǒng)捏肢，都沒有問題，運行一切OK饥侵。這就奇怪了鸵赫，看來真的是xib初始化tableView的問題。
? ?調(diào)試工程躏升，返回到初始xib加載tableView的狀態(tài)辩棒，iOS11不用驗證了，直接在iOS10系統(tǒng)下膨疏，運行一睁，依舊崩潰。難道是xib加載tableView的時候都默認設(shè)置了什么嗎佃却？于是在xib中者吁，查看tableView的一些設(shè)置，發(fā)現(xiàn)一個問題：
在xib 加載tableView的時候饲帅，會默認選中estimatedRowHeight砚偶，如上圖（圖8）。會不會是這兩個默認設(shè)置的原因洒闸？于是，取消默認選中均芽。然后運行程序（iOS11和iOS10系統(tǒng)）丘逸，居然程序運行正常，沒一點毛病掀宋。在勾選上深纲，運行程序崩潰【⒚睿看來真的是它的原因造成的湃鹊。但是為啥系統(tǒng)默認的在iOS10會崩潰呢？按道理來說 不應(yīng)該的呢镣奋。難道是工程里面有別的設(shè)置導致的币呵？
? ? ?為了探討這個問題，又重新創(chuàng)建一個全新的工程侨颈，就初始化一個xib和tableView余赢。所有xib設(shè)置和上面工程一樣芯义，然后運行程序，發(fā)現(xiàn)程序運行居然正常Ｆ奁狻？覆Α！（iOS11举塔、iOS10系統(tǒng)）都OK绑警。這說明xib上tableView默認勾選也沒有問題呀。那么問題究竟出在什么地方央渣？
? ? ?在項目中计盒，默認選中estimatedRowHeight在iOS10系統(tǒng)下 就會崩潰，是不是在工程里面也設(shè)置這個屬性痹屹，導致沖突的章郁？果不其然，為適配iPhone X時志衍，在項目中加入了如下代碼：
? ? ?為啥加入這幾行代碼就會崩潰暖庄？看下蘋果怎么定義的吧。
是不是瞬間明白了楼肪。因此培廓，在iOS11 系統(tǒng)下，程序沒有崩潰春叫。在iOS10系統(tǒng)下肩钠，由于設(shè)置了全局的tableView的estimatedRowHeight屬性，而導致程序崩潰暂殖。
解決方案：注釋掉圖9的代碼价匠，或者加個判斷，只在iOS11下面設(shè)置呛每〔冉眩或者取消圖8xib系統(tǒng)默認勾選。
如有問題晨横，歡迎指正洋腮。Demo地址：測試Demo?
