得物H5容器野指針疑難問題排查 & 解決

作者：Luke 2023-05-29 18:33:30

本文中的crash從出現到解決歷時近一年，一開始根據線上日志判斷是h5 頁面返回 & h5 頁面滾動導致的問題，禁用手勢后雖然幾乎解決問題，但是線上還有零星crash上報，因此為了保證h5 離線功能的線上穩(wěn)定性，需要完美解決問題。

1、背景

得物 iOS 4.9.x 版本上線后，一些帶有橫向滾動內容的h5頁面，有一個webkit 相關crash增加較快。通過Crash堆棧判斷是UIScrollview執(zhí)行滾動動畫過程中內存野指針導致的崩潰。

2、前期排查

通過頁面瀏覽日志，發(fā)現發(fā)生崩潰時所在的頁面都是在h5 web容器內，且都是在頁面的生命周期方法viewDidDisappear方法調用后才發(fā)生崩潰，因此推測崩潰是在h5 頁面返回時發(fā)生的。

剛好交易的同事復現了崩潰證實了我們的推測。因此可以基本確定：崩潰的原因是頁面退出后，頁面內存被釋放，但是滾動動畫繼續(xù)執(zhí)行，這時崩潰堆棧中scrollview的delegate沒有置空，系統(tǒng)繼續(xù)執(zhí)行delegate的相關方法，訪問了已經釋放的對象的內存（野指針問題）。

同時發(fā)生crash h5 頁面都存在一個特點，就是頁面內存在可以左右橫滑的tab視圖。

操作手勢側滑存在體驗問題，左右橫滑的tab視圖也會跟著滾動（見下面視頻）。關聯bugly用戶行為日志，判斷這個體驗問題是和本文中的crash有相關性的。

3、不完美的解決方案

經過上面的分析，修復思路是在h5頁面手勢側滑返回時，將h5容器頁面內tab的橫滑手勢禁掉（同時需要在 h5 web容器的viewWillAppear方法里將手勢再打開，因為手勢側滑是可以取消在返回頁面）。

具體代碼如下(這樣在操作頁面?zhèn)然祷貢r，頁面的手勢被禁掉，不會再滾動)：

@objc dynamic func webViewCanScroll(enable:Bool) {        let contentView = self.webView.scrollView.subviews.first { view in            if let className = object_getClass(view), NSStringFromClass(className) == "WKContentView" {                return true            }            return false        }        let webTouchEventsGestureRecognizer = contentView?.gestureRecognizers?.first(where: { gesture in            if let className = object_getClass(gesture), NSStringFromClass(className) == "UIWebTouchEventsGestureRecognizer" {                return true            }            return false        })        webTouchEventsGestureRecognizer?.isEnabled = enable    }
@objc dynamic func webViewCanScroll(enable:Bool) {
        let contentView = self.webView.scrollView.subviews.first { view in
            if let className = object_getClass(view), NSStringFromClass(className) == "WKContentView" {
                return true
            }
            return false
        }
        let webTouchEventsGestureRecognizer = contentView?.gestureRecognizers?.first(where: { gesture in
            if let className = object_getClass(gesture), NSStringFromClass(className) == "UIWebTouchEventsGestureRecognizer" {
                return true
            }
            return false
        })
        webTouchEventsGestureRecognizer?.isEnabled = enable
    }

經過測試，h5 web容器側滑時出現的tab頁面左右滾動的體驗問題確實被解決。這樣既可以解決體驗問題，又可以解決側滑離開頁面導致的崩潰問題，但是這樣并沒有定位crash的根因。修復代碼上線后，crash量確實下降，但是每天還是有一些crash出現，且收到了個別頁面極端操作下偶現卡住的問題反饋。因此需要繼續(xù)排查crash根因，將crash根本解決掉。

繼續(xù)看文章開始的crash堆棧，通過Crash堆棧判斷崩潰原因是UIScrollview執(zhí)行滾動動畫過程中回調代理方法(見上圖)時訪問被釋放的內存。常規(guī)解決思路是在退出頁面后，在頁面生命周期的dealloc方法中，將UIScrollview的delegate置空即可。WKWebView確實有一個scrollVIew屬性，我們在很早的版本就將其delegate屬性置空，但是崩潰沒有解決。

deinit {         scrollView.delegate = nil         scrollView.dataSource = nil    }
deinit {
         scrollView.delegate = nil
         scrollView.dataSource = nil
    }

因此崩潰堆棧里的Scrollview代理不是這里的WKWebView的scrollVIew的代理。那崩潰堆棧中的scrollView代理到底屬于哪個UIScrollview呢？幸運的是蘋果webkit 是開源的，我們可以將webkit源碼下載下來看一下。

4、尋找崩潰堆棧中的ScrollViewDelegate

崩潰堆棧中的ScrollViewDelegate是WKScrollingNodeScrollViewDelegate。首先看看WKWebView的scrollview的 delegate是如何實現的，因為我們猜想這個scrollview的delegate除了我們自己設置的，是否還有其他delegate（比如崩潰堆棧中的WKScrollingNodeScrollViewDelegate）。

通過對Webkit源碼一番研究，發(fā)現scrollview的初始化方法：

- (void)_setupScrollAndContentViews{    CGRect bounds = self.bounds;    _scrollView = adoptNS([[WKScrollView alloc] initWithFrame:bounds]);    [_scrollView setInternalDelegate:self];    [_scrollView setBouncesZoom:YES];
}
- (void)_setupScrollAndContentViews
{
    CGRect bounds = self.bounds;
    _scrollView = adoptNS([[WKScrollView alloc] initWithFrame:bounds]);
    [_scrollView setInternalDelegate:self];
    [_scrollView setBouncesZoom:YES];


}

WKWebView的scrollVIew 是WKScrollView 類型。

4.1 WKScrollView 代理實現

首先看到WKWebView的scrollview的類型其實是WKScrollView（UIScrollview的子類），他除了繼承自父類的delegate屬性，還有一個internalDelegate屬性，那么這個internalDelegate屬性是不是我們要找的WKScrollingNodeScrollViewDelegate 呢？

@interface WKScrollView : UIScrollView
@property (nonatomic, assign) WKWebView <UIScrollViewDelegate> *internalDelegate;

@end
@interface WKScrollView : UIScrollView


@property (nonatomic, assign) WKWebView <UIScrollViewDelegate> *internalDelegate;




@end

通過閱讀源碼后發(fā)現不是這樣的（代碼有刪減，感興趣可自行閱讀源碼）。

- (void)setInternalDelegate:(WKWebView <UIScrollViewDelegate> *)internalDelegate{    if (internalDelegate == _internalDelegate)        return;    _internalDelegate = internalDelegate;    [self _updateDelegate];}
- (void)setDelegate:(id <UIScrollViewDelegate>)delegate{    if (_externalDelegate.get().get() == delegate)        return;    _externalDelegate = delegate;    [self _updateDelegate];}
- (id <UIScrollViewDelegate>)delegate{    return _externalDelegate.getAutoreleased();}
- (void)_updateDelegate{//......    if (!externalDelegate)    else if (!_internalDelegate)    else {        _delegateForwarder = adoptNS([[WKScrollViewDelegateForwarder alloc] initWithInternalDelegate:_internalDelegate externalDelegate:externalDelegate.get()]);        [super setDelegate:_delegateForwarder.get()];    }}
- (void)setInternalDelegate:(WKWebView <UIScrollViewDelegate> *)internalDelegate
{
    if (internalDelegate == _internalDelegate)
        return;
    _internalDelegate = internalDelegate;
    [self _updateDelegate];
}


- (void)setDelegate:(id <UIScrollViewDelegate>)delegate
{
    if (_externalDelegate.get().get() == delegate)
        return;
    _externalDelegate = delegate;
    [self _updateDelegate];
}


- (id <UIScrollViewDelegate>)delegate
{
    return _externalDelegate.getAutoreleased();
}


- (void)_updateDelegate
{//......
    if (!externalDelegate)
    else if (!_internalDelegate)
    else {
        _delegateForwarder = adoptNS([[WKScrollViewDelegateForwarder alloc] initWithInternalDelegate:_internalDelegate externalDelegate:externalDelegate.get()]);
        [super setDelegate:_delegateForwarder.get()];
    }
}

這個internalDelegate的作用是讓WKWebView 監(jiān)聽scrollview的滾動回調，同時也可以讓開發(fā)者在外部監(jiān)聽WKWebView的scrollview回調。如何實現的呢？可以查看WKScrollViewDelegateForwarder的實現。

- (void)forwardInvocation:(NSInvocation *)anInvocation{    //...    if (internalDelegateWillRespond)        [anInvocation invokeWithTarget:_internalDelegate];    if (externalDelegateWillRespond)        [anInvocation invokeWithTarget:externalDelegate.get()];
}
- (void)forwardInvocation:(NSInvocation *)anInvocation
{
    //...
    if (internalDelegateWillRespond)
        [anInvocation invokeWithTarget:_internalDelegate];
    if (externalDelegateWillRespond)
        [anInvocation invokeWithTarget:externalDelegate.get()];


}

通過復寫- (void)forwardInvocation:(NSInvocation *)anInvocation 方法，在消息轉發(fā)時實現的。

4.2 猜想 & 驗證

既然WKScrollingNodeScrollViewDelegate 不是WKScrollview的屬性，那說明崩潰堆棧中的scrollview不是WKScrollview，那頁面上還有其他scrollview么。我們看源碼WKScrollingNodeScrollViewDelegate 是在哪里設置的。

void ScrollingTreeScrollingNodeDelegateIOS::commitStateAfterChildren(const ScrollingStateScrollingNode& scrollingStateNode){        //......        if (scrollingStateNode.hasChangedProperty(ScrollingStateNode::Property::ScrollContainerLayer)) {            if (!m_scrollViewDelegate)                m_scrollViewDelegate = adoptNS([[WKScrollingNodeScrollViewDelegate alloc] initWithScrollingTreeNodeDelegate:this]);        } }
void ScrollingTreeScrollingNodeDelegateIOS::commitStateAfterChildren(const ScrollingStateScrollingNode& scrollingStateNode)
{
        //......
        if (scrollingStateNode.hasChangedProperty(ScrollingStateNode::Property::ScrollContainerLayer)) {
            if (!m_scrollViewDelegate)
                m_scrollViewDelegate = adoptNS([[WKScrollingNodeScrollViewDelegate alloc] initWithScrollingTreeNodeDelegate:this]);
        }
 }

搜索webkit的源碼，發(fā)現創(chuàng)建WKScrollingNodeScrollViewDelegate的位置只有一處。但是webkit的源碼太過于復雜，無法通過閱讀源碼的方式知道WKScrollingNodeScrollViewDelegate屬于哪個scrollview。

為此我們只能換一種思路，我們通過xcode調試的方式查看當前webview加載的頁面是否還有其他scrollview。

頁面上剛好還有一個scrollview：WKChildScrollview

這個WKChildScrollview 是否是崩潰堆棧中的scrollview呢，如果我們能確定他的delegate是WKScrollingNodeScrollViewDelegate，那就說明這個WKChildScrollview 是崩潰堆棧中的scrollview。

為了驗證這個猜想，我們首先找到源碼，源碼并沒有太多，看不出其delegate類型。

@interface WKChildScrollView : UIScrollView <WKContentControlled>@end
@interface WKChildScrollView : UIScrollView <WKContentControlled>
@end

我們只能轉換思路在運行時找到WKWebView的類型為WKChildScrollView的子view（通過OC runtime & 視圖樹遍歷的方式），判斷他的delegate是否為WKScrollingNodeScrollViewDelegate 。

我們運行時找到類型為 WKChildScrollView 的子view后，獲取其delegate類型，確實是WKScrollingNodeScrollViewDelegate。至此我們找到了崩潰堆棧中的scrollview。

確定了崩潰堆棧中的scrollview的類型，那么修復起來也比較容易了。在頁面生命周期的viewDidAppear方法里，獲取類型為 WKChildScrollView的子view。然后在dealloc方法里，將其delegate置空即可。

deinit {        if self.childScrollView != nil {            if self.childScrollView?.delegate != nil {                 self.childScrollView?.delegate = nil             }        }}

deinit {
        if self.childScrollView != nil {
            if self.childScrollView?.delegate != nil {
                 self.childScrollView?.delegate = nil
             }
        }
}

4.3 小程序同層渲染

想完了解決方案，那么WKChildScrollView 是做啥用的呢？

WKWebView 在內部采用的是分層的方式進行渲染，它會將 WebKit 內核生成的 Compositing Layer（合成層）渲染成 iOS 上的一個 WKCompositingView，這是一個客戶端原生的 View，不過可惜的是，內核一般會將多個 DOM 節(jié)點渲染到一個 Compositing Layer 上，因此合成層與 DOM 節(jié)點之間不存在一對一的映射關系。當把一個 DOM 節(jié)點的 CSS 屬性設置為 overflow: scroll （低版本需同時設置 -webkit-overflow-scrolling: touch）之后，WKWebView 會為其生成一個 WKChildScrollView，與 DOM 節(jié)點存在映射關系，這是一個原生的 UIScrollView 的子類，也就是說 WebView 里的滾動實際上是由真正的原生滾動組件來承載的。WKWebView 這么做是為了可以讓 iOS 上的 WebView 滾動有更流暢的體驗。雖說 WKChildScrollView 也是原生組件，但 WebKit 內核已經處理了它與其他 DOM 節(jié)點之間的層級關系，這一特性可以用來做小程序的同層渲染。（「同層渲染」顧名思義則是指通過一定的技術手段把原生組件直接渲染到 WebView 層級上，此時「原生組件層」已經不存在，原生組件此時已被直接掛載到 WebView 節(jié)點上。你幾乎可以像使用非原生組件一樣去使用「同層渲染」的原生組件，比如使用 view、image 覆蓋原生組件、使用 z-index 指定原生組件的層級、把原生組件放置在 scroll-view、swiper、movable-view 等容器內等等）。

5、蘋果的修復方案

本著嚴謹的態(tài)度，我們想是什么導致了最開始的崩潰堆棧呢？是我們開發(fā)過程中的功能還是系統(tǒng)bug？如果是系統(tǒng)bug，其他公司也可能遇到，但是互聯網上搜不到其他公司或開發(fā)者討論崩潰相關信息。我們繼續(xù)看一下崩潰堆棧的top 函數RemoteScrollingTree::scrollingTreeNodeDidScroll() 源碼如下：

void RemoteScrollingTree::scrollingTreeNodeDidScroll(ScrollingTreeScrollingNode& node, ScrollingLayerPositionAction scrollingLayerPositionAction){    ASSERT(isMainRunLoop());
    ScrollingTree::scrollingTreeNodeDidScroll(node, scrollingLayerPositionAction);
    if (!m_scrollingCoordinatorProxy)        return;
    std::optional<FloatPoint> layoutViewportOrigin;    if (is<ScrollingTreeFrameScrollingNode>(node))        layoutViewportOrigin = downcast<ScrollingTreeFrameScrollingNode>(node).layoutViewport().location();
    m_scrollingCoordinatorProxy->scrollingTreeNodeDidScroll(node.scrollingNodeID(), node.currentScrollPosition(), layoutViewportOrigin, scrollingLayerPositionAction);}
void RemoteScrollingTree::scrollingTreeNodeDidScroll(ScrollingTreeScrollingNode& node, ScrollingLayerPositionAction scrollingLayerPositionAction)
{
    ASSERT(isMainRunLoop());


    ScrollingTree::scrollingTreeNodeDidScroll(node, scrollingLayerPositionAction);


    if (!m_scrollingCoordinatorProxy)
        return;


    std::optional<FloatPoint> layoutViewportOrigin;
    if (is<ScrollingTreeFrameScrollingNode>(node))
        layoutViewportOrigin = downcast<ScrollingTreeFrameScrollingNode>(node).layoutViewport().location();


    m_scrollingCoordinatorProxy->scrollingTreeNodeDidScroll(node.scrollingNodeID(), node.currentScrollPosition(), layoutViewportOrigin, scrollingLayerPositionAction);
}

崩潰在這個函數里，查看這個函數的commit記錄：

簡單描述一下就是scrollingTreeNodeDidScroll方法中使用的m_scrollingCoordinatorProxy 對象改成weak指針，并進行判空操作。這種改變，正是解決m_scrollingCoordinatorProxy 內存被釋放后還在訪問的方案。

這個commit是2023年2月28號提交的，commit log是：

[UI-side compositing] RemoteScrollingTree needs to hold a weak ref to the RemoteScrollingCoordinatorProxyhttps://bugs.webkit.org/show_bug.cgi?id=252963rdar://105949247
Reviewed by Tim Horton.
The scrolling thread can extend the lifetime of the RemoteScrollingTree via activity on that thread,so RemoteScrollingTree needs to hold a nullable reference to the RemoteScrollingCoordinatorProxy;use a WeakPtr.
[UI-side compositing] RemoteScrollingTree needs to hold a weak ref to the RemoteScrollingCoordinatorProxy
https://bugs.webkit.org/show_bug.cgi?id=252963
rdar://105949247


Reviewed by Tim Horton.


The scrolling thread can extend the lifetime of the RemoteScrollingTree via activity on that thread,
so RemoteScrollingTree needs to hold a nullable reference to the RemoteScrollingCoordinatorProxy;
use a WeakPtr.

至此，我們基本確認，這個崩潰堆棧是webkit內部實現的一個bug，蘋果內部開發(fā)者最終使用弱引用的方式解決。

同時修復上線后，這個crash的崩潰量也降為0。

6、總結

本文的crash 似曾相識，但是經過驗證和閱讀源碼后發(fā)現并不是想象的那樣，繼續(xù)通過猜想+閱讀源碼的方式尋找到了崩潰堆棧中的真正scrollview代理對象，從而在app 側解決問題。最后發(fā)現是蘋果webkit的bug。

本文中的崩潰問題本質上是野指針問題，那么野指針問題定位有沒有通用的解決方案呢？

責任編輯：武曉燕來源：得物技術

得物 H5 容器