別人說(shuō)前端的前景不好,后端的發(fā)展會(huì)好很多？

方向不同崗位對(duì)比自然也就不同，一千個(gè)人眼里有一千個(gè)哈姆雷特

網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、小程序制作、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了鎮(zhèn)原免費(fèi)建站歡迎大家使用！

關(guān)于Web前端開發(fā)，近幾年發(fā)生了諸多新聞，從React v16普及，到j(luò)Query被GitHub下掉完成階段性歷史使命，再到版本帝AngularJS發(fā)布v6和v7兩個(gè)版本讓人們更多地看到了PC端開發(fā)的走向。那么，2020年Web前端開發(fā)的趨勢(shì)如何？帶你詳細(xì)了解下。

一、端

Web前端開發(fā)的有一個(gè)方向就是端體系的打通發(fā)展。前端通俗一點(diǎn)理解可以視為是靠前一點(diǎn)的端。而端口的不統(tǒng)一或者說(shuō)不夠樹形多態(tài)是其麻煩之處。因此在打通場(chǎng)景上會(huì)遇到諸多的問題，于是端體系的打通與發(fā)展是一個(gè)很重要的道路。無(wú)論是從產(chǎn)品、業(yè)務(wù)還是技術(shù)角度來(lái)說(shuō)，都是一個(gè)具有挑戰(zhàn)意義的方向。

二、DevOps的成熟

DevOps是整個(gè)IT價(jià)值流中實(shí)施精益原則的結(jié)果。延續(xù)端的打通，Web前端將為為整個(gè) DevOps 步調(diào)提供服務(wù)。從評(píng)審=開發(fā)=CR=測(cè)試=灰度=回滾=發(fā)布=運(yùn)維+運(yùn)營(yíng)，單點(diǎn)發(fā)展演變?yōu)榫€性發(fā)展，形成一套完整的方案。

三、前端云化

GUI 的發(fā)展，最終是要發(fā)展成云端的形態(tài)，這將不僅是前端要的形態(tài)，也是服務(wù)端的一個(gè)形態(tài)。我們能體會(huì)到的貫穿 DevOps 流程的云態(tài)，這個(gè)只是一個(gè)方向，并不是所有都會(huì)去到這個(gè)方向。

四、可視化領(lǐng)域

隨著端+云化的狀態(tài)，可視化的領(lǐng)域?qū)⑦M(jìn)一步的發(fā)展，渲染等瓶頸會(huì)逐漸增高，以及加上 5G 的發(fā)展，必將在 DT 時(shí)代為前端帶來(lái)更多的可視化方向和領(lǐng)域。

五、Flutter

嚴(yán)格來(lái)講，F(xiàn)lutter并不是前端技術(shù)，而是“客戶端”技術(shù)。而目前Web前端的地位遠(yuǎn)遠(yuǎn)不如客戶端。對(duì)于大多數(shù)的公司來(lái)說(shuō)。移動(dòng)App所帶來(lái)的現(xiàn)金流，僅僅靠下載和推廣就可以養(yǎng)活一個(gè)灰色的產(chǎn)業(yè)鏈。而移動(dòng)Web的收益可能不值一提。那么前端與客戶端的合二為一的發(fā)展趨勢(shì)是否也將是一個(gè)重要的方向！

總之，Web前端開發(fā)的就業(yè)前景形勢(shì)一片大好，所以學(xué)起來(lái)也要趁早，現(xiàn)在很多專業(yè)培訓(xùn)學(xué)校都很不錯(cuò)，比如北大青鳥、南京中博軟件學(xué)院和課工場(chǎng)等等，你可以試聽課程綜合考慮。

為什么Flutter開發(fā)APP性能最接近原生，前端程序員請(qǐng)關(guān)注

Flutter是谷歌公司推出的跨終端的開發(fā)框架，支持Android、iOS和WEB終端。1.0版在2018年12月5日發(fā)布，目前的最新版本是1.5，它采用的開發(fā)語(yǔ)言是Dart，Dart也是谷歌開發(fā)的計(jì)算機(jī)編程語(yǔ)言，語(yǔ)法類似C，是編譯型語(yǔ)言：

hello world例子，打印字符串“Hello World!”：

1、沒有橋接層

React Native、Weex等技術(shù)都是跨終端的框架，然而性能跟原生App存在很大差距。這是由于它們的工作原理決定的：

React Native、Weex等技術(shù)多了一個(gè)橋接層，所以界面渲染會(huì)慢一些，由于UI渲染非常頻繁，想要不卡頓，基本上比較難，性能和用戶體驗(yàn)跟原生代碼有差距。而這恰恰是Flutter的優(yōu)勢(shì)所在：

Dart可以被編譯成不同平臺(tái)的本地代碼，讓Flutter不通過(guò)橋接層直接跟平臺(tái)通信，自然性能會(huì)快一些。

2、編譯執(zhí)行

JavaScript是解釋執(zhí)行的，Dart是編譯執(zhí)行的，性能誰(shuí)好一目了然。

3、Flutter Engine虛擬機(jī)

Flutter是依靠Flutter Engine虛擬機(jī)在iOS和Android上運(yùn)行的，F(xiàn)lutter Engine使用C/C++編寫，開發(fā)人員通過(guò)Flutter框架直接和API在內(nèi)部進(jìn)行交互，所以具有輸入低延遲和UI渲染高幀速率的特點(diǎn)。除了這特點(diǎn)之外，F(xiàn)lutter還提供了自己的小部件，F(xiàn)lutter小部件是使用從React獲取靈感的現(xiàn)代框架構(gòu)建的。 中心思想是您使用小部件構(gòu)建UI。

窗口小部件根據(jù)其當(dāng)前配置和狀態(tài)描述了它們的視圖。 當(dāng)窗口小部件的狀態(tài)發(fā)生更改時(shí)，窗口小部件會(huì)重建其描述，框架將根據(jù)前面的描述進(jìn)行區(qū)分，以確定底層呈現(xiàn)樹從一個(gè)狀態(tài)轉(zhuǎn)換到下一個(gè)狀態(tài)所需的最小更改?？梢灾苯釉贠S平臺(tái)提供的畫布上進(jìn)行描繪，也就是一些核心類庫(kù)直接放到虛擬機(jī)里面，調(diào)用起來(lái)更快。

從它的系統(tǒng)結(jié)構(gòu)可以看出，類似安卓的ART(Android Run Time)虛擬機(jī)，同樣采用AOT(Ahead of TIme)技術(shù)，會(huì)在APP安裝時(shí)就編譯成機(jī)器語(yǔ)言，不再解釋執(zhí)行，從而優(yōu)化了APP運(yùn)行的性能。

4、自帶渲染引擎

Flutter使用谷歌自己的Skia渲染引擎，而Android系統(tǒng)自帶Skia引擎，iOS平臺(tái)上Flutter也會(huì)把Skia引擎打包到APP中，從而實(shí)現(xiàn)了高效渲染。而React Native通過(guò)橋接層訪問原生UI，操作頻繁就容易出性能問題。

綜合所述，F(xiàn)lutter 是性能最接近原生代碼 的一種開發(fā)框架，未來(lái)也會(huì)是構(gòu)建谷歌Fuchsia應(yīng)用的主要方式，前途不可限量，唯一的問題就是需要學(xué)習(xí)一門新的語(yǔ)言：Dart，而有Java或者C#語(yǔ)言基礎(chǔ)的程序員會(huì)比較容易學(xué)習(xí)。

學(xué)js還是直接flutter

js先學(xué)在學(xué)Flutter

Flutter是谷歌的移動(dòng)UI框架，可以快速在iOS和Android上構(gòu)建高質(zhì)量的原生用戶界面。Flutter可以與現(xiàn)有的代碼一起工作。在全世界，F(xiàn)lutter正在被越來(lái)越多的開發(fā)者和組織使用，并且Flutter是完全免費(fèi)、開源的。

Flutter組件采用現(xiàn)代響應(yīng)式框架構(gòu)建，這是從React中獲得的靈感，中心思想是用組件(widget)構(gòu)建你的UI。組件描述了在給定其當(dāng)前配置和狀態(tài)時(shí)他們顯示的樣子。當(dāng)組件狀態(tài)改變，組件會(huì)重構(gòu)它的描述(description)，F(xiàn)lutter會(huì)對(duì)比之前的描述，以確定底層渲染樹從當(dāng)前狀態(tài)轉(zhuǎn)換到下一個(gè)狀態(tài)所需要的最小更改。

Flutter 與 iOS 原生 webView 對(duì)比

本文對(duì)比的是 UIWebView、WKWebView、flutter_webview_plugin（在iOS中使用的是WKWebView）的加載速度，內(nèi)存使用情況。

測(cè)試網(wǎng)頁(yè)打開的速度，只需要獲取 WebView 在開始加載網(wǎng)頁(yè)和網(wǎng)頁(yè)加載完成時(shí)的時(shí)間戳，時(shí)間戳的差即為打開網(wǎng)頁(yè)的時(shí)間

為了使差異更明顯，我們選擇較為復(fù)雜的 新浪首頁(yè) 進(jìn)行加載的對(duì)比，為了減小網(wǎng)絡(luò)對(duì)加載速度的影響，我們讓手機(jī)連接同一個(gè)網(wǎng)絡(luò)，分別進(jìn)行 10 次測(cè)試然后取平均值，另外，我們需要關(guān)閉 WebView 的緩存，防止緩存對(duì)加載速度產(chǎn)生影響

下面使筆者進(jìn)行 10 次測(cè)試所得到的數(shù)據(jù)

結(jié)果讓我有點(diǎn)驚訝，一直以為 WKWebView 會(huì)是個(gè)王者。結(jié)果看，速度上 WKWebView 略慢一點(diǎn)，不過(guò)總體差異不大（該結(jié)果僅僅是測(cè)試新浪的結(jié)果，僅供參考啦）

在這里，筆者又加了一個(gè)測(cè)試，嘗試記錄從 viewController 的 viewDidLoad 到 webview 的 didFinish 時(shí)間，測(cè)試了新浪的數(shù)據(jù)，如下：

UIWebViewA ： 4970、3808、3815、4250、3556 avg(4079.8) （加載完所有頁(yè)面）

UIWebViewB ： 4103、3124、3070、3256、2835 avg(3277.6)（加載sina完畢）

WKWebView ： 3672、3032、2892、2912、2739 avg(3049.4)

flutter_webView ： 4532、3901、4310、3496、3378 avg(3923.4)

其中可以看到，webView 有兩行，UIWebViewB 的數(shù)據(jù)就是加載 sina 主站的時(shí)間；UIWebViewA 的數(shù)據(jù)是因?yàn)樵诩虞d完 sina 主站之后，新浪又加載了一個(gè) ，所以導(dǎo)致總時(shí)間延長(zhǎng)，不過(guò)即使按照 UIWebViewB 的數(shù)據(jù)來(lái)比較，也是 wkWebView 略勝一籌。

此處可以看出 flutter_webView 使用的是 wkwebView，所以它吃虧的主要原因是 flutter 包了一層。

結(jié)論：

速度（didStart - didFinish） UIWebView flutter_webview WKWebView

速度（viewDidLoad - didFinish）WKWebView UIWebView flutter_webview

這里查看內(nèi)存使用的是 xcode 的 debug session 中的 memory。

首先看之前測(cè)試時(shí)，連續(xù)打開十次新浪的內(nèi)存情況

接著我們?cè)诳匆幌麓蜷_淘寶首頁(yè)的內(nèi)存情況

從圖上可以看出，WKWebView 在內(nèi)存方面有很大的優(yōu)勢(shì)啊，UIWebView 的內(nèi)存是真的傷啊，然后 debug 看了一下 flutter_webView，他使用的就是原生的 webView 。

他相比較原生 WKWebView 的內(nèi)存開銷稍大一點(diǎn)，從測(cè)試表現(xiàn)來(lái)看，一般大個(gè) 30 MB 左右。

結(jié)論：內(nèi)存 WKWebView flutter_webview UIWebView

可以在 html5test 中對(duì)瀏覽器的兼容性進(jìn)行評(píng)分，通過(guò)測(cè)試發(fā)現(xiàn)得分分別如下

因?yàn)?flutter 里使用的就是 WK，所以和原生的 WKWebView 一樣都是 444 分，比 UIWebView 的 437 略勝一籌

結(jié)論：兼容性 WKWebView = flutter_webview UIWebView

UIWebView : 速度相比較 WKWebView 稍快一點(diǎn)，但是內(nèi)存是一大硬傷，所以只要條件允許，就不推薦使用了

WKWebView : 速度略慢一點(diǎn)，不過(guò)差別不大，總體可以接受。是比UIWebView更好的選擇，推薦使用。

flutter_webView_plugin ：在iOS中使用的就是原生的WKWebView，所以總體和 native WKWebView 表現(xiàn)差不多。如果是混編項(xiàng)目中，因?yàn)樗话艘粚樱皂?yè)面加載上存在一定的劣勢(shì)，所以混編項(xiàng)目中仍然推薦使用 WKWebView。不過(guò)如果從多端考慮、以及項(xiàng)目可遷移等，那么使用也未嘗不可，就是維護(hù)成本要增加一些，需要維護(hù)兩套 webView。這個(gè)就需要根據(jù)自己的情況自己取舍了。