摘要：是一款高性能的前端開發(fā)引擎。這些功能模塊的被放置在一起時，將很難避免相互影響，造成難以測試的。結(jié)尾的文檔目前還不夠完善，但完全可以滿足必要的開發(fā)。

之前公眾號《前端早讀課》推了我的文章（在這里表示感謝），很多同學(xué)有在底下留言，問我 Ionic 和 IOING 是什么關(guān)系？從名字來看兩者的開頭雖然都是 IO 打頭但其實兩者毫無關(guān)系，一丁點(diǎn)兒都沒有。

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

IOING 的歷史大概有5年之久了，一直作為私人項目使用，使用文檔也在近期發(fā)布的。我在這之前將其中的兩個功能點(diǎn)作為推廣試水，于是收到了很多朋友的郵件和微信表示對該項目很感興趣，所以我想 IOING 在用戶接受程度上還是蠻高的，于是有了這篇文章來討論 IOING 的獨(dú)特之處

作為一款應(yīng)用應(yīng)該能和 WEB 體驗有明顯區(qū)分，首先主要體現(xiàn)在布局上，合適的布局至少讓應(yīng)用從外觀上看起來就更像是個 App，比如你的 WebApp 應(yīng)當(dāng)有 header 和 footer，當(dāng)然這些技術(shù)實現(xiàn)上都比較簡單，稍微復(fù)雜的例子是多重滾動嵌套視圖，比如下面的效果

（示例：1-1）

這個例子中的有三個可滾動區(qū)域，一個最外層的父級滾動，另外兩個是 tab 頁面的子滾動，且子滾動和父級滾動有著事件的交互傳遞

（示例：1-2）

對于 1-2 示例就要更復(fù)雜一些了，首先最外層是頁面滾動，組件父級是一個橫向滑動，左右滑動時切換不同選項卡，鼠標(biāo)上下滑動到底也需要切換卡片，每個卡片內(nèi)部還有很多的子滾動

這么多層嵌套的滾動效果對于前端開發(fā)來說無疑是一個很大的工作量，而我們將其抽象來看的話我們需要什么呢？我們需要一個強(qiáng)大的滾動 API，而這一點(diǎn)需求瀏覽器恰恰沒有提供。我們目可用的滾動除了可憐的 body 滾動外還有部分可以使用 overflow-scrolling:touch 來支持區(qū)域滾動的方法，body 滾動只局限在窗口，并且滾動條會覆蓋 header 和 footer 非常丑陋，在不同設(shè)備上滾動慣性也不一致，效果非常不好，而 overflow-scrolling 除了有兼容問題外自身 API 也基本沒有，所以我們只能放棄以上方案，自己造輪子吧。

關(guān)于 js滾動庫中也存在著很多問題，iscroll.js 就是一個知名的滾動庫，我先來簡單說一下關(guān)于 js滾動庫的缺點(diǎn)

不當(dāng)?shù)?CSS 布局可導(dǎo)致其性能急劇下滑

無法通過設(shè)置 0s 動畫來停止當(dāng)前 CSS3 動畫的兼容問題

內(nèi)容更新時不能及時更新滾動對象

大數(shù)據(jù)列表時可導(dǎo)致 GPU 內(nèi)存不足，從而嚴(yán)重卡頓

Android 中觸摸反饋動畫掉幀嚴(yán)重

嗯、好像問題不少，要解決這寫問題要從很多方面思考，這里就不展開詳解只簡單說一下這里關(guān)聯(lián)到的 IOING 中的另一個神奇：DOM 引擎，通過該引擎能自動化處理很多問題，比如像下面這樣創(chuàng)建一個滾動控件

    
        內(nèi)容...
    

這樣就完成了一個全屏的橫豎向滾動控件

作為一個 App，功能模塊間切換一定是要保持狀態(tài)的，即每個模塊的瀏覽痕跡不能銷毀，比如你在 A列表頁進(jìn)行瀏覽，這時看到一條吸引你的內(nèi)容點(diǎn)進(jìn)去 B內(nèi)容頁，點(diǎn)擊的一瞬間會通過一個動畫將 A列表頁和 B內(nèi)容頁同時進(jìn)行動畫轉(zhuǎn)場，此時兩個模塊就必須都有自有滾動控件了，當(dāng)返回時 A列表頁應(yīng)停留在歷史位置。滾動控件的問題在上面有解決方案了，除了歷史位置問題外，想要完成模塊切換還有更多的問題：

載入模塊越來越多，大家都堆放在同一個 DOM Tree下，必然會帶來高耦合，同時一顆龐大的 DOM Tree 也導(dǎo)致了嚴(yán)重的性能問題。這些功能模塊的CSS、Js、html 被放置在一起時，將很難避免相互影響，造成難以測試的 bug。

高耦合下模塊在卸載時難以卸載干凈，余留的全局變量或僵尸事件將一直影響著后續(xù)操作

直接訪問任何一個路由頁面時應(yīng)當(dāng)能在返回時返回到程序主屏幕

歷史記錄應(yīng)按照應(yīng)用層級返回，比如訪問歷史：商品列表頁-詳情頁-訂單頁-支付頁-支付完成頁，此時如果用戶完成交易后點(diǎn)擊返回是不應(yīng)該再進(jìn)入訂單頁和支付頁的，而應(yīng)該直接進(jìn)去詳情頁或列表頁，所以在路由控制上必須有解決方案

模塊與模塊間不應(yīng)能夠直接操作，應(yīng)該有通信規(guī)范

模塊被緩存時應(yīng)有生命周期管理，以保證模塊正常更新

模塊數(shù)據(jù)資源也應(yīng)有生命周期管理，以保證數(shù)據(jù)的正常更新

模塊的更新操作應(yīng)保證舊數(shù)據(jù)與新數(shù)據(jù)更替間不出現(xiàn)白屏現(xiàn)象

模塊應(yīng)該有自己的資源管理，數(shù)據(jù)管理，事件管理，配置管理等方案

模塊智能預(yù)載方案

模塊類型方案：嵌入式模塊，系統(tǒng)模塊，獨(dú)立模塊

不同類型模塊的轉(zhuǎn)場，并提供動畫接口

保證動畫性能，需要建立動畫隊列，對所有動畫操作進(jìn)行統(tǒng)一封裝

以上部分都是當(dāng)你決定要做模塊頁面轉(zhuǎn)場時不得不考慮的問題，除了這些主要問題外還有很多細(xì)節(jié)問題需要考慮，比如動畫前指定加載模塊如何迅速渲染完畢等等。
模塊中可對模塊配置自定義函數(shù)動畫，也可以使用內(nèi)置默認(rèn)動畫，向下面這樣的效果

animation:"fade"

animation:"flip"

animation:"zoom"

animation:"slide"

對于模塊管理方面 IOING 設(shè)計了很多方案，比如資源管理方面IOING 通過一個配置文件進(jìn)行統(tǒng)一管理

(模塊配置文件)
在模塊配置文件中描述了該模塊的資源庫、類型、事件、級別、運(yùn)行方式、以及轉(zhuǎn)場動畫等，其中sandbox項能讓模塊在沙盒下運(yùn)行，即保證模塊擁有自己的獨(dú)立運(yùn)行空間

其實在 webComponent 技術(shù)規(guī)范之前我們就已經(jīng)在使用 web 組件了，最常見的 web 組件就是 input，那我們怎么才能實現(xiàn)一個想 input 這樣的組件呢？
瀏覽器需要支持如下特性：

1. Custom elements
2. Template
3. Shadow DOM
4. 

(示例 3-1)
該示例是一個組件在瀏覽器中所呈現(xiàn)的結(jié)構(gòu)
當(dāng)你在一個或多個模塊中引用了多個相同組件時就會涉及一個問題：組件通信。
比如你每個組件副本都需要獲取一段數(shù)據(jù)，那么如果每個組件都各自進(jìn)行獲取數(shù)據(jù)源顯然是不正確的，那么此時就需要一個總控來進(jìn)行做數(shù)據(jù)管理
再來一個例子你有一個開關(guān)的組件在多個模塊中都被引用到，此時當(dāng)你關(guān)閉了其中一個開關(guān)組件，那該數(shù)據(jù)應(yīng)同步到所有其他開關(guān)組件中
條件四：可編程CSS及物理像素
做過手機(jī)端 h5 開發(fā)的同學(xué)都應(yīng)該有體會，尤其是在 ios 上，1px 總是比預(yù)期的要粗，因為這個問題不少前端也被視覺同學(xué)吐槽過。
那為什么會出現(xiàn)這樣的問題呢？這是因為現(xiàn)在的手機(jī)分辨率越來越高，如果把 iphone 的 1px 像素點(diǎn)和普通 pc顯示器的 1像素點(diǎn)放在一起對比，你會發(fā)現(xiàn) iphone 的1px 要小很多，這個小于標(biāo)準(zhǔn)像素的倍數(shù)就是我們常說的devicePixelRatio，既然像素變小了那應(yīng)該在 iphone 上看同一個頁面應(yīng)該更小才對呀，也正是因為這樣問題才催生了viewport。
viewport 的作用就像是等比拉伸一張圖那樣，最終圖像中 1px 的細(xì)節(jié)很明顯受到影響，失去發(fā)髻線效果。因此我們首先要做的就是把viewport特性干掉，而干掉后我們還需要一個新單位來解決適配問題，于是就有了新單位dp dp = density px = devicePixelRatio * px
當(dāng)然有了dp還不夠，我們還需要結(jié)合vm，vh，vw等來做更多的適配工作，但是并不是所有設(shè)備都支持這些單位，所以我們還需要一個 CSS引擎來處理這些問題，比如 calc計算
div {
    width: calc(50vw - 20dp + 1px)
}
多個單位合并計算的場景在 App設(shè)計過程中很常見，如果不能兼容掉將會非常影響開發(fā)效率
再來一個例子，在你的 App中 header的高度等于 60dp，并且它還有 1px 的邊線，因此它在 DPI為 3 的設(shè)備下應(yīng)該等于 181px，在DPI 為 2的設(shè)備下等于 121dp，在另一個模塊的 CSS中我們希望知道 header 的高度時同樣應(yīng)該有一種機(jī)制讓模塊間共享數(shù)據(jù)，在 IOING 中就像下面這樣
/*主模塊 CSS文件*/
@global {
    header-height: calc(60dp + 1px);
}
/*A模塊 CSS文件*/
div {
    top: [header-height];
}
有時候光滿足 CSS 內(nèi)變量代換還不夠，我們還要支持 CSS 中引入模塊數(shù)據(jù)源，就像模版語法那樣，CSS也應(yīng)該有自己的邏輯語法
@if(device.os.ios) {
    header {
        backdrop-filter: blur(20dp);
    }
}
更多用法關(guān)注這里http://ioing.com/#docs-css-scope/

華麗分割線

QA
IOING 是什么？
IOING 是一款高性能的前端開發(fā)引擎。它為創(chuàng)建一個大型應(yīng)用提供一整套的完備方案，如頁面模塊化拆分、層級路由控制、可編程CSS、熱拔插組件、雙向數(shù)據(jù)綁定、DOM語法擴(kuò)展、自動兼容處理等
IOING 項目還需要 SASS、LESS、Stylus 等嗎？
不需要。IOING 是一個純前端引擎，所有服務(wù)都是前端運(yùn)行的結(jié)果
IOING 和 React、vue、Angular 的區(qū)別在哪里？
IOING 從容器層解決了很多 web開發(fā)難題，目的是為了提供一套完整的 SPA開發(fā)方案，而不是解決某幾方面的問題。
結(jié)尾
IOING 的文檔目前還不夠完善，但完全可以滿足必要的開發(fā)。對于文檔的更新工作我日后會持續(xù)，也歡迎對 IOING 該興趣的同學(xué)關(guān)注我的公眾號或 star我
項目地址：https://github.com/ioing/IOING
公眾號請掃：