如何在 JavaScript 中使用 C 程序
JavaScript 是個靈活的腳本語言，能方便的處理業務邏輯。當須要傳輸通訊時，咱們大多選擇 JSON 或 XML 格式。javascript
但在數據長度很是苛刻的狀況下，文本協議的效率就很是低了，這時不得不使用二進制格式。css
去年的今天，在折騰一個 先後端結合的 WAF 時，就遇到了這個麻煩。html
由於前端腳本須要採集很多數據，而最終是隱寫在某個 cookie 裏的，所以可用的長度很是有限，只有幾十個字節。前端
若是不假思索就用 JSON 的話，光一個標記字段 {"enableXX": true} 就佔去了一半長度。然而在二進制裏，標記 true 或 false 不過是 1 個比特的事，能夠節省上百倍的空間。java
同時，數據還要通過校驗、加密等環節，只有使用二進制格式，才能方便的調用這些算法。nginx
優雅實現
不過，JavaScript 並不支持二進制。git
這裏的「不支持」不是說「沒法實現」，而是沒法「優雅實現」。語言的發明，就是用來優雅解決問題的。即便沒有語言，人類也能夠用機器指令來編寫程序。github
若是非要用 JavaScript 操做二進制，最終就相似這樣：算法
var flags = +enableXX1 << 16 | +enableXX2 << 15 | ...
雖然能實現，但很醜陋。各類硬編碼、各類位運算。後端
然而，對於先天支持二進制的語言，看起來就十分優雅：
union {
struct { int enableXX1: 1; int enableXX2: 1; ... }; int16_t value; } flags; flags.enableXX1 = enableXX1; flags.enableXX2 = enableXX2;
開發者只需定義一個描述便可。使用時，字段偏移多少、如何讀寫，這些細節徹底不用關心。
爲了能達到相似效果，起先封裝了一個 JS 版的結構體：
// 最初方案：封裝一個 JS 結構體
var s = new Struct([ {name: 'month', bit: 4, signed: false}, ... ]); s.set('month', 12); s.get('month');
將細節進行了隱藏，看起來就優雅多了。
優雅但不完美
可是，這總感受不是最完美的。結構體這種東西，本該由語言提供，現在卻要用額外的代碼實現，並且仍是在運行期間。
另外，後端解碼是用 C 實現的，因此得維護兩套代碼。一旦數據結構或者算法變了，得同時更新 JS 和 C，很麻煩。
因而琢磨，可否共用一套 C 代碼，同時用於前端和後端？
也就是說，須要能將 C 編譯成 JS 來運行。
認識 emscripten
能將 C 編譯成 JS 的工具備很多，最專業的要數 emscripten。
emscripten 的使用方式很簡單，和傳統 C 編譯器差很少，只不過生成的是 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; }
編譯以後便可運行：
頗有趣吧~ 你們能夠嘗試下，這裏就很少介紹了。
實用缺陷
然而咱們關心的不是有趣，而是實用。
事實上，即便一個 Hello World 編譯出來的 JS 也過萬行，多達數百 KB。就算壓縮再 GZIP，仍有幾十 KB。
同時 emscripten 使用了 asm.js 規範，內存訪問是經過 TypedArray 實現的。
這意味着 IE10 如下的用戶都沒法運行。這也是不可接受的。
所以，咱們得作以下改進：
- 減小體積
- 增長兼容
首先寄託 emscripten 自己，看看能不能經過設置參數，來達到咱們的目的。
不過一番嘗試以後，並無成功。那隻能本身動手實現了。
減小體積
爲何最終腳本會那麼大，裏面都放了些什麼？分析了下內容，大體有這幾個部分：
- 輔助功能
- 接口模擬
- 初始化操做
- 運行時函數
- 程序邏輯
輔助功能
好比字符串和二進制轉換、提供回調包裝等。這些基本都是用不着的，咱們能夠給本身寫個特殊的回調函數。
接口模擬
提供文件、終端、網絡、渲染等接口。以前見過用 emscripten 移植的客戶端遊戲，看來模擬了很多接口。
初始化操做
全局內存、運行時、各類模塊的初始化。
運行時函數
純粹的 C 只能作簡單的計算，不少功能都依靠運行時函數。
不過，有些經常使用的函數，其背後的實現是及其複雜的。例如 malloc 和 free，對應的 JS 有近 2000 行！
程序邏輯
這纔是 C 程序真正對應的 JS 代碼。由於編譯時通過 LLVM 的優化，邏輯可能變得面目全非了。
這部分代碼量不大，是咱們真正想要的。
事實上，若是程序沒有用到一些特殊功能的話，把邏輯函數單獨摳出來，仍然是能夠運行的！
考慮到咱們的 C 程序很是簡單，因此簡單粗暴的提取出來，也是沒問題的。
C 程序對應的 JS 邏輯位於 // EMSCRIPTEN_START_FUNCS 和 // EMSCRIPTEN_END_FUNCS 之間。過濾掉運行時函數，剩下的就是 100% 的邏輯代碼了。
增長兼容
接着解決內存訪問的兼容性問題。
首先了解下，爲什麼要用 TypedArray。
emscripten 申請了一大塊 ArrayBuffer 來模擬內存，而後關聯了一些 HEAP 開頭的變量。
這些不一樣類型的 HEAP 共享同一塊內存，這樣就能高效的指針操做。
然而不支持 TypedArray 的瀏覽器，顯然沒法運行。因此得提供個 polyfill 兼容下。
但經分析，這幾乎不可能實現 —— 由於 TypedArray 和數組同樣，是經過索引來訪問的：
var buf = new Uint8Array(100); buf[0] = 123; // set alert(buf[0]); // get
然而 [] 操做符在 JS 裏是沒法重寫的，所以難以將其變成 setter 和 getter。何況不支持 TypedArray 的都是低版本 IE，更不用考慮 ES6 的那些特徵。
因而琢磨 IE 的私有接口。好比用 onpropertychange 事件來模擬 setter。不過這樣作效率極低，並且 getter 仍不易實現。
通過一番考慮，決定不用鉤子的方式，而是直接從源頭上解決 —— 修改語法！
咱們用正則，找出源碼中的賦值操做:
HEAP[index] = val;
替換成:
HEAP_SET(index, val);
相似的，將讀取操做:
HEAP[index]
替換成:
HEAP_GET(index)
這樣，原先的索引操做，就變成函數調用了。咱們就能接管內存的讀寫，而且沒有任何兼容性問題！
而後實現 八、1六、32 位有無符號的版本。經過 JS 的 Array 來模擬，很是簡單。
麻煩的是模擬 Float32 和 Float64 兩個類型。不過本次 C 程序中並未用到浮點，因此就暫不實現了。
到此，兼容性問題就解決了。
大功告成
解決了這些缺陷，咱們就能夠愉快的在 JS 中使用 C 邏輯了。
做爲腳本，只需關心採集哪些數據。這樣 JS 代碼就很是的優雅：
數據的儲存、加密、編碼，這些底層數據操做，則經過 C 實現。
編譯時使用 -Os 參數優化體積。最終的 JS 混淆壓縮以後，還不到 2 KB，十分小巧精煉。
更完美的是，咱們只需維護一份代碼，便可同時編譯出前端和後端兩個版本。
因而，這個「先後端 WAF」開發就容易多了。
全部的數據結構和算法，都由 C 實現。前端編譯成 JS 代碼，後端編譯成 lua 模塊，供 nginx-lua 使用。
先後端的腳本，都只需關注業務功能便可，徹底不用涉及數據層面的細節。
測試版
事實上，還有第三個版本 —— 本地版。
由於全部的 C 代碼都在一塊兒，所以能夠方便的編寫測試程序。
這樣就無需啓動 WebServer、打開瀏覽器來測試了。只需模擬一些數據，直接運行程序便可測試，很是輕量。
同時藉助 IDE，調試起來更容易。
小結
每一門語言都有各自的優缺點。將不一樣語言的優點相互結合，可讓程序變得更優雅、更完美。