前言
本文主要分享了開發中遇到的問題，和相關的一些思考。分享出來給有需要的朋友們參考學習，下面話不多說了，來一起看看詳細的介紹吧。
iOS11鍵盤問題
功能背景：
彈出鍵盤時，如果有輸入框的話，需要輸入框的位置跟隨鍵盤大小而變動。
問題描述：
當快速切換鍵盤之后，容易出現輸入框的位置沒有緊貼鍵盤，如下：（以簡書鍵盤為例）
相關實現：
輸入框監聽系統的UIKeyboardWillShowNotification和UIKeyboardWillHideNotification事件，在回調的過程中用UIKeyboardFrameEndUserInfoKey獲取鍵盤的frame，再動態調整輸入框的位置。
問題定位：
此問題可以復現，呼起鍵盤之后頻繁切換鍵盤。
添加Log進行調試，得到以下結果：
/*226是系統英文鍵盤的高度；292是搜狗輸入法鍵盤的高度；271是emoji鍵盤的高度；*/UIKeyboardWillShowNotification : {{0, 510}, {414, 226}}UIKeyboardWillShowNotification : {{0, 444}, {414, 292}}UIKeyboardWillShowNotification : {{0, 510}, {414, 226}}UIKeyboardWillShowNotification : {{0, 444}, {414, 292}}UIKeyboardWillShowNotification : {{0, 465}, {414, 271}}UIKeyboardWillShowNotification : {{0, 510}, {414, 226}}UIKeyboardWillShowNotification : {{0, 444}, {414, 292}}實際操作中，當鍵盤從292高度的搜狗鍵盤切換成271的emoji鍵盤的時候，有時會無法觸發回調，造成實際上鍵盤高度產生292-271的誤差（21pt）。
正常蘋果應該每次切換鍵盤都回調，但在切換emoji表情鍵盤的時候，偶現不觸發回調。
問題修復：
輸入框增高，增加上圖左邊紅框部分的高度；
和鍵盤對齊的時候，往下計算紅框的高度。
附：
iOS 11還有另外的鍵盤表現異常：在APP中呼起鍵盤，把APP切入后臺，在系統桌面下滑呼起系統搜索的鍵盤，會導致APP內的鍵盤收起。
靜態庫相關
功能背景：
項目中存在某些功能，需要用靜態庫集成的方式接入。
問題描述：
在線上運行過程中發現某些Crash出自靜態庫，但是Crash日志里面無法定位到靜態庫出現Crash的具體代碼行數。
如下，testNull的Thread 0發生Crash，但是沒有函數相關信息。
Exception Type: EXC_BAD_ACCESS (SIGSEGV)Thread 0 name: Dispatch queue: com.apple.main-threadThread 0 Crashed:0 testNull 0x000000010494aacc 0x104944000 + 273401 testNull 0x000000010494aac8 0x104944000 + 273362 testNull 0x000000010494a6b0 0x104944000 + 262883 UIKit 0x000000018cec4efc -[UIViewController loadViewIfRequired] + 10404 UIKit 0x000000018cec4ad4 -[UIViewController view] + 285 UIKit 0x000000018cecb6a0 -[UIWindow addRootViewControllerViewIfPossible] + 1366 UIKit 0x000000018cec890c -[UIWindow _setHidden:forced:] + 2727 UIKit 0x000000018cf379ec -[UIWindow makeKeyAndVisible] + 48
相關實現：
靜態庫有單獨的工程，會打包出模擬器和真機兩個framework，然后合并成一個framework，再放入項目的工程。
問題定位：
Crash日志里面的信息無法符號化，原因就是還原Crash信息的符號表里沒有靜態庫的信息。
我們知道，靜態庫是只有編譯，沒有鏈接的過程。
在實際打到二進制包的時候，才會進行鏈接操作。
符號表里沒有靜態庫的信息，是靜態庫的framework里沒有代碼行數的相關信息！
通過查詢官方文檔知道，Generate Debug Symbols的屬性描述如下
Enables or disables generation of debug symbols. When debug symbols are enabled, the level of detail can be controlled by the Debug Information Format (DEBUG_INFORMATION_FORMAT) setting.
靜態庫的工程如果設置該屬性為NO，那么打包出來的framework是不包括Debug用的信息。
問題修復：
修改Generate Debug Symbols設置。
正確設置
附：
Xcode相關設置的文檔，直接點擊這里的鏈接。如果失效，可以按照下面的步驟查找：
Xcode設置
UITableView下拉刷新導致的動畫異常
功能背景：
UITableView用于展示內容，scrollView上會添加一個RefreshHeadrView，用于實現下拉刷新。
問題描述：
現在在下拉刷新之后，Cell內部的視圖會有移動，類似的效果如下（為了方便展示，用按鈕點擊取代下拉刷新的操作）：
相關實現：
RefreshHeadrView（下拉刷新view）通過監聽scrollView的didScroll回調，觸發下拉刷新；在結束的時候通過修改scrollView.contentInset，實現刷新完畢自動上滑的操作。
下拉刷新結束的代碼如下：
[UIView beginAnimations:nil context:NULL]; [UIView setAnimationDuration:0.2]; [UIView setAnimationCurve:UIViewAnimationCurveEaseOut]; scrollView.contentInset = UIEdgeInsetsMake(-REFRESH_TRIGGER_HEIGHT + _initTopContentInset, 0.0f, 0.0f, 0.0f); [UIView commitAnimations];
問題定位：
首先看問題的表現：UITableViewCell上的視圖在刷新后進行位移。
位移的原因有多種可能，同事奧斯丁提供了一種解決方案：下拉刷新之后，把reloadData放到下個runloop再執行。
在嘗試之后，果然修復了此問題！
奧斯丁的解決方案讓我確定到問題一定是出現在當前runloop做的一些操作，導致了UITableViewCell上的視圖位移。
經過一番調試，把問題的整個原路徑給回溯出來：
視圖位移原因就在4.3的結束動畫是在UIView的動畫事務操作，而4.7的改變frame的操作會被認為也在動畫事務內，所以會觸發視圖的動畫效果。
問題修復：
修復方案，可以是dispatch到下一個runloop再執行reloadData，這樣在4.5回調中調用visiableCell的時候visiableCell拿到上一次的cell，這樣鏈路會斷開，不會導致視圖位移。但是，這樣會把Bug隱藏：數據源和UI顯示不一致?。?/p>
最佳解決方案：不調用visiableCell去獲取當前顯示的cell，改為監聽UITableView的willDisplay和didEndDisplayingCell方法，再用一個雙端隊列維護一個業務側的當前可見cell。
通過這個問題，我們可以確定-reloadData方法是把UITableView的可見cell清空；
visiableCell是一個getter，調用的時候如果visiableCell是空，會觸發cellfor的方法進行初始化。
Crash定位
源于實際開發中遇到的一個Crash問題，類似堆棧如下：
crash問題在各個iOS版本均有出現，每天的crash率(crash次數/用戶數)在萬分之1.5左右。
通過crash的描述platform_memmove，還有堆棧信息我們可以定位到代碼異常是出現在memcpy的函數。
通過錯誤類型，我們知道是訪問非法內存地址。
memcpy一共有三個參數，在執行函數的時候會把三個參數push進x0、x1、x2三個寄存器。再通過crash日志的寄存器信息，我們可以拿到這三個參數的值，如下：
Thread 0 crashed with ARM Thread State (64-bit): x0: 0x00000000000000aa x1: 0x00000000000000bb x2: 0x00000000000000cc x3: 0x00000000000000c0 x4: 0x0000000000000010 x5: 0x0000000000000002 x6: 0x0000000000000064 x7: 0x0000000000000000 x8: 0x00000000000000aa x9: 0x0000ddf9664f0000 x10: 0x0000000000004887 x11: 0x00000001b8741211 x12: 0x00000001b8741211 x13: 0x000000000000001d x14: 0x0000000000000001 x15: 0x0000000000000881 x16: 0x00000001855b1ab0 x17: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x00000000000000aa x20: 0x0000000119d064f0 x21: 0x0000000000000018 x22: 0x000000018fb4dd6a x23: 0x0000000000000000 x24: 0x0000000000000010 x25: 0x0000000119e01b40 x26: 0x0000000000000280 x27: 0x0000000119d06c50 x28: 0x0000000000000001 fp: 0x000000016bce95f0 lr: 0x000000018542ce58 sp: 0x000000016bce95f0 pc: 0x00000001855b1b60 cpsr: 0x80000000
從上面的寄存器信息，我們可以拿到x0、x1、x2的寄存器值為0xAA、0xBB、0xCC，從而還原出導致crash的函數為memcpy(0xaa, 0xbb, 0xcc);。
（這里memcpy的三個參數是我特意構造的，以便描述問題）
這里有兩種crash的可能性：
1、參數1寫數據非法；
2、參數2讀數據非法；
先看一個類似的問題，下面的代碼有什么問題？
int *p1=malloc(1024);int *p2=malloc(1024);memcpy(p1, p2, 1025);
答案是：大多數情況下正常運行，少數情況下會Crash。
Crash本質是堆內存訪問越界，但堆內存空間到棧內存空間的距離不固定，如果p1+1025仍有寫權限，p2+1025仍有讀權限，則不會出現crash的情況。
附：
實際開發中，寄存器x2+寄存器x5的值，才是真正的memcpy的第三個參數。
x2: 0x00000000000003e0 + x5: 0x0000000000000020 = 0x0000000000000400 = 1024
懷疑是蘋果對memcpy的方法做了修改：
當 第二個參數是堆內存地址的時候，會進行截斷；
當 第二個參數是非法地址時（比如0x00000000000000bb），就不會進行截斷；
總結
遇到問題是常態，如果能從解決問題中學到知識，以及用問題去驗證知識，那么問題也可以成為學習進步的一部分。
好了，以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對VEVB武林網的支持。
新聞熱點
疑難解答
