Solve the problem of page overflow: Scroll scrolling on mobile iOS system

If the overflow: Scroll attribute is used for a div or module, there will be obvious lag phenomenon when browsing on the mobile phone of iOS system. This problem does not occur on Android phones. Through a morning crawler search and technical discussion with the front-end development expert learned that the following code can solve the problem of this kind of lag:

-webkit-overflow-scrolling: touch; This line of code supposedly slides smoothly because it has hardware acceleration enabled. But this property is also relatively memory intensive. Given the choice between smooth sliding and memory consumption, I chose the former.

I later looked into this property in more detail. Specific in-depth points are as follows:

In fact, Safari does use native controls to create a UIScrollView for pages that have -webkit-overflow-scrolling, providing a sublayer for the rendering module to use. The stack is created as follows:

Thread 1, Queue : com.apple.main-thread #0 0x00086723 in -[UIScrollView initWithFrame:] () #1 0x004ec3bd in -[UIWebOverflowScrollView initWithLayer:node:webDocumentView:] () #2 0x001f1769 in -[UIWebDocumentView webView:didCreateOrUpdateScrollingLayer:withContentsLayer:scrollSize:forNode:allowHorizontalScrollbar:allowVerticalScrol lbar:] () #3 0x01d571bd in invoking_ () #4 0x01d570d6 in -[NSInvocation invoke] () #5 0x01d5724a in -[NSInvocation invokeWithTarget:] () #6 0x027fb6a1 in -[_WebSafeForwarder forwardInvocation:] () #7 0x027fb8ab in __44-[_WebSafeAsyncForwarder forwardInvocation:]_block_invoke_0 () #8 0x04ac753f in _dispatch_call_block_and_release () #9 0x04ad9014 in _dispatch_client_callout () #10 0x04ac97d5 in _dispatch_main_queue_callback_4CF () #11 0x01d09af5 in __CFRunLoopRun () #12 0x01d08f44 in CFRunLoopRunSpecific () #13 0x01d08e1b in CFRunLoopRunInMode () #14 0x01cbd7e3 in GSEventRunModal () #15 0x01cbd668 in GSEventRun () #16 0x00032ffc in UIApplicationMain () #17 0x00002ae2 in main at /Users/liuhx/Desktop/UIWebView_Research/WebViewResearch/main.mm:16

UIWebOverflowScrollView is actually created, which inherits from UIScrollView and is declared as:

@class DOMNode, UIWebDocumentView, UIWebOverflowContentView, UIWebOverflowScrollListener; @interface UIWebOverflowScrollView : UIScrollView { UIWebDocumentView *_webDocumentView; UIWebOverflowScrollListener *_scrollListener; UIWebOverflowContentView *_overflowContentView; DOMNode *_node; BOOL _beingRemoved; } @property(nonatomic, getter=isBeingRemoved) BOOL beingRemoved; // @synthesize beingRemoved=_beingRemoved; @property(retain, nonatomic) DOMNode *node; // @synthesize node=_node; @property(retain, nonatomic) UIWebOverflowContentView *overflowContentView; // @synthesize overflowContentView=_overflowContentView; @property(retain, nonatomic) UIWebOverflowScrollListener *scrollListener; // @synthesize scrollListener=_scrollListener; @property(nonatomic) UIWebDocumentView *webDocumentView; // @synthesize webDocumentView=_webDocumentView; – (void)setContentOffset:(struct CGPoint)arg1; – (void)_replaceLayer:(id)arg1; – (void)prepareForRemoval; – (void)fixUpViewAfterInsertion; – (id)superview; – (void)dealloc; – (id)initWithLayer:(id)arg1 node:(id)arg2 webDocumentView:(id)arg3; @end

It also has a child View as a ContentView, which is the container for the Layer that WebCore really uses to render overflow-type content. UIWebOverflowContentView declares:

@interface UIWebOverflowContentView : UIView { } – (void)_setCachedSubviews:(id)arg1; – (void)_replaceLayer:(id)arg1; – (void)fixUpViewAfterInsertion; – (id)superview; – (id)initWithLayer:(id)arg1; @end

And then down below, it’s CALayer’s operation. Both of these classes are UIKit layer implementations that require hardware acceleration for WebCore to be meaningful, and the logic is contained in the ACCELERATED_COMPOSITING macro.

I said a lot about the principle, but I didn’t understand a word of it. However, as the knowledge of the sharer should always be the most simple and clear statement to explain the problem, so summarize the following points for your reference:

According to SVN log, WebKit 108400 is not supported, so iOS Safari should be 5.0. Android supports 4.0 and above. From a front-end development perspective, just know that the CSS property-webkit-overflow-scrolling really creates system-level controls with hardware acceleration, so it’s efficient. From a practical development perspective, this approach is relatively memory intensive, and is best applied only when overflow is very large.