ios 顶部tab滑动实现_iOS关于UIScrollView的嵌套联动

iOS-关于UIScrollView的嵌套联动

基本场景

(最终效果和链接在文末)UIScrollView嵌套多个UITableView的场景在APP里很常见，复杂点还有各种UITableView、UICollectionView各种嵌套的场景，目前通用的解决办法基本是在UIScrollView的代理方法- (void)scrollViewDidScroll:(UIScrollView *)scrollView里比较偏移量和需要悬停的坐标位置再做相应处理，定义主要父视图scrollView为mainScrollView,嵌套的多个联动scrollView为contentScrollView，先总结下大致思路。

1. 手势响应，shouldRecognizeSimultaneouslyWithGestureRecognizer必须同时作用于mainScrollView和所有contentScrollView，而contentScrollView是需要横向滑动的，因此要允许同时垂直滑动，而不支持水平和垂直同时滑动。

2. mainScrollView 、contentScrollView均需要实现scrollViewDidScroll并分别处理，两者的实际滑动是互斥的，同一时刻只有一方需要响应滑动，另一方做悬停处理，相互通知也很是麻烦。

3. 下拉刷新，mainScrollView 、contentScrollView各自有着需要下拉刷新的场景，一般contentScrollView需要下拉刷新时也正好处于自身临界固定点的位置，这里也需要单独处理下。

4. scrollsToTop 这其实是一个很容易被忽略的点，iOS系统有个小的隐藏功能，点击系统状态栏会查找到当前显示的UIScrollView并响应回到顶部，而在这种嵌套的场景里，主次需要响应的时机就依赖于需求了，或许需求就要求先回到contentScrollView后回到mainScrollView的顶部呢?。

要把这些都处理好，写代码的时候必须梳理清楚，即便如此，当项目不同模块都有着类似的需求的时候，又得好好捋一遍了，可能相似而不相同，一不小心就容易一团麻，令人抓狂。

之前在网上搜索这类需求的方案，大部分都是上述的大概思路，其他有些是对整个相关UI层的封装，一来学习使用成本略高，二则在已经成型的项目里使用的话，改动略大，耦合性比较高。于是打算自己重新整理一个低耦合的方案出来。

结果方案

依然是比较偏移量处理悬停，为了减少耦合，因此不走代理，采用KVO<