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

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

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

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

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

（示例：1-1）

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

（示例：1-2）

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

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

關(guān)于 js滾動(dòng)庫(kù)中也存在著很多問(wèn)題，iscroll.js 就是一個(gè)知名的滾動(dòng)庫(kù)，我先來(lái)簡(jiǎn)單說(shuō)一下關(guān)于 js滾動(dòng)庫(kù)的缺點(diǎn)

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

無(wú)法通過(guò)設(shè)置 0s 動(dòng)畫(huà)來(lái)停止當(dāng)前 CSS3 動(dòng)畫(huà)的兼容問(wèn)題

內(nèi)容更新時(shí)不能及時(shí)更新滾動(dòng)對(duì)象

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

Android 中觸摸反饋動(dòng)畫(huà)掉幀嚴(yán)重

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

    
        內(nèi)容...
    

這樣就完成了一個(gè)全屏的橫豎向滾動(dòng)控件

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

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

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

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

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

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

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

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

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

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

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

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

不同類(lèi)型模塊的轉(zhuǎn)場(chǎng)，并提供動(dòng)畫(huà)接口

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

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

animation:"fade"

animation:"flip"

animation:"zoom"

animation:"slide"

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

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

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

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

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

華麗分割線

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