iOS中鍵盤、靜態庫、動畫和Crash定位的示例分析

這篇文章主要介紹了iOS中鍵盤、靜態庫、動畫和Crash定位的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

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-thread
Thread 0 Crashed:
0 testNull       0x000000010494aacc 0x104944000 + 27340
1 testNull       0x000000010494aac8 0x104944000 + 27336
2 testNull       0x000000010494a6b0 0x104944000 + 26288
3 UIKit        0x000000018cec4efc -[UIViewController loadViewIfRequired] + 1040
4 UIKit        0x000000018cec4ad4 -[UIViewController view] + 28
5 UIKit        0x000000018cecb6a0 -[UIWindow addRootViewControllerViewIfPossible] + 136
6 UIKit        0x000000018cec890c -[UIWindow _setHidden:forced:] + 272
7 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上的視圖位移。
經過一番調試，把問題的整個原路徑給回溯出來：

• 1.下拉刷新 ==> 2.數據請求 ==> 3.本地數據源更新 ==> 4.1調用reloadData更新視圖

• 3.本地數據源更新 ==> 4.2 下拉刷新結束didfinish ==> 4.3refreshHeaderView結束動畫 ==> 4.4觸發didScroll
   回調 ==> 4.5回調中調用visiableCell ==> 4.6觸發cellFor方法 ==> 4.7UITableViewCell初始化會改變frame

視圖位移原因就在4.3的結束動畫是在UIView的動畫事務操作，而4.7的改變frame的操作會被認為也在動畫事務內，所以會觸發視圖的動畫效果。

問題修復：

修復方案，可以是dispatch到下一個runloop再執行reloadData，這樣在4.5回調中調用visiableCell的時候visiableCell拿到上一次的cell，這樣鏈路會斷開，不會導致視圖位移。但是，這樣會把Bug隱藏：數據源和UI顯示不一致！！

最佳解決方案：不調用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），就不會進行截斷；

感謝你能夠認真閱讀完這篇文章，希望小編分享的“iOS中鍵盤、靜態庫、動畫和Crash定位的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!