年來,前端技術日新月異,前端已經不僅僅是網頁,更多的開始由狹義向廣義發展。
先后涌現出了具備后端能力的node,具備移動開發能力的react native,具備游戲渲染能力的cocos2d-js,以及iOS上的熱修復技術JSPatch等等新技術。
咋一看,幾乎各個端都被JavaScript攻陷,大有一統江湖之勢。
究竟,JavaScript如何做到上天入地無所不能?JavaScript真的能一統江湖嗎?
亂世出英雄:JavaScript的誕生故事要從JavaScript的由來說起。
高能瞎扯淡版,正經臉的同學可以忽略
有人的地方就有江湖,有江湖的地方就有紛爭。
故事要從當年的瀏覽器之戰說起。
時間回到1994年,
(→ 那時候我還是個寶寶~ #天真臉#)
景兄弟橫空出世,并自帶神器網景導航,戰斗力爆表,勢如劈竹,瞬時間威震天下。
一出世就武裝到牙齒,武力值這么高還自帶兵器,這個科學嗎?
港真,我也覺得不科學,也許跟熊孩子哪吒、女漢子雅典娜是一個品種吧?
這一切北方的老前輩微軟大濕,都看在眼里,不甘天下盡歸景兄弟這個初出茅廬的毛孩子,大濕積淀多年,潛心修煉一年,終于帶著大殺器IE 1.0出關了,誓于景兄弟爭個高低。
自此景兄弟的網景導航 VS 微軟大濕的IE 的軍備戰爭開始。
景兄弟仔細掂量,微軟大濕財大氣粗,內功深厚,臣妾實在是辦不到啊啊啊啊啊啊。
景兄弟緊急召集門人商議對策,有一門人曰:”以我們微薄之力硬磕,是萬萬使不得的。如今我們,一是宜施行合縱之策,抱大腿,組成聯盟!二是避其鋒芒,出奇招致勝?!?/p>
于是景兄弟依照此策略,一方面找到了當時德高為重的另一位前輩SUN,組成了開發者聯盟。
(微軟大濕:握草,聯盟都粗來了,那我是不是得搞個部落?)
另一方面,景兄弟找到了鍛造大師布蘭登,請布大師幫忙升級兵器網景導航,大師就是大師,不費吹灰之力就完成了強化升級,然而布大師突發奇想,本來這是近距離攻擊兵器,要是有多一個遠距離攻擊的能力那豈不是更好?Just do it. 想罷大師就加了一個遠距離攻擊的feature。于是有了自帶遠距離攻擊能力的網景導航2.0。景兄弟一看這么流弊心里甚是歡喜,不過遠距離攻擊的技能叫做LiveScript,感覺不是特別Fashion。特然想到這不是跟SUN前輩聯盟嘛,SUN家的Java正是獨霸武林之時。不如把名字改成跟Java有關,蹭一把東風,蹭點光環。一拍腦袋,JavaScript?。?!眾門人一聽:”好好好,JavaScript 流弊炫酷吊炸天!“
果然第一節下半場,景兄弟攜強化過的網景導航2.0 戰個痛快,那是杠杠的!人家一問,你咋還能遠程攻擊,你這個遠程攻擊用的是啥?答曰:JavaScript?!癑avaScript,一定是跟SUN家Java是一個系列產品,一定很流弊!”#光環加成,各種膜拜臉#
微軟大濕虧了一場,痛定思痛,也要搞遠程攻擊功能,果然不久,就祭出了同樣帶有遠程攻擊能力的IE 3.0,鑒于景兄弟的遠程攻擊叫做JavaScript,J開頭的感覺應該比較流弊,所以微軟大濕的叫做JScript。
然后戰爭就從地面貼身肉搏戰,開始逐步升級到了遠距離核戰爭。
正所謂,城門失火,殃及池魚。這么打下去苦逼的是搬磚的頁面仔,就是我這種,到處都是雷區,無處下腳。
最后到了1997年,“聯合國安理會秘書長”艾瑪(ECMA)出來調停,多方簽署了“核不擴散條約”,約束各種遠程攻擊武器的使用,這才走上了正軌。
1995年SUN開發了Java技術,這是第一個通用軟件平臺。Java擁有跨平臺、面向對象、泛型編程的特性,廣泛應用于企業級Web應用開發和移動應用開發。Java也伴隨著互聯網的迅猛發展而發展,逐漸成為重要的網絡編程語言。名噪一時。
1994年Netscape公司成立,并推出了自己的瀏覽器的免費版本 Netscape Navigator,很快就占有了瀏覽器市場。到了 1995 年,微軟公司開始加入,并很快發布了自己的 Internet Explorer 1.0。
1995年,當時在Netscape就職的Brendan Eich(布蘭登·艾克),正為Netscape Navigator 2.0瀏覽器開發的一門名為LiveScript的腳本語言,后來Netscape與Sun Microsystems組成的開發聯盟,為了讓這門語言搭上Java這個編程語言“熱詞”,將其臨時改名為“JavaScript”,日后這成為大眾對這門語言有諸多誤解的原因之一。
JavaScript最初受Java啟發而開始設計的,目的之一就是“看上去像Java”,因此語法上有類似之處,一些名稱和命名規范也借自Java。但JavaScript的主要設計原則源自Self和Scheme。JavaScript與Java名稱上的近似,是當時Netscape為了營銷考慮與SUN達成協議的結果。
==> 所以,JavaScript和Java其實沒有半毛錢關系。
JavaScript推出后在瀏覽器上大獲成功,微軟在不久后就為Internet Explorer 3.0瀏覽器推出了JScript,以與處于市場領導地位的Netscape產品同臺競爭。JScript也是一種JavaScript實現,這兩個
JavaScript語言版本在瀏覽器端共存意味著語言標準化的缺失,對這門語言進行標準化被提上了日程,在1997年,由Netscape、SUN、微軟、寶藍等公司組織及個人組成的技術委員會在ECMA(歐洲計算機制造商協會)確定定義了一種名叫ECMAScript的新腳本語言標準,規范名為ECMA-262。JavaScript成為了ECMAScript的實現之一。ECMA-262 第五版,即是ES5。
==> ECMA-262,包括ES5, ES6等是一個標準,JavaScript是ECMAScript的一個實現。
完整的JavaScript實現應該包含三個部分:
在網景導航2.0和IE 3.0出現之后的幾年間,網景和微軟公司不停的發布新版本的瀏覽器,支持更多的新功能。自此拉開了瀏覽器之戰的序幕。這場瀏覽器之戰到現在還在繼續,以下一張圖看清楚過程。
從瀏覽器之戰可以看出,各家瀏覽器比拼的大致兩個方面視覺體驗(渲染排版)和速度(腳本運行)。
==> 所以一個完整的瀏覽器組成,至少包含兩個部分:
補充一個市面常見瀏覽器的內核和JavaScript引擎搭配:
其他JavaScript引擎,Rhino,由Mozilla基金會管理,開放源代碼,完全以Java編寫,可以看做SpiderMonkey的Java版。
注意:webkit不單單只是一個排版引擎,webkit = 排版引擎 + JavaScript引擎。
==> 所以,JavaScript是動態語言,它的運行都是基于JavaScript引擎,引擎大都是由靜態語言實現C++、Java、and so on。JavaScript的能力也是由引擎賦予。不管是瀏覽器環境中是window,亦或是node環境中的process,均是由引擎提供。
(番外:Mozilla的人不知道為啥特別喜歡猴子,經常以猴子命名技術,所以看到帶Monkey的,十有八九估計是他們搞的。)
在瀏覽器環境中,DOM、BOM、window對象、setTimeout/setInterval,alert,console等方法均不是JavaScript自身具備的能力,而是瀏覽器native實現,然后通過JavaScript引擎注入到JS運行的全局上下文中,供JS使用。
鑒別方式,在調試器console中打出來,帶有[native code]的即是:
講道理:
JavaScript運行 → 依賴于JavaScript引擎 ← 瀏覽器集成了JavaScript引擎,同時通過JavaScript引擎注入native代碼工JS腳本使用
發散一下思維,只要有JavaScript引擎,就能運行JS腳本,不管有沒有瀏覽器!只是缺少瀏覽器提供的alert,window等方法。
既然瀏覽器可以往JavaScript引擎中注入代碼,賦予JS腳本在網頁中特殊的能力,同理我們可以自己集成JavaScript引擎,自己定義自己的方法往JavaScript引擎中注入,賦予JS更多更強的自定義能力!
注入的關鍵是:值類型相互對應,Obj映射class的一個實例,function映射一個句柄或者引用
JavaScript內部,所有數字都是以64位浮點數形式儲存,即使整數也是如此
這就是說,在JavaScript語言的底層,根本沒有整數,所有數字都是小數(64位浮點數)。容易造成混淆的是,某些運算只有整數才能完成,此時JavaScript會自動把64位浮點數,轉成32位整數,然后再進行運算。由于浮點數不是精確的值,所以涉及小數的比較和運算要特別小心。盡量避免使用JavaScript做精準計算和密集計算。
根據國際標準IEEE 754,JavaScript浮點數的64個二進制位,從最左邊開始,是這樣組成的。
第1位:符號位,0表示正數,1表示負數
第2位到第12位:儲存指數部分
第13位到第64位:儲存小數部分(即有效數字)
符號位決定了一個數的正負,指數部分決定了數值的大小,小數部分決定了數值的精度。
IEEE 754規定,有效數字第一位默認總是1,不保存在64位浮點數之中。也就是說,有效數字總是1.xx…xx的形式,其中xx..xx的部分保存在64位浮點數之中,最長可能為52位。因此,JavaScript提供的有效數字最長為53個二進制位(64位浮點的后52位+有效數字第一位的1)。
內部表現公式:(-1)^符號位 1.xx…xx 2^指數位
精度最多只能到53個二進制位,這意味著,絕對值小于2的53次方的整數,即-(253-1)到253-1,都可以精確表示。
而大部分的后端語言,C++、Java、Python等的long型都是可以支持到64位,因此long型數據從后端語言傳給JavaScript會發生低位截斷。遇到這種情況一般使用String處理,如需要在JavaScript中做long型計算,需要自行實現計算器。
有了自行往JavaScript引擎中注入的想法,接下來就是分析可行性。
大部分是JavaScript引擎是使用C++編寫,如果自己的程序使用的是C++可以很方便的進行注入,如果是OC,可以使用OC和C++混編的形式。
其他語言怎么破?
要在一門靜態語言上與動態語言JavaScript相互調用,最便捷的方式是找到一個這門語言實現的JavaScript引擎(開源),直接進行集成,注入。如果沒有,則需要使用多一層橋接,把這門語言的接口暴露給C++,再由C++實現的JavaScript引擎將接口注入供JavaScript使用。
服務端集成思路&實踐:
我們都知道nodeJS,但是nodeJS的運行依賴于Google的V8 引擎,V8是C++實現,底層使用C++實現底層功能,比如網絡,數據庫IO,對外暴露一個構造器接口注入到上下文中,注意此處暴露的只是一個構造器接口而不是一個創建完的實例。然后實現了一個require的hook函數。當使用require加載一個JS模塊時,跟網頁中使用AMD 的require并無異樣,當使用require加載系統庫,既是C++的模塊時,會調用暴露出來的構造器接口,得到一個實例對象。不管是裝載JS模塊還是裝載C++模塊,得到的都可以看做是一個Module Object,node會將裝載完的模塊緩存到binding_cache中,下次在別處的代碼中使用require裝載模塊時,就會先去binding_cache中查找,如果找到了則返回該module object,如果沒找到再執行上面的裝載流程。
這就是node的基本原理:C++封裝底層操作,通過V8注入,使得JS腳本有網絡和IO能力
以上說到的幾個都是C++層面的應用,那么經典的Java怎么玩?是不是Java就必須是靜態語言的玩法,沒有辦法像C++之類的,可以使用JS的動態特性?
當然不是。這個時候,我們需要說起前面介紹過的一個JS引擎 Rhino,Rhino是完全由Java編寫,可想而知,Rhino幾乎就是為Java應用而生的。
用法是這樣:
首先在我們的Java應用中集成Rhino;
所有的IO操作,網絡操作等,都封裝成service,并提供增刪改查,setter && getter等多種方法
通過spring,把這些service bean注入到Rhino中;
把業務邏輯寫到JS代碼中,JS代碼調用多個已注入的Java service處理業務邏輯,拼裝數據返回!
好處:修改業務邏輯不需要修改Java代碼,也就是不需要重新編譯和部署,只需要刷新下跑在Rhino中的JS代碼即可。以往Java應用的一個痛點是部署,需要重新編譯,打包,部署重啟服務器,現在以這種形式開發,可以達到服務端的熱更新和熱部署。既可以享有Java服務的穩定性和可靠性,又可以享有JS的靈活性。
這種技術和用法在差不多十年前就有過,前EMC的工程師基于EMC著名的商業產品Documentum,設計了一套Java開源的中小企業CMS系統Alfresco,在該系統中實現了這種技術,這種技術基于spring,叫做spring-surf,做了一個膠水層??梢钥醋鲂∈昵暗膎ode吧。
Demo,使用spring-surf框架的系統中一個webscript模塊
categorynode.get.xml定義URL攔截器和權限控制;
.get指明是處理GET請求,RESTful;
在categorynode.get.js中調用已注入的Java Bean處理業務邏輯;
若為網頁請求返回.html.ftl,若為Ajax,返回.json.ftl;
(此處配套使用的是FreeMarker模板引擎)
==> categorynode.get.desc.xml
==> categorynode.get.js
==> categorynode.get.html.ftl
==> categorynode.get.json.ftl
React Native目前也是異?;鸨?,RN程序的運行依賴于Facebook的RN框架。在iOS、Android的模擬器或是真機上,React Native使用的是JavaScriptCore引擎,也就是Safari所使用的JavaScript引擎。但是在iOS上JavaScriptCore并沒有使用即時編譯技術(JIT),因為在iOS中應用無權擁有可寫可執行的內存頁(因而無法動態生成代碼),在安卓上,理論上是可以使用的。JavaScriptCore引擎也是使用C++編寫,在iOS和安卓中,JavaScriptCore都做了一層封裝,可以無須關心引擎和系統橋接的那一層。iOS/Android系統通過JavaScriptCore引擎將定制好的各種原生組件注入,如:listview,text等。
cocos2dx是游戲開發中非常常用的游戲渲染引擎,有一系列的產品,如:cocos2dx(C++),cocos2d-lua(lua), cocos2d-js(JavaScript)等多個產品。其中最新退出的是cocos2dx的JS版本的cocos2d-js,編寫游戲渲染特效代碼相比于C++和lua非常方便。對于做需要經常更新的渲染場景,C++是靜態語言,每次修改都需要重新編譯才能運行,顯然是不合適的。自然也就想到了腳本語言,lua和js,兩者有些類似,都是動態語言,只需要集成一個運行引擎,提供一個運行的容器即可運行,同時通過引擎注入底層方法供腳本調用即可。lua好處是精簡,語法精簡,引擎頁很小很精簡,所以不可避免的代碼量會比js多,同時學習成本比較高。js的好處是有ECMAScrtpt的核心,語法比較豐富,同時有支持一些高級屬性。在cocos2d-js中,cocos2dx(C++)集成了SpiderMonkey(C++)作為JS運行引擎,中間做了一個膠水層既是JS Binding,通過引擎注入了一個cc的全局對象,映射的是底層C++的一個單例C++實例。表面上寫的是JS代碼,實際上操作的是底層的C++。cocos2d-js是代碼可以運行在多種環境中,當運行的網頁環境中時,使用的是cocos2d-html5引擎,底層操作的是canvas;當運行在客戶端上時,使用的是cocos2dx引擎,底層操作的是C++,再由C++去操控openGL做繪制和渲染。提供相同的API,對開發者幾乎是透明無差異的,開發者只需要關注實現效果即可。達到一套代碼,多端運行(網頁端,客戶端)。
JSPatch是目前比較流行的iOS上的熱修復技術,JSPatch 能做到通過 JS 調用和改寫 OC 方法最根本的原因是 Objective-C 是動態語言,OC 上所有方法的調用/類的生成都通過 Objective-C Runtime 在運行時進行,我們可以通過類名/方法名反射得到相應的類和方法。JSPatch 的基本原理就是:JS 傳遞字符串給 OC,OC 通過 Runtime 接口調用和替換 OC 方法。
關鍵技術之一是 JS 和 OC 之間的消息互傳。JSPatch里包含了,一個JS引擎JavaScriptCore(Safari,React Native用的同款)。用到了 JavaScriptCore 的接口,OC 端在啟動 JSPatch 引擎時會創建一個 JSContext 實例,JSContext 是 JS 代碼的執行環境,可以給 JSContext 添加方法,JS 就可以直接調用這個方法。本質上就是通過JavaScriptCore引擎注入,暴露OC的方法供JS調用來實現動態修改OC的反射。
Demo,iOS熱更新,熱修復:
集成JavaScriptCore引擎;
通過引擎,橋接JS和OC;
通過JS修改OC反射。
詳細的JSPatch技術介紹請移步:https://github.com/bang590/JSPatch/wiki
關于JavaScript引擎:
在iOS 或 android 上能夠運行的JavaScript 引擎有4個:JavaScriptCore,SpiderMonkey,V8,Rhino。下面這個表格展示各個引擎在iOS 和 Android 的兼容性。
因為iOS平臺不支持JIT即時編譯,而V8只有JIT模式,所以V8無法在iOS平臺使用(越獄設備除外,想體驗iOS JIT的同學可以自行越獄)。
所以,目前可以做到橫跨iOS和Android雙平臺的JS引擎,只有兩款,即是SpiderMonkey和JavaScriptCore。
JavaScript引擎會受很多東西影響,比如交叉編譯器的版本、引擎的版本和操作系統的種類等。
至于如何選擇,可以參考:《Part I: How to Choose a JavaScript Engine for iOS and Android Development》
至此,JavaScript從立足于前端,到征戰全端的逆襲之路,可以總結為“攜引擎以令天下”。
不足之處,還請各位看官輕拍~
bang590/JSPatch中問參考文檔
Cocos2d-JS | Cocos2d-x官方參考文檔
Alfresco官方參考文檔
《Browser Wars: The End or Just the Beginning?》
《Part I: How to Choose a JavaScript Engine for iOS and Android Development》
《React Native 從入門到源碼》
eact Native (簡稱RN)是Facebook于2015年4月開源的跨平臺移動應用開發框架,是Facebook早先開源的UI框架 React 在原生移動應用平臺的衍生產物,目前支持iOS和安卓兩大平臺。RN使用Javascript語言,類似于HTML的JSX,以及CSS來開發移動應用,因此熟悉Web前端開發的技術人員只需很少的學習就可以進入移動應用開發領域。
React Native使你能夠在Javascript和React的基礎上獲得完全一致的開發體驗,構建世界一流的原生APP。
React Native著力于提高多平臺開發的開發效率 —— 僅需學習一次,編寫任何平臺。(Learn once, write anywhere)
Facebook已經在多項產品中使用了React Native,并且將持續地投入建設React Native。
React Native主要特性如下:
原生的iOS組件
React Native主張“Learn once, write everywhere”而非其他跨平臺工具一直宣揚的“Write once, run everywhere”。通過React Native,開發者可以使用UITabBar、UINavigationController等標準的iOS平臺組件,讓應用界面在其他平臺上亦能保持始終如一的外觀、風格。
異步執行
JavaScript應用代碼和原生平臺之間所有的操作都采用異步執行模式,原生模塊使用額外線程,開發者可以解碼主線程圖像、后臺保存至磁盤、無須顧忌UI等諸多因素直接度量文本設計布局。
觸摸處理
React Native引入了一個類似于iOS上Responder Chain響應鏈事件處理機制的響應體系,并基于此為開發者提供了諸如TouchableHighlight等更高級的組件。
需要的小伙伴可以私聊我,發送關鍵字‘RN資料’即可
017 年 1 月 9 日,微信小程序正式發布。在近一年里,不管外界評價如何,小程序一直在堅定的向前走。同時它的理念和模式受到廣泛認可,也被其它公司所模仿。
在微信小程序尚在內測之時,外界對它所采用的技術就有很多猜測,正式發布的小程序解答了人們的一些疑惑,但有些問題官方并未正式對外公開說過。在即將于 10 月 17 日舉辦的 QCon 上海 2017 大會上, 微信小程序相關項目負責人王躍將向大家分享小程序的核心架構及實戰案例,我們也對他進行了采訪,提前了解了一些我們關心的問題。
受訪嘉賓介紹
王躍(微信號:springwang),微信小程序相關項目負責人,擁有 10+ 年前端開發經驗,曾就職于搜狐和新浪,2013 年加入騰訊,負責互娛游戲營銷系統,道聚城等多個項目前端架構和開發。對小程序底層架構原理有深入的研究和理解,并且有騰訊多款小程序開發實戰經驗。
Q:王老師好,您在負責小程序前端之前,做過哪些事情?
王躍:在微信小程序項目之前,我負責過騰訊互娛游戲高級營銷系統的前端架構和開發,它承載騰訊幾百款游戲業務的日常營銷活動,另外還有騰訊道聚城前端架構和開發,覆蓋像王者榮耀,LOL,CF 游戲道具的交易,在騰訊之前我還負責過搜狐白社會 SNS 的前端核心框架和模塊開發,新浪微博的前端開發工作。
Q:當時小程序還沒發布時,坊間傳說小程序使用了類似 RN 的技術,發布后人們發現它還是運行在 WebView 里的,不知道實際情況如何?
王躍:從技術實現的層面來說,不管是小程序,還是 RN,或者 Weex,都有共同點,比如 JS 和 Native 的通訊機制,比如 JS 直接調用原生組件的渲染,如在 iOS 平臺,小程序和 RN 都采用 JavaScriptCore 來執行 JS。但是小程序和 RN 設計初衷和應對的場景不一樣,我們知道小程序的場景主要是在當前實際物理場景用戶可以即掃即用,用完即走,整個交互都是非常輕量級的,不涉及特別復雜的交互邏輯,所以在設計上考慮盡量簡單,首先是系統底層框架簡單,其次開發者開發簡單,再次用戶使用簡單,所以小程序大部分的 UI 組件還是 H5 的渲染方式,而不是像 RN 設計成 Native 的 UI 組件。
當然小程序本身為了解決部分組件性能的問題也采用了 Native 的方式,所以方案上的選項主要是基于實際場景考慮,不是純技術上的考量。
另外準確的說小程序不僅僅運行在 Webview 里,需要區分不同的部分,這個在我的分享里會有詳細的解釋。
Q:在 Android 上小程序是運行在 X5 引擎上的,X5 團隊有為小程序做一些特別的優化,或者添加特性嗎?
王躍:微信Android版的瀏覽服務用的確實是我們騰訊瀏覽器團隊提供的X5引擎,在性能方面小程序和X5團隊之間一直有保持溝通和協調,雙方都盡可能設法優化并持續提升用戶體驗。
Q:剛發布時有人發現小程序的一些代碼和 Vue 的有點像,而單向數據流又讓人聯想到 React,在當初開發小程序核心框架的時候有哪些思考?
王躍:這個跟問題 2 類似,首先小程序和 Vue,React 本質上還是不一樣的,小程序是需要特定的 Native 層支持,同時底層功能也更強大,而 Vue 和 React 運行在通用的 WebView 之上,不需要特定 Native 支持,但大家為什么覺得會有些類似呢,主要是指在數據綁定,事件綁定等部分的實現上會有一些類似,當然這幾種技術沒有好壞,主要還是看我們是解決什么場景下的什么問題。
Q:iOS 和 Android 平臺的小程序有一些區別,比如 Android 上可以把小程序圖標放到主屏,還有人發現微信小程序在 Android 下有單獨的進程,小程序是不是對 Android 進行過更多 Native 化的探索?
王躍:Android 可以放到主屏幕而 iOS 不行這個主要是 OS 層面的限制,至于 Android 下的運行方式,主要是通過單獨的 Activity 來承載視圖,設置為單獨的進程主要是為了保證小程序的運行內存,跟 Native 化沒有直接的聯系。
前面問題也提到了,小程序本身已經有好幾個組件是使用 Native 方式實現的,主要目的還是為了保證小程序的執行效率,達到更好的用戶體驗,Native 的組件也不是針對 Android 一個平臺,Android 和 iOS 都有做,后續是否會有更多的 Native 化的實現,還是看實際組件在采用 Web 實現時是否符合我們對用戶體驗的標準。
Q:前段時間有人發現小程序出了自己的腳本格式 WXS,它是小程序新的 DSL 嗎?
王躍:目前,WXS對于小程序開發不是必須的,它的主要目的是為了增強WXML的數據處理能力而新引入一種技術實現,其實際解析的語言規范還是JS,并沒有引入新的語法,僅僅對JS做了上層的封裝和限制,所以學習上基本沒什么成本,大致了解下開發文檔馬上就能上手,這里WXS跟DSL也沒太大關系,沒有可對比性。
Q:小程序和 PWA 可以說代表著移動 Web 的兩條不同的發展路線,從旁人的眼光來看,小程序更加務實,但人們也期待小程序更加開放一些。在這方面您是怎么看的?
王躍:這里我說下個人的想法,不代表官方意見,任何一種模式都是為了在特定環境下解決特定問題而設計的,所以 PWA 有它的應用場景,而小程序有小程序的應用場景,兩種模式都有其優勢和限制,這兩種模式的差異其實跟我們現在的 Web 和 Native 很像,Web 提供相對常用和通用的功能(大部分功能和基本使用體驗),而個性定制(更流程復雜的功能和交互體驗)可以充分發揮當前平臺的能力,我個人覺得這兩種模式都會一直存在,關鍵是看能否為用戶提供價值,不過,未來這兩種模式一定會有越來越多的融合,就像 web 和 Native 的融合產生了 Hybird 模式一樣,想象一下,未來一定會有一種新的模式,可以像 PWA 一樣具有更通用的運行場景(提供核心功能),同時又可以根據當前的運行環境接入定制化的高級能力,實現 Write Once,Run Anywhere 的美好愿景。
活動推薦:
Google 如何用 AI 造聊天機器人?Pinterest 如何用機器學習獲得兩億活躍用戶?10 月 QCon 上海站,還有來自 Uber、Paypal、LinkedIn、Airbnb 等頂尖技術專家前來分享前沿實踐經驗。
QCon 報名即將結束,識別下方二維碼或點擊【閱讀原文】與 100+ 國內外技術大咖零距離,如有問題歡迎聯系票務經理 Hanna ,電話:15110019061,微信:qcon-0410。
*請認真填寫需求信息,我們會在24小時內與您取得聯系。