JavaScript 是個(gè)靈活的腳本語(yǔ)言，能方便的處理業(yè)務(wù)邏輯。當(dāng)需要傳輸通信時(shí)，我們大多選擇 JSON 或 XML 格式。

但在數(shù)據(jù)長(zhǎng)度非?？量痰那闆r下，文本協(xié)議的效率就非常低了，這時(shí)不得不使用二進(jìn)制格式。

去年的今天，在折騰一個(gè) 前后端結(jié)合的 WAF 時(shí)，就遇到了這個(gè)麻煩。

因?yàn)榍岸四_本需要采集不少數(shù)據(jù)，而最終是隱寫(xiě)在某個(gè) cookie 里的，因此可用的長(zhǎng)度非常有限，只有幾十個(gè)字節(jié)。

如果不假思索就用 JSON 的話，光一個(gè)標(biāo)記字段 {"enableXX": true} 就占去了一半長(zhǎng)度。然而在二進(jìn)制里，標(biāo)記 true 或 false 不過(guò)是 1 個(gè)比特的事，可以節(jié)省上百倍的空間。

同時(shí)，數(shù)據(jù)還要經(jīng)過(guò)校驗(yàn)、加密等環(huán)節(jié)，只有使用二進(jìn)制格式，才能方便的調(diào)用這些算法。

優(yōu)雅實(shí)現(xiàn)

不過(guò)，JavaScript 并不支持二進(jìn)制。

這里的「不支持」不是說(shuō)「無(wú)法實(shí)現(xiàn)」，而是無(wú)法「優(yōu)雅實(shí)現(xiàn)」。語(yǔ)言的發(fā)明，就是用來(lái)優(yōu)雅解決問(wèn)題的。即使沒(méi)有語(yǔ)言，人類(lèi)也可以用機(jī)器指令來(lái)編寫(xiě)程序。

如果非要用 JavaScript 操作二進(jìn)制，最終就類(lèi)似這樣：

var flags = +enableXX1 << 16 | +enableXX2 << 15 | ...

雖然能實(shí)現(xiàn)，但很丑陋。各種硬編碼、各種位運(yùn)算。

然而，對(duì)于先天支持二進(jìn)制的語(yǔ)言，看起來(lái)就十分優(yōu)雅：


union { 
    struct { 
        int enableXX1: 1; 
        int enableXX2: 1; 
        ... 
    }; 
    int16_t value; 
} flags; 
 
flags.enableXX1 = enableXX1; 
flags.enableXX2 = enableXX2; 

開(kāi)發(fā)者只需定義一個(gè)描述即可。使用時(shí)，字段偏移多少、如何讀寫(xiě)，這些細(xì)節(jié)完全不用關(guān)心。

為了能達(dá)到類(lèi)似效果，起先封裝了一個(gè) JS 版的結(jié)構(gòu)體：


// 最初方案：封裝一個(gè) JS 結(jié)構(gòu)體 
var s = new Struct([ 
    {name: 'month', bit: 4, signed: false}, 
    ... 
]); 
s.set('month', 12); 
s.get('month'); 

將細(xì)節(jié)進(jìn)行了隱藏，看起來(lái)就優(yōu)雅多了。

優(yōu)雅但不***

但是，這總感覺(jué)不是最***的。結(jié)構(gòu)體這種東西，本該由語(yǔ)言提供，如今卻要用額外的代碼實(shí)現(xiàn)，而且還是在運(yùn)行期間。

另外，后端解碼是用 C 實(shí)現(xiàn)的，所以得維護(hù)兩套代碼。一旦數(shù)據(jù)結(jié)構(gòu)或者算法變了，得同時(shí)更新 JS 和 C，很麻煩。

于是琢磨，能否共用一套 C 代碼，同時(shí)用于前端和后端？

也就是說(shuō)，需要能將 C 編譯成 JS 來(lái)運(yùn)行。

認(rèn)識(shí) emscripten

能將 C 編譯成 JS 的工具有不少，最專(zhuān)業(yè)的要數(shù) emscripten。

emscripten 的使用方式很簡(jiǎn)單，和傳統(tǒng) C 編譯器差不多，只不過(guò)生成的是 JS 代碼。

./emcc hello.c -o hello.html 
// hello.c 
#include <stdio.h> 
#include <time.h>  
 
int main() { 
    time_t now; 
    time(&now); 
    printf("Hello World: %s", ctime(&now)); return 0; 
} 

編譯之后即可運(yùn)行：

很有趣吧~ 大家可以嘗試下，這里就不多介紹了。

實(shí)用缺陷

然而我們關(guān)心的不是有趣，而是實(shí)用。

事實(shí)上，即使一個(gè) Hello World 編譯出來(lái)的 JS 也過(guò)萬(wàn)行，多達(dá)數(shù)百 KB。就算壓縮再 GZIP，仍有幾十 KB。

同時(shí) emscripten 使用了 asm.js 規(guī)范，內(nèi)存訪問(wèn)是通過(guò) TypedArray 實(shí)現(xiàn)的。

這意味著 IE10 以下的用戶(hù)都無(wú)法運(yùn)行。這也是不可接受的。

因此，我們得做如下改進(jìn)：

• 減少體積

• 增加兼容

首先寄托 emscripten 本身，看看能不能通過(guò)設(shè)置參數(shù)，來(lái)達(dá)到我們的目的。

不過(guò)一番嘗試之后，并沒(méi)有成功。那只能自己動(dòng)手實(shí)現(xiàn)了。

減少體積

為什么最終腳本會(huì)那么大，里面都放了些什么？分析了下內(nèi)容，大致有這幾個(gè)部分：

• 輔助功能

• 接口模擬

• 初始化操作

• 運(yùn)行時(shí)函數(shù)

• 程序邏輯

輔助功能

比如字符串和二進(jìn)制轉(zhuǎn)換、提供回調(diào)包裝等。這些基本都是用不著的，我們可以給自己寫(xiě)個(gè)特殊的回調(diào)函數(shù)。

接口模擬

提供文件、終端、網(wǎng)絡(luò)、渲染等接口。之前見(jiàn)過(guò)用 emscripten 移植的客戶(hù)端游戲，看來(lái)模擬了不少接口。

初始化操作

全局內(nèi)存、運(yùn)行時(shí)、各種模塊的初始化。

運(yùn)行時(shí)函數(shù)

純粹的 C 只能做簡(jiǎn)單的計(jì)算，很多功能都依靠運(yùn)行時(shí)函數(shù)。

不過(guò)，有些常用的函數(shù)，其背后的實(shí)現(xiàn)是及其復(fù)雜的。例如 malloc 和 free，對(duì)應(yīng)的 JS 有近 2000 行！

程序邏輯

這才是 C 程序真正對(duì)應(yīng)的 JS 代碼。因?yàn)榫幾g時(shí)經(jīng)過(guò) LLVM 的優(yōu)化，邏輯可能變得面目全非了。

這部分代碼量不大，是我們真正想要的。

事實(shí)上，如果程序沒(méi)有用到一些特殊功能的話，把邏輯函數(shù)單獨(dú)摳出來(lái)，仍然是可以運(yùn)行的！

考慮到我們的 C 程序非常簡(jiǎn)單，所以簡(jiǎn)單粗暴的提取出來(lái)，也是沒(méi)問(wèn)題的。

C 程序?qū)?yīng)的 JS 邏輯位于 // EMSCRIPTEN_START_FUNCS 和 // EMSCRIPTEN_END_FUNCS 之間。過(guò)濾掉運(yùn)行時(shí)函數(shù)，剩下的就是 100% 的邏輯代碼了。

增加兼容

接著解決內(nèi)存訪問(wèn)的兼容性問(wèn)題。

首先了解下，為何要用 TypedArray。

emscripten 申請(qǐng)了一大塊 ArrayBuffer 來(lái)模擬內(nèi)存，然后關(guān)聯(lián)了一些 HEAP 開(kāi)頭的變量。

這些不同類(lèi)型的 HEAP 共享同一塊內(nèi)存，這樣就能高效的指針操作。

然而不支持 TypedArray 的瀏覽器，顯然無(wú)法運(yùn)行。所以得提供個(gè) polyfill 兼容下。

但經(jīng)分析，這幾乎不可能實(shí)現(xiàn) —— 因?yàn)?TypedArray 和數(shù)組一樣，是通過(guò)索引來(lái)訪問(wèn)的：

var buf = new UInt8Array(100); 
buf[0] = 123;     // set 
alert(buf[0]);    // get 

然而 [] 操作符在 JS 里是無(wú)法重寫(xiě)的，因此難以將其變成 setter 和 getter。況且不支持 TypedArray 的都是低版本 IE，更不用考慮 ES6 的那些特征。

于是琢磨 IE 的私有接口。比如用 onpropertychange 事件來(lái)模擬 setter。不過(guò)這樣做效率極低，而且 getter 仍不易實(shí)現(xiàn)。

經(jīng)過(guò)一番考慮，決定不用鉤子的方式，而是直接從源頭上解決 —— 修改語(yǔ)法！

我們用正則，找出源碼中的賦值操作:

HEAP[index] = val; 

替換成:

HEAP_SET(index, val); 

類(lèi)似的，將讀取操作:

HEAP[index] 

替換成:

HEAP_GET(index) 

這樣，原先的索引操作，就變成函數(shù)調(diào)用了。我們就能接管內(nèi)存的讀寫(xiě)，并且沒(méi)有任何兼容性問(wèn)題！

然后實(shí)現(xiàn) 8、16、32 位有無(wú)符號(hào)的版本。通過(guò) JS 的 Array 來(lái)模擬，非常簡(jiǎn)單。

麻煩的是模擬 Float32 和 Float64 兩個(gè)類(lèi)型。不過(guò)本次 C 程序中并未用到浮點(diǎn)，所以就暫不實(shí)現(xiàn)了。

到此，兼容性問(wèn)題就解決了。

大功告成

解決了這些缺陷，我們就可以愉快的在 JS 中使用 C 邏輯了。

作為腳本，只需關(guān)心采集哪些數(shù)據(jù)。這樣 JS 代碼就非常的優(yōu)雅：

數(shù)據(jù)的儲(chǔ)存、加密、編碼，這些底層數(shù)據(jù)操作，則通過(guò) C 實(shí)現(xiàn)。

編譯時(shí)使用 -Os 參數(shù)優(yōu)化體積。最終的 JS 混淆壓縮之后，還不到 2 KB，十分小巧精煉。

更***的是，我們只需維護(hù)一份代碼，即可同時(shí)編譯出前端和后端兩個(gè)版本。

于是，這個(gè)「前后端 WAF」開(kāi)發(fā)就容易多了。

所有的數(shù)據(jù)結(jié)構(gòu)和算法，都由 C 實(shí)現(xiàn)。前端編譯成 JS 代碼，后端編譯成 lua 模塊，供 nginx-lua 使用。

前后端的腳本，都只需關(guān)注業(yè)務(wù)功能即可，完全不用涉及數(shù)據(jù)層面的細(xì)節(jié)。

測(cè)試版

事實(shí)上，還有第三個(gè)版本 —— 本地版。

因?yàn)樗械?C 代碼都在一起，因此可以方便的編寫(xiě)測(cè)試程序。

這樣就無(wú)需啟動(dòng) WebServer、打開(kāi)瀏覽器來(lái)測(cè)試了。只需模擬一些數(shù)據(jù)，直接運(yùn)行程序即可測(cè)試，非常輕量。

同時(shí)借助 IDE，調(diào)試起來(lái)更容易。

小結(jié)

每一門(mén)語(yǔ)言都有各自的優(yōu)缺點(diǎn)。將不同語(yǔ)言的優(yōu)勢(shì)相互結(jié)合，可以程序變得更優(yōu)雅、更***。