產品經理的技術腦：html是什么意思？

文本標記語言（HTML）是用于在 Internet 上顯示 Web 頁面的主要標記語言。換句話說，網頁由 HTML 組成，用于通過 Web 瀏覽器顯示文本，圖像或其他資源。

使用標記來描述文檔結構和表現形式并通過瀏覽器進行解析,然后把結果顯示在網頁上. 它是網頁構成的基礎,你見到的所有網頁都離不開HTML,所以學習HTML是基礎中的基礎。

什么是HTML？

HTML是用來制作網頁的標記語言

HTML是Hypertext MarkupLanguage的英文縮寫, 即超文本標記語言

HTML語言是一種標記語言,不需要編譯,直接由瀏 HTML語言是一種標記語言,不需要編譯,直接由瀏覽器執行

HTML文件是一個文本文件,包含了一些HTML元素, HTML文件是一個文本文件,包含了一些HTML元素,標簽等.

HTML文件必須使用html或htm為文件名后綴

HTML是大小寫不敏感的,HTML與html是一樣的

Html和CSS的關系

學習web前端開發基礎技術需要掌握：HTML、CSS、JavaScript語言。下面我們就來了解下這三門技術都是用來實現什么的：

1. HTML是網頁內容的載體。內容就是網頁制作者放在頁面上想要讓用戶瀏覽的信息，可以包含文字、圖片、視頻等。

2. CSS樣式是表現(外觀控制)。就像網頁的外衣。比如，標題字體、顏色變化，或為標題加入背景圖片、邊框等。所有這些用來改變內容外觀的東西稱之為表現。

3. JavaScript是用來實現網頁上的特效效果。如：鼠標滑過彈出下拉菜單。或鼠標滑過表格的背景顏色改變。還有焦點新聞（新聞圖片）的輪換。可以這么理解，有動畫的，有交互的一般都是用JavaScript來實現的。

HTML形象案例理解

為了簡化對復雜Internet的理解，暫時把復雜的Internet抽象成：向女生宿舍發送信號。

為了能夠在斷網后繼續聯絡女神，我們買來了電池和開關，然后拉了普通電線線到女神的寢室。女神把小燈泡接在了電線的兩端。

這時只需要開閉開關，就可以控制女神屋里的燈泡了。

發送信號

關閉著小燈泡1秒鐘，代表發送一個0。

打開了小燈泡1秒鐘，代表發送一個1。

此時可以向女神發送任意二進制內容了。

發送文本

我們只希望發送一個“Good Night”。所以必須想辦法對“Good Night”進行編碼。

'G','o','o','d'的ASCII編碼是：071，111，111，100，轉換成二進制就是：0100 0001 0110 1111 0110 1111 0110 0100

使用發送二進制信號的方法發過去，女神需要自己解碼來閱讀出“Good”。

發送富文本

有一天，我們希望發送“I miss you”。

為了表達心意，你希望加粗“you”，并使用紅色的字體發送“miss”，而這一根簡陋的電線似乎很難理解“加粗”和“紅色”

于是機智的我們發送了：I <red>miss</red> <b>you</b>

同樣機智的女神理解了這件事情。

你發明了一種語言

我們很喜歡這種編碼格式，這是一種標記語言，于是我們稱其為：TGML （To Girl Markup Language）

平時你使用TGML來和你的女神通信，TGML可以非常好的解決富文本的傳輸問題。

表白

終于決定表白了，我們繪制了很美麗的心形圖片，還有兩個按鈕：接受、拒絕。

兩個按鈕分別會鏈接到 "接受.tgml"和"拒絕.tgml"

為了描述圖片，我們使用了<img src="pic">

為了描述按鈕，我們使用了<a href="接受.tgml">

現在發送給女神的內容，已經不只是帶格式的富文本，而是帶鏈接的富文本。

于是在這個世界上，擁有了一種能夠描述超文本的語言，叫做TGML

超文本

描述超文本的方式有很多，例如：HTML，TGML，還有markdown。HTML的誕生是為了描述超文本。

超文本的用途也很多，例如：描述一個網頁，或者描述一個Word文檔。HTML文件是超文本文件。但是超文本未必是HTML。

Microsoft Word

Microsoft Word是Office的一個組件。它同樣代表一個超文本資源。

如果你解壓一個docx文件并仔細翻一翻，你能找到你剛才寫的作業，是以HTML方式記載著。

當然，描述超文本還有markdown。所以你可以使用一些工具，比如pandoc，把markdown轉換成word。

故事的結局

女神的名字叫瀏覽器，我們的名字叫Web服務器，女神和我們中間的那根線叫HTTP。

在前面

今年國慶假期終于可以憋在家里了不用出門了，不用出去看后腦了，真的是一種享受。這么好的光陰怎么浪費，睡覺、吃飯、打豆豆這怎么可能（耍多了也煩），完全不符合我們程序員的作風，趕緊起來把文章寫完。

這篇文章比較基礎，在國慶期間的業余時間寫的，這幾天又完善了下，力求把更多的前端所涉及到的關于文件上傳的各種場景和應用都涵蓋了,若有疏漏和問題還請留言斧正和補充。

自測讀不讀

以下是本文所涉及到的知識點，break or continue ?

文件上傳原理
最原始的文件上傳
使用 koa2 作為服務端寫一個文件上傳接口
單文件上傳和上傳進度
多文件上傳和上傳進度
拖拽上傳
剪貼板上傳
大文件上傳之分片上傳
大文件上傳之斷點續傳
node 端文件上傳

原理概述

原理很簡單，就是根據 http 協議的規范和定義，完成請求消息體的封裝和消息體的解析，然后將二進制內容保存到文件。

我們都知道如果要上傳一個文件，需要把 form 標簽的enctype設置為multipart/form-data,同時method必須為post方法。

那么multipart/form-data表示什么呢？

multipart互聯網上的混合資源，就是資源由多種元素組成，form-data表示可以使用HTML Forms 和 POST 方法上傳文件，具體的定義可以參考RFC 7578。

multipart/form-data 結構

看下 http 請求的消息體

請求頭：

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryDCntfiXcSkPhS4PN 表示本次請求要上傳文件，其中boundary表示分隔符，如果要上傳多個表單項，就要使用boundary分割，每個表單項由———XXX開始，以———XXX結尾。

消息體- Form Data 部分

每一個表單項又由Content-Type和Content-Disposition組成。

Content-Disposition: form-data 為固定值，表示一個表單元素，name 表示表單元素的名稱，回車換行后面就是name的值，如果是上傳文件就是文件的二進制內容。

Content-Type：表示當前的內容的 MIME 類型，是圖片還是文本還是二進制數據。

解析

客戶端發送請求到服務器后，服務器會收到請求的消息體，然后對消息體進行解析，解析出哪是普通表單哪些是附件。

可能大家馬上能想到通過正則或者字符串處理分割出內容，不過這樣是行不通的，二進制buffer轉化為string,對字符串進行截取后，其索引和字符串是不一致的，所以結果就不會正確，除非上傳的就是字符串。

不過一般情況下不需要自行解析，目前已經有很成熟的三方庫可以使用。

至于如何解析，這個也會占用很大篇幅，后面的文章在詳細說。

最原始的文件上傳

使用 form 表單上傳文件

在 ie時代，如果實現一個無刷新的文件上傳那可是費老勁了，大部分都是用 iframe 來實現局部刷新或者使用 flash 插件來搞定，在那個時代 ie 就是最好用的瀏覽器（別無選擇）。

DEMO

這種方式上傳文件，不需要 js ，而且沒有兼容問題，所有瀏覽器都支持，就是體驗很差，導致頁面刷新，頁面其他數據丟失。

HTML

 <form method="post" action="http://localhost:8100" enctype="multipart/form-data">

        選擇文件:
            <input type="file" name="f1"/> input 必須設置 name 屬性，否則數據無法發送<br/>
<br/>
            標題：<input type="text" name="title"/><br/><br/><br/>

        <button type="submit" id="btn-0">上 傳</button>

</form>

復制代碼

文件上傳接口

服務端文件的保存基于現有的庫koa-body結合 koa2實現服務端文件的保存和數據的返回。

在項目開發中，文件上傳本身和業務無關，代碼基本上都可通用。

在這里我們使用koa-body庫來實現解析和文件的保存。

koa-body 會自動保存文件到系統臨時目錄下，也可以指定保存的文件路徑。

然后在后續中間件內得到已保存的文件的信息，再做二次處理。

ctx.request.files.f1 得到文件信息，f1為input file 標簽的 name
獲得文件的擴展名，重命名文件

NODE

/**
 * 服務入口
 */
var http = require('http');
var koaStatic = require('koa-static');
var path = require('path');
var koaBody = require('koa-body');//文件保存庫
var fs = require('fs');
var Koa = require('koa2');

var app = new Koa();
var port = process.env.PORT || '8100';

var uploadHost= `http://localhost:${port}/uploads/`;

app.use(koaBody({
    formidable: {
        //設置文件的默認保存目錄，不設置則保存在系統臨時目錄下  os
        uploadDir: path.resolve(__dirname, '../static/uploads')
    },
    multipart: true // 開啟文件上傳，默認是關閉
}));

//開啟靜態文件訪問
app.use(koaStatic(
    path.resolve(__dirname, '../static') 
));

//文件二次處理，修改名稱
app.use((ctx) => {
    var file = ctx.request.files.f1;//得道文件對象
    var path = file.path;
    var fname = file.name;//原文件名稱
    var nextPath = path+fname;
    if(file.size>0 && path){
        //得到擴展名
        var extArr = fname.split('.');
        var ext = extArr[extArr.length-1];
        var nextPath = path+'.'+ext;
        //重命名文件
        fs.renameSync(path, nextPath);
    }
    //以 json 形式輸出上傳文件地址
    ctx.body = `{
        "fileUrl":"${uploadHost}${nextPath.slice(nextPath.lastIndexOf('/')+1)}"
    }`;
});

/**
 * http server
 */
var server = http.createServer(app.callback());
server.listen(port);
console.log('demo1 server start ......   ');
復制代碼

CODE

https://github.com/Bigerfe/fe-learn-code/

年來，前端技術日新月異，前端已經不僅僅是網頁，更多的開始由狹義向廣義發展。

先后涌現出了具備后端能力的node，具備移動開發能力的react native，具備游戲渲染能力的cocos2d-js，以及iOS上的熱修復技術JSPatch等等新技術。

咋一看，幾乎各個端都被JavaScript攻陷，大有一統江湖之勢。

究竟，JavaScript如何做到上天入地無所不能？JavaScript真的能一統江湖嗎？

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

高能瞎扯淡版，正經臉的同學可以忽略
有人的地方就有江湖，有江湖的地方就有紛爭。
故事要從當年的瀏覽器之戰說起。
時間回到1994年，
（→ 那時候我還是個寶寶~ #天真臉#）
景兄弟橫空出世，并自帶神器網景導航，戰斗力爆表，勢如劈竹，瞬時間威震天下。
一出世就武裝到牙齒，武力值這么高還自帶兵器，這個科學嗎？
港真，我也覺得不科學，也許跟熊孩子哪吒、女漢子雅典娜是一個品種吧？
這一切北方的老前輩微軟大濕，都看在眼里，不甘天下盡歸景兄弟這個初出茅廬的毛孩子，大濕積淀多年，潛心修煉一年，終于帶著大殺器IE 1.0出關了，誓于景兄弟爭個高低。
自此景兄弟的網景導航 VS 微軟大濕的IE 的軍備戰爭開始。
景兄弟仔細掂量，微軟大濕財大氣粗，內功深厚，臣妾實在是辦不到啊啊啊啊啊啊。
景兄弟緊急召集門人商議對策，有一門人曰：”以我們微薄之力硬磕，是萬萬使不得的。如今我們，一是宜施行合縱之策，抱大腿，組成聯盟！二是避其鋒芒，出奇招致勝。“
于是景兄弟依照此策略，一方面找到了當時德高為重的另一位前輩SUN，組成了開發者聯盟。
（微軟大濕：握草，聯盟都粗來了，那我是不是得搞個部落？）
另一方面，景兄弟找到了鍛造大師布蘭登，請布大師幫忙升級兵器網景導航，大師就是大師，不費吹灰之力就完成了強化升級，然而布大師突發奇想，本來這是近距離攻擊兵器，要是有多一個遠距離攻擊的能力那豈不是更好？Just do it. 想罷大師就加了一個遠距離攻擊的feature。于是有了自帶遠距離攻擊能力的網景導航2.0。景兄弟一看這么流弊心里甚是歡喜，不過遠距離攻擊的技能叫做LiveScript，感覺不是特別Fashion。特然想到這不是跟SUN前輩聯盟嘛，SUN家的Java正是獨霸武林之時。不如把名字改成跟Java有關，蹭一把東風，蹭點光環。一拍腦袋，JavaScript！！！眾門人一聽：”好好好，JavaScript 流弊炫酷吊炸天！“
果然第一節下半場，景兄弟攜強化過的網景導航2.0 戰個痛快，那是杠杠的！人家一問，你咋還能遠程攻擊，你這個遠程攻擊用的是啥？答曰：JavaScript。“JavaScript，一定是跟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的，十有八九估計是他們搞的。）

諾曼底登陸：JavaScript Binding/Bridge 橋接技術

在瀏覽器環境中，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數值型中的坑

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，但是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能力

基于Spring的橋接

以上說到的幾個都是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，做了一個膠水層。可以看做小十年前的node吧。

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中的橋接

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等。

Cocos2d-JS中的橋接

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技術中的橋接

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

在線咨詢

上一篇：HTML5 代碼要怎樣憑“魅力”吸引搜索引擎的注意？
下一篇：HTML表單標簽詳解：如何用HTML標簽打造互動網頁？

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商