简书的文章页主要由文章内容和评论列表两部分构成，考虑到评论列表的操作体验和复用性等其它问题，我们最终选择用UIWebView展示文章内容，而用原生的UITableView来展示评论。这就涉及到了UIWebView与UITableView嵌套的问题，难点在于怎样处理两个UIScrollView嵌套时滚动的问题。

简书文章页从内容到评论的滚动

方案一

最早开发简书文章页时第一时间想到的方案，也是后来有不少开发者质疑我们为什么不使用的方案。
将tableView作为主体，tableView.tableHeaderView = webView，把webView.scrollView.scrollEnabled置为NO，然后在加载完成后将webView的size设置成其scrollView.contentSize。相当于是撑开webView，滑动事件完全交给tableView。如图所示

撑开webView的构成方案.jpg

优点：简单粗暴
缺点：业务上仅适用于HTML内容长度可控的情况，比如和内容生产者约定了内容最大长度。代码上在HTML里无法正确取到viewport的大小。
简书作为UGC社区，作者可能会写上万字，上传几十甚至上百张图片，显然是无法使用该方案的。

方案二

简书文章页在v3.7.0前一直使用的方案。
视图构成同方案一tableView.tableHeaderView = webView，但不撑开webView。禁用webView.scrollView和tableView的bounces，完全由系统来管理滚动哪个scrollView。demo里就不上代码了。唯一的难点是已滚动到tableView后，如果webView的内容高度还在变动（比如图片还在加载，加载后会改变内容高度），需要不断将webView的contentOffset设置到底，否则再滚回文章的时候就会出现由于webView.scrollView未处于底部又无法滚动，而导致的类似文章被“截断”的问题。

优点：除了省事貌似没什么优点。。
缺点：体验上滑到两个scrollView临界的地方会卡住，需要手指抬起后重新滚动；代码上需要频繁更改scrollView的contentOffset，一不留神就会出现webView内容被“截断”无法滚动的效果。

方案三

重点来了，简书文章页在v3.7.0以来使用的方案。
首先是视图构成，将webView作为主体，其加载的HTML最后留一个空白div，用于确定tableView的位置。tableView加到webView.scrollView上，在监听到webView.scrollView的内容尺寸变化后，不断调整tableView的位置对应于该空白div的位置，同时将该div的尺寸设置为tableView的尺寸。如图所示

简书文章页视图构成

这里要注意在更新div高度，即更改webView.scrollView.contentSize时，要先移除监听，更新完后再加上，来避免死循环。

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context {
    if (object == self.webView.scrollView &&
        [change[NSKeyValueChangeNewKey] CGSizeValue].height != [change[NSKeyValueChangeOldKey] CGSizeValue].height) {
        //取消监听，因为这里会调整contentSize，避免无限循环
        [self removeObserverForWebViewContentSize];
        [self changeWebViewContentSize];
        [self addObserverForWebViewContentSize];
    }
}

然后是手势操作，将两者的scrollEnabled都禁用，添加UIPanGestureRecognizer和UIDynamicAnimator来构建仿原生的惯性滚动和回弹效果。说简单点就是要解决webView滚动到底后，让tableView继续以此初速度开始滚动，反向亦然。

- (void)handlePanGestureRecognizer:(UIPanGestureRecognizer *)recognizer {
    switch (recognizer.state) {
        case UIGestureRecognizerStateBegan: {
            [self.dynamicAnimator removeAllBehaviors];
        }
            break;
        case UIGestureRecognizerStateChanged: {
            CGPoint translation = [recognizer translationInView:self.view];
            [self scrollViewsWithDeltaY:translation.y];
            [recognizer setTranslation:CGPointZero inView:self.view];
        }
            break;
        case UIGestureRecognizerStateEnded: {
            DynamicItem *item = [[DynamicItem alloc] init];
            item.center = CGPointZero;
            __block CGFloat lastCenterY = 0;
            UIDynamicItemBehavior *inertialBehavior = [[UIDynamicItemBehavior alloc] initWithItems:@[item]];
            [inertialBehavior addLinearVelocity:CGPointMake(0, -[recognizer velocityInView:self.view].y) forItem:item];
            inertialBehavior.resistance = 2;
            __weak typeof(self) weakSelf = self;
            inertialBehavior.action = ^{
                [weakSelf scrollViewsWithDeltaY:lastCenterY - item.center.y];
                lastCenterY = item.center.y;
            };
            self.inertialBehavior = inertialBehavior;
            [self.dynamicAnimator addBehavior:inertialBehavior];
        }
            break;
        default:
            break;
    }
}

UIGestureRecognizerStateChanged滚动当前拖动的scrollView，UIGestureRecognizerStateEnded手指离开时继续惯性运动，其中还包含可能的弹性运动。因为要保证两个scrollView的运动连贯性，就不能给两个scrollView分别加物理运动，而是创建一个DynamicItem，它遵循UIDynamicItem协议，可以看做是一个质点。实际就是通过它的物理运动来修改两个scrollView的偏移量。
具体描述起来比较复杂，可以直接看Demo工程里的第三个PlanCViewController，有详细的代码。

优点：自己管理滚动事件，至少体验上不会再出什么幺蛾子
缺点：代码实现略复杂。另外，由于禁掉了webView.scrollView.scrollEnabled，在js里是无法监听到scroll事件的，但是webView的scrollViewDidScroll回调却会走，所以如果要做图片懒加载之类依赖于scroll事件的功能，需要自己控制好频率，在scrollViewDidScroll中不停的调js

以上就是简书文章页在开发中的一些经验之谈，大家可以根据自己的业务需求选择合适的技术方案。不过要说的是，苹果和安卓官方开发都不推荐这种形式的ScrollView嵌套，如果评论列表的操作较简单，请优先考虑整个页面使用HTML。

参考资料

• 用UIKit Dynamics模仿UIScrollView
• UIWebView的scrollView和渲染机制探究