- CompoundButton 源码分析
- LinearLayout 源码分析
- SearchView 源码解析
- LruCache 源码解析
- ViewDragHelper 源码解析
- BottomSheets 源码解析
- Media Player 源码分析
- NavigationView 源码解析
- Service 源码解析
- Binder 源码分析
- Android 应用 Preference 相关及源码浅析 SharePreferences 篇
- ScrollView 源码解析
- Handler 源码解析
- NestedScrollView 源码解析
- SQLiteOpenHelper/SQLiteDatabase/Cursor 源码解析
- Bundle 源码解析
- LocalBroadcastManager 源码解析
- Toast 源码解析
- TextInputLayout
- LayoutInflater 和 LayoutInflaterCompat 源码解析
- TextView 源码解析
- NestedScrolling 事件机制源码解析
- ViewGroup 源码解析
- StaticLayout 源码分析
- AtomicFile 源码解析
- AtomicFile 源码解析
- Spannable 源码分析
- Notification 之 Android 5.0 实现原理
- CoordinatorLayout 源码分析
- Scroller 源码解析
- SwipeRefreshLayout 源码分析
- FloatingActionButton 源码解析
- AsyncTask 源码分析
- TabLayout 源码解析
文章来源于网络收集而来,版权归原创者所有,如有侵权请及时联系!
5. 总结
一个 View(或其子 View) 一旦不消费某一个 MotionEvent 事件,该 View 便再也捕获不到这个后续的 MotionEvent 序列。这样就使得“视差”这类的交互逻辑无法实现。
试想,如果是我们自身去设计这个“视差”,以 AppbarLayout 的 Behavior 效果为例,常规思路应该是这样的:
- 当我们向上滑动视图的时候,MotionEvent 由 CoordinatorLayout 去消费,这个时候 NestedScrollView 内部并没有滑动,只是 CoordinatorLayout 实现了位移。
- 当 toolbar 悬停的时候,我们再继续向上拖拽,MotionEvent 由 NestedScrollView 去消费,CoordinatorLayout 不去拦截,视图的滑动是 NestedScrollView 内部的滑动。
这样的常规思路,对我们普通人来说,或许更容易理解。但是在安卓的 Touch 传递机制来看,这却是无解的。至于为何无解的原因,前面已经提及多次。Google 的工程师们在最初设计这一套 Touch 机制的时候,应该是没有问题的。只是随着时间不断往前推移,出现了视差这样更复杂的交互逻辑。
Behavior 的出现,并没有改变 Touch 自身的机制,它只是钻了之前 MotionEvent 的一个空子。通过调用 MotionEvent 的 offsetLocation 方法,巧妙地解决了视差问题。在 layout 文件可视化的那个 design 页签上面,CoordinatorLayout 的第二个子 View 是越过屏幕高度的。单从这个方面,我们也能猜测 AppbarLayout 的 Behavior 的工作机制了:MotionEvent 事件一直由 NestedScrollView 去消费,只是在消费的同时,也通过 Behavior 影响了 CoordinatorLayout 的上下位移量。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论