❶ 移動APP開發框架盤點2:Web移動前端框架大全
開源項目其實有一個成熟周期,這個周期大概是三年左右,自React框架在2013年發布並引爆了前端框架的大潮,這個屬於前端的周期就此開始了。
之後在2015年5月開源的React Native又開啟了屬於Web移動前端的周期,15-16年,18-19年,21-22年正好就是屬於移動前端的三個爆發點。
三年前,在第一個成熟收獲期,我盤點了移動開發框架。在這第二個成熟收獲期,理所當然要來盤點一波。
不過,當我點開github項目的code-frequency時,還是被這個准到嚇人的周期猜想驚呆了,先給你們看一波,剩下的自行驗證。
1、https://github.com/youzan/vant/graphs/code-frequency
2、https://github.com/quasarframework/quasar/graphs/code-frequency
再來說第二個比較有意思的發現,停止維護的項目絕大多數是Vue框架項目。
盤點開始的時候我還覺得React框架處於絕對劣勢,到完成時我發現React無論在選擇面還是成熟度上都超過了Vue。
原因我這里就不分析了,反正大家都有自己的看法。
網頁類框架就是前端組件框架,這一次雖然有大量項目停止維護,但是也有很多項目堅持了下來,而且還涌現出了一批新項目。
大廠佔了主導,因為這些年大廠在移動開發上的需求,遠高於其它方面。個人項目要堅持確實不易。
本來是想要做一個驗證項目,把所有框架都試用一遍並給出推薦度的。由於進度太慢,還是下一次再發吧。
這次的重點是漸進類框架,就是所謂多端同構框架(小程序框架)。這幾年國內的重點的各種小程序平台,所以多端框架的需求很是旺盛。
不過大多數先行者都沒挺過來還是讓我很意外,只有Taro成功了,想想還是有很多讓人唏噓的東西。
在這里還是先預測一波吧,因為這一類框架最變化最大,最終還是有很多框架要出局的。
漸進類框架是一個過渡性的產品,最終會變成橋接類框架的一部分,所以,與橋接類框架協同才是框架的出路。
這個賽道基本全是大廠了。
騰訊新一代跨端開發框架Hippy
Hippy一看就是淘寶Weex的對標項目,Kpi功能全面壓制。所以官方支持 React 和 Vue 兩種主流前端框架。在Weex2019年實質停更後發布,要不要這么卷?
Hippy 2.x 架構主要分成三層,UI(JS) 層 Hippy-React 和 Hippy-Vue 負責驅動 UI 指令生成;中間層 C++ HippyCore 負責抹平平台差異性和提供高性能模塊;渲染層 android 和 iOS 負責提供終端底層模塊、組件,並與布局引擎通信。
對Weex慘遭遺棄,我上次就說過:「ReactNative提供工具,Weex提供框架,將平台差異化屏蔽(Write Once, Run Everywhere)。所以Weex則註定功能相對弱小,並且坑比較多。」Weex最終下馬也是必然的,淘寶又發布升級版北海,為了實現(Write Once, Run Everywhere),它採用自繪,而且是基於Flutter自繪。
所以Hippy3.x就一如既往的Kpi功能層層加碼,很有騰訊風格。在未來的 3.x 中業務與渲染層中的具體實現可根據用戶實際場景進行切換:業務層上不再局限於 JS 驅動,還可選擇(如:DSL/Dart/WASM 等)其它語言進行驅動;在渲染層中,渲染引擎除了支持現有原生(Native)渲染之外,還可以選擇其他渲染 Renderer,如 Flutter(Voltron) 渲染。
「Kraken 北海」是一款高性能Web渲染引擎。底層基於 Flutter 進行渲染。
Kraken 不限制上層開發者使用的框架,無論你是使用 Vue 、Rax 還是 React 都可以開發 Kraken 應用。
Kraken 的 runtime 通過 JS Engine Binding 的方式提供了一系列 Web 標準的 API 介面,調用相應 API 會執行相關邏輯並創建一系列需要發送給 Dart 層處理的指令。
Kraken 其實就是一個小程序平台,而且追求全平台完全一致。我雖然認為各平台不一致是很自然的事情,但是也表示理解,畢竟別人吹牛有當真的傳統(KFC表示認同)。
Kraken 現在也是一個小號瀏覽器,所以它的主要工作就是摳標准,畢竟它是一款基於 W3C 標準的高性能渲染引擎。
最後,我勸淘寶領導定Kpi要理智些,畢竟Hippy4我還蠻期待的。
滴滴出品的超輕量級動態化跨端開發框架,主打輕量和實用。
Hummer 以 JS 引擎為基石,目前已支持 javaScriptCore、Hermers、QuickJS 等業內知名 JS 引擎(這里本來還有個V8的,我刪除了,源碼裡面沒有,Kpi需要)。再配合經過調優的 Yoga 布局引擎,抹平了兩端視圖布局差異(性能更佳的自研布局引擎開發中)。順便提一下,Hippy採用V8(功能更強)自研布局引擎(性能更佳)。
Hummer 的特點是拋棄了業界其他動態化跨端框架普遍使用的DSL層和VDOM層,因此原生 Hummer 不具備前端開發常用的響應式編程的能力,但同時換來的是接近原生開發的體驗和性能。再以原生 Hummer 為基礎,在此之上開發了一套基於MVVM架構的開發框架 —— Tenon ,通過 Tenon,可以把使用 Vue/React 編寫的代碼,轉換成原生 Hummer 的代碼。
Hummer也是一個小程序平台,而且超輕量。如果想要無限提升自己APP的能力,可以考慮嵌入Hummer。
Web移動前端框架正在迎來第三個高速發展期,各類框架得到極大繁榮。
個人在具體項目的貢獻已經微乎其微了,創新、架構創新是唯一制勝的手段,這也是我看好React的根本原因。
最後,還是想做點微不足道的 探索 ,現在前端組件庫層出不窮,更換組件庫帶來的代價有點大。想創建一個框架,來實現上次說的組件公約數和公倍數,無縫切換組件庫。理論上支持所有組件庫 ,也能為後來者提供彎道超車的機會。我想大廠可能沒有需求,也不會願意發布這種框架,畢竟都是平台部門說了算。
這個庫就是useMobile,當然分為useMobileReact和useMobileVue。下次先發布useMobileReact。等我發布後,再來填上面表中缺的推薦度。
原文地址: https://www.cnblogs.com/windfic/p/16019457.html
❷ 小丸工具箱的介紹
小丸工具箱一款可以壓制H264+AAC視頻的圖形界面工具,內核是x264、neroaac、mp4box等軟體。預制了@zj262144 研究出來的高清高壓參數。x264.exe是06_taro編譯的x264_32_tMod-8bit-420.exe,軟體已經附帶x264_32_tMod-10bit-420.exe。用戶可自行替換為10bit版本,其他版本請點擊06_taro編譯版。注意:XP系統需要安裝Microsoft.NET Framework 2.0小丸工具箱(視頻圖形界面壓制器)是一款可以壓制H264+AAC視頻的圖形界面工具,內核是x264、neroaac、mp4box等開源軟體,屬於傻瓜型壓制工具。
❸ 像美團外賣這樣的APP用一種開發語言,能開發得出來嗎
像美團外賣這樣的APP用一種開發語言,能開發得出來嗎?答案是不能。
美團發展到現在可以說已經是一個【巨無霸】了,裡面集成了很多很多功能,除了核心的外賣,還有 旅遊 、 娛樂 、購物、出行,金融等等業務線,那麼這么多復雜的業務根本不可能用同一種開發語言實現。
那麼美團都用到哪些開發語言和技術了呢?下面就根據我的理解詳細說一下。
前端是把產品的核心服務交給用戶的呈現者,它的表述方式、展示形式以及交互邏輯都跟用戶息息相關,都影響著用戶使用產品的體驗,也就是說直接影響產品的用戶留存。
前端開發主要分為三大類型:Andriod、IOS和PC(H5) ,Android開發語言是Kotlin和Java,IOS開發語言是Object-c和Swift,PC(H5)開發語言就比較雜了,有JS、CSS、HTML,還有很多第三方的前端框架,比如Angular.js、vue.js、Bootstrap、JQuery等等。
關於後端的功能,這一點可以說是眾說紛紜,主要需要考慮的是如何實現功能、數據的交互流程和存取、平台的穩定性與性能等。
那麼後端都用到哪些開發語言和技術呢?
根據後端技術選型的標准,後端可選的開發語言和技術是非常多的。
比如Java體系的話,可以選用SpringMVC、Spring cloud、Hibernate,Mybatis、Mysql、Redis、Memcache、zookeeper、Kafka......;
比如python體系的話,可以選用Django、Flask、Tarnado、Web2py等,中間件都是通用的,Redis,MQ、MySQL、Kafka等都可以用在python體系中;
當然還有PHP、C、Perl等開發語言。
綜上所述,美團這個巨無霸公司,隨著業務線的擴展用到的技術肯定會越來越多,而且越來越復雜,技術快速變革的時代,適者生存的競爭性也會越來越激烈。
俗話說:羅馬不是一日建成的,任何事都不可能一蹴而就,包含技術。在以後的發展中美團也會逐步更新自己的技術和開發語言的。
至少三種語言。後端一種語言(比如Java丶Go丶Python丶PHP等),後端語言及生態比較成熟。下面重點聊前端App開發。
前台兩種語言(Android和iOS是不同的開發環境。比如Android用Java或者Kotlin,iOS採用Object C++或Swift),稱之為Native開發。
當然創業公司可以用一種前端語言寫App前端,這樣就不需要Android和蘋果分兩種語言寫,寫一次代碼可以編譯成Android和iOS的App,現在通行的方案有Vue之類的DOM渲染模式,以及ReactNative方案(RN)。性能上RN優於DOM渲染但低於用Native開發的App。所以美團這種公司,一定是Native方式寫App,但RN是初創項目不錯的選擇。
與RN競爭的還有一種新貴flutter,是google推出來的,但設計原理與RN不同,性能方面優於RN,只是目前生態不夠健全,國內有閑魚app是採用此技術。未來可能會佔一席之地。
最後,其實App開發已經是強努之末,我覺得主流應該是朝PWA和小程序方向發展。
你好,開發譬如美團這種APP,用一種語言是實現不了的,一個APP有安卓和蘋果兩個操作系統,開發能在安卓iOS端應用的APP主流的開發語言和技術是很多的,如後台有JAVA、C++、PHP、Python等多種開發語言,前端有kotlin、HTML、css、jquery、ajax、bootstrap、angular.js、react、vue.js、node.js、swift、object-c等多種語言和框架。
一個APP的開發是需要前端技術和後台技術共同配合完成,這樣的APP不論是功能還是性能都給用戶很好的體驗,單一開發語言畢竟技術支持有限,所以即使能開發出來,APP的用戶體驗也是不理想的。
一般APP有這幾種開發組合模式:1、原生安卓iOS開發,前端:JAVA、kotlin、swift、object-c後台:JAVA、PHP、C++等後台技術,這種模式開發周期長,成本高,性能好;2、混合APP開發即hybrid app,前端以網頁技術為主,穿插原生開發功能,兼具原生APP和web app的優點,如淘寶、微信等應用都是走的這個技術;3、web app,前端純網頁技術,後台為主流開發語言,這種模式開發速度快,成本低,界面體驗可能弱一些。
可見開發一款APP大多數都是多種語言配合完成,謝謝閱讀。
看完之前的評論,依然好奇為什麼一個語言不能完全勝任。
前端跨平台的方案有react native,cordova,flutter等,如果需要兼容開發小程序,h5頁面,可以採用taro來開發,一套代碼,所有平台通吃。
後端的方案有服務端運行時nodejs,大數據背景下運用而生的資料庫mobgodb,緩存解決方案redis,搜索工具elasticsearch,負載均衡ngix,基本上是需要什麼就有什麼
所以總結下來,一句話,一種語言可以實現類似美團這樣的app和小程序。為什麼美團使用的語言那麼多,一大原因估計是美團app開發的早,當時前端技術不成熟,工具沒現在這么多。
使用混合開發與C++ 進行跨平台開發,有好有壞。
C++ 進行跨平台開發
編寫一次,隨處運行。早在 2013 年,Dropbox 就採用上述策略進行移動開發,這背後的想法很簡單:用 C++ 編寫一次代碼,而不是用 Java 和 Objective-C 編寫兩次。那時,整個移動工程團隊相對還比較小,但需要支持快速增長的移動路線圖。因此,公司希望找到一種方法,使這個小團隊可以快速交付大量 Android 和 iOS 代碼。
如今,Dropbox 完全放棄了這個策略,轉而使用各個平台的原生語言(主要是 Swift 和 Kotlin ,這兩種語言在剛開始制定移動策略時還不存在)。
Hybrid App混合開發
Hybrid App主要以JS+Native兩者相互調用為主,從開發層面實現「一次開發,多處運行」的機制,成為真正適合跨平台的開發。Hybrid App兼具了Native App良好用戶體驗的優勢,也兼具了Web App使用HTML5跨平台開發低成本的優勢。
目前已經有眾多Hybrid App開發成功應用,比如美團、愛奇藝、支付寶等知名移動應用,都是採用Hybrid App開發模式。
移動應用開發的方式,目前主要有三種:
幾種模似都可以開發出應用,小應用無所謂,但是大流量應用,對圖形要求高的如 游戲 等原生開發的效果還是最好
支付寶打開很慢,就是因為採用混合開發,使用人多了不如原生開發
不行的哦。任何你看到的應用和網頁,都需要多個語言開發的,大的分比如前端和後端,用的語言都是不一樣的
❹ 小丸工具箱顯示100卡住
壓縮文件過大,屬於正常現象,需要耐心等待一下。實在不行可能需要從新進行壓縮。
小丸工具箱一款可以壓制H264+AAC視頻的圖形界面工具,內核是x264、neroaac、mp4box等軟體。預制了研究出來的高清高壓參數。x264.exe是06_taro編譯的x264_32_tMod-8bit-420.exe,軟體已經附帶x264_32_tMod-10bit-420.exe。用戶可自行替換為10bit版本,其他版本請點擊06_taro編譯版。注意:XP系統需要安裝Microsoft.NETFramework2.0小丸工具箱(視頻圖形界面壓制器)是一款可以壓制H264+AAC視頻的圖形界面工具,內核是x264、neroaac、mp4box等開源軟體,屬於傻瓜型壓制工具。
壓縮方法:1、首先,我們打開小丸工具箱。2、然後把需要壓縮的視頻拉到小丸工具箱查看參數。3、知道了參數,我們把視頻拖進這個位置,看圖就明白了,然後設置好參數,參數設置方法看後面計算方法。4、自己計算一下,各個參數設置是否可以,根據計算規則得到的結果是否正確。5、設置好視頻的參數,如解析度設置好,我們還需要設置音頻的參數,具體看圖就明白了,一般設置50或32的碼率。6、全部設置好以後,我們直接點壓制,稍等一會兒,壓縮好的視頻就出來了,文件就在沒有壓縮的視頻旁邊,可以點屬性查看壓縮後的參數。7、我們看看各種參數,文件大小是否滿意,也需要播放一下,看看清晰度是否滿意,如果不滿意,可以重新調整一下數據,進行第二次壓縮。
❺ 雲南北大青鳥java培訓告訴你web前端多端編程開發框架結構
❻ taro 怎麼集成 android sdk
【CSDN 編者按】小程序這個由微信帶頭的產物,格外鮮明地體現了移動互聯網的「時機」這個詞,早在微信小程序之前,有力推輕應用的網路,有來自 HTML5 中國產業聯盟的 DCloud 所主張的流應用,但最終卻都已經淹沒在了移動互聯網的歷史長河之中。唯有微信小程序風生水起,更是帶動了巨頭們的爭相入場。
小程序迎來了專屬於中國移動互聯網的群雄逐鹿的時代。
本文作者王安即是流應用的創造者,作為移動領域的老兵,他依然在矢志不移地構建移動開發工具框架及生態,從原生應用到 HTML5 再到如今的小程序,他是這段歷史的見證者、參與者。從這篇文章中,我們能夠鮮活地看到小程序的技術演進歷程,以及對於所有開發者來說,終將去往何處。
作者 | 王安
責編 | 唐小引
封圖 | CSDN 付費下載自東方 IC
出品 | CSDN(ID:CSDNnews)
中國特色的移動互聯網時代
伴隨著QQ 小程序面向用戶開放,這個手機端月活 7 億的巨無霸正式入場。小程序,終於成為了超級 App 的標配。
盤點下已經支持小程序的超級 App:
微信、企業微信、QQ、支付寶、高德地圖、手機淘寶、網路、網路貼吧、網路地圖、今日頭條、抖音……
這些璀璨耀眼的名字,背後都是巨大的流量。
在這群超級 App 的支持下,中國的移動互聯網格局被徹底改變。
這個有中國特色的移動互聯網時代,被稱為「小程序時代」。
這是繼手機支付後,中國的移動互聯網領先世界的第二個代表事物。
中國的技術標准、開發者生態,第一次得到大規模的普及應用,而且很明顯,小程序在功能和體驗上均超過了 HTML5。
中國人能建立開發者生態嗎?這個命題曾一度讓人懷疑。
小程序完成了這一步突破,這是一場值得歌頌的中國技術生態發展史。
讓我們來回顧下這場技術生態革命,是如何開始,又將要去向何方。
羅馬不是一天建成的
小程序不是一天發明出來的
HTML5 於 2007 年在 W3C 立項,與 iPhone 發布同年。
喬布斯曾期待 HTML5 能幫助 iPhone 打造起應用生態系統。
但 HTML5 的發展速度並不如預期,它雖然成功地實現了打破 IE+Flash 壟斷局面的目標,卻沒有達到承載優秀的移動互聯網體驗的地步。
於是在 iPhone 站穩腳跟後,發布了自己的 App Store,開啟了移動互聯網的原生應用時代。
隨後的 Android,本來是基於 Linux 的 OS,與之同期的 MeeGo 等競爭對手採用 C + HTML5 的雙模應用生態策略,然而 C 的開發難度太大,HTML5 體驗又不行。Android 依靠 Java 技術生態,在競爭中脫穎而出。
於是在移動互聯網初期,應用生態被定了基調 —— 原生開發。
在那個時候,硬體不行,也沒有其他辦法,原生開發才能在低配硬體上帶來商用體驗。
但大家都在懷念 HTML,那種無需安裝更新、即點即用,直達二級頁面的特點,一直讓人迷戀。
圖源:CSDN 付費下載自東方 IC
國內有一批做瀏覽器的廠商,嘗試去改進 HTML5,他們提出了輕應用的概念。
通過給 WebView 擴展原生能力,補充 JS API,讓 HTML5 應用可以實現更多功能。
不過這類業務沒有取得成功,HTML5 的問題不止是功能不足,性能體驗是它更嚴重的問題,而體驗問題,不是簡單地擴展 JS 能力能搞定的。
這類業務發展的頂峰,是微信的 JS SDK。
作為國內事實上最大的手機瀏覽器,微信為它的瀏覽器內核擴充了大量 JS API,讓開發者可以用 JS 調用微信支付、掃碼等眾多 HTML5 做不到的功能。
微信 JS SDK 說明文檔
但微信團隊對這套方案的體驗仍然不滿意,微信錢包欄目里打車、理財等很多應用雖然嵌入了 JS SDK,但每次點擊要等半天白屏,讓人用著很痛苦,他們在業內開始尋找新的解決方案。
業內早有專業團隊看到了相同的問題。
與瀏覽器不同,Hybrid 應用是另一個細分領域。它們為開發者提供使用 JS 編寫跨平台應用的工具,為了讓 JS 應用更接近原生應用的功能體驗,這個行業的從業者做出了很多嘗試。
筆者所在的 DCloud 即是其中之一,我們提出了改進 HTML5 的「性工能」障礙的解決方案 —— 通過工具、引擎優化、開發模式調整,讓開發者可以通過 JS 寫出更接近原生 App 體驗的應用。
多 WebView 模式,原生接管轉場動畫、下拉刷新、Tab 分頁,預載 WebView……各種優化技術不停迭代,終於讓 Hybrid 應用取得了性能體驗的突破。
Hybrid 應用和普通的輕應用相比,還有一個巨大的差別:一個是 Client/Server,一個是 Browser/Server。簡單來說,Hybrid 應用是 JS 編寫的需要安裝的 App,而輕應用是在線網頁。
C/S 的應用在每次頁面載入時,僅需要聯網獲取 JSON 數據;而 B/S 應用除了 JSON 數據外,還需要每次從伺服器載入頁面 DOM、樣式、邏輯代碼,所以 B/S 應用的頁面載入很慢,體驗很差。
可是這樣的 C/S 應用雖然體驗好,卻失去了 HTML5 的動態性,仍然需要安裝、更新,無法即點即用、直達二級頁面。
那麼 C/S 應用的動態性是否可以解決呢?對此,我們提出了流應用概念,把之前 Hybrid 應用里的運行於客戶端的 JS 代碼,先打包發布到伺服器,制定流式載入協議,手機端引擎動態下載這些 JS 代碼到本地,並且為了第一次載入速度更快,實現了應用的邊下載邊運行。
就像流媒體的邊下邊播一樣,應用也可以實現邊用邊下。
在這套方案的保障下,終於解決了之前的各種難題:讓 JS 應用功能體驗達到原生,並且可即點即用、可直達二級頁面。
如今看來,這已經變成了常識。但在當年,先驅們做了無數艱辛探索。
這套技術,需要讓客戶端引擎提前預置在手機上,就像流媒體的普及,建立在 Flash 的裝機量巨大的基礎上,那麼普及這個客戶端引擎就變得很重要。
2015 年,360 和 DCloud 合作,在 360 手機助手裡內嵌了這個客戶端引擎,推出了業內第一個商用的小程序,360 稱之為 360 微應用。
微應用實現了在 360 手機助手的應用下載頁面,同時出現了「秒開」按鈕,點擊後直接使用。
並且在 360 手機助手的掃碼里,應用的分享里,都實現了掃碼獲得一個應用,點擊分享消息獲得一個應用。
在 360 手機助手 3.4 版本中上線的中國第一個小程序
為了做大生態,DCloud 把這套技術標准,捐獻給了 HTML5 中國產業聯盟,隨後,聯盟開始推動更多的超級 App 和手機廠商加入,共同推進動態 App 產業的發展。
然而事情並不順利,巨頭們有自己的利益訴求。雖然有一批廠商同意加入聯盟共建生態,但最關鍵的角色,真正的國民應用「微信」,最終決定自立標准、自研引擎,當然技術原理與流應用是基本一致的。
2016 年 1 月 11 日,微信公開課,張小龍罕見露面,公布了微信應用號的計劃,為這個大事件親自站台。
2016 年 9 月 21 日,微信宣布更名應用號為小程序,面向首批開發者內測。從此,這個詞被正式定了下來,「小程序」,成為後續一個時代的代名詞。而「流應用」、「微應用」則淹沒在歷史長河中成為一個令人唏噓的故事。
2017 年 1 月 9 日,微信公開課,小程序面向用戶正式推出。
從此後,阿里巴巴、手機廠商聯盟、網路、今日頭條,陸續推出了自己的小程序平台,其中也有很多波折與故事,在有偶然、有必然的過程中,形成了今天的局面。
小程序大潮捲入了更多人,並形成了更大的浪潮,最終迎來了不可逆轉的小程序時代。
生態難,難於上青天
發明能解決功能體驗和動態性的技術方案,雖然難,但不是最難的事情。
最難的是開發者生態的建設。
最初 HTML5 中國產業聯盟的策略是在 HTML5 上擴展強化,復用現有的 HTML5 生態。
當微信的標准完全自立重建時,業內人士都懸著一顆心。
在全球,基於 Web 的技術生態已經非常成熟,各種開發工具、框架、組件、模板...提升著開發者的效率。
小程序丟棄了國際標准組織 W3C 的 DOM 和 Window 標准,僅僅採用基礎 JavaScript。這意味著 HTML5 生態的各種輪子無法復用,要完全重造一個新的小程序開發生態。
當初微信推廣 JS SDK 時,是那麼地順其自然,開發者紛紛開始使用,因為對於開發者,只是在他們的 H5 版本上補充一些 API 而已。
而小程序初期,充滿了開發者的質疑聲:我的業務迭代那麼久,讓我重新做一個版本,你的生態到底能不能支撐我的投入?
微信用持續而快速的版本升級、高管的站台,告訴大家微信做小程序的決心,並最終通過 2017 年底的跳一跳,引爆了小程序。
從此大家的問題不再是我要不要做小程序了,而轉向了:既然要做,怎麼才能提升小程序的開發效率、降低開發成本?
任何一種技術,或者開發模式的演進,在不斷成熟的過程中,都遵循著類似的成熟規律:
技術標准 -> 基礎平台 -> 開發工具 -> 培訓市場 -> 框架誕生 -> 周邊生態逐步完善 -> 輪子之上的輪子
在 HTML5 生態里,已經發展到最終極的形態,比如 Vue 是一個重要框架,而基於 Vue 的各種豐富的 UI 庫、測試框架,則是輪子之上的輪子。
多層輪子代表著生態的繁榮,也意味著開發者的開發效率更高。
可微信的全新標准出現時,它把開發者推回了原始社會,一切都要重來。
這在當時看來,並不是一個必然會成功的事情(其實直到現在,比如圖表類輪子,小程序仍然比不過 HTML5)。
時至今日,討論這個標準的選擇對錯已經沒有意義。當支付寶、網路、今日頭條都開始參考這個標准做小程序時,時代已經不可阻擋。
所幸,最終的結果是,中國人做成了。在國際標准之外,在中國,終於建立起了自己的技術生態。
並且這個生態,給用戶帶來了更好的體驗,給開發者帶來了更多流量和變現效率的提升,這是一個比 HTML5 更優秀的生態。
野蠻的技術生態成長速度
兩年時間,中國的小程序開發者如何從原始社會進階到現代文明?這也是一段有趣的歷史。
我們來看看小程序技術生態是如何快速成長,走完上面所說的這套技術成熟路線,也就是從技術標准到輪子之上的輪子的。
在 Web 世界裡,已經成熟到了原生 JS 用量很少的時代了,開發人員大量使用 Vue 等框架,並且在 Vue 的基礎之上,又有更多輪子。
當中國的開發人員面臨重頭開始時,他們感受到效率對比的差距,既然時代已不可阻擋,那就擁抱它。勤勞的中國技術人開始蓬勃地建設起了小程序各種周邊技術生態。
其中比較重要的是開發框架的迭代,我們看看每個小程序開發框架為什麼會誕生、流行和衰落。
最初的微信小程序,一片荒蠻,一份文檔 + 一個難用的 IDE,很多效率工具比如 npm、預處理器這些都不支持,而這些已經是大型項目離不開的工具。
於是,第一個標志性的框架出現了 —— WePY。
WePY 緊隨微信小程序在 2017 年發布,原本是騰訊其他部門的一個個人工程師的作品。在那個年代,WePY 有效地解決了小程序不支持 npm、預處理器的痛點,被引爆後,騰訊官方才把這個框架收編到官方的 GitHub 下。
不過WePY也面臨很多問題,它使用了私有語法,這讓它在生態建設上面臨很大難度,IDE 著色、語法提示、語法校驗、格式化、人員招聘培訓等各方面問題制約著它的流行和普及。
面對這些問題,人們開始思考,有什麼更好的方式,可以復用現有技術生態來快速完善小程序生態?
這時候下一個重要框架借勢誕生,美團前端在 2018 年初開源了MPVue。
MPVue 採用 Vue 語法來開發小程序,通過對 Vue.js 的底層改造,實現了編譯到微信小程序。
MPVue良好地藉助了 Vue 的技術生態,周邊工具如 IDE、校驗器、格式化等支持直接復用、人員招聘培訓等生態建設壓力大幅下降,受到了大量開發者的歡迎。
看著熟悉 Vue 的開發者終於有了趁手的輪子,那熟悉 React 的開發者怎會無動於衷?
京東團隊是 React 的重度用戶,還自研了 JDreact,於是他們開發了 Taro 框架,一款基於 React 語法編寫小程序的框架。
但 Taro 並不是想簡單做一個MPVue在 React 世界裡的翻版,Taro 相比MPVue,想要解決更多重要問題。
Taro 面世較晚,此時微信、支付寶、網路、頭條都已發布或宣傳了自己的小程序,開發者面臨一個多端開發和適配的問題。
於是 Taro 率先支持多端開發,它甚至還能發布到 H5 和 App。
圖源:京東凹凸實驗室
當時小程序領域還有一個重要變化,微信開始支持小程序自定義組件。
組件是一個成熟框架不可缺的東西,不管是 Vue 還是 React 都有豐富的組件生態。
在過去,MPVue時代,是把 Vue 組件也編譯成頁面模板,這帶來一個很大的性能問題,在復雜頁面里(比如長列表)使用組件,更新組件狀態會導致整個頁面的數據全部從 JS 邏輯層向視圖層通訊一次,大量數據通訊會非常卡頓。
注意:小程序的邏輯層運行在 V8 或JSCore下,和視圖層是分離的,通訊阻塞很容易引發性能問題。
於是 Taro 把 React 組件編譯為新出的微信小程序自定義組件,這種組件在數據更新時,只會更新組件內部的數據,而不是整個頁面更新數據,從而大幅減少了數據通信量。
這一輪的後浪推前浪很猛,Taro 在性能和多端支持上,都超越了MPVue。
看著 React 陣營取得如此成績,Vue 陣營自然會繼續追擊。
我們基於 Vue 開發了 uni-app,它實現了自定義組件編譯模式,並在演算法上做了很多優化。另外,之前MPVue對 Vue 的語法支持度不太完善,比如過濾器等不支持,在 uni-app 中我們進行了解決。
同樣,uni-app 也看到了前浪的其他問題:Taro 雖然邁出了多端的第一步,但多端支持能力比較弱,每個平台仍然各自開發大量代碼。核心原因,是Taro 在 H5 端和 App 端,並不是一個完整的小程序技術架構,無法保持最大程度的統一。
於是 uni-app 在 App 端,使用了一個技術架構相同的小程序引擎,本身就可以直接運行小程序應用,這個引擎搭配小程序代碼打包為 App,開發者一行代碼不用改,可以同時發布小程序和 App。
當然,其 App 引擎從 Hybrid 應用起家,它提供的 API 要比小程序多很多,因為 App 的需求會比小程序豐富,它還支持把 WebView 渲染引擎替換為 Weex 渲染引擎。
之後 uni-app 又發布了 H5 版的小程序引擎,原理與小程序的 PC 模擬器相同,實現了良好的跨 H5 版的發布。於是 uni-app 比較完美地實現了開發一次,7 個平台發布。
第一層輪子就這樣迅速發展了起來,Web 世界裡最成熟的 Vue、React 技術生態被導入了小程序開發生態中。然後輪子之上的輪子開始如火如荼的建設。
以 UI 庫為例,之前的 UI 庫,有 Vue 庫、React 庫,有 PC 庫、H5 庫和小程序庫,種類繁多,甚至說混亂。
比如在 Vue 陣營中,Vant 和 iView 這兩個 UI 庫,都是同時維護兩個版本,它們即有 H5 版,又有小程序版。
不止框架作者麻煩,開發者想在多端使用這些 UI 庫時,會發現在不同端還需要引入不同的 UI 庫,寫法都不一樣,這讓開發者很崩潰。
既然已經可以多端開發應用,於是在多端開發的領域里,開始出現輪子之上的輪子,多端 UI 庫。
首先是 Taro 推出了 Taro UI,實現了 H5 和小程序 UI 庫的統一,不過可惜 Taro UI 不支持 App 端。
然後 uni-app 推出了 uni UI,這個 UI 庫同時支持多家小程序、H5、App。
由於 uni-app 和 MPVue 同屬 Vue 陣營,它們的組件是互通的。於是這兩家聯合舉辦了一場插件大賽,建立了插件市場。
在中國的前端開發者領域,有很多和國外不一樣的地方:一個是國內有小程序,第二個是國內 Vue 的開發者體量遠超過 React 和 Angular。這裡面很大的原因,是 Vue.js 的作者尤雨溪,是中國人。
Vue 和 React 網路指數對比
在龐大的 Vue 用戶體量支持下,uni-app 和 MPVue 的周邊生態迅速發展起來,開發工具、周邊輪子、教育培訓等生態快速完善。目前在 Vue 陣營下,開發者在 Web 生態下所需的輪子,在多端開發下基本也都有了。
短短兩年時間,小程序開發生態里幾撥迭代,輪子之上的輪子不斷涌現,快速進入了成熟期。
結語
產業還在繼續發展,每當底層有重大技術變更時,上層框架世界就會發生新機會。
當年 HTML5 標准不統一,瀏覽器兼容性問題嚴重,誕生了 jQurey 的機會。而在移動互聯網下半場,瀏覽器兼容已經不再是核心問題,jQurey 的地位被更適合移動互聯網的 Vue 替代。
我們不知道未來還會有什麼新的框架出世,但我們知道方向:
對於開發者而言,總是會向著更高的開發效率、更高的性能、更高的投入產出比前進。
對於開發商,目前的小程序,雖然發展了 2 年,但流量增長空間仍然巨大,微信之外,很多超級 App 的勢能將逐漸釋放,整個小程序產業的日活總量有數億的提升空間。
如果開發商能追上這撥紅利,就能獲得更多增長。而多端框架的出現,可以幫助開發商更好的把握這撥紅利。
中國的技術發展,此刻正在經歷一個分水嶺,從全面的技術進口,到開始建設自己的標准和開發者生態。遲早,會開始向外輸出,引領世界的進步。
不管中美是否開打貿易戰,這一轉變都是必須做的事情。
中國的移動支付、小程序、5G,很多領域已經走在了全球前面。中國人發明的 Vue 已經在影響全球。
雖然還有很多困難仍需克服,但我們每個開發者,都是新時代的見證者,更是新生態的建設者!
作者簡介:王安,DCloud 公司創始人,HTML5 中國產業聯盟秘書長。2003 年開始從事移動互聯網工作,十幾年編程和商業經驗,連續創業者。
聲明:作者獨立觀點,不代表 CSDN 立場
❼ taro framework有什麼用
Taro框架是目前支持小程序最多的前端框架,Taro 框架的出現目的就是為了解決多端混亂的局面
Taro 一套 遵循React 語法規范的多端開發解決方案。使用 Taro,只書寫一套代碼,再通過 Taro 的編譯工具,將源代碼分別編譯出可以在不同端(微信小程序、H5、App 端等)運行的代碼。同時 Taro 還提供了開箱即用的語法檢測和自動補全等功能。Taro 基於組件化,組件生命周期和 React 的完全一致,使用聲明式的 JSX 語法。
❽ 移動端都用什麼前端框架
如果只是普通的移動端用Vue、React 或者dva,如果是要編譯成小程序或者混生,就用uni-app(對應vue語法)taro(對應react)
❾ taro ui時間軸中可以放圖片不
可以放,taro—ui本身給我們提供了時間軸taroUI官方文檔-時間軸。但是個人用起來taroui始終有些不靈活,於是乎自己手碼,數據是動態渲染的,為了方便復用,看得更清楚。只貼了一小段代碼,flex+100%布局;小圓點是我拿css畫出來的,想加icon圖標也是同樣的道理。所以是可以加圖片的。
拓展知識:Taro 是一個開放式多端開發框架,支持使用 React、Vue、Nerv 等框架,來開發微信、京東、網路、支付寶、位元組跳動、QQ小程序、H5等應用。
Taro 一套 遵循 React 語法規范的多端開發解決方案。使用 Taro,只書寫一套代碼,再通過 Taro 的編譯工具,將源代碼分別編譯出可以在不同端(微信小程序、H5、App 端等)運行的代碼。同時 Taro 還提供了開箱即用的語法檢測和自動補全等功能。
Taro 基於組件化,組件生命周期和 React 的完全一致,使用聲明式的 JSX 語法。
❿ 小丸工具箱的軟體簡介
小丸工具箱一款可以壓制H264+AAC視頻的圖形界面工具,內核是x264、neroaac、mp4box等軟體。預制了@zj262144 研究出來的高清高壓參數。
x264.exe是06_taro編譯的x264_32_tMod-8bit-420.exe,軟體已經附帶x264_32_tMod-10bit-420.exe。用戶可自行替換為10bit版本,其他版本請點擊06_taro編譯版。
注意:XP系統需要安裝Microsoft .NET Framework 2.0
小丸工具箱(視頻圖形界面壓制器)是一款可以壓制H264+AAC視頻的圖形界面工具,內核是x264、neroaac、mp4box等開源軟體,屬於傻瓜型壓制工具。
視頻壓制
方法一(推薦):
在視頻頁面輸入視頻,音頻、字幕等,點擊壓制即可。音頻參數一般選FAAC,碼率默認為128,可酌情調整。如果安裝了QuickTime,也可使用QTAAC,但只能使用32位的x264.
需要上傳新浪視頻的請在封裝頁面轉換為FLV。
方法二:
在視頻頁面和音頻頁面設置參數,然後在其他頁面的一鍵壓制中壓制。
方法三:
1.音頻獲取:方法a不作重編碼,但要求音頻格式為aac。方法b重編碼,但無任何限制。
a.進入抽取頁面,抽取原視頻的音頻流,音頻流文件生成在視頻源目錄下面。一般是AAC格式。
b.進入音頻頁面,輸入視頻,設置碼率,一般網路視頻96Kbps即可。壓製得到新的音頻流。
2.視頻獲取:
進入視頻頁面,輸入原視頻文件,設置質量(或碼率)、寬度、高度。點擊壓制。
3.封裝:
進入封裝頁面,將以上得到視頻流和音頻流合並即可。
4.上傳:
進入新浪播客,進入上傳頁面,把文件放入裡面,等待上傳完畢即可