九色porny在线,视频一区在线观看,精品入口麻豆88视频

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

2023-05-30 09:43:11 來源：得物技術

1、背景

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

2、前期排查

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

【資料圖】

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

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

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

3、不完美的解決方案

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

具體代碼如下(這樣在操作頁面側滑返回時，頁面的手勢被禁掉，不會再滾動)：

@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出現，且收到了個別頁面極端操作下偶現卡住的問題反饋。因此需要繼續排查crash根因，將crash根本解決掉。

繼續看文章開始的crash堆棧，通過Crash堆棧判斷崩潰原因是UIScrollview執行滾動動畫過程中回調代理方法(見上圖)時訪問被釋放的內存。常規解決思路是在退出頁面后，在頁面生命周期的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源碼一番研究，發現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  *internalDelegate;@end@interface WKScrollView : UIScrollView@property (nonatomic, assign) WKWebView  *internalDelegate;@end

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

- (void)setInternalDelegate:(WKWebView  *)internalDelegate{    if (internalDelegate == _internalDelegate)        return;    _internalDelegate = internalDelegate;    [self _updateDelegate];}- (void)setDelegate:(id )delegate{    if (_externalDelegate.get().get() == delegate)        return;    _externalDelegate = delegate;    [self _updateDelegate];}- (id )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  *)internalDelegate{    if (internalDelegate == _internalDelegate)        return;    _internalDelegate = internalDelegate;    [self _updateDelegate];}- (void)setDelegate:(id )delegate{    if (_externalDelegate.get().get() == delegate)        return;    _externalDelegate = delegate;    [self _updateDelegate];}- (id )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 監聽scrollview的滾動回調，同時也可以讓開發者在外部監聽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 方法，在消息轉發時實現的。

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的源碼，發現創建WKScrollingNodeScrollViewDelegate的位置只有一處。但是webkit的源碼太過于復雜，無法通過閱讀源碼的方式知道WKScrollingNodeScrollViewDelegate屬于哪個scrollview。

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

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

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

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

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

5、蘋果的修復方案

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

void RemoteScrollingTree::scrollingTreeNodeDidScroll(ScrollingTreeScrollingNode& node, ScrollingLayerPositionAction scrollingLayerPositionAction){    ASSERT(isMainRunLoop());    ScrollingTree::scrollingTreeNodeDidScroll(node, scrollingLayerPositionAction);    if (!m_scrollingCoordinatorProxy)        return;    std::optional layoutViewportOrigin;    if (is(node))        layoutViewportOrigin = downcast(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 layoutViewportOrigin;    if (is(node))        layoutViewportOrigin = downcast(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://105949247Reviewed 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 RemoteScrollingCoordinatorProxyhttps://bugs.webkit.org/show_bug.cgi?id=252963rdar://105949247Reviewed 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，蘋果內部開發者最終使用弱引用的方式解決。

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

6、總結

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

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

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

標簽：