在实现上一篇介绍的自定义滑动关联菜单控件BFScrollMenu时，关于滑动方向判断的逻辑其实一开始是准备用手势操作来实现的，结果发现在ScrollView中处理手势的逻辑比较困难，在写的时候还没有仔细研究过ScrollView的滑动原理，只是知道需要自定义一个ScrollView才能实现，但是我的本意是不希望用户还要显示指定一个自定义的ScrollView而是直接用category进行无缝的对接，所以就改用didScroll delegate 用offset来计算滑动逻辑了，效果可以接受。
回过头来花了些时间仔细研究了下UIScrollView的滑动处理逻辑，这样就可以采用Customer ScrollView来实现同样的BFScrollMenu逻辑了。
-
UIScrollView的滑动处理原理
网上相关的文章有很多，但是我感觉没有一个能清晰的解释清楚。这里我用流程图的方式，把我自己经过试验后的结论和理解和大家分享一下，希望能帮助到你。如果有不正确的欢迎指正。
首先我们来看Apple的官方代码文档里的注释：
Scrolling with no scroll bars is a bit complex. on touch down, we don't know if the user will want to scroll or track a subview like a control. on touch down, we start a timer and also look at any movement. if the time elapses without sufficient change in position, we start sending events to the hit view in the content subview. if the user then drags far enough, we switch back to dragging and cancel any tracking in the subview. the methods below are called by the scroll view and give subclasses override points to add in custom behaviour. you can remove the delay in delivery of touchesBegan:withEvent: to subviews by setting delaysContentTouches to NO.
然后再往下看2个可以set的property和2个可以重载的方法：
// default is YES. if NO, we immediately call -touchesShouldBegin:withEvent:inContentView:.
// this has no effect on presses
@property(nonatomic) BOOL delaysContentTouches;
// default is YES. if NO, then once we start tracking, we don't try to drag if the touch moves.
// this has no effect on presses
@property(nonatomic) BOOL canCancelContentTouches;
// override points for subclasses to control delivery of touch events to subviews of the scroll view
// called before touches are delivered to a subview of the scroll view.
// if it returns NO the touches will not be delivered to the subview
// this has no effect on presses
// default returns YES
- (BOOL)touchesShouldBegin:(NSSet<UITouch *> *)touches withEvent:(nullable UIEvent *)event inContentView:(UIView *)view;
// called before scrolling begins if touches have already been delivered to a subview of the scroll view.
// if it returns NO the touches will continue to be delivered to the subview and scrolling will not occur
// not called if canCancelContentTouches is NO. default returns YES if view isn't a UIControl.
// this has no effect on presses
- (BOOL)touchesShouldCancelInContentView:(UIView *)view;
有了以上这些，已经基本能够理解ScrollView对手势操作的处理原理，这里来统一归纳一下。我们直接上图最清晰：
解释下上图：
- Apple使用了一个延迟机制来判断在一个ScrollView内是否产生有效的滑动手势
，而这个延迟机制由开关delaysContentTouches来控制，默认为YES - 如果延迟打开且检测到有效Scroll，则将会直接发送滑动操作到ScrollView，并停止向SubView发送任何tracking；
- 如果延迟未打开或者打开但是没有检测到有效的动作，则会看
touchesShouldBegin:withEvent:inContentView:的返回：NO则立即返回给ScrollView，否则会将touch事件发送给SubView。默认为YES。
当touch事件已经发送给SubView之后，如果用户继续产生touch事件（做出Scroll动作），则： - 检查
canCancelContentTouches开关（默认为YES）。如果为N，则将所有后续事件发送到SubView，否则： - 检查
touchesShouldCancelInContentView的返回值，如果为N，则将所有事件发送到SubView，否则返回到ScrollView。默认情况下，如果SubView不是UIControl的一种，则返回YES。
-
一个简单的总结：
针对1，2： 默认情况下，只要用户迅速做出滑动手势，都将触发ScrollView滑动；
针对3：默认情况下，点击操作都可以传入到SubView
针对4,5：默认情况下，SubView中的Button, UISlider, UISwitch等等都可以直接响应你的Touch，滑动事件；但是UIView之类则无法响应复杂事件（Multi-Touch）
-
想要让SubView响应手势操作 ？
最简单的：
- 关闭
delaysContentTouches - 关闭
canCancelContentTouches
如果想要再多一些自定义，比如有些地方响应，有些地方不响应，则可以：
在touchesShouldBegin:withEvent:inContentView:中设定响应条件，或者：
打开canCancelContentTouches，在touchesShouldCancelInContentView:中设定响应条件。
-
Sample Demo
说这么多还是没懂？再来一发Demo，直接看代码最清晰：
这个Demo中，首先自定义一个ScrollView叫做“MyScollView”，在MyScollView上，有2个SubView：绿色的greenView和黄色的yellowView，两个View都添加的左右滑动的手势操作，但是在touchesShouldBegin:withEvent:inContentView:方法中，当检测到当前view为greenView时，返回NO。
另外，有2个Switch开关，分别操作delaysContentTouches 和 canCancelContentTouches。
我们可以看一下效果：
1） 初始状态下，所有开关打开，UIButton正常工作，yellowView不能响应手势；
a) 触动yellowView屏幕后马上滑动，则UISilder不能正常工作，ScrollView滑动；
b) 触动yellowView屏幕后等待一小会再滑动，则UISilder正常工作；
2） 关闭canCancelContentTouches：
a) 触动yellowView屏幕后马上滑动，则ScrollView滑动；
b) 触动yellowView屏幕后等待一小会再滑动，则UISilder， yellowView响应手势；
3）关闭delaysContentTouches，无论怎样，UISilder，yellowView都会响应手势；
4）以上任何情况，greenView始终不会响应手势
希望你喜欢，欢迎大家讨论。
2016.6.14 完稿于南京
