iOS中鍵盤(pán)、靜態(tài)庫(kù)、動(dòng)畫(huà)和Crash定位的示例分析

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

iOS11鍵盤(pán)問(wèn)題

功能背景：

彈出鍵盤(pán)時(shí)，如果有輸入框的話，需要輸入框的位置跟隨鍵盤(pán)大小而變動(dòng)。

問(wèn)題描述：

當(dāng)快速切換鍵盤(pán)之后，容易出現(xiàn)輸入框的位置沒(méi)有緊貼鍵盤(pán)，如下：（以簡(jiǎn)書(shū)鍵盤(pán)為例）

相關(guān)實(shí)現(xiàn)：

輸入框監(jiān)聽(tīng)系統(tǒng)的UIKeyboardWillShowNotification和UIKeyboardWillHideNotification事件，在回調(diào)的過(guò)程中用UIKeyboardFrameEndUserInfoKey獲取鍵盤(pán)的frame，再動(dòng)態(tài)調(diào)整輸入框的位置。

問(wèn)題定位：

此問(wèn)題可以復(fù)現(xiàn)，呼起鍵盤(pán)之后頻繁切換鍵盤(pán)。

添加Log進(jìn)行調(diào)試，得到以下結(jié)果：

/*
226是系統(tǒng)英文鍵盤(pán)的高度；
292是搜狗輸入法鍵盤(pán)的高度；
271是emoji鍵盤(pán)的高度；
*/
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}}

實(shí)際操作中，當(dāng)鍵盤(pán)從292高度的搜狗鍵盤(pán)切換成271的emoji鍵盤(pán)的時(shí)候，有時(shí)會(huì)無(wú)法觸發(fā)回調(diào)，造成實(shí)際上鍵盤(pán)高度產(chǎn)生292-271的誤差（21pt）。

正常蘋(píng)果應(yīng)該每次切換鍵盤(pán)都回調(diào)，但在切換emoji表情鍵盤(pán)的時(shí)候，偶現(xiàn)不觸發(fā)回調(diào)。

問(wèn)題修復(fù)：

輸入框增高，增加上圖左邊紅框部分的高度；

和鍵盤(pán)對(duì)齊的時(shí)候，往下計(jì)算紅框的高度。

附：

iOS 11還有另外的鍵盤(pán)表現(xiàn)異常：在APP中呼起鍵盤(pán)，把APP切入后臺(tái)，在系統(tǒng)桌面下滑呼起系統(tǒng)搜索的鍵盤(pán)，會(huì)導(dǎo)致APP內(nèi)的鍵盤(pán)收起。

靜態(tài)庫(kù)相關(guān)

功能背景：

項(xiàng)目中存在某些功能，需要用靜態(tài)庫(kù)集成的方式接入。

問(wèn)題描述：

在線上運(yùn)行過(guò)程中發(fā)現(xiàn)某些Crash出自靜態(tài)庫(kù)，但是Crash日志里面無(wú)法定位到靜態(tài)庫(kù)出現(xiàn)Crash的具體代碼行數(shù)。
如下，testNull的Thread 0發(fā)生Crash，但是沒(méi)有函數(shù)相關(guān)信息。

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

相關(guān)實(shí)現(xiàn)：

靜態(tài)庫(kù)有單獨(dú)的工程，會(huì)打包出模擬器和真機(jī)兩個(gè)framework，然后合并成一個(gè)framework，再放入項(xiàng)目的工程。

問(wèn)題定位：

Crash日志里面的信息無(wú)法符號(hào)化，原因就是還原Crash信息的符號(hào)表里沒(méi)有靜態(tài)庫(kù)的信息。

我們知道，靜態(tài)庫(kù)是只有編譯，沒(méi)有鏈接的過(guò)程。

在實(shí)際打到二進(jìn)制包的時(shí)候，才會(huì)進(jìn)行鏈接操作。

符號(hào)表里沒(méi)有靜態(tài)庫(kù)的信息，是靜態(tài)庫(kù)的framework里沒(méi)有代碼行數(shù)的相關(guān)信息！

通過(guò)查詢官方文檔知道，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.

靜態(tài)庫(kù)的工程如果設(shè)置該屬性為NO，那么打包出來(lái)的framework是不包括Debug用的信息。

問(wèn)題修復(fù)：

修改Generate Debug Symbols設(shè)置。

正確設(shè)置

附：

Xcode相關(guān)設(shè)置的文檔，直接點(diǎn)擊這里的鏈接。如果失效，可以按照下面的步驟查找：

Xcode設(shè)置

UITableView下拉刷新導(dǎo)致的動(dòng)畫(huà)異常

功能背景：

UITableView用于展示內(nèi)容，scrollView上會(huì)添加一個(gè)RefreshHeadrView，用于實(shí)現(xiàn)下拉刷新。

問(wèn)題描述：

現(xiàn)在在下拉刷新之后，Cell內(nèi)部的視圖會(huì)有移動(dòng)，類似的效果如下（為了方便展示，用按鈕點(diǎn)擊取代下拉刷新的操作）：

相關(guān)實(shí)現(xiàn)：

RefreshHeadrView（下拉刷新view）通過(guò)監(jiān)聽(tīng)scrollView的didScroll回調(diào)，觸發(fā)下拉刷新；在結(jié)束的時(shí)候通過(guò)修改scrollView.contentInset，實(shí)現(xiàn)刷新完畢自動(dòng)上滑的操作。

下拉刷新結(jié)束的代碼如下：

  [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];

問(wèn)題定位：

首先看問(wèn)題的表現(xiàn)：UITableViewCell上的視圖在刷新后進(jìn)行位移。

位移的原因有多種可能，同事奧斯丁提供了一種解決方案：下拉刷新之后，把reloadData放到下個(gè)runloop再執(zhí)行。
在嘗試之后，果然修復(fù)了此問(wèn)題！

奧斯丁的解決方案讓我確定到問(wèn)題一定是出現(xiàn)在當(dāng)前runloop做的一些操作，導(dǎo)致了UITableViewCell上的視圖位移。
經(jīng)過(guò)一番調(diào)試，把問(wèn)題的整個(gè)原路徑給回溯出來(lái)：

• 1.下拉刷新 ==> 2.數(shù)據(jù)請(qǐng)求 ==> 3.本地?cái)?shù)據(jù)源更新 ==> 4.1調(diào)用reloadData更新視圖

• 3.本地?cái)?shù)據(jù)源更新 ==> 4.2 下拉刷新結(jié)束didfinish ==> 4.3refreshHeaderView結(jié)束動(dòng)畫(huà) ==> 4.4觸發(fā)didScroll
   回調(diào) ==> 4.5回調(diào)中調(diào)用visiableCell ==> 4.6觸發(fā)cellFor方法 ==> 4.7UITableViewCell初始化會(huì)改變frame

視圖位移原因就在4.3的結(jié)束動(dòng)畫(huà)是在UIView的動(dòng)畫(huà)事務(wù)操作，而4.7的改變frame的操作會(huì)被認(rèn)為也在動(dòng)畫(huà)事務(wù)內(nèi)，所以會(huì)觸發(fā)視圖的動(dòng)畫(huà)效果。

問(wèn)題修復(fù)：

修復(fù)方案，可以是dispatch到下一個(gè)runloop再執(zhí)行reloadData，這樣在4.5回調(diào)中調(diào)用visiableCell的時(shí)候visiableCell拿到上一次的cell，這樣鏈路會(huì)斷開(kāi)，不會(huì)導(dǎo)致視圖位移。但是，這樣會(huì)把Bug隱藏：數(shù)據(jù)源和UI顯示不一致??！

最佳解決方案：不調(diào)用visiableCell去獲取當(dāng)前顯示的cell，改為監(jiān)聽(tīng)UITableView的willDisplay和didEndDisplayingCell方法，再用一個(gè)雙端隊(duì)列維護(hù)一個(gè)業(yè)務(wù)側(cè)的當(dāng)前可見(jiàn)cell。

通過(guò)這個(gè)問(wèn)題，我們可以確定-reloadData方法是把UITableView的可見(jiàn)cell清空；
visiableCell是一個(gè)getter，調(diào)用的時(shí)候如果visiableCell是空，會(huì)觸發(fā)cellfor的方法進(jìn)行初始化。

Crash定位

源于實(shí)際開(kāi)發(fā)中遇到的一個(gè)Crash問(wèn)題，類似堆棧如下：

crash問(wèn)題在各個(gè)iOS版本均有出現(xiàn)，每天的crash率(crash次數(shù)/用戶數(shù))在萬(wàn)分之1.5左右。

通過(guò)crash的描述platform_memmove，還有堆棧信息我們可以定位到代碼異常是出現(xiàn)在memcpy的函數(shù)。

通過(guò)錯(cuò)誤類型，我們知道是訪問(wèn)非法內(nèi)存地址。

memcpy一共有三個(gè)參數(shù)，在執(zhí)行函數(shù)的時(shí)候會(huì)把三個(gè)參數(shù)push進(jìn)x0、x1、x2三個(gè)寄存器。再通過(guò)crash日志的寄存器信息，我們可以拿到這三個(gè)參數(shù)的值，如下：

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，從而還原出導(dǎo)致crash的函數(shù)為memcpy(0xaa, 0xbb, 0xcc);。

（這里memcpy的三個(gè)參數(shù)是我特意構(gòu)造的，以便描述問(wèn)題）

這里有兩種crash的可能性：

1、參數(shù)1寫(xiě)數(shù)據(jù)非法；

2、參數(shù)2讀數(shù)據(jù)非法；

先看一個(gè)類似的問(wèn)題，下面的代碼有什么問(wèn)題？

int *p1=malloc(1024);
int *p2=malloc(1024);
memcpy(p1, p2, 1025);

答案是：大多數(shù)情況下正常運(yùn)行，少數(shù)情況下會(huì)Crash。

Crash本質(zhì)是堆內(nèi)存訪問(wèn)越界，但堆內(nèi)存空間到棧內(nèi)存空間的距離不固定，如果p1+1025仍有寫(xiě)權(quán)限，p2+1025仍有讀權(quán)限，則不會(huì)出現(xiàn)crash的情況。

附：
實(shí)際開(kāi)發(fā)中，寄存器x2+寄存器x5的值，才是真正的memcpy的第三個(gè)參數(shù)。
x2: 0x00000000000003e0 + x5: 0x0000000000000020 = 0x0000000000000400 = 1024
懷疑是蘋(píng)果對(duì)memcpy的方法做了修改：
當(dāng) 第二個(gè)參數(shù)是堆內(nèi)存地址的時(shí)候，會(huì)進(jìn)行截?cái)啵?br/>當(dāng) 第二個(gè)參數(shù)是非法地址時(shí)（比如0x00000000000000bb），就不會(huì)進(jìn)行截?cái)啵?br/>

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“iOS中鍵盤(pán)、靜態(tài)庫(kù)、動(dòng)畫(huà)和Crash定位的示例分析”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持億速云，關(guān)注億速云行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來(lái)學(xué)習(xí)!