[發明專利]一種WebAssembly加載方法、裝置及存儲介質

在審

• 申請號: 202011246964.6
• 申請日: 2020-11-10
• 公開（公告）號: CN112269602A
• 公開（公告）日: 2021-01-26
• 發明（設計）人: 熊智;馬健;溫書豪;賴力鵬
• 申請（專利權）人: 深圳晶泰科技有限公司
• 主分類號: G06F9/445
• 分類號: G06F9/445;G06F8/41;G06F8/51
• 代理公司: 深圳市科吉華烽知識產權事務所(普通合伙) 44248
• 代理人: 胡吉科

本發明提供一種WebAssembly加載方法、裝置及存儲介質，包括如下幾個步驟：A1：采用emscripten編譯器將c++源碼編譯到wasm文件和中間層build.js文件;A2,讀取wasm文件二進制內容，壓縮內容，再轉換為十六進制字符串;A3,讀取中間層build.js內容，與轉換后的wasm字符串合并;A4,進行封裝，在合并的字符串前面注入自動解壓代碼;A5,將封裝后的字符串內容保存到本地文件，完成整個構建過程。

技術領域

本發明屬于WebAssembly加載技術領域，尤其涉及一種WebAssembly加載方法、裝置及存儲介質。

背景技術

使用WebAssembly可以更快地在 web 應用上運行代碼，其有如下特點：

文件加載 - WebAssembly 文件體積更小，所以下載速度更快。

解析 - 解碼 WebAssembly 比解析 JavaScript 要快。

編譯和優化 - 編譯和優化所需的時間較少，因為在將文件推送到服務器之前已經進行了更多優化，JavaScript 需要為動態類型多次編譯代碼。

重新優化 - WebAssembly 代碼不需要重新優化，因為編譯器有足夠的信息可以在第一次運行時獲得正確的代碼。

執行 - 執行可以更快，WebAssembly 指令更接近機器碼。

垃圾回收 - 目前 WebAssembly 不直接支持垃圾回收，垃圾回收都是手動控制的，所以比自動垃圾回收效率更高。

WebAssembly在2019年12月正式納入W3C標準，在前端領域的應用逐漸普及，業界主流的應用方法為：通過emscripten編譯器將c++源碼編譯到wasm文件和中間層build.js文件；Web應用中引入中間層build.js文件；build.js文件內部通過網絡請求完成wasm的加載；以此實現web應用中加載WebAssembly。

已有技術的加載過程如圖1和圖2所示，以上方法存在的不足：對前端模塊化兼容性不好，不能將wasm文件與web應用完全解耦， 對于單頁面web應用（SPA），需要將wasm文件單獨拆出，與靜態文件部署到同級目錄下。操作繁瑣，且通過網絡單獨異步請求wasm文件的速度受網絡環境影響較大，不利于開發體驗和用戶體驗。

發明內容

為了解決以上技術問題，本發明提供了一種模塊化的WebAssembly的構建過程，包括如下幾個步驟：

A1， emscripten編譯器將c++源碼編譯到wasm文件和中間層build.js文件;

A2,讀取wasm文件二進制內容，壓縮內容，再轉換為十六進制字符串;

A3,讀取中間層build.js內容，與轉換后的wasm字符串合并;

A4,進行封裝，在合并的字符串前面注入自動解壓代碼;

A5,將封裝后的字符串內容保存到本地文件，完成整個構建過程。

其中，使用的現有技術進行編譯的，使用的編譯工具就是 “emscripten編譯器”。

優選的，所述步驟A4中，封裝代碼的作用就是A2的反向過程：從十六進制提取出壓縮內容，再解壓，解壓后得到的內容即為wasm文件原始的二進制內容，將wasm二進制內容賦值給Module全局變量。優選的，所述步驟A4中，合并就是將封裝的代碼或字符串添加到build.js內容或字符串前面，然后保存為本地文件，也就是構建生成的文件，即步驟A5。

相應的，本發明還提供了一種WebAssembly的加載過程,包括如下步驟：