摘要：為使瀏覽器載入大量模塊時不會造成內(nèi)存占用過高，瀏覽器應(yīng)能使被移除后的模塊能被完全釋放。瀏覽器應(yīng)使模塊運行在獨立空間中，以保證模塊自身錯誤時不至于導(dǎo)致整個應(yīng)用停止工作。

IOING 在你的代碼和瀏覽器之間架設(shè)了一個中間解釋層，該解釋層提供了一套新的語法來填補瀏覽器所不具備的能力。

開發(fā)一個 SPA 應(yīng)用的痛點是不同模塊頁面的狀態(tài)保存，當(dāng)從一個頁面跳轉(zhuǎn)到另一個頁面的時候窗口的所有狀態(tài)都將被清空重載，歷史頁面與當(dāng)前頁面將不產(chǎn)生任何聯(lián)系，這個過程是一個拆毀重建的過程，如果你要回到歷史同樣只能再次拆毀重建，并且在這個過程中不可避免的出現(xiàn)加載期的窗口白屏，顯然這樣的丑陋效果不符合一個高貴 App 的設(shè)定，但正因這種方式前后頁面不共存的簡單特性也使得開發(fā)邏輯變得簡單，開發(fā)者只需考慮單個頁面的邏輯即可，而每一次新頁面的加載都能將之前頁面進(jìn)行完全釋放，完全不需要擔(dān)心高耦合和內(nèi)存無法完全釋放的問題，這也算是傳統(tǒng)技術(shù)的優(yōu)點，雖然簡單粗暴，但是它很管用。那到底有沒有兩全其美的辦法呢？

和 SPA 應(yīng)用不同的是多頁面應(yīng)用往往相對要變得簡單，頁面與頁面之間不需要有復(fù)雜的數(shù)據(jù)交換，也無需保存頁面歷史狀態(tài)，因此使用傳統(tǒng)技術(shù)最適合不過了。

而 SPA 應(yīng)用則要協(xié)調(diào)頁面間的關(guān)系，它的每一個模塊都可能是聯(lián)動的，而且需要保持窗口的數(shù)據(jù)狀態(tài)，因而催生了另一個技術(shù)的流行，即通過使用 Ajax 和模版將新模塊內(nèi)容載入到當(dāng)前頁面，但這也導(dǎo)致新載入模塊的腳本和 DOM 樹內(nèi)容在主文檔下不斷堆積，且在不需要時也無法將其很好移除和釋放（比如 setTimeout 等僵尸事件）。另一種情況是一旦其中一個模塊發(fā)生錯誤將很有可能導(dǎo)致整個 SPA 應(yīng)用崩潰。

除了高耦合問題外，Ajax 每次載入大量的 DOM 結(jié)構(gòu)到主 DOM Tree 下時都將可能會導(dǎo)致這個龐大的 DOM Tree 進(jìn)行 reflow(回流) 和 repaint(重繪)，從而影響整體運行效率

基于上述分析，我們要得到一個穩(wěn)定的 SPA 應(yīng)用時必須改造瀏覽器使其支持以下特性：

為保證應(yīng)用松耦合，瀏覽器必須具備能夠使新加載的模塊與已加載模塊不產(chǎn)生相互干擾的能力。

為使瀏覽器載入大量模塊時不會造成內(nèi)存占用過高，瀏覽器應(yīng)能使被移除后的模塊能被完全釋放。

瀏覽器應(yīng)使模塊運行在獨立空間中，以保證模塊自身錯誤時不至于導(dǎo)致整個應(yīng)用停止工作。

只有具備了這些特性時才能保證一個大型 WEB 應(yīng)用的穩(wěn)定運行，那么對于上述問題 IOING 是怎么處理的呢？

首先為了保證模塊的代碼錯誤不至于影響整個應(yīng)用的運行，我們需要保證除引擎外的所有不可控腳本都不能運行在主 window 下，而模塊腳本自需要運行在多帶帶的沙盒中。

沙盒（Sandbox）簡單來講就是:
無需解釋大家也就都懂了，但是很多人在看到 iframe 時就開始各種擔(dān)心起來，聯(lián)想起各種文章對 iframe 的負(fù)面描述。這里需要解釋一下，iframe 直接作為嵌入網(wǎng)頁使用時確實會占用當(dāng)前頁面連接池，但其在引擎中其主要目的是作為沙盒使用而并不是為了嵌入網(wǎng)頁使用的，當(dāng)引擎將編譯好內(nèi)容時會先主動創(chuàng)建一個空 iframe，然后直接將編譯內(nèi)容直接丟入其中，注意 iframe 的 src="_blank"，這是一個空頁面，該情況下 iframe 并不會共享主窗口連接池。

我們設(shè)想一下這樣一個場景：你在瀏覽器打開多個窗口分別載入不同的模塊頁面，然后在你需要打開其他頁面時能通過自定義動畫使瀏覽器窗口進(jìn)行動畫過渡將頁面展示，當(dāng)你返回時也能通過反向動畫再將之前窗口內(nèi)容過渡回來，如果瀏覽器支持這些或許 webApp 看起來將更酷，但現(xiàn)實是瀏覽器并沒有這樣的操作??♂?。

而這個設(shè)想可以通過沙盒來實現(xiàn)，在沙盒中的頁面就像新開一個瀏覽器窗口那樣，能夠很好的隔離模塊的 DOM 元素和變量，也能保存頁面狀態(tài)，并能通過動畫控制其轉(zhuǎn)場。

沙盒雖然很穩(wěn)妥，但其過于獨立，這導(dǎo)致模塊內(nèi)元素不能突破沙盒限制顯示在模塊外區(qū)域，比如說一些復(fù)合型模塊（即嵌入主模塊中的模塊，沙盒一般適用與獨立的全屏模塊），當(dāng)你有這個需求時沙盒特性則不能滿足你，此時你應(yīng)該支持另一種模塊運行方式：shadowbox 應(yīng)運而生。

使用 shadowbox 配置的模塊，其模塊內(nèi)容將以一顆新 DOM Tree 插入到主 DOM Tree 中（即 shadowdom 方式），這顆新 DOM Tree 中的 CSS樣式 和 元素id 將不會和外部元素耦合，而此時模塊的 js 文件則依舊在其沙盒中運行。（若運行瀏覽器不支持該特性時應(yīng)自動降級處理）

當(dāng)然只有一個沙盒模型是遠(yuǎn)遠(yuǎn)不夠的，比如組件同樣需要一套合理運作機制。之后「兩分鐘了解IOING」將會繼續(xù)推出以下話題：

組件設(shè)計與通信

模塊刷新機制

量子 DOM 原理（和 Def 算法不同的數(shù)據(jù)雙向綁定設(shè)計）

CSS 引擎的設(shè)計思想

更多敬請期待...

IOING在開發(fā)SPA大型應(yīng)用時有哪些必要的技術(shù)條件？
如何用 js 獲取虛擬鍵盤高度？（適用所有平臺）
讓 CSS 完成背景圖加載完畢后顯示 之 解析 IOING 的 onload url 原理

IOING 是一款高性能的前端開發(fā)引擎。它為創(chuàng)建一個大型應(yīng)用提供一整套的完備方案，如頁面模塊化拆分、層級路由控制、可編程CSS、熱拔插組件、雙向數(shù)據(jù)綁定、DOM語法擴展、自動兼容處理等

掃碼二維碼關(guān)注我的公眾號：

傳送門：IOING 仿ios界面

傳送門：官網(wǎng)

傳送門：Github 項目地址