在鸿蒙中开发Flutter项目，一个最大的问题，就是「不太会写鸿蒙代码」，这对于一个Flutter开发者来说，虽然不是一件很麻烦的事，但由于现在鸿蒙的版本和文档还略有一些混乱，所以要写好还是有一些麻烦的，所以，秉着能用工具解决的问题就不要自己写的原则，我们参考Native的Flutter Channel的实现，也就是pigeon的方式，不熟悉的同学可以参考我之前的文章。
首先说明一下，这篇文章是给具备Flutter开发经验的客户端同学看的。Flutter 的诞生虽然来自 Google 的 Chrome 团队，但大家都知道 Flutter 最先支持的平台是 Android 和 iOS，至今最核心的维护平台依然是 Android 和 iOS。由于 dart 语言的学习成本不高，Flutter 的响应式UI与 ComposeUI 和 SwiftUI 都有极大的相似之处，整体的架构思路也更偏向于客户端的模式，再加上为了实现很多硬件或 Native 相关的基础功能也需要专业的客户端开发知识，所以 Flutter 更多的是被客户端开发同学认可并使用（在我们的团队中，Flutter 已经是客户端开发同学的必备基本技能）。 在此背景下，Flutter 最初并不在 web 端上发力。不过由于 Flutter 本身就是携带了 web 的基因，在 Flutter2 发布的同时也发布了 web 的稳定版。那么它有什么优势和劣势呢？
在Android应用中， 用户时常会遇到界面卡顿的情况，非常影响用户的体验。作为Android开发肯定都知道：应用在主线程里做了大量的耗时操作(例如文件读写， 数据库读写，网络访问，图片编解码等)，就会导致UI不能及时刷新，出现跳帧现象。如果应用主线程不能及时处理用户的输入事件或广播消息，系统甚至会直接弹出著名的ANR对话框，提示用户杀死应用。 在Flutter应用中，如果出现界面卡顿，它的原因也是如此吗？ 我们带着这些疑问，一起来搞清楚Flutter的线程模型和异步原理，并找到问题的答案。
那么接下来我们想详细的说一说Flutter是如何处理手势事件的。本文将通过源码详细分析Flutter的事件分发与冲突处理过程，并通过示例说明不同冲突的处理方式。
