前言

本文主要分享了開發(fā)中遇到的問題，和相關(guān)的一些思考。分享出來給有需要的朋友們參考學(xué)習(xí)，下面話不多說了，來一起看看詳細的介紹吧。

iOS11鍵盤問題

功能背景：

彈出鍵盤時，如果有輸入框的話，需要輸入框的位置跟隨鍵盤大小而變動。

問題描述：

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

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

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

問題定位：

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

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

/*
226是系統(tǒng)英文鍵盤的高度；
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}}

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

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

問題修復(fù)：

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

和鍵盤對齊的時候，往下計算紅框的高度。

附：

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

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

功能背景：

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

問題描述：

在線上運行過程中發(fā)現(xiàn)某些Crash出自靜態(tài)庫，但是Crash日志里面無法定位到靜態(tài)庫出現(xiàn)Crash的具體代碼行數(shù)。
如下，testNull的Thread 0發(fā)生Crash，但是沒有函數(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)實現(xiàn)：

靜態(tài)庫有單獨的工程，會打包出模擬器和真機兩個framework，然后合并成一個framework，再放入項目的工程。

問題定位：

Crash日志里面的信息無法符號化，原因就是還原Crash信息的符號表里沒有靜態(tài)庫的信息。

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

在實際打到二進制包的時候，才會進行鏈接操作。

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

通過查詢官方文檔知道，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)庫的工程如果設(shè)置該屬性為NO，那么打包出來的framework是不包括Debug用的信息。

問題修復(fù)：

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

正確設(shè)置

附：

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

Xcode設(shè)置

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

功能背景：

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

問題描述：

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

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

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

下拉刷新結(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];

問題定位：

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

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

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

• 1.下拉刷新 ==> 2.數(shù)據(jù)請求 ==> 3.本地數(shù)據(jù)源更新 ==> 4.1調(diào)用reloadData更新視圖
• 3.本地數(shù)據(jù)源更新 ==> 4.2 下拉刷新結(jié)束didfinish ==> 4.3refreshHeaderView結(jié)束動畫 ==> 4.4觸發(fā)didScroll
  回調(diào) ==> 4.5回調(diào)中調(diào)用visiableCell ==> 4.6觸發(fā)cellFor方法 ==> 4.7UITableViewCell初始化會改變frame

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

問題修復(fù)：

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

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

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

Crash定位

源于實際開發(fā)中遇到的一個Crash問題，類似堆棧如下：

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

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

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

memcpy一共有三個參數(shù)，在執(zhí)行函數(shù)的時候會把三個參數(shù)push進x0、x1、x2三個寄存器。再通過crash日志的寄存器信息，我們可以拿到這三個參數(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的三個參數(shù)是我特意構(gòu)造的，以便描述問題）

這里有兩種crash的可能性：

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

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

先看一個類似的問題，下面的代碼有什么問題？

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

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

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

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

總結(jié)

遇到問題是常態(tài)，如果能從解決問題中學(xué)到知識，以及用問題去驗證知識，那么問題也可以成為學(xué)習(xí)進步的一部分。

好了，以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。

最新評論