整合營銷服務(wù)商

          電腦端+手機端+微信端=數(shù)據(jù)同步管理

          免費咨詢熱線:

          低代碼和無代碼的演進歷程、應(yīng)用范圍以及是否需要開源?

          低代碼和無代碼的演進歷程、應(yīng)用范圍以及是否需要開源?

          疫情影響下,企業(yè)信息化建設(shè)和數(shù)字化轉(zhuǎn)型的需求日益強烈,無代碼和低代碼平臺憑借“靈活、易上手”等特性,迎來了新一波的快速發(fā)展。據(jù)艾瑞相關(guān)報告顯示,2025年中國低代碼/無代碼行業(yè)規(guī)模將超過百億。

          新技術(shù)蓬勃發(fā)展的同時也會帶來許多疑問。為幫助大家消除疑惑,騰源會聯(lián)合輕享會,特別邀請輕流聯(lián)合創(chuàng)始人&CTO 李婷婷,騰訊前端技術(shù)委員會委員、低代碼 Oteam 負責(zé)人丁濤,一起聊聊低代碼和無代碼技術(shù)的演進、應(yīng)用領(lǐng)域,以及低代碼、無代碼和開源有哪些碰撞地點等內(nèi)容。

          以下為演講干貨內(nèi)容:

          低代碼和無代碼技術(shù)的演進發(fā)展

          整個軟件開發(fā)的演進路徑大致可以分為四個階段:第一代程序設(shè)計語言,就是最早的指令編程,第二代是匯編語言;第三代是現(xiàn)在常見的高級語言,比如 Python、Java 等;第四代就是低代碼和無代碼技術(shù)。低代碼、無代碼并非完全新鮮的事物,它更像是一個行業(yè)自然而然發(fā)展到一定階段而催生出來的觀念。

          從前端視角來說,技術(shù)的發(fā)展演進讓研發(fā)流程不斷簡化。最初,一個網(wǎng)頁的開發(fā)需要手寫 HTML,CSS,甚至 DOM 節(jié)點也需要去操作。“庫”的出現(xiàn),讓一些基本的DOM結(jié)構(gòu)可以直接操作。后來,“框架”幫助我們進入了開發(fā)工程化時代,出現(xiàn)了像Webpack rowup這樣公眾化打包工具,進一步縮短了研發(fā)時間。再之后就是低代碼、無代碼平臺,將一些基礎(chǔ)的代碼模塊封裝成一個個“輪子”,人們可以直接用這些輪子快速開發(fā)落地,大大提高了開發(fā)效率。

          但低代碼和無代碼技術(shù)在初期并沒有受到市場上的普遍認可。至2018年,Gartner 提出 aPaaS,低代碼/無代碼才被越來越多的人認識。2018 至 2020 年,大多數(shù)人是通過研究國外軟件來了解研究低代碼、無代碼,對于兩者之間的區(qū)別仍沒有清晰認知,且不說市場上是否分得清楚,廠商之間也還沒有形成共識。

          直至2020年,疫情為低代碼、無代碼的發(fā)展按下了加速鍵。在疫情形勢的逼迫下,企業(yè)進行線上化和數(shù)字化轉(zhuǎn)型的需求尤為迫切,但傳統(tǒng)的軟件開發(fā)從需求提出到最終落地,需要經(jīng)歷非常長的周期,而利用低代碼、無代碼工具,則能快速地完成軟件的落地和驗證,在完美滿足企業(yè)需求的同時,讓低代碼、無代碼真正能夠在數(shù)字化領(lǐng)域快速增長。


          低代碼和無代碼技術(shù)的應(yīng)用范圍

          從字面理解,低代碼和無代碼之間最大的區(qū)別在于使用代碼量的多少。這個區(qū)分點也讓低代碼和無代碼的應(yīng)用范圍有不同的偏向。

          技術(shù)側(cè)——布局方式靈活,多終端覆蓋

          低代碼主要面對的對象是專業(yè)的 IT 開發(fā)者,因此使用過程中與研發(fā)人員有比較深的互動,應(yīng)用范圍較于無代碼也更偏向技術(shù)側(cè)一些。丁濤老師 主要從布局架構(gòu)和能覆蓋的終端范圍,兩方面做了詳細的解釋。

          從UI布局架構(gòu)上來說,主要有兩種布局范圍:

          第一種是流式布局,即在低代碼的開發(fā)編排過程中,是按照一定的順序,由固定的表單組成,排列布局都較為規(guī)整,這種方式比較多的應(yīng)用在內(nèi)部管理系統(tǒng)的開發(fā)上。

          第二種布局方式是絕對定位的方式。在這種布局方式下,圖片文字或是一些垂直領(lǐng)域的業(yè)務(wù)級控件是可以自由調(diào)動的,層級上可以有覆蓋,位置也可以隨意擺放。比較多的應(yīng)用在運營活動的場景中。比如,傳統(tǒng)的 H5 營銷活動一般采用的就是這種方式。

          通過低代碼和無代碼技術(shù)開發(fā)出的系統(tǒng)軟件最終還是要部署和運行在各個終端上。從終端來說,低代碼主要覆蓋以下五類:

          • 第一類:小程序。比如微信小程序、支付寶小程序等;
          • 第二類:web,包括PC端和移動端;
          • 第三類:移動 App。包括 iOS 和安卓兩大平臺;
          • 第四類:桌面端的應(yīng)用程序,包括 Windows 和 Mac 兩個主流桌面端;
          • 第五類:邏輯編排。提供后端接口服務(wù)。

          低代碼和無代碼在技術(shù)側(cè)的應(yīng)用范圍是相對全面的,因此也更能滿足應(yīng)用者對于低代碼和無代碼在業(yè)務(wù)側(cè)的需求。

          業(yè)務(wù)側(cè)——滿足企業(yè)個性化需求,助力多角色協(xié)同開發(fā)

          提到低代碼和無代碼的業(yè)務(wù)應(yīng)用范圍,很多人會自然聯(lián)想到企業(yè)數(shù)字化轉(zhuǎn)型所需要的系統(tǒng)軟件。的確,低代碼和無代碼因為其低門檻、靈活易用的特性頗受企業(yè)管理者的歡迎。相較于低代碼,無代碼的應(yīng)用范圍更傾向于業(yè)務(wù)側(cè)。李婷婷老師,從行業(yè)和場景橫縱兩個維度介紹了無代碼的應(yīng)用范圍。

          行業(yè)作為橫向維度,就是我們平常所說的制造業(yè)、零售業(yè)、教育培訓(xùn)等垂類行業(yè);場景作為縱向維度是指不同行業(yè)中的共性場景,比如財務(wù)場景、客戶管理、生產(chǎn)管理等。

          無代碼的開放包容特性,讓它能夠跨越多行業(yè)場景,適用范圍非常廣,但它的應(yīng)用同樣需要過程。以輕流無代碼開發(fā)平臺為例,制造業(yè)是輕流最早開拓的行業(yè),通過無代碼平臺快速搭建出適配行業(yè)業(yè)務(wù)特點的系統(tǒng)軟件,為制造業(yè)企業(yè)服務(wù)。等到應(yīng)用路徑成熟之后,再慢慢將這種無代碼工具的觀念思維延伸至各個行業(yè)。在這個過程中可以發(fā)現(xiàn),不管是傳統(tǒng)制造業(yè)還是教培、新零售對于無代碼的接受度都比較高。

          從縱向場景角度來說,無代碼價值最高的地方,不在那些已經(jīng)被成熟 SaaS 覆蓋的場景,如ERP、CRM等,而在于非標(biāo)場景,比如精益生產(chǎn)、設(shè)備巡檢,這類雖然通用,但不同企業(yè),不同業(yè)務(wù)都有所區(qū)別的場景。市面上的成品 SaaS 不能滿足企業(yè)的個性化需求,但借助無代碼工具,能夠根據(jù)企業(yè)需求靈活調(diào)整,實現(xiàn)完美適配。

          無代碼技術(shù)作為 IT 技術(shù)的一種,如何更好地賦能業(yè)務(wù),讓它在實際的業(yè)務(wù)場景中發(fā)揮效用,是輕流一直在思考的一個問題。在服務(wù)客戶的過程中,輕流發(fā)現(xiàn),很多客戶在利用無代碼工具打磨開發(fā)軟件的過程中,找到了一種高效協(xié)同的方式,我們稱之為:圓桌式開發(fā)。

          傳統(tǒng)開發(fā)的一般模式是業(yè)務(wù)提需求,IT 接收需求后進行開發(fā),開發(fā)完成后交付業(yè)務(wù)。整個協(xié)作過程類似于坐在長桌兩頭的甲乙兩方,不僅開發(fā)落地的周期長,溝通成本也十分高昂。但利用無代碼工具,業(yè)務(wù)、IT、數(shù)據(jù)分析師、架構(gòu)師等多方角色可以圍坐在一張“圓桌”上,參與方都可以用一種平等互助的方式,快速溝通需求,協(xié)作產(chǎn)出成果,不僅大大提高了軟件開發(fā)的效率,也讓每一方角色更能實現(xiàn)專業(yè)價值。

          關(guān)于「圓桌式開發(fā)」等更多內(nèi)容,可以關(guān)注7月6日的無代碼探索者大會,輕流將于國際知名數(shù)據(jù)中心IDC,共同發(fā)布圓桌式開發(fā)的研究成果。(預(yù)約方式:添加輕流小助手 qingflow2018,備注“76”)


          低代碼/無代碼是否要開源?

          開源是生態(tài)協(xié)作發(fā)展的一種很好的形式,“低代碼和無代碼產(chǎn)品是否會開源”的話題,也是行業(yè)內(nèi)外很多朋友非常關(guān)注的問題。對于這個問題丁濤老師和李婷婷老師也分別從低代碼和無代碼角度,給出了自己的看法。

          低代碼——開源項目必備四大模塊

          據(jù)丁濤老師介紹,騰訊低代碼 Oteam就是公司內(nèi)部一直在合力開源的項目。并例舉了開源中必不可少的四大因素:

          首先,要有開源項目。開源項目是做開源比較核心的一點,你要有代碼,有項目才有條件去開源。對于低代碼來說,如果沒有開源代碼,那整個一塊是沒有意義的。

          第二,要有載體。不管是官網(wǎng)、公眾號還是像github這樣的托管平臺,都是開源載體。

          第三,要有開發(fā)者。主要分兩類:一類是開源的貢獻者,一個開源項目的貢獻者數(shù)量越龐大,這個項目才能發(fā)展得越好,越活躍。還有一類是用戶開發(fā)者,他們是維系、促進我們整個開源生態(tài)的繁榮和進步的關(guān)鍵。

          第四,要有關(guān)于開源,關(guān)于項目的交流社區(qū)。這個社區(qū)為開發(fā)者提供了技術(shù)上的或者是產(chǎn)品上的探討平臺。開發(fā)者可以在這里自由討論對相關(guān)技術(shù)和相關(guān)的功能能力,也可以自由組織相關(guān)的技術(shù)沙龍活動等等。

          在這四個板塊的基礎(chǔ)上,才能讓整個低代碼開源生態(tài)繁榮起來。

          無代碼——“輕代碼”拓展能力邊界

          無代碼是否要進行開源是一個比較有爭議的話題。輕流在無代碼領(lǐng)域深耕7年,在我們看來,無代碼系統(tǒng)一定不能是封閉的系統(tǒng),它更應(yīng)該與其他系統(tǒng)做好連接和交互,打通傳統(tǒng)代碼開發(fā)制造的“數(shù)據(jù)煙囪”。

          偽開源無代碼產(chǎn)品無法維護,當(dāng)廠商進行代碼更新后,會產(chǎn)生代碼一致性問題,導(dǎo)致代碼差異沖突,造成不可逆后果。但無代碼產(chǎn)品的接口能力和API能力需要重點關(guān)注,所以,在無代碼產(chǎn)品上實現(xiàn)的二次開發(fā)非常類似“插座”和“積木”,把二次開發(fā)定義的代碼塊,同API和無代碼產(chǎn)品進行交互。為此,輕流近些年一直在打磨「輕代碼」。

          輕代碼是面向開發(fā)者的板塊。在開源社區(qū)中是有很多比較好的能力拓展,這些能力拓展如果能夠直接運行在輕代碼上,就可以快速拓展無代碼平臺的能力邊界。我們希望能夠借助輕代碼,召集更多有編程能力的伙伴,將原本無代碼力所不能及的地方,用一種可插拔的方式,去拓寬無代碼邊界,實現(xiàn)更多可能。

          目前,輕流的輕代碼板塊已涵蓋了連接中心、代碼塊、自定義組件和賬號體系等模塊,幫助企業(yè)快速實現(xiàn)系統(tǒng)集成解決數(shù)據(jù)孤島問題,完成系統(tǒng)權(quán)限的自動分發(fā)與變更,提升對于復(fù)雜業(yè)務(wù)場景的處理能力。

          同時,對于業(yè)務(wù)人員來說,他不需要去關(guān)心這項能力是如何實現(xiàn)的,到底是前端代碼拓展了,還是說只是 API 提供的服務(wù),更多的是這個模塊是我所需要的,并且能夠通過插件中心,簡單操作之后就能使用它。在輕代碼的輔助下,IT人員和業(yè)務(wù)人員不需要深入了解對方的工作內(nèi)容,只需負責(zé)各自的專業(yè)板塊,在各自領(lǐng)域發(fā)揮更大的專業(yè)價值。

          近兩年,輕流無代碼平臺定向邀請了一些伙伴和開發(fā)團隊做初步的嘗試,希望在不久的未來,會有讓更多的開發(fā)者加入到無代碼開發(fā)的進程中,不斷的豐富拓展無代碼能力。


          在數(shù)字化浪潮中,低代碼和無代碼的熱度越來越高,如果你想了解更多相關(guān)干貨內(nèi)容,推薦閱讀:

          無代碼的「數(shù)據(jù)驅(qū)動」,打破傳統(tǒng)軟件開發(fā)「模型驅(qū)動」牢籠

          無代碼?低代碼?輕代碼

          低代碼包含無代碼?無代碼/低代碼的七大誤解,一次給你解釋清楚

          現(xiàn)代 Javascript 教程》是一本語言簡單易懂,對初學(xué)者友好的開源書籍。遵守知識共享非商業(yè)話的許可,有多個語言版本,包含中文版。本書知識覆蓋面廣,涉及語法、測試、DOM、瀏覽器交互、Async/await、動畫等豐富細節(jié)。

          主要包含三部分:

          • JavaScript 編程語言

          • 瀏覽器:文檔、事件和接口

          • 其他文章

          適合于從頭開始學(xué)習(xí) JavaScript的初學(xué)者,包含基礎(chǔ)知識、Objects(對象)、數(shù)據(jù)類型、對象、類和繼承等內(nèi)容,有大量的代碼練習(xí)和示例。

          開源派紅包福利

          打開支付寶首頁搜索“556850443” 立即領(lǐng)大紅包

          微信訂閱號:開源派 (opensourcepie)

          ↓點擊閱讀原文,查看下載鏈接

          年來,前端技術(shù)日新月異,前端已經(jīng)不僅僅是網(wǎng)頁,更多的開始由狹義向廣義發(fā)展。

          先后涌現(xiàn)出了具備后端能力的node,具備移動開發(fā)能力的react native,具備游戲渲染能力的cocos2d-js,以及iOS上的熱修復(fù)技術(shù)JSPatch等等新技術(shù)。

          咋一看,幾乎各個端都被JavaScript攻陷,大有一統(tǒng)江湖之勢。

          究竟,JavaScript如何做到上天入地?zé)o所不能?JavaScript真的能一統(tǒng)江湖嗎?

          亂世出英雄:JavaScript的誕生故事要從JavaScript的由來說起。

          高能瞎扯淡版,正經(jīng)臉的同學(xué)可以忽略

          有人的地方就有江湖,有江湖的地方就有紛爭。

          故事要從當(dāng)年的瀏覽器之戰(zhàn)說起。

          時間回到1994年,

          (→ 那時候我還是個寶寶~ #天真臉#)

          景兄弟橫空出世,并自帶神器網(wǎng)景導(dǎo)航,戰(zhàn)斗力爆表,勢如劈竹,瞬時間威震天下。

          一出世就武裝到牙齒,武力值這么高還自帶兵器,這個科學(xué)嗎?

          港真,我也覺得不科學(xué),也許跟熊孩子哪吒、女漢子雅典娜是一個品種吧?

          這一切北方的老前輩微軟大濕,都看在眼里,不甘天下盡歸景兄弟這個初出茅廬的毛孩子,大濕積淀多年,潛心修煉一年,終于帶著大殺器IE 1.0出關(guān)了,誓于景兄弟爭個高低。

          自此景兄弟的網(wǎng)景導(dǎo)航 VS 微軟大濕的IE 的軍備戰(zhàn)爭開始。

          景兄弟仔細掂量,微軟大濕財大氣粗,內(nèi)功深厚,臣妾實在是辦不到啊啊啊啊啊啊。

          景兄弟緊急召集門人商議對策,有一門人曰:”以我們微薄之力硬磕,是萬萬使不得的。如今我們,一是宜施行合縱之策,抱大腿,組成聯(lián)盟!二是避其鋒芒,出奇招致勝。“

          于是景兄弟依照此策略,一方面找到了當(dāng)時德高為重的另一位前輩SUN,組成了開發(fā)者聯(lián)盟。

          (微軟大濕:握草,聯(lián)盟都粗來了,那我是不是得搞個部落?)

          另一方面,景兄弟找到了鍛造大師布蘭登,請布大師幫忙升級兵器網(wǎng)景導(dǎo)航,大師就是大師,不費吹灰之力就完成了強化升級,然而布大師突發(fā)奇想,本來這是近距離攻擊兵器,要是有多一個遠距離攻擊的能力那豈不是更好?Just do it. 想罷大師就加了一個遠距離攻擊的feature。于是有了自帶遠距離攻擊能力的網(wǎng)景導(dǎo)航2.0。景兄弟一看這么流弊心里甚是歡喜,不過遠距離攻擊的技能叫做LiveScript,感覺不是特別Fashion。特然想到這不是跟SUN前輩聯(lián)盟嘛,SUN家的Java正是獨霸武林之時。不如把名字改成跟Java有關(guān),蹭一把東風(fēng),蹭點光環(huán)。一拍腦袋,JavaScript?。?!眾門人一聽:”好好好,JavaScript 流弊炫酷吊炸天!“

          果然第一節(jié)下半場,景兄弟攜強化過的網(wǎng)景導(dǎo)航2.0 戰(zhàn)個痛快,那是杠杠的!人家一問,你咋還能遠程攻擊,你這個遠程攻擊用的是啥?答曰:JavaScript。“JavaScript,一定是跟SUN家Java是一個系列產(chǎn)品,一定很流弊!”#光環(huán)加成,各種膜拜臉#

          微軟大濕虧了一場,痛定思痛,也要搞遠程攻擊功能,果然不久,就祭出了同樣帶有遠程攻擊能力的IE 3.0,鑒于景兄弟的遠程攻擊叫做JavaScript,J開頭的感覺應(yīng)該比較流弊,所以微軟大濕的叫做JScript。

          然后戰(zhàn)爭就從地面貼身肉搏戰(zhàn),開始逐步升級到了遠距離核戰(zhàn)爭。

          正所謂,城門失火,殃及池魚。這么打下去苦逼的是搬磚的頁面仔,就是我這種,到處都是雷區(qū),無處下腳。

          最后到了1997年,“聯(lián)合國安理會秘書長”艾瑪(ECMA)出來調(diào)停,多方簽署了“核不擴散條約”,約束各種遠程攻擊武器的使用,這才走上了正軌。

          1995年SUN開發(fā)了Java技術(shù),這是第一個通用軟件平臺。Java擁有跨平臺、面向?qū)ο?、泛型編程的特性,廣泛應(yīng)用于企業(yè)級Web應(yīng)用開發(fā)和移動應(yīng)用開發(fā)。Java也伴隨著互聯(lián)網(wǎng)的迅猛發(fā)展而發(fā)展,逐漸成為重要的網(wǎng)絡(luò)編程語言。名噪一時。

          1994年Netscape公司成立,并推出了自己的瀏覽器的免費版本 Netscape Navigator,很快就占有了瀏覽器市場。到了 1995 年,微軟公司開始加入,并很快發(fā)布了自己的 Internet Explorer 1.0。

          1995年,當(dāng)時在Netscape就職的Brendan Eich(布蘭登·艾克),正為Netscape Navigator 2.0瀏覽器開發(fā)的一門名為LiveScript的腳本語言,后來Netscape與Sun Microsystems組成的開發(fā)聯(lián)盟,為了讓這門語言搭上Java這個編程語言“熱詞”,將其臨時改名為“JavaScript”,日后這成為大眾對這門語言有諸多誤解的原因之一。

          JavaScript最初受Java啟發(fā)而開始設(shè)計的,目的之一就是“看上去像Java”,因此語法上有類似之處,一些名稱和命名規(guī)范也借自Java。但JavaScript的主要設(shè)計原則源自Self和Scheme。JavaScript與Java名稱上的近似,是當(dāng)時Netscape為了營銷考慮與SUN達成協(xié)議的結(jié)果。

          ==> 所以,JavaScript和Java其實沒有半毛錢關(guān)系。

          JavaScript推出后在瀏覽器上大獲成功,微軟在不久后就為Internet Explorer 3.0瀏覽器推出了JScript,以與處于市場領(lǐng)導(dǎo)地位的Netscape產(chǎn)品同臺競爭。JScript也是一種JavaScript實現(xiàn),這兩個

          JavaScript語言版本在瀏覽器端共存意味著語言標(biāo)準化的缺失,對這門語言進行標(biāo)準化被提上了日程,在1997年,由Netscape、SUN、微軟、寶藍等公司組織及個人組成的技術(shù)委員會在ECMA(歐洲計算機制造商協(xié)會)確定定義了一種名叫ECMAScript的新腳本語言標(biāo)準,規(guī)范名為ECMA-262。JavaScript成為了ECMAScript的實現(xiàn)之一。ECMA-262 第五版,即是ES5。

          ==> ECMA-262,包括ES5, ES6等是一個標(biāo)準,JavaScript是ECMAScript的一個實現(xiàn)。

          完整的JavaScript實現(xiàn)應(yīng)該包含三個部分:

          在網(wǎng)景導(dǎo)航2.0和IE 3.0出現(xiàn)之后的幾年間,網(wǎng)景和微軟公司不停的發(fā)布新版本的瀏覽器,支持更多的新功能。自此拉開了瀏覽器之戰(zhàn)的序幕。這場瀏覽器之戰(zhàn)到現(xiàn)在還在繼續(xù),以下一張圖看清楚過程。

          從瀏覽器之戰(zhàn)可以看出,各家瀏覽器比拼的大致兩個方面視覺體驗(渲染排版)和速度(腳本運行)。

          ==> 所以一個完整的瀏覽器組成,至少包含兩個部分:

          補充一個市面常見瀏覽器的內(nèi)核和JavaScript引擎搭配:

          其他JavaScript引擎,Rhino,由Mozilla基金會管理,開放源代碼,完全以Java編寫,可以看做SpiderMonkey的Java版。

          注意:webkit不單單只是一個排版引擎,webkit=排版引擎 + JavaScript引擎。

          ==> 所以,JavaScript是動態(tài)語言,它的運行都是基于JavaScript引擎,引擎大都是由靜態(tài)語言實現(xiàn)C++、Java、and so on。JavaScript的能力也是由引擎賦予。不管是瀏覽器環(huán)境中是window,亦或是node環(huán)境中的process,均是由引擎提供。

          (番外:Mozilla的人不知道為啥特別喜歡猴子,經(jīng)常以猴子命名技術(shù),所以看到帶Monkey的,十有八九估計是他們搞的。)

          諾曼底登陸:JavaScript Binding/Bridge 橋接技術(shù)

          在瀏覽器環(huán)境中,DOM、BOM、window對象、setTimeout/setInterval,alert,console等方法均不是JavaScript自身具備的能力,而是瀏覽器native實現(xiàn),然后通過JavaScript引擎注入到JS運行的全局上下文中,供JS使用。

          鑒別方式,在調(diào)試器console中打出來,帶有[native code]的即是:

          講道理:

          1. JavaScript運行 → 依賴于JavaScript引擎 ← 瀏覽器集成了JavaScript引擎,同時通過JavaScript引擎注入native代碼工JS腳本使用

          2. 發(fā)散一下思維,只要有JavaScript引擎,就能運行JS腳本,不管有沒有瀏覽器!只是缺少瀏覽器提供的alert,window等方法。

          3. 既然瀏覽器可以往JavaScript引擎中注入代碼,賦予JS腳本在網(wǎng)頁中特殊的能力,同理我們可以自己集成JavaScript引擎,自己定義自己的方法往JavaScript引擎中注入,賦予JS更多更強的自定義能力!

            注入的關(guān)鍵是:值類型相互對應(yīng),Obj映射class的一個實例,function映射一個句柄或者引用

          JavaScript數(shù)值型中的坑

          JavaScript內(nèi)部,所有數(shù)字都是以64位浮點數(shù)形式儲存,即使整數(shù)也是如此

          這就是說,在JavaScript語言的底層,根本沒有整數(shù),所有數(shù)字都是小數(shù)(64位浮點數(shù))。容易造成混淆的是,某些運算只有整數(shù)才能完成,此時JavaScript會自動把64位浮點數(shù),轉(zhuǎn)成32位整數(shù),然后再進行運算。由于浮點數(shù)不是精確的值,所以涉及小數(shù)的比較和運算要特別小心。盡量避免使用JavaScript做精準計算和密集計算。

          根據(jù)國際標(biāo)準IEEE 754,JavaScript浮點數(shù)的64個二進制位,從最左邊開始,是這樣組成的。

          • 第1位:符號位,0表示正數(shù),1表示負數(shù)

          • 第2位到第12位:儲存指數(shù)部分

          • 第13位到第64位:儲存小數(shù)部分(即有效數(shù)字)

            符號位決定了一個數(shù)的正負,指數(shù)部分決定了數(shù)值的大小,小數(shù)部分決定了數(shù)值的精度。

            IEEE 754規(guī)定,有效數(shù)字第一位默認總是1,不保存在64位浮點數(shù)之中。也就是說,有效數(shù)字總是1.xx…xx的形式,其中xx..xx的部分保存在64位浮點數(shù)之中,最長可能為52位。因此,JavaScript提供的有效數(shù)字最長為53個二進制位(64位浮點的后52位+有效數(shù)字第一位的1)。

          內(nèi)部表現(xiàn)公式:(-1)^符號位 1.xx…xx 2^指數(shù)位

          精度最多只能到53個二進制位,這意味著,絕對值小于2的53次方的整數(shù),即-(253-1)到253-1,都可以精確表示。

          而大部分的后端語言,C++、Java、Python等的long型都是可以支持到64位,因此long型數(shù)據(jù)從后端語言傳給JavaScript會發(fā)生低位截斷。遇到這種情況一般使用String處理,如需要在JavaScript中做long型計算,需要自行實現(xiàn)計算器。

          有了自行往JavaScript引擎中注入的想法,接下來就是分析可行性。

          大部分是JavaScript引擎是使用C++編寫,如果自己的程序使用的是C++可以很方便的進行注入,如果是OC,可以使用OC和C++混編的形式。

          其他語言怎么破?

          要在一門靜態(tài)語言上與動態(tài)語言JavaScript相互調(diào)用,最便捷的方式是找到一個這門語言實現(xiàn)的JavaScript引擎(開源),直接進行集成,注入。如果沒有,則需要使用多一層橋接,把這門語言的接口暴露給C++,再由C++實現(xiàn)的JavaScript引擎將接口注入供JavaScript使用。

          服務(wù)端集成思路&實踐:

          nodeJS中的橋接

          我們都知道nodeJS,但是nodeJS的運行依賴于Google的V8 引擎,V8是C++實現(xiàn),底層使用C++實現(xiàn)底層功能,比如網(wǎng)絡(luò),數(shù)據(jù)庫IO,對外暴露一個構(gòu)造器接口注入到上下文中,注意此處暴露的只是一個構(gòu)造器接口而不是一個創(chuàng)建完的實例。然后實現(xiàn)了一個require的hook函數(shù)。當(dāng)使用require加載一個JS模塊時,跟網(wǎng)頁中使用AMD 的require并無異樣,當(dāng)使用require加載系統(tǒng)庫,既是C++的模塊時,會調(diào)用暴露出來的構(gòu)造器接口,得到一個實例對象。不管是裝載JS模塊還是裝載C++模塊,得到的都可以看做是一個Module Object,node會將裝載完的模塊緩存到binding_cache中,下次在別處的代碼中使用require裝載模塊時,就會先去binding_cache中查找,如果找到了則返回該module object,如果沒找到再執(zhí)行上面的裝載流程。

          這就是node的基本原理:C++封裝底層操作,通過V8注入,使得JS腳本有網(wǎng)絡(luò)和IO能力

          基于Spring的橋接

          以上說到的幾個都是C++層面的應(yīng)用,那么經(jīng)典的Java怎么玩?是不是Java就必須是靜態(tài)語言的玩法,沒有辦法像C++之類的,可以使用JS的動態(tài)特性?

          當(dāng)然不是。這個時候,我們需要說起前面介紹過的一個JS引擎 Rhino,Rhino是完全由Java編寫,可想而知,Rhino幾乎就是為Java應(yīng)用而生的。

          用法是這樣:

          1. 首先在我們的Java應(yīng)用中集成Rhino;

          2. 所有的IO操作,網(wǎng)絡(luò)操作等,都封裝成service,并提供增刪改查,setter && getter等多種方法

          3. 通過spring,把這些service bean注入到Rhino中;

          4. 把業(yè)務(wù)邏輯寫到JS代碼中,JS代碼調(diào)用多個已注入的Java service處理業(yè)務(wù)邏輯,拼裝數(shù)據(jù)返回!

          好處:修改業(yè)務(wù)邏輯不需要修改Java代碼,也就是不需要重新編譯和部署,只需要刷新下跑在Rhino中的JS代碼即可。以往Java應(yīng)用的一個痛點是部署,需要重新編譯,打包,部署重啟服務(wù)器,現(xiàn)在以這種形式開發(fā),可以達到服務(wù)端的熱更新和熱部署。既可以享有Java服務(wù)的穩(wěn)定性和可靠性,又可以享有JS的靈活性。

          這種技術(shù)和用法在差不多十年前就有過,前EMC的工程師基于EMC著名的商業(yè)產(chǎn)品Documentum,設(shè)計了一套Java開源的中小企業(yè)CMS系統(tǒng)Alfresco,在該系統(tǒng)中實現(xiàn)了這種技術(shù),這種技術(shù)基于spring,叫做spring-surf,做了一個膠水層??梢钥醋鲂∈昵暗膎ode吧。

          Demo,使用spring-surf框架的系統(tǒng)中一個webscript模塊

          1. categorynode.get.xml定義URL攔截器和權(quán)限控制;

          2. .get指明是處理GET請求,RESTful;

          3. 在categorynode.get.js中調(diào)用已注入的Java Bean處理業(yè)務(wù)邏輯;

          4. 若為網(wǎng)頁請求返回.html.ftl,若為Ajax,返回.json.ftl;

          (此處配套使用的是FreeMarker模板引擎)

          ==> categorynode.get.desc.xml

          ==> categorynode.get.js

          ==> categorynode.get.html.ftl

          ==> categorynode.get.json.ftl

          移動端集成思路&實踐:

          React Native中的橋接

          React Native目前也是異常火爆,RN程序的運行依賴于Facebook的RN框架。在iOS、Android的模擬器或是真機上,React Native使用的是JavaScriptCore引擎,也就是Safari所使用的JavaScript引擎。但是在iOS上JavaScriptCore并沒有使用即時編譯技術(shù)(JIT),因為在iOS中應(yīng)用無權(quán)擁有可寫可執(zhí)行的內(nèi)存頁(因而無法動態(tài)生成代碼),在安卓上,理論上是可以使用的。JavaScriptCore引擎也是使用C++編寫,在iOS和安卓中,JavaScriptCore都做了一層封裝,可以無須關(guān)心引擎和系統(tǒng)橋接的那一層。iOS/Android系統(tǒng)通過JavaScriptCore引擎將定制好的各種原生組件注入,如:listview,text等。

          Cocos2d-JS中的橋接

          cocos2dx是游戲開發(fā)中非常常用的游戲渲染引擎,有一系列的產(chǎn)品,如:cocos2dx(C++),cocos2d-lua(lua), cocos2d-js(JavaScript)等多個產(chǎn)品。其中最新退出的是cocos2dx的JS版本的cocos2d-js,編寫游戲渲染特效代碼相比于C++和lua非常方便。對于做需要經(jīng)常更新的渲染場景,C++是靜態(tài)語言,每次修改都需要重新編譯才能運行,顯然是不合適的。自然也就想到了腳本語言,lua和js,兩者有些類似,都是動態(tài)語言,只需要集成一個運行引擎,提供一個運行的容器即可運行,同時通過引擎注入底層方法供腳本調(diào)用即可。lua好處是精簡,語法精簡,引擎頁很小很精簡,所以不可避免的代碼量會比js多,同時學(xué)習(xí)成本比較高。js的好處是有ECMAScrtpt的核心,語法比較豐富,同時有支持一些高級屬性。在cocos2d-js中,cocos2dx(C++)集成了SpiderMonkey(C++)作為JS運行引擎,中間做了一個膠水層既是JS Binding,通過引擎注入了一個cc的全局對象,映射的是底層C++的一個單例C++實例。表面上寫的是JS代碼,實際上操作的是底層的C++。cocos2d-js是代碼可以運行在多種環(huán)境中,當(dāng)運行的網(wǎng)頁環(huán)境中時,使用的是cocos2d-html5引擎,底層操作的是canvas;當(dāng)運行在客戶端上時,使用的是cocos2dx引擎,底層操作的是C++,再由C++去操控openGL做繪制和渲染。提供相同的API,對開發(fā)者幾乎是透明無差異的,開發(fā)者只需要關(guān)注實現(xiàn)效果即可。達到一套代碼,多端運行(網(wǎng)頁端,客戶端)。

          JSPatch技術(shù)中的橋接

          JSPatch是目前比較流行的iOS上的熱修復(fù)技術(shù),JSPatch 能做到通過 JS 調(diào)用和改寫 OC 方法最根本的原因是 Objective-C 是動態(tài)語言,OC 上所有方法的調(diào)用/類的生成都通過 Objective-C Runtime 在運行時進行,我們可以通過類名/方法名反射得到相應(yīng)的類和方法。JSPatch 的基本原理就是:JS 傳遞字符串給 OC,OC 通過 Runtime 接口調(diào)用和替換 OC 方法。

          關(guān)鍵技術(shù)之一是 JS 和 OC 之間的消息互傳。JSPatch里包含了,一個JS引擎JavaScriptCore(Safari,React Native用的同款)。用到了 JavaScriptCore 的接口,OC 端在啟動 JSPatch 引擎時會創(chuàng)建一個 JSContext 實例,JSContext 是 JS 代碼的執(zhí)行環(huán)境,可以給 JSContext 添加方法,JS 就可以直接調(diào)用這個方法。本質(zhì)上就是通過JavaScriptCore引擎注入,暴露OC的方法供JS調(diào)用來實現(xiàn)動態(tài)修改OC的反射。

          Demo,iOS熱更新,熱修復(fù):

          1. 集成JavaScriptCore引擎;

          2. 通過引擎,橋接JS和OC;

          3. 通過JS修改OC反射。

          詳細的JSPatch技術(shù)介紹請移步:https://github.com/bang590/JSPatch/wiki

          關(guān)于JavaScript引擎:

          在iOS 或 android 上能夠運行的JavaScript 引擎有4個:JavaScriptCore,SpiderMonkey,V8,Rhino。下面這個表格展示各個引擎在iOS 和 Android 的兼容性。

          因為iOS平臺不支持JIT即時編譯,而V8只有JIT模式,所以V8無法在iOS平臺使用(越獄設(shè)備除外,想體驗iOS JIT的同學(xué)可以自行越獄)。

          所以,目前可以做到橫跨iOS和Android雙平臺的JS引擎,只有兩款,即是SpiderMonkey和JavaScriptCore。

          JavaScript引擎會受很多東西影響,比如交叉編譯器的版本、引擎的版本和操作系統(tǒng)的種類等。

          至于如何選擇,可以參考:《Part I: How to Choose a JavaScript Engine for iOS and Android Development》

          至此,JavaScript從立足于前端,到征戰(zhàn)全端的逆襲之路,可以總結(jié)為“攜引擎以令天下”。

          不足之處,還請各位看官輕拍~

          參考文章:

          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 從入門到源碼》


          主站蜘蛛池模板: 国产伦理一区二区| 日韩精品福利视频一区二区三区| 极品少妇一区二区三区四区| 内射少妇一区27P| 免费无码一区二区| 国产在线精品一区二区在线看 | 色欲AV蜜桃一区二区三| 日本道免费精品一区二区| 丰满人妻一区二区三区免费视频| 国产综合无码一区二区辣椒| 国产亚洲一区二区三区在线| 亚洲中文字幕久久久一区| 九九无码人妻一区二区三区| 成人久久精品一区二区三区| 亚洲乱码国产一区网址| 中文字幕一区二区三区在线观看| 波多野结衣电影区一区二区三区 | 国产精品成人一区无码| 国产精品亚洲产品一区二区三区| 99久久精品国产高清一区二区| 国产在线一区二区三区| 成人免费观看一区二区| 国产一区二区三区日韩精品| 久久精品国产一区| 精品国产一区二区三区在线| 亚洲AV综合色区无码一区| 无码国产精品久久一区免费| 精品无码综合一区| 在线视频一区二区日韩国产| 人妻少妇AV无码一区二区| 免费精品一区二区三区在线观看| 精品国产亚洲一区二区在线观看 | 91一区二区在线观看精品| 国产精品成人99一区无码| 农村人乱弄一区二区| 国产91精品一区| 无码精品人妻一区二区三区AV| 亚洲日韩一区二区一无码| 国产成人一区二区三区视频免费| 波霸影院一区二区| 国产精品电影一区二区三区|