得物H5容器野指針疑難問題排查 & 解決
1、背景
得物 iOS 4.9.x 版本 上線后，一些帶有橫向滾動內(nèi)容的h5頁面，有一個webkit 相關(guān)crash增加較快。通過Crash堆棧判斷是UIScrollview執(zhí)行滾動動畫過程中內(nèi)存野指針導致的崩潰。
2、前期排查
通過頁面瀏覽日志，發(fā)現(xiàn)發(fā)生崩潰時所在的頁面都是在h5 web容器內(nèi)，且都是在頁面的生命周期方法viewDidDisappear方法調(diào)用后才發(fā)生崩潰，因此推測崩潰是在h5 頁面返回時發(fā)生的。
剛好交易的同事復現(xiàn)了崩潰證實了我們的推測。因此可以基本確定：崩潰的原因是頁面退出后，頁面內(nèi)存被釋放，但是滾動動畫繼續(xù)執(zhí)行，這時崩潰堆棧中scrollview的delegate沒有置空，系統(tǒng)繼續(xù)執(zhí)行delegate的相關(guān)方法，訪問了已經(jīng)釋放的對象的內(nèi)存（野指針問題）。
同時發(fā)生crash h5 頁面都存在一個特點，就是頁面內(nèi)存在可以左右橫滑的tab視圖。
操作手勢側(cè)滑存在體驗問題，左右橫滑的tab視圖也會跟著滾動（見下面視頻）。關(guān)聯(lián)bugly用戶行為日志，判斷這個體驗問題是和本文中的crash有相關(guān)性的。
3、不完美的解決方案
經(jīng)過上面的分析，修復思路是在h5頁面手勢側(cè)滑返回時，將h5容器頁面內(nèi)tab的橫滑手勢禁掉（同時需要在 h5 web容器的viewWillAppear方法里將手勢再打開，因為手勢側(cè)滑是可以取消在返回頁面）。
具體代碼如下(這樣在操作頁面?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
}經(jīng)過測試，h5 web容器側(cè)滑時出現(xiàn)的tab頁面左右滾動的體驗問題確實被解決。這樣既可以解決體驗問題，又可以解決側(cè)滑離開頁面導致的崩潰問題，但是這樣并沒有定位crash的根因。修復代碼上線后，crash量確實下降，但是每天還是有一些crash出現(xiàn)，且收到了個別頁面極端操作下偶現(xiàn)卡住的問題反饋。因此需要繼續(xù)排查crash根因，將crash根本解決掉。
繼續(xù)看文章開始的crash堆棧，通過Crash堆棧判斷崩潰原因是UIScrollview執(zhí)行滾動動畫過程中回調(diào)代理方法(見上圖)時訪問被釋放的內(nèi)存。常規(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是如何實現(xiàn)的，因為我們猜想這個scrollview的delegate除了我們自己設(shè)置的，是否還有其他delegate（比如崩潰堆棧中的WKScrollingNodeScrollViewDelegate）。
通過對Webkit源碼一番研究，發(fā)現(xiàn)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 代理實現(xiàn)
首先看到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ā)現(xiàn)不是這樣的（代碼有刪減，感興趣可自行閱讀源碼）。
- (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的滾動回調(diào)，同時也可以讓開發(fā)者在外部監(jiān)聽WKWebView的scrollview回調(diào)。如何實現(xiàn)的呢？可以查看WKScrollViewDelegateForwarder的實現(xiàn)。
- (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 方法，在消息轉(zhuǎn)發(fā)時實現(xiàn)的。
4.2 猜想 & 驗證
既然WKScrollingNodeScrollViewDelegate 不是WKScrollview的屬性，那說明崩潰堆棧中的scrollview不是WKScrollview，那頁面上還有其他scrollview么。我們看源碼WKScrollingNodeScrollViewDelegate 是在哪里設(shè)置的。
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ā)現(xiàn)創(chuàng)建WKScrollingNodeScrollViewDelegate的位置只有一處。但是webkit的源碼太過于復雜，無法通過閱讀源碼的方式知道WKScrollingNodeScrollViewDelegate屬于哪個scrollview。
為此我們只能換一種思路，我們通過xcode調(diào)試的方式查看當前webview加載的頁面是否還有其他scrollview。
頁面上剛好還有一個scrollview：WKChildScrollview
這個WKChildScrollview 是否是崩潰堆棧中的scrollview呢，如果我們能確定他的delegate是WKScrollingNodeScrollViewDelegate，那就說明這個WKChildScrollview 是崩潰堆棧中的scrollview。
為了驗證這個猜想，我們首先找到源碼，源碼并沒有太多，看不出其delegate類型。
@interface WKChildScrollView : UIScrollView <WKContentControlled>@end
@interface WKChildScrollView : UIScrollView <WKContentControlled>
@end我們只能轉(zhuǎn)換思路在運行時找到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 在內(nèi)部采用的是分層的方式進行渲染，它會將 WebKit 內(nèi)核生成的 Compositing Layer（合成層）渲染成 iOS 上的一個 WKCompositingView，這是一個客戶端原生的 View，不過可惜的是，內(nèi)核一般會將多個 DOM 節(jié)點渲染到一個 Compositing Layer 上，因此合成層與 DOM 節(jié)點之間不存在一對一的映射關(guān)系。當把一個 DOM 節(jié)點的 CSS 屬性設(shè)置為 overflow: scroll （低版本需同時設(shè)置 -webkit-overflow-scrolling: touch）之后，WKWebView 會為其生成一個 WKChildScrollView，與 DOM 節(jié)點存在映射關(guān)系，這是一個原生的 UIScrollView 的子類，也就是說 WebView 里的滾動實際上是由真正的原生滾動組件來承載的。WKWebView 這么做是為了可以讓 iOS 上的 WebView 滾動有更流暢的體驗。雖說 WKChildScrollView 也是原生組件，但 WebKit 內(nèi)核已經(jīng)處理了它與其他 DOM 節(jié)點之間的層級關(guān)系，這一特性可以用來做小程序的同層渲染。（「同層渲染」顧名思義則是指通過一定的技術(shù)手段把原生組件直接渲染到 WebView 層級上，此時「原生組件層」已經(jīng)不存在，原生組件此時已被直接掛載到 WebView 節(jié)點上。你幾乎可以像使用非原生組件一樣去使用「同層渲染」的原生組件，比如使用 view、image 覆蓋原生組件、使用 z-index 指定原生組件的層級、把原生組件放置在 scroll-view、swiper、movable-view 等容器內(nèi)等等）。
5、蘋果的修復方案
本著嚴謹?shù)膽B(tài)度，我們想是什么導致了最開始的崩潰堆棧呢？是我們開發(fā)過程中的功能還是系統(tǒng)bug？如果是系統(tǒng)bug，其他公司也可能遇到，但是互聯(lián)網(wǎng)上搜不到其他公司或開發(fā)者討論崩潰相關(guān)信息。我們繼續(xù)看一下崩潰堆棧的top 函數(shù)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);
}崩潰在這個函數(shù)里，查看這個函數(shù)的commit記錄：
簡單描述一下就是scrollingTreeNodeDidScroll方法中使用的m_scrollingCoordinatorProxy 對象改成weak指針，并進行判空操作。這種改變，正是解決m_scrollingCoordinatorProxy 內(nèi)存被釋放后還在訪問的方案。
這個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內(nèi)部實現(xiàn)的一個bug，蘋果內(nèi)部開發(fā)者最終使用弱引用的方式解決。
同時修復上線后，這個crash的崩潰量也降為0。
6、總結(jié)
本文中的crash從出現(xiàn)到解決歷時近一年，一開始根據(jù)線上日志判斷是h5 頁面返回 & h5 頁面滾動導致的問題，禁用手勢后雖然幾乎解決問題，但是線上還有零星crash上報，因此為了保證h5 離線功能的線上穩(wěn)定性，需要完美解決問題。
本文的crash 似曾相識，但是經(jīng)過驗證和閱讀源碼后發(fā)現(xiàn)并不是想象的那樣，繼續(xù)通過猜想+閱讀源碼的方式尋找到了崩潰堆棧中的真正scrollview代理對象，從而在app 側(cè)解決問題。最后發(fā)現(xiàn)是蘋果webkit的bug。
本文中的崩潰問題本質(zhì)上是野指針問題，那么野指針問題定位有沒有通用的解決方案呢？
