简书的文章页主要由文章内容和评论列表两部分构成，考虑到评论列表的操作体验和复用性等其它问题，我们最终选择用UIWebView展示文章内容，而用原生的UITableView来展示评论。这就涉及到了UIWebView与UITableView嵌套的问题，难点在于怎样处理两个UIScrollView嵌套时滚动的问题。
简书文章页从内容到评论的滚动
方案一
最早开发简书文章页时第一时间想到的方案，也是后来有不少开发者质疑我们为什么不使用的方案。
将tableView作为主体，tableView.tableHeaderView = webView，把webView.scrollView.scrollEnabled置为NO，然后在加载完成后将webView的size设置成其scrollView.contentSize。相当于是撑开webView，滑动事件完全交给tableView。如图所示
撑开webView的构成方案.jpg
乍一看很完美，当时差点就这么上线了，直到碰到了篇有50张图片的文章。可以看下Demo工程里的第一个，加载的HTML里仅包含了33张图片，在iPhone 8模拟器中运行，正常UIWebView打开，内存会增长约45M，而用这种“撑开”的UIWebView打开，内存直接增长了约150M。
因为UIWebView正常情况下不是一次性把所有东西都渲染的，而是在滚动时通过内部的
_UIWebBrowserView每次渲染比可视区域大一点的内容（猜测有一定的复用和回收机制），如果强行把WebView撑开，UIWebBrowserView就会一次渲染整个HTML内容，导致内存飙升甚至闪退。
优点：简单粗暴
缺点：业务上仅适用于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。
网友评论