記一次Crash分析

在這里主要分析使用UIWebView導(dǎo)致產(chǎn)生crash的原因倚聚。

從我們項(xiàng)目的crash日志收集平臺中,有諸多如下的日志:

Application received signal 11  

1   libobjc.A.dylib 0x1800bc150 _objc_msgSend + 16
2   UIKit           0x18799156c -[UIWebView webView:resource:didFinishLoadingFromDataSource:] + 84
3   CoreFoundation  0x18164ce80 ___invoking___ + 144
4   CoreFoundation  0x1815422c4 -[NSInvocation invoke] + 292
5   CoreFoundation  0x181546e9c -[NSInvocation invokeWithTarget:] + 60
6   WebKitLegacy    0x1873d4820 <redacted>

Application received signal 11

崩潰線程
WebThread
格式化
1   libobjc.A.dylib 0x1800bc150 _objc_msgSend + 16
2   UIKit           0x187c33354 -[UIWebView webThreadWebView:resource:willSendRequest:redirectResponse:fromDataSource:] + 92
3   WebKitLegacy    0x187477e60 <redacted>
4   WebKitLegacy    0x1873d315c <redacted>
5   WebCore         0x1861cdee0 WebCore::ResourceLoadNotifier::dispatchWillSendRequest(WebCore::DocumentLoader*, unsigned long, WebCore::ResourceRequest&, WebCore::ResourceResponse const&) + 232
6   WebCore         0x186f1c494 WebCore::ResourceLoader::willSendRequestInternal(WebCore::ResourceRequest&, WebCore::ResourceResponse const&) + 556
7   WebCore         0x18703cbb0 WebCore::SubresourceLoader::willSendRequestInternal(WebCore::ResourceRequest&, WebCore::ResourceResponse const&) + 252
8   WebCore         0x1861cd040 WebCore::ResourceLoader::init(WebCore::ResourceRequest const&) + 288
9   WebCore         0x1861ccdec WebCore::SubresourceLoader::startLoading() + 36
10  WebKitLegacy    0x1874b23b0 <redacted>

以前在看到這種日志的時候凿可,就在想惑折,signal 11崩潰日志不明確,或者說WebView的系統(tǒng)代碼枯跑,不是我們自己的代碼改不了的種種惨驶。。敛助。

不過現(xiàn)在從crash統(tǒng)計平臺的數(shù)據(jù)看來數(shù)量相當(dāng)大粗卜,是非常影響用戶的體驗(yàn)的。所以今天就抽時間來分析分析其原因纳击。

從日志上看续扔,基本都是Application received signal 11攻臀,那么signal 11是代表什么呢?

于是翻看系統(tǒng)的頭文件sys/signal.h, 我們可以發(fā)現(xiàn)里面有一個宏定義#define SIGSEGV 11 /* segmentation violation */, 這個SIGSEGV其實(shí)就是signal 11的宏定義纱昧,注釋很明確了:無效的內(nèi)存引用

那么問題就來了刨啸,WebCore內(nèi)部發(fā)出無效內(nèi)存引用,我們好像也無能為力笆洞唷呜投??存璃?咋辦呢?

這時候就去看看UIWebView有沒有其它什么可能的原因雕拼,發(fā)現(xiàn)在頭delegate的定義
@property (nullable, nonatomic, assign) id <UIWebViewDelegate> delegate;
我們都知道assign一般是用于元類型纵东,delegate在ARC下一般是被聲明為weak

這就奇怪了啥寇,怎么這么聲明呢? 因此帶著疑問去看UIWebView的文檔:

Protocol
UIWebViewDelegate
The UIWebViewDelegate protocol defines methods that a delegate of a 
UIWebView
 object can optionally implement to intervene when web content is loaded.
SDK

iOS 2.0+
Framework

UIKit
On This Page

Overview
Topics
Relationships
See Also
Overview

> Important
> Before releasing an instance of UIWebView for which you have set a delegate,
> you must first set the UIWebView delegate property to nil before disposing of the UIWebView instance. 
> This can be done, for example, in the dealloc method where you dispose of the UIWebView.`
>

意思就是: 在釋放一個你已經(jīng)為其設(shè)過 delegate 的 UIWebView 實(shí)例之前偎球,你首先一定要將該 UIWebView 對象的 delegate 屬性設(shè)為 nil。比如說辑甜,你可以在你的 dealloc 方法中這樣做衰絮。

這時候就恍然大悟了,我們的項(xiàng)目中對WebView的使用并沒有如此!!! 因?yàn)樵赨IWebView的delgate屬性為assign 在被銷毀的時候delegate不會被設(shè)為nil磷醋,導(dǎo)致WebView回調(diào)的時候引用的delegate已經(jīng)是無效的內(nèi)存指針了猫牡,因?yàn)橹羔樦赶虻膬?nèi)存已經(jīng)被釋放,但指針沒有被置空邓线,這也正是文檔里面為什么要重要強(qiáng)調(diào)需要在銷毀前設(shè)置為nil的原因淌友。

這也解釋了為什么crash日志中總是收到莫名的WebView的crash,而且都是Application received signal 11(即無效的內(nèi)存引用

到這里骇陈,相信大家都應(yīng)該知道什么原因了震庭,修改 UIWebView 的 delegate 的對象的 dealloc 方法中添加 _webView.delegate = nil; 如下:

- (void)dealloc{
    /*
     Important
     Before releasing an instance of UIWebView for which you have set a delegate,
     you must first set the UIWebView delegate property to nil before disposing of the UIWebView instance. 
     This can be done, for example, in the dealloc method where you dispose of the UIWebView.
     */
    if (self.webView.loading) {
        [self.webView stopLoading];
    }
    self.webView.delegate = nil;
}

ps:由于很少寫文章,所以寫出來的都是沒深度沒難度的流水帳你雌。這里也就記錄一下這個過程器联,以便以后遇到類似問題能夠有不至于無從下手。如有錯誤婿崭,望看官們不吝指正拨拓。萬分感激!

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末氓栈,一起剝皮案震驚了整個濱河市千元,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌颤绕,老刑警劉巖幸海,帶你破解...
    沈念sama閱讀 206,311評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件祟身,死亡現(xiàn)場離奇詭異,居然都是意外死亡物独,警方通過查閱死者的電腦和手機(jī)袜硫,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,339評論 2 382
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來挡篓,“玉大人婉陷,你說我怎么就攤上這事」傺校” “怎么了秽澳?”我有些...
    開封第一講書人閱讀 152,671評論 0 342
  • 文/不壞的土叔 我叫張陵,是天一觀的道長戏羽。 經(jīng)常有香客問我担神,道長,這世上最難降的妖魔是什么始花? 我笑而不...
    開封第一講書人閱讀 55,252評論 1 279
  • 正文 為了忘掉前任妄讯,我火速辦了婚禮,結(jié)果婚禮上酷宵,老公的妹妹穿的比我還像新娘亥贸。我一直安慰自己,他們只是感情好浇垦,可當(dāng)我...
    茶點(diǎn)故事閱讀 64,253評論 5 371
  • 文/花漫 我一把揭開白布炕置。 她就那樣靜靜地躺著,像睡著了一般男韧。 火紅的嫁衣襯著肌膚如雪讹俊。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 49,031評論 1 285
  • 那天煌抒,我揣著相機(jī)與錄音仍劈,去河邊找鬼。 笑死寡壮,一個胖子當(dāng)著我的面吹牛贩疙,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播况既,決...
    沈念sama閱讀 38,340評論 3 399
  • 文/蒼蘭香墨 我猛地睜開眼这溅,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了棒仍?” 一聲冷哼從身側(cè)響起悲靴,我...
    開封第一講書人閱讀 36,973評論 0 259
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎莫其,沒想到半個月后癞尚,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體耸三,經(jīng)...
    沈念sama閱讀 43,466評論 1 300
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 35,937評論 2 323
  • 正文 我和宋清朗相戀三年浇揩,在試婚紗的時候發(fā)現(xiàn)自己被綠了仪壮。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 38,039評論 1 333
  • 序言:一個原本活蹦亂跳的男人離奇死亡胳徽,死狀恐怖积锅,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情养盗,我是刑警寧澤缚陷,帶...
    沈念sama閱讀 33,701評論 4 323
  • 正文 年R本政府宣布,位于F島的核電站往核,受9級特大地震影響箫爷,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜铆铆,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,254評論 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望丹喻。 院中可真熱鬧薄货,春花似錦、人聲如沸碍论。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,259評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽鳍悠。三九已至税娜,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間藏研,已是汗流浹背敬矩。 一陣腳步聲響...
    開封第一講書人閱讀 31,485評論 1 262
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留蠢挡,地道東北人弧岳。 一個月前我還...
    沈念sama閱讀 45,497評論 2 354
  • 正文 我出身青樓,卻偏偏與公主長得像业踏,于是被迫代替她去往敵國和親禽炬。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 42,786評論 2 345

推薦閱讀更多精彩內(nèi)容

  • 在這里主要分析使用UIWebView導(dǎo)致產(chǎn)生crash的原因勤家。 從我們項(xiàng)目的crash日志收集平臺中腹尖,有諸多如下的...
    cnNapoleon閱讀 1,801評論 3 2
  • 前言 關(guān)于UIWebView的介紹,相信看過上文的小伙伴們伐脖,已經(jīng)大概清楚了吧热幔,如果有問題乐设,歡迎提問。 本文是本系列...
    CoderLF閱讀 8,943評論 2 12
  • iOS 的 Cookie 存取 https://juejin.im/entry/58d4c4cc44d904006...
    Farmers閱讀 5,893評論 0 16
  • 前言 iOS崩潰是讓iOS開發(fā)人員比較頭痛的事情断凶,app崩潰了伤提,說明代碼寫的有問題,這時如何快速定位到崩潰的地方很...
    齊滇大圣閱讀 65,233評論 29 443
  • 人們往把自己看得過重才會患得患失认烁,不要以自己的眼光和認(rèn)知去評論一個人肿男,其實(shí)心有多大,快樂就有多少却嗡;包容越多舶沛,得到越多。
    湘子雅閱讀 151評論 0 0