【轉】客戶端軟件GUI開發技術漫談:原生與跨平臺解決方案分析

原生開發應用開發

Microsoft陣營的

Winform

WinForm是·Net開發平臺中對Windows Form的一種稱謂。javascript

若是你想深刻的美化UI,須要耗費很大的力氣,對於目前主流的CSS樣式表來說,美化Winform的界面以及自定義控件是須要耗費更多的時間的。html

WPF

基於XML+C#+CSS的呈現方式讓它在UI上有了更加靈活的設計寬度。具體看官方:https://github.com/dotnet/wpf前端

WPF技術架構

WPF和WinForms是兩種徹底不同的UI技術,WPF也並不能徹底取代WinForms。java

WPF不能運行在其餘操做系統,而且在XAML中編寫樣式表,通用性仍是不如HTML強,從學習應用的範圍來說,仍是HTML更好一些。node

UWP

微軟爲了針對移動端市場開放的開發框架,若是你的APP只須要運行在Windows下,我認爲WPF或者UWP是最好的選擇,畢竟在調用系統原生API上微軟的親兒子們有着巨大的優點。react

 

windows上各類各樣的技術開發的IDE和其餘程序android

  • 性能上:Java最差 -> Electron -> WindowsForms -> 原生 -> WPFgit

  • 佔內存:Java最多 -> Electron -> WPF -> WindowsForms -> 原生程序員

 

Java陣營

Swing

零幾年學Java的老頭子們幾乎都是從Swing開始學起的,Swing謎通常的默認UI審美觀讓我直接放棄了繼續學習下去的動力。github

JavaFx

優勢在於能夠跨平臺,缺點在於整個生態環境很是很差,與Winforms同樣,自定義一些控件相對比較困難。

Adobe陣營

Air

Flex程序,它的優勢在於能夠跨平臺,能夠基於Flash作出不少超級炫酷的動畫特效,可是缺點主要就是效率實在是過低下了,而且在調用操做系統原生API的時候也很是不方便。隨着Flash在瀏覽器上的節節敗退,Air也悄無聲息的消失在了大衆的視野當中。

Apple

Objective-C(或如今的Swift),跟Winforms同樣,能夠很是方便的調用操做系統底層API,劣勢也同樣,不跨平臺、自定義控件比較複雜,可用資源太少。如今大多數程序員都是基於C#、Java進行開發,若是不是Apple死忠,根部不會花大力氣研究

跨平臺軟件應用開發

直接元素開發確定是最好的——這樣的性能確定最有保證,可是跨平臺的主要優點在於代碼邏輯的複用,減小各平臺同一邏輯,因人而異的開發成本。對於企業而言,一套業務邏輯能夠在多處使用是最理想也是最保險的。

Electron

Electron是由Github開發,用HTML,CSS和JavaScript來構建跨平臺桌面應用程序的一個開源庫。 Electron經過將Chromium和Node.js合併到同一個運行時環境中,並將其打包爲Mac,Windows和Linux系統下的應用來實現這一目的。經過Node它提供了一般瀏覽器所不能提供的能力。 

electron的特色就是能夠複用前端的各類輪子。因此它開發快,招人方便。還有.net :https://github.com/ElectronNET/Electron.NET

能夠方便的經過Node.JS調用系統API、可使用SQLite作本地字典項的緩存處理,能夠將複雜的計算邏輯放在客戶端進行,從而減輕服務器端的壓力等等。

electron都成千上萬個成熟項目在桌面裏用了,什麼flutter,javafx,swiftui,目前仍是沒法比

electron和node-webkit(如今叫nw.js)的區別:

。從概念上,Electron與nw.js很類似,可是他們有很重要的區別:一個主要的不一樣點是Electron 經過 Googles Chromium Content Module 來使用 Chromium 的功能,nw.js 則直接使用了 Chromium自己。

electron創建在 Chromium 和 NodeJS 之上的,一個負責界面,一個負責背後的邏輯

Electron的運行原理

 

Cordova,PhoneGap

Cordova[ˈkɔːdəbə]是 hybride 類框架,基於HTML,CSS和JavaScript的,建立移動跨平臺移動應用程序的快速開發平臺

2011年10月4日Adobe公司收購了PhoneGap和PhoneGap Build的新創公司Nitobi Software,隨後將Phonegap的核心代碼剝離並捐給了Apache公司,並更名爲了Cordova。

核心的東西就是H5與Native的交互原理、Bridge、定義的解析規則(Engine)

 Cordova架構設計

 

Cordova Application是Cordova框架獨立於不一樣手機操做系統的一個封裝層。具體包括 

  • Web App層是開發人員編寫代碼的主要地方,應用程序以網頁的形式呈現,在一個index.html的本地頁面文件中引用所須要的各類Web資源,如CSS、JavaScript、圖像、影音文件等。應用程序的配置保存在config.xml文件中。

    對於使用cordova cli初始化的web app 在主目錄下會存在一個config.xml,其中包含了整個app的一些基本信息:好比appName、app入口文件、白名單、webview初始化的一些配置、plugin信息、圖標資源信息

  • WebView層用來呈現用戶界面,即web頁面的展示。例如,在Android平臺是經過WebView控件實現web頁面的呈現。

  • Plugins主要用於在JavaScript代碼中調用各平臺native的功能。Cordova項目已經包含一些核心的plugin,如電池、攝像頭、通信錄等。開發人員也能夠開發自定義的plugin,來實現所須要的功能。 

Mobile OS就是具體的手機操做系統層

Cordova預先幫咱們預先封裝了各類mobile os上最經常使用的本地api調用,而後以統一的JavaScript api形式提供給webapp開發者調用。

對於webapp的開發者來講,無需關注系統底層調用實現細節,也就實現了所謂的「跨平臺」。實際上,各平臺涉及到本地能力的調用,以插件形式被封裝了。(每一個插件的實現實際上仍是Native模式)。

JS和Native是如何實現互調的,這裏先研究安卓的

Cordova-Android是經過addJavascriptInterface(Android Webview的API)和JS Prompt這兩種方式來實現JS對於Native API的調用。

咱們先來看一個Cordova-Android框架中的一個關鍵類: CordovaActivity.java。

該類繼承了Android Activty類,其實是Cordova-Android的Launcher Activity,也就是啓動入口activity。

應用啓動後,核心幹了兩件事:讀取config.xml和loadUrl。這個loadUrl實際上就是加載webapp的啓動頁(默認是index.html)。

IOS具體參看《Cordova 工做原理(IOS篇)》,這裏關於原理這是簡介。

 

React-Native

 React-Native厲害在於它能打通JS和Native Code, 讓JS可以調用豐富的原生接口,充分發揮硬件的能力, 實現很是複雜的效果,同時能保證效率和跨平臺性。

在必定程度上,React Native和NodeJS有殊途同歸之妙。它們都是經過擴展JavaScript Engine, 使它具有強大的本地資源和原生接口調用能力,而後結合JavaScript豐富的庫和社區和及其穩定的跨平臺能力,把javascript的魔力在瀏覽器以外的地方充分發揮出來

React Native 架構

React Native 渲染 在 React 框架中,JSX 源碼經過 React 框架最終渲染到了瀏覽器的真實 DOM 中

React 能夠渲染到多平臺上

在 React Native 框架中,JSX 源碼經過 React Native 框架編譯後,經過對應平臺的 Bridge 實現了與原生框架的通訊。若是咱們在程序中調用了 React Native 提供的 API,那麼 React Native 框架就經過 Bridge 調用原生框架中的方法。 由於 React Native 的底層爲 React 框架,因此若是是 UI 層的變動,那麼就映射爲虛擬 DOM 後進行 diff 算法,diff 算法計算出變更後的 JSON 映射文件,最終由 Native 層將此 JSON 文件映射渲染到原生 App 的頁面元素上,最終實現了在項目中只須要控制 state 以及 props 的變動來引發 iOS 與 Android 平臺的 UI 變動。 編寫的 React Native代碼最終會打包生成一個 main.bundle.js 文件供 App 加載,此文件能夠在 App 設備本地,也能夠存放於服務器上供 App 下載更新

大多數組件都相似HTML,例如View組件跟div標籤就很相似,Text組件相似於p標籤。

React Native 框架構成A diagram showing React Native's Core Components are a subset of React Components that ship with React Native.

具體參看《ReactJS到React-Native 零碎筆記 》

Xamarin

Xamarin ['zæmərɪn]是一個開放源代碼平臺,用於經過 .NET 構建適用於 iOS、Android 和 Windows 的新式高性能應用程序。

Xamarin主要有這麼幾項技術,Xamarin.Android、Xamarin.iOS和Xamarin.Forms,此外還有Xamarin.UWP、Xamarin.Windows、Xamarin.WinPhone等。本質都是對原生API作了一層C#的封裝,所以在使用上與原生API會十分類似。這種封裝會結合一些C#的語法特性,讓開發者能夠享受C#的語法糖。Xamarin.iOS是直接編譯成ARM的二進制代碼,所以執行效率確定是很是高的。

Xamarin.Android被編譯成中間語言,Xamarin在APK安裝包中會包含一個mono(跨平臺的.NET運行環境),代碼是在mono運行時和安卓本地的運行時上完成工做的。

Mono [ˈmɒnəʊ] 虛擬機包含一個實時編譯引擎,該引擎可用於以下處理器:x86,SPARC,PowerPC,ARM,S390(32位模式和64位模式),x86-64,IA64 和64位模式的 SPARC。該虛擬機能夠將代碼實時編譯或者預先編譯到原生代碼。對於那些沒有列出來的系統,則使用的是代碼解釋器。

Xamarin 是一個抽象層,可管理共享代碼與基礎平臺代碼的通訊。 Xamarin 在提供便利(如內存分配和垃圾回收)的託管環境中運行。

Xamarin始創於2011年,旨在使移動開發變得難以置信地迅捷和簡單。

Xamarin 適用於具備如下目標的開發人員:

  • 跨平臺共享代碼、測試和業務邏輯。

  • 使用 Visual Studio 在 C# 中編寫跨平臺應用程序。

 Xamarin 容許在每一個平臺上建立本機 UI,並在 C# 中編寫跨平臺共享的業務邏輯。 在大多數狀況下,80% 的應用程序代碼可以使用 Xamarin 進行共享。

Xamarin最爲關鍵的技術Xamarin.Forms,把IOS、android、UWP等平臺的GUI進行了一統地抽象,開發者只須要寫一套代碼,編譯器會在編譯時將界面映射到原先控件上,從而得到原平生臺的外觀和性能。

Xamarin 體系結構示意圖

Xamarin 在 .NET 的基礎之上進行構建,它自動處理諸如內存分配、垃圾回收以及與基礎平臺的互操做性等任務。

Xamarin以前是收費的,並且聽說收費不菲,因此使用的人數比較少,在國內幾乎無人問津。後來Xamarin被微軟收購,現已免費開放,可是從白學.net開始,就對微軟的東西不感冒了。微軟的東西雖好,可是叫好不叫座。

Flutter

flutter 其實就是一套谷歌開源的跨平臺 UI 開發框架,支持 Android 和 iOS ,而且目前開始支持 Web 和 MacOS,將來還會繼續支持 Win和 Linux 平臺的一套 UI 框架。

Dart UI是一個 C++實現的 dart:ui庫的 Native Binding,而且 UI Lib也是 Dart GUI程序的應用主要入口。

Dart UI向上層提供了 window、text、canvas、geometry等通用的繪圖能力, Runtime在調用 Dart UI時,Dart UI根據傳遞的 main entrypoint 來執行而且向 window渲染圖像。

react-native 、weex 和 flutter 都只是 UI 框架,它解決的實際上是跨平臺上的 UI 實現,讓界面佈局或者實現的業務邏輯能夠在多端統一。可是它也僅僅只是 UI 框架,好比 react-native 自己就是依賴於原生控件,而 flutter 的 webview 、mapview 也都須要依賴原生開發來支撐。

Flutter的原理 Flutter是如何設計

Dart這門語言最初就是一幫Java程序員爲了方便寫UI搞出來的。若是大家團隊Java/Swift程序員比較多,那Flutter從上手方面來講更快。

爲何選擇Dart

  • Dart 的性能更好。Dart在 JIT模式下,速度與 JavaScript基本持平。可是 Dart支持 AOT,當以 AOT模式運行時,JavaScript便遠遠追不上了。

  • Native Binding。在 Android上,v8的 Native Binding能夠很好地實現,可是 iOS上的 JavaScriptCore不能夠,因此若是使用 JavaScript,Flutter 基礎框架的代碼模式就很難統一了。而 Dart的 Native Binding能夠很好地經過 Dart Lib實現。

  • Fuchsia [ˈfjuːʃə] OS內置的應用瀏覽器就是使用 Dart語言做爲 App的開發語言。並且實際上,Flutter是 Fuchisa OS的應用框架概念上的一個子集。

  • Dart是類型安全的語言,擁有完善的包管理和諸多特性。Google召集了如此多個編程語言界的設計專家開發出這樣一門語言,旨在取代 JavaScript,因此 Fuchsia OS內置了 Dart。Dart能夠做爲 embedded lib嵌入應用,而不用只能隨着系統升級才能得到更新,這也是優點之一。

Skia是什麼?

Skia是一個 2D的繪圖引擎庫,其前身是一個向量繪圖軟件,Chrome和 Android均採用 Skia做爲繪圖引擎。Skia提供了很是友好的 API,而且在圖形轉換、文字渲染、位圖渲染方面都提供了友好、高效的表現。Skia是跨平臺的,因此能夠被嵌入到 Flutter的 iOS SDK中,而不用去研究 iOS閉源的 Core Graphics / Core Animation。由於Android自帶了 Skia,因此 Flutter Android SDK要比 iOS SDK小不少。

QT C++

QT最大的優點就是跨平臺!高效率!可是與Objective-C同樣,CPP如同一座小山橫在了衆多server side程序員的面前,若是沒有CPP這道小山橫貫在前,我認爲QT是最好的Desktop Application特別是嵌入式終端的UI開發框架。

QT另外有一個優點在於,它在UI上彷佛要比以前幾位要方便一些,在它的QML中甚至能夠直接使用JavaScript(固然,Java也內置了JS引擎),同時QT中也包含了大量的標準CSS樣式表可使用

若是但願本身從事真正意義上的Desktop Application development,QT絕對值得你去學習。

QT有可視化編輯器,可是相比較而言,可能略強於NetBeans的Swing,可是跟VS比起來仍是差太遠了,不過大可能是實際開發都是基於代碼的

x-platform

這玩意,我的以爲沒有啥奔頭。

Avalonia

知乎有道友留言,提到Avalonia,我的以前確實沒有據說過。看官方資料:https://github.com/AvaloniaUI/Avalonia,Examples of UIs built with Avalonia,確實蠻漂亮的。

Avalonia是一個基於WPFXAML的跨平臺UI框架,並支持多種操做系統:Windows(.NETFramework,.NETCore),Linux(GTK),MacOS,Android和iOS。

不過我的對微軟的 .net 都是過敏狀態。2014 微軟向Open SDK 投懷送抱後,微軟向Java 環境貢獻愈來愈多。微軟如今愈來愈開放。

NET 5 是 .NET Core 的下一步。該項目旨在經過如下幾個關鍵方式改進 .NET:

  • 製造一個可在任何地方使用的 .NET 運行時和框架,並具備統一的運行時行爲和開發人員體驗。

  • 經過充分利用 .NET Core、.NET Framework、Xamarin 和 Mono 來擴展 .NET 的功能。

  • 從單個代碼庫構建該產品,開發人員( Microsoft 和社區)能夠一塊兒工做並一塊兒擴展,從而改進全部方案。

目前沒有選擇.net 技術棧的打算。過幾年拼不動了,在去學下.net,去個壓力小點的公司,或許是比送外賣好的結局把

 

參考文章:

快速瞭解Electron:新一代基於Web的跨平臺桌面技術 http://www.javashuo.com/article/p-xaxirlqi-my.html

Flutter原理簡解 https://zhuanlan.zhihu.com/p/36861174

https://zhuanlan.zhihu.com/p/65010663

 

原文:https://www.zhoulujun.cn/html/webfront/engineer/Architecture/8468.html

相關文章
相關標籤/搜索