手勢(shì)操作在 Flutter 中分為兩類：
目前成都創(chuàng)新互聯(lián)公司已為超過(guò)千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬空間、網(wǎng)站改版維護(hù)、企業(yè)網(wǎng)站設(shè)計(jì)、阿城網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。
第一類是原始的指針事件（Pointer Event），即原生開(kāi)發(fā)中常見(jiàn)的觸摸事件，表示屏幕上觸摸（或鼠標(biāo)、手寫筆）行為觸發(fā)的位移行為；
第二類則是手勢(shì)識(shí)別（Gesture Detector），表示多個(gè)原始指針事件的組合操作，如點(diǎn)擊、雙擊、長(zhǎng)按等，是指針事件的語(yǔ)義化封裝。
指針事件表示用戶交互的原始觸摸數(shù)據(jù)，如手指接觸屏幕 PointerDownEvent、手指在屏幕上移動(dòng) PointerMoveEvent、手指抬起 PointerUpEvent，以及觸摸取消 PointerCancelEvent。在手指接觸屏幕，觸摸事件發(fā)起時(shí)，F(xiàn)lutter 會(huì)確定手指與屏幕發(fā)生接觸的位置上究竟有哪些組件，并將觸摸事件交給最內(nèi)層的組件去響應(yīng)。事件會(huì)從這個(gè)最內(nèi)層的組件開(kāi)始，沿著組件樹(shù)向根節(jié)點(diǎn)向上冒泡分發(fā)。通過(guò) hitTestBehavior 去調(diào)整組件在命中測(cè)試期內(nèi)應(yīng)該如何表現(xiàn)，比如把觸摸事件交給子組件，或者交給其視圖層級(jí)之下的組件去響應(yīng)。關(guān)于組件層面的原始指針事件的監(jiān)聽(tīng)，F(xiàn)lutter 提供了 Listener Widget，可以監(jiān)聽(tīng)其子 Widget 的原始指針事件。
Listener(
child: Container(
color: Colors.black,
width: 300,
height: 300,
),
onPointerDown: (event) = print("down $event"),// 手勢(shì)按下回調(diào)
onPointerMove:? (event) = print("move $event"),// 手勢(shì)移動(dòng)回調(diào)
onPointerUp:? (event) = print("up $event"),// 手勢(shì)抬起回調(diào)
);
Gesture 是手勢(shì)語(yǔ)義的抽象，而如果我們想從組件層監(jiān)聽(tīng)手勢(shì)，則需要使用 GestureDetector 。GestureDetector 是一個(gè)處理各種高級(jí)用戶觸摸行為的 Widget，與 Listener 一樣，也是一個(gè)功能性組件。
GestureDetector(// 手勢(shì)識(shí)別
? ? child: Container(color: Colors.red,width: 50,height: 50),// 紅色子視圖
? ? onTap: ()=print("Tap"),// 點(diǎn)擊回調(diào)
? ? onDoubleTap: ()=print("Double Tap"),// 雙擊回調(diào)
? ? onLongPress: ()=print("Long Press"),// 長(zhǎng)按回調(diào)
? ? onPanUpdate: (e) {// 拖動(dòng)回調(diào)
? ? ? setState(() {
? ? ? ? // 更新位置
? ? ? ? _left += e.delta.dx;
? ? ? ? _top += e.delta.dy;
? ? ? });
? ? },
? ),
Flutter支持穩(wěn)定的桌面設(shè)備開(kāi)發(fā)已經(jīng)一段時(shí)間了，不得不說(shuō)，F(xiàn)lutter多平臺(tái)支持的特性真的很香。我本人并沒(méi)有任何桌面開(kāi)發(fā)的經(jīng)驗(yàn)，但仍然使用Flutter開(kāi)發(fā)出了一個(gè)桌面版小程序，功能很簡(jiǎn)單，就是對(duì)輸入的json做格式化處理和轉(zhuǎn)模型。
話不多說(shuō)，先來(lái)看看實(shí)際效果。 項(xiàng)目源碼地址
開(kāi)發(fā)環(huán)境如下：
Flutter : 2.8.1
Dart : 2.15.1
IDE : VSCode
JSON作為我們?nèi)粘ｉ_(kāi)發(fā)工作中經(jīng)常要打交道的一種數(shù)據(jù)格式，它共有6種數(shù)據(jù)類型： null , num , string , object , array , bool 。我們勢(shì)必對(duì)它又愛(ài)又恨。愛(ài)他因?yàn)樗鳛閿?shù)據(jù)處理的一種格式確實(shí)非常方便簡(jiǎn)潔。但是在我們做Flutter開(kāi)發(fā)中，又需要接觸到j(luò)son解析時(shí)，就會(huì)感覺(jué)非常棘手，因?yàn)閒lutter沒(méi)有反射，導(dǎo)致json轉(zhuǎn)模型這塊需要手寫那繁雜的映射關(guān)系。就像下面這樣子。
數(shù)據(jù)量少還能接受，一旦量大，那么光手寫這個(gè)解析方法都能讓你懷疑人生。更何況手寫還有出錯(cuò)的可能。好在官方有個(gè)工具**json_serializable**可以自動(dòng)生成這塊轉(zhuǎn)換代碼，也解決了flutter界json轉(zhuǎn)模型的空缺。當(dāng)然，業(yè)界也有專門解析json的網(wǎng)站，可以自動(dòng)生成dart代碼，使用者在生成后復(fù)制進(jìn)項(xiàng)目中即可，也是非常方便的。
本項(xiàng)目以json解析為切入點(diǎn)，和大家一起來(lái)看下flutter是如何開(kāi)發(fā)桌面應(yīng)用的。
要讓我們的flutter項(xiàng)目支持桌面設(shè)備。我們首先需要修改下flutter的設(shè)置。如下，讓我們的項(xiàng)目支持 windows 和 macos 系統(tǒng)。
接下來(lái)使用 flutter create 命令創(chuàng)建我們的模版工程。
創(chuàng)建完項(xiàng)目后，我們就可以 run 起來(lái)了。
先來(lái)看下整體界面，界面四塊，分別為功能模塊、文件選擇模塊、輸入模塊、輸出模塊。
我們?cè)谛陆ㄒ粋€(gè)桌面應(yīng)用時(shí)，默認(rèn)的模版又一個(gè)Appbar，此時(shí)應(yīng)用可以用鼠標(biāo)拖拽移動(dòng)，放大縮小，還可以縮到很小。但是，我們一旦去掉這個(gè)導(dǎo)航欄，那么窗口就不能用鼠標(biāo)拖動(dòng)了，并且我們往往不希望用戶將我們的窗口縮放的很小，這會(huì)導(dǎo)致頁(yè)面異常，一些重要信息都展示不全。因此這里需要借助第三方組件 bitsdojo_window 。通過(guò) bitsdojo_window ，我們可以實(shí)現(xiàn)窗口的定制化，拖動(dòng)，最小尺寸，最大尺寸，窗口邊框，窗口頂部放大、縮小、關(guān)閉的按鈕等。
通過(guò) InkWell 組件，可以捕捉到手勢(shì)、鼠標(biāo)、觸控筆的移動(dòng)和停留位置
這個(gè)功能是鼠標(biāo)移動(dòng)后的UI交互界面。要在窗口上顯示一個(gè)提示框，可以使用 Overlay 。需要注意的是，由于在 Overlay 上的 text 的根結(jié)點(diǎn)不是 Material 風(fēng)格的組件，因此會(huì)出現(xiàn)黃色的下劃線。因此一定要用 Material 包一下 text 。并且你必須給創(chuàng)建的 OverlayEntry 一個(gè)位置，否則它將全屏顯示。
讀取說(shuō)表拖拽的文件一開(kāi)始想嘗試使用 InkWell 組件，但是這個(gè)組件無(wú)法識(shí)別拖拽中的鼠標(biāo)，并且也無(wú)法從中拿到文件信息。因此放棄。后來(lái)從文章《Flutter-2天寫個(gè)桌面端APP》中發(fā)現(xiàn)一個(gè)可讀取拖拽文件的組件 desktop_drop ，能滿足要求。
使用開(kāi)源組件 file_picker ，選完圖片后的操作和拖拽選擇圖片后的操作一致。
Textfield 如果要顯示富文本，那么需要自定義 TextEditingController 。并重寫 buildTextSpan 方法。
在做導(dǎo)出功能時(shí)遇到下列報(bào)錯(cuò)，保存提示為沒(méi)有權(quán)限訪問(wèn)對(duì)應(yīng)目錄下的文件。
通過(guò)Apple的開(kāi)發(fā)文檔找到有關(guān)權(quán)限問(wèn)題的說(shuō)明。其中有個(gè)授權(quán)私鑰的key為 com.apple.security.files.downloads.read-write ，表示 對(duì)用戶的下載文件夾的讀/寫訪問(wèn)權(quán)限 。那么，使用Xcode打開(kāi)Flutter項(xiàng)目中的mac應(yīng)用，修改工程目錄下的 DebugProfile.entitlements 文件，向 entitlements 文件中添加 com.apple.security.files.downloads.read-write ，并將值設(shè)置為YES，保存后重啟Flutter項(xiàng)目。發(fā)現(xiàn)已經(jīng)可以向下載目錄中讀寫文件了。
當(dāng)然，這是正常操作。還有個(gè)騷操作就是關(guān)閉系統(tǒng)的沙盒機(jī)制。將 entitlements 文件的 App Sandbox 設(shè)置為NO。這樣我們就可以訪問(wèn)任意路徑了。當(dāng)然關(guān)閉應(yīng)用的沙盒也就相當(dāng)于關(guān)閉了應(yīng)用的防護(hù)機(jī)制，因此這個(gè)選項(xiàng)慎用。
原文地址：
對(duì)于一些復(fù)雜或不規(guī)則的UI，我們可能無(wú)法使用現(xiàn)有的 Widget 組合去實(shí)現(xiàn)，比如需要一個(gè)帶動(dòng)畫的進(jìn)度條，
又或者是一個(gè)特殊形狀的多邊形等等，當(dāng)然有時(shí)候我們可以直接用圖片去實(shí)現(xiàn)，但是并沒(méi)有達(dá)到我們想要
的效果，反而會(huì)讓我們產(chǎn)生不良的體驗(yàn)。
幾乎所有的UI系統(tǒng)都會(huì)提供一個(gè)自繪UI的接口，這個(gè)接口通常會(huì)提供一塊2D畫布Canvas，Canvas內(nèi)部封裝了
一些基本繪制的API，開(kāi)發(fā)者可以通過(guò)Canvas繪制各種自定義圖形。在Flutter中，提供了一個(gè)CustomPaint Widget，
它可以結(jié)合一個(gè)畫筆CustomPainter來(lái)實(shí)現(xiàn)繪制自定義圖形。
我們看看 CustomPaint 構(gòu)造函數(shù)：
1.painter: 背景畫筆，會(huì)顯示在子節(jié)點(diǎn)后面;
2.foregroundPainter: 前景畫筆，會(huì)顯示在子節(jié)點(diǎn)前面
3.size：當(dāng)child為null時(shí)，代表默認(rèn)繪制區(qū)域大小，如果有child則忽略此參數(shù)，畫布尺寸則為child尺寸。如果有child但是想指定畫布為特定大小，可以使用SizeBox包裹CustomPaint實(shí)現(xiàn)。
4.isComplex：是否復(fù)雜的繪制，如果是，F(xiàn)lutter會(huì)應(yīng)用一些緩存策略來(lái)減少重復(fù)渲染的開(kāi)銷。
5.willChange：和isComplex配合使用，當(dāng)啟用緩存時(shí)，該屬性代表在下一幀中繪制是否會(huì)改變。
可以看到，繪制時(shí)我們需要提供前景或者背景畫筆，兩者也可以同時(shí)提供，
我們的畫筆需要繼承 CustomPainter 類，我們?cè)诋嫻P類中實(shí)現(xiàn)真正的繪制邏輯。
顧名思義畫布的意思，我們繪制布局當(dāng)然是在一張畫布上進(jìn)行繪制，畫布為我們繪制圖形提供了很多方法。（熟悉畫布的就無(wú)需再看了）
在繪制之前我們需要準(zhǔn)備畫筆 Paint，就如畫畫一樣，你用什么筆就能畫什么樣的畫，在Paint中，
我們可以配置畫筆的各種屬性如粗細(xì)、顏色、樣式等。如：
好了，繼承CustomPainter類，然后準(zhǔn)備好畫筆，就可以在畫布上盡情的揮灑了！
寫的挺簡(jiǎn)單的，就是介紹了一下自定義view的準(zhǔn)備工作以及畫布畫筆的功能，具體實(shí)戰(zhàn)請(qǐng)看下一篇博客。
CustomPaint class提供了讓用戶自定義widget的能力，它暴露了一個(gè)canvas，可以通過(guò)這個(gè)canvas來(lái)繪制widget，CustomPaint會(huì)先調(diào)用painter繪制背景，然后再繪制child，最后調(diào)用foregroundPainter來(lái)繪制前景，CustomPaint的定義如下
CustomPaint的繪制過(guò)程都將會(huì)交給CustomPainter來(lái)完成，CustomPainter是個(gè)抽象接口，在子類化CustomPainter的時(shí)候必須要重寫它的 paint 跟 shouldRepaint 接口，可以根據(jù)自己的場(chǎng)景來(lái)選擇性的重寫 hitTest 跟 shouldRebuildSemantics 方法。
canvas--畫布，真正的繪制是由canvas跟paint來(lái)完成的，畫布提供了各種繪制的接口來(lái)繪制圖形，除此以外畫布還提供了平移、縮放、旋轉(zhuǎn)等矩陣變換接口，畫布都有固定大小跟形狀，還可以使用畫布提供的裁剪接口來(lái)裁剪畫布的大小形狀等等。
常用的繪制接口有 更多請(qǐng)查看官方文檔
Paint---筆畫，是用來(lái)設(shè)置在畫布上面繪制圖形時(shí)的一些筆畫屬性，如：顏色、線寬、繪制模式、抗鋸齒等等。常用屬性有 更多請(qǐng)查看官方文檔
color ： 設(shè)置畫筆顏色
isAntiAlias ： 設(shè)置畫筆是否扛鋸齒
shader : 著色器，填充形狀或者畫線時(shí)用到，如果沒(méi)設(shè)置將會(huì)使用color
strokeWidth ： 設(shè)置畫筆畫線寬度
style ：繪制模式，畫線或充滿
下面這個(gè)例子來(lái)自于官方，通過(guò) CustomPaint 畫出了一個(gè)藍(lán)天跟太陽(yáng)出來(lái)
效果如下：
Flutter中自定義組件一般有兩種方式：
CustomPaint繼承自SingleChildRenderObjectWidget，即它可以在通過(guò)嵌套引入到widget樹(shù)中，并且可以有一個(gè)child子widget。它的構(gòu)造方法如下：
painter和foregroundPainter需要接收CustomPainter對(duì)象，是CustomPaint核心。CustomPainter是進(jìn)行UI繪制的核心類，繪制時(shí), CustomPaint 首先在畫布上調(diào)用 painter繪制 , 然后再繪制它的 child Widget, child 繪制完成后再調(diào)用 foregroundPainter 進(jìn)行繪制。
size屬性標(biāo)識(shí)繪制區(qū)域大小，但當(dāng)CustomPaint有child，該屬性將會(huì)忽略，而使用child的大小為繪制區(qū)域大小。
isComplex和willChange用于控制繪制層緩存處理的，這里暫不討論。
可實(shí)現(xiàn)CustomPainter子類進(jìn)行UI繪制
實(shí)現(xiàn)paint方法進(jìn)行真正的繪制，canvas是畫布對(duì)象，size是繪制區(qū)域，是從CustomPaint中size屬性傳遞得到的。繪制過(guò)程與Android原生開(kāi)發(fā)十分類似，連API都十分相像，這點(diǎn)對(duì)熟悉Android原生開(kāi)發(fā)者真是太友好了。
Paint對(duì)象是畫筆對(duì)象，就是繪圖工具，我們可以設(shè)置畫筆的顏色、粗細(xì)、是否抗鋸齒、筆觸形狀以及作畫風(fēng)格等，通過(guò)這些屬性我們可以很方便的來(lái)定制自己的UI效果，在繪制的過(guò)程中可以定義多個(gè)畫筆，以便實(shí)現(xiàn)多種風(fēng)格圖形的集合。
根據(jù)需求選擇合適的畫筆屬性，完成你的繪制。
Canvas是繪制的畫布，它包含了很多繪制方法，可以繪制出各種形狀的圖形。需要注意的是，畫布是應(yīng)用所有控件都在使用的, 所以通過(guò)這個(gè)畫布其實(shí)是可以繪制充滿屏幕的內(nèi)容的，每次繪制都應(yīng)該限制在本控件的區(qū)域(Size)內(nèi), 以免繪制覆蓋到其他組件。
下面介紹下Canvas的繪制方法：
PointMode是個(gè)枚舉
p1、p2為線段兩個(gè)端點(diǎn)
Rect定義矩形的大小位置，有多種構(gòu)造方式:
RRect描述圓角矩形，他通過(guò)Rect和Radius來(lái)構(gòu)造
畫圓比較簡(jiǎn)單，c表示圓心位置，radius是半徑。
橢圓使用外接矩形確定大小位置，rect就是外接矩形。
繪制弧形，先確定弧形對(duì)應(yīng)的橢圓，同樣地用外接矩形rect確定橢圓，然后根據(jù)起始點(diǎn)和結(jié)束點(diǎn)角度來(lái)確定那一段弧度，startAngle，sweepAngle分別代表起始和結(jié)束點(diǎn)角度，角度用弧度表示法。
useCenter表示是否連接閉合形狀，userCenter = false表示不閉合，即畫一段弧線，userCenter = true表示閉合，即繪制一個(gè)扇形。
繪制路徑，關(guān)鍵在于構(gòu)建路徑Path，可以直接new Path對(duì)象，然后通過(guò)path方法可以連接出圖形，path關(guān)鍵方法如下：
還有其他方法，有興趣可以查看API。
講道理我起的好長(zhǎng)的名字啊，不過(guò)文如上題，搜索到這里的兄弟應(yīng)該都知道我說(shuō)的是啥情況，正好
～～
我這個(gè)方案可能有點(diǎn)笨拙TT，不過(guò)自測(cè)有效，有其它想法的老哥希望可以幫忙指點(diǎn)一下～
下面進(jìn)入正題
點(diǎn)進(jìn)源碼里面看，可以發(fā)現(xiàn)他直接繼承了StatelessWidget，那我們就直接看看build方法
可以看到，這里直接返回一個(gè)scrollable或者一個(gè)子節(jié)點(diǎn)是scrollable的InheritedWidget
scrollable是一個(gè)StatefulWidget，那我們就看看它的state
首先scrollable持有一個(gè)scrollposition對(duì)象，是通過(guò)其scrollcontroller構(gòu)建的
在其state的setCanDrag方法中，對(duì)其拖動(dòng)設(shè)置了一系列的監(jiān)聽(tīng)
這里就可以看出來(lái)，當(dāng)拖動(dòng)觸發(fā)時(shí)，就會(huì)通過(guò)當(dāng)前scrollable的position生成一個(gè)Drag/Hold對(duì)象，并調(diào)用相應(yīng)的方法 這個(gè)position有幾個(gè)子類，我們先隨便看一個(gè)實(shí)現(xiàn)
可以看到生成了一個(gè)ScrollDragController對(duì)象，當(dāng)手勢(shì)拖動(dòng)而調(diào)用這個(gè)對(duì)象的update方法時(shí)
可以看到直接調(diào)用其委托對(duì)象的applyUserOffset方法進(jìn)行偏移，而這個(gè)委托對(duì)象根據(jù)剛才的drag方法可以得知正是我們scrollable中的position
最后，由position通知其scrollcontext，也就是之前的scrollable進(jìn)行滑動(dòng)
具體的滑動(dòng)流程這里就不細(xì)說(shuō)了，我們只是要知道這個(gè)事件是怎么傳遞的就好了，有興趣的老哥可以自行分析
NestedScrollView是一個(gè)statefulwidget，那我們就先看看它的build方法
先忽略其他奇奇怪怪的方法，我們發(fā)現(xiàn)在我們body的外面，包裹了一層PrimaryScrollController，同時(shí)它還持有innerController，這個(gè)innerController暫時(shí)先不管它是啥
還記不記得在最開(kāi)始ScrollView的build方法中，生成Scrollable的時(shí)候，我們已經(jīng)見(jiàn)過(guò)這個(gè)PrimaryScrollController了，再回顧一下
再看看PrimaryScrollController.of(context)
可以看到，在生成scrollable的時(shí)候，在primary = true的情況下是會(huì)向上查找的，看看有沒(méi)有PrimaryScrollController，如果有的話，scrollable使用的controller實(shí)際就是nestedscrollview中的innerController了
而之前看過(guò)了，scrollable中的position就是scrollcontroller來(lái)生成的，那么在這種情況下：
實(shí)際上是生成了_NestedScrollPosition并返回給了body中的scrollable
構(gòu)造方法中有一個(gè)參數(shù)coordinator 暫時(shí)先不管
好了，下面我們?cè)诨仡^看剛才NestedScrollView的build方法，實(shí)際上是生成了一個(gè)_NestedScrollViewCustomScrollView，繼承自大名鼎鼎的CustomScrollView，它當(dāng)然也是scrollview啦，而我們傳給它的controller也是一個(gè)_NestedScrollController，不過(guò)叫做_outerController，和body中的不是同一個(gè)罷了，那么自然這個(gè)父scrollview的position也是_NestedScrollPosition。
下面我們按照之前的邏輯，當(dāng)拖動(dòng)開(kāi)始時(shí)，就會(huì)調(diào)用position.drag方法
可以看到，實(shí)際上吧方法交給了我們之前多次見(jiàn)到的coordinator來(lái)完成，那我們就簡(jiǎn)單看一下吧
這里可以看到，他把返回的ScrollDragController的委托者設(shè)成了自己
那么自然在拖動(dòng)的時(shí)候，調(diào)用的就是coordinator的applyUseroffset方法了 我們分析一下
可以看到，在需要子列表滾動(dòng)時(shí)，是對(duì)innerPositions中的所有position調(diào)用滑動(dòng)方法的
而這innerPositions中的position是怎么來(lái)的呢？跟蹤一下可以發(fā)現(xiàn)是在調(diào)用NestedScrollController的attach時(shí)添加進(jìn)來(lái)的，如下
因?yàn)橹拔覀兛吹竭^(guò)，子scrollable中的controller就是這個(gè)NestedScrollController，所以在updateopsition時(shí)會(huì)把舊的detach調(diào)，把新生成的position attach進(jìn)來(lái)
另外，在dispose中也會(huì)detach
由此我們就知道啦，因?yàn)殚_(kāi)啟了緩存后就不會(huì)調(diào)用劃出屏幕的頁(yè)面的dispose，自然所有子scrollable的position都存在nestedScrollController里面了，當(dāng)發(fā)生滑動(dòng)時(shí)，遍歷調(diào)用positions數(shù)組，就導(dǎo)致屏幕外的列表也跟著滑動(dòng)了～
既然開(kāi)啟了緩存，手動(dòng)dispose肯定是沒(méi)啥意義的，實(shí)際上我們只要在頁(yè)面切換過(guò)后把未顯示的position 給detach掉就好了。
然鵝，因?yàn)閒lutter不支持反射，子布局傳遞的position我們拿不到，nestedScrollController我們也不能直接拿到=。=
不過(guò)有一個(gè)對(duì)象我們之前見(jiàn)到過(guò)，scrollable就是通過(guò)他獲取controller的，而position則是傳給了獲取到的controller 就是PrimaryScrollController了，所以我打算在中間第三者插足，對(duì)傳遞Position的PrimaryScrollController進(jìn)行Hook
在使用的時(shí)候把子列表添加進(jìn)去，并設(shè)置對(duì)應(yīng)的GlobalKey。
然后監(jiān)聽(tīng)Tab切換
以上是我的方案，有問(wèn)題的話還希望老哥幫忙指正，也希望有其他思路的老哥指點(diǎn)一下～～
上一下Github項(xiàng)目地址 用Flutter寫的WanAndroid 其中用到了這個(gè)方案
= =
3
重慶分公司
重慶分公司
