這一周繼續(xù)聊跨平臺桌面開發(fā)這個事情。
“專業(yè)、務實、高效、創(chuàng)新、把客戶的事當成自己的事”是我們每一個人一直以來堅持追求的企業(yè)文化。 創(chuàng)新互聯(lián)是您可以信賴的網(wǎng)站建設服務商、專業(yè)的互聯(lián)網(wǎng)服務提供商! 專注于成都網(wǎng)站制作、成都網(wǎng)站建設、外貿(mào)營銷網(wǎng)站建設、軟件開發(fā)、設計服務業(yè)務。我們始終堅持以客戶需求為導向，結合用戶體驗與視覺傳達，提供有針對性的項目解決方案，提供專業(yè)性的建議，創(chuàng)新互聯(lián)建站將不斷地超越自我，追逐市場，引領市場！
在這篇文章中，我暫時會放下Electron與WebView2的一個對比，而聊一聊跨平臺這個對于程序員群體來說不陌生的詞。
一個趨勢是：跨平臺開發(fā)幾乎是在各個技術方向都會持續(xù)發(fā)展的
跨平臺這個詞，對于程序員來說，應該是不陌生的。因為這個概念不只在某一端存在，后端，前端，移動端，桌面端幾乎所有方向都對跨平臺有需求。
在后端，Java是跨平臺的，當你用Java來編寫后端服務時，并不需要考慮操作系統(tǒng)，因為它幾乎支持主流的操作系統(tǒng)?，F(xiàn)在，編寫一個后端服務，選用Java仍是主流。雖然可能它的跨平臺特性已經(jīng)不是程序員最在意的點了。
而在移動端，類似React Native，F(xiàn)lutter也是非常有名的跨平臺移動開發(fā)，它們與移動原生開發(fā)方式之間一直是競爭與共存。
而前端因為依托于瀏覽器，天然就是跨平臺的。事實上，很多應用或服務早期紛紛選擇從原生應用遷移至前端WEB方式的一個非常重要的原因就在于它是跨平臺的。
桌面操作系統(tǒng)很長一段時間一直是Windows一家獨大，所以桌面開發(fā)一直是Windows獨占，直至現(xiàn)在為止，很多專業(yè)級的軟件仍然是Windows獨占的。
而Linux桌面操作系統(tǒng)與MacOS桌面操作系統(tǒng)，早些年幾乎可以忽略不計，壓根不需要考慮這兩種系統(tǒng)。但隨著近些年它們的慢慢流行，特別是蘋果的MacOS的以其杰出的工藝，流暢的體驗，疊加蘋果手機的流行，其市場份額增長非常之快，在特定的諸如編程，設計等行業(yè)人群中使用范圍較廣，這使得開發(fā)支持MacOS系統(tǒng)這個點變得越來越重要。
所以，在桌面開發(fā)領域，跨平臺的需求也越來越高。
這也是Electron及早期的NW.js能迅速發(fā)展起來并得到非常廣應用的原因所在。
無論是哪一端，跨平臺技術之所以頻繁出現(xiàn)與不斷發(fā)展，其根本原因就在于編程的一個重要痛點在于：
為了讓同一個服務能在所有設備上運行，程序員不得不編寫與維護非常多不同版本的程序
每一個程序或軟件后面的服務，都有一個非常迫切的需求，就是期望它的用戶無論何時，無論何地，無論使用任何設備，都能方便友好的使用這個服務。
也是因為這個原因，Web發(fā)展起來了，因為Web的優(yōu)勢就在這，只要你的設備上有瀏覽器，就能訪問。
但Web畢竟性能有限，且瀏覽器這種形式并不利于用戶忠誠度的培養(yǎng)，它存在天然的弱點。一些簡單的操作服務使用Web并無問題，但稍微有點要求的，Web可能就并不是非常適合。
所以，一種趨勢不可避免地流行起來：
對不同設備或系統(tǒng)進行抽象，基于某一種特定的編程語言，編寫出能與原生程序相媲美的，又能跨平臺的技術便層出不窮了
對吧，Java是使用JVM來抽象不同的操作系統(tǒng)，React Native則是使用虛擬DOM以及轉換成原生控件的方式來實現(xiàn)跨平臺，而Electron則是通過性能較好的Chrome內(nèi)核+NodeJS原生調用能力的搭配來實現(xiàn)跨平臺桌面開發(fā)。
總而言之，這種跨平臺的技術不會消亡，只會有新的技術層出不窮，而它們與原生開發(fā)一定是相互競爭，配合與共存的。相互之間無法取代。
那再回到跨平臺技術上來說，一個良好的跨平臺開發(fā)的技術或框架，重點是什么。
或者換種方式說，哪些特性使得它更易于流行起來？
我個人認為有以下的幾個點：
跨平臺開發(fā)技術能不能流行起來的一個非常重要的點就在于，使用了什么樣的編程語言。
以移動端跨平臺開發(fā)技術來說明，一個React Native，一個Flutter，這兩個是比較知名主流的跨平臺移動開發(fā)技術。React Native使用的是前端React技術，而Flutter則是Google的D語言。
顯而易見的是，雖然Flutter是使用skia引擎在底層重繪一套UI，其性能相比React Native這種模式更佳，但React Native更易于被接受。
在流行度上，React Native始終比Flutter更流行，一個最重要的原因也在于：
使用已熟知的前端編程語言，比起重新學習一個D語言更易于被接受，維護成本更可控。
這個問題在跨平臺桌面開發(fā)中也是類似，跨平臺桌面開發(fā)技術也不是Electron最開始出現(xiàn)，比如著名的QT很早就有了，但比起Electron這種使用前端編程技術來說，顯然在編程語言的門檻上和程序員群體上都存在困難，這也是Electron能后來居上的原因所在。
因為，大多數(shù)程序員群體，相比較另外學習一門什么語言去做什么，使用自己熟悉的語言來做什么是更容易，意愿也更高。
而從公司或團隊的考量上看，選擇偏門的小眾語言存在成本上的顧慮，比如人員招聘是否容易？
跨平臺技術在嘗試解決不同平臺不一致，它或多或少會損耗性能。這也決定了幾乎沒有任何一個跨平臺技術能取代原生開發(fā)。
這是一個取舍的問題，對于一個程序來說，究竟性能有多重要。對于比較看重性能的程序來說，原生開發(fā)可能是最優(yōu)選擇。
但跨平臺的性能損耗也有高低之分，并不在同一水平線上。
其實，無論是Electron，或是WebView2，都是基于瀏覽器內(nèi)核+前端技術的跨平臺桌面解決方案，這也是為什么要把它們放在一起聊的原因。
Electron是先行者（當然，嚴格說來，NW.js出現(xiàn)的更早，但今天它的流行度已遠遠落后于Electron了），而WebView2則是后來者。
那做為后來者的WebView2究竟做了哪些改進？它又有多大的能力來挑戰(zhàn)Electron呢？
下一篇，繼續(xù)聊。
Uniapp目前比較成熟，而且用的是Vue語法，學習成本比較低，而且行業(yè)里面用的也比較廣泛，而Flutter的話，學習成本略高，因為要學習新的語言，還有就是目前生態(tài)不是特別完備，等他再發(fā)展發(fā)展吧。黑馬程序員官網(wǎng)有成套免費視頻哦，有什么不懂的可以直接過去學習。您的采納是對我成長的鞭策
描述了屏幕上指針（觸摸、鼠標、觸控筆）的位置和移動。
Flutter中可以使用Listener(功能性組件)來監(jiān)聽原始觸摸事件
例1
例2
例3
忽略PointerEvent
手勢: 描述由一個或多個指針移動組成的語義動作，如拖動、縮放、雙擊等。
Material大多數(shù)widget已經(jīng)對tap或手勢做出了響應。 例如 IconButton和 FlatButton 響應單擊，ListView響應滑動事件觸發(fā)滾動。
用于手勢識別的功能性組件，通過它可以來識別各種手勢。
例（單擊）
例（添加Material觸摸水波效果 InkWell組件）
例（滑動關閉 Dismissable組件）
例（單擊、雙擊、長按）
例（滑動）
例（掃動---單一方向）
例（縮放）
GestureRecognizer是一個抽象類。
一種手勢的識別器對應一個GestureRecognizer的子類。
例
由于手勢競爭最終只有一個勝出者，所以，當有多個手勢識別器時，可能會產(chǎn)生沖突。
例
例
在APP中經(jīng)常會需要一個廣播機制，用以跨頁面通知。比如一個需要登錄的APP中，頁面會關注用戶登錄或注銷事件，來進行一些狀態(tài)更新。
這時候，一個事件總線便會非常有用，事件總線通常實現(xiàn)了訂閱者模式，訂閱者模式包含發(fā)布者和訂閱者兩種角色，可以通過事件總線來觸發(fā)事件和監(jiān)聽事件。
對于一些簡單的應用，事件總線是足以滿足業(yè)務需求的，如果決定使用狀態(tài)管理包的話，一定要想清楚APP是否真的有必要使用它，防止“化簡為繁”、過度設計。
例
在widget樹中，每一個節(jié)點都可以分發(fā)通知，通知會沿著當前節(jié)點向上傳遞，所有父節(jié)點都可以通過NotificationListener來監(jiān)聽通知。
Flutter中將這種由子向父的傳遞通知的機制稱為通知冒泡（Notification Bubbling）。
通知冒泡和用戶觸摸事件冒泡是相似的，但有一點不同：通知冒泡可以中止，但用戶觸摸事件不行。
通知冒泡和Web開發(fā)中瀏覽器事件冒泡原理是相似的，都是事件從出發(fā)源逐層向上傳遞，可以在上層節(jié)點任意位置來監(jiān)聽通知/事件，也可以終止冒泡過程，終止冒泡后，通知將不會再向上傳遞。
Flutter的UI框架實現(xiàn)中，除了在可滾動組件在滾動過程中會發(fā)出ScrollNotification之外，還有一些其它的通知，如SizeChangedLayoutNotification、KeepAliveNotification 、LayoutChangedNotification等，F(xiàn)lutter正是通過這種通知機制來使父元素可以在一些特定時機來做一些事情。
例
例
例
阻止冒泡
通知冒泡原理
既然有了 Metal 我們是否還有學習 OpenGL ES 的必要呢.我個人認為暫時還是有必要的.OpenGL /OpenGL ES/ Metal 在任何項目中解決問題的本質就是利用GPU芯片來?效渲染圖形圖像.所以它們底層的原理相近,首先了解OpenGL之后再去了解Metal會更加容易, 其二OpenGL是跨平臺的框架.保不齊以后會在其他的地方用到,所謂技多不壓身.畢竟不可能保證一直都做蘋果開發(fā)吧.
理論枯燥且乏味, 但是我們聯(lián)想一下flutter開發(fā)中用到的context, iOS開發(fā)中CoreGraphics里也有用到context. 是不是此時心中就有了一定的答案.我個人理解其設計模式大同小異. 顧名思義我們能夠通過context拿到很多必要的狀態(tài)和數(shù)據(jù).
比如需要顯示一個正方形, 則需要兩個正等邊三角形圖元來完成
為了讀取效率起見, 提前分配一塊顯存, 將頂點數(shù)組存放在顯存中. 這部分顯存就叫做 頂點緩沖區(qū)
OpenGL渲染的過程中會經(jīng)歷很多節(jié)點. 這些節(jié)點串起來就是管線.
常見的著?器主要有: 頂點著?器(VertexShader) , ?段著?器(FragmentShader) , 幾何著?(GeometryShader) , 曲?細分著?器(TessellationShader)
OpenGL ES 中只?持 頂點著?器 和 片段著?器 .
光柵化就是把頂點數(shù)據(jù)轉換為片元的過程。片元中的每一個元素對應于幀緩沖區(qū)中的一個像素。
如果把渲染比作是畫畫, 那么頂點著色器操作相當與確定畫的內(nèi)容的框架. 而之后往框架里填充內(nèi)容的過程就是光柵化.
填充好內(nèi)容之后就是片元著色器操作像素點填充顏色等操作
這里附上一張流程圖:
紋理可以理解為圖?。 在渲染圖形時需要在頂點圍成的區(qū)域中填充圖?，使得場景更加逼真。?這?使?的圖?，就是常說的紋理。只是在OpenGL，我們更加習慣叫紋理，?不是圖?。
最近在做的一個項目，項目的前期采用Weex開發(fā)。但是隨著交互復雜度的增加，Weex一處開發(fā)多處多處運行的特征并沒有很好的體現(xiàn)，相反很多時候我們還是需要做IOS和Android的適配。如今火熱的Flutter相比Weex和Rn來說，給出了更好的跨平臺解決方案。所以我們設計了一套基于Weex實現(xiàn)，底層跑在Flutter Engine上的框架。
底層的Runtime采用isolate engine,框架業(yè)務邏輯，Dom的解析邏輯和Render邏輯都跑在這里。
渲染引擎采用Flutter的Skia，徹底剝離了Android和IOS的差異性.
將Weex VirsualDom的解析都替換成Flutter Widget.
設計基于Weex2Dart的Brider,使JS和Dart可以相互調用
weex-demo的性能展示
release環(huán)境下采用AOT模式，性能會有質的飛躍。
Android-Release版本只有10m大小
相比Weex和Rn具有更好的性能，同時具有更好的跨平臺性
相比Flutter，具有動態(tài)部署的能力（Flutter Release采用AoT模式并沒有動態(tài)部署的能力，即使Debug版本也只是開發(fā)環(huán)境下才有動態(tài)化能力并沒有可以實施項目的能力）
只需要會Weex開發(fā)或則Rn開發(fā)就可以，不需要額外學習Dart，已有的Weex項目可以無縫切換。
重慶分公司
重慶分公司
