Hero Solution移動(dòng)跨平臺(tái)開(kāi)發(fā)方案

HERO 是一個(gè)移動(dòng)跨平臺(tái)開(kāi)發(fā)方案。

類似產(chǎn)品對(duì)比

解釋上述表格

• 性能 react native和weex界面表現(xiàn)層是原生的，但是構(gòu)造元素本身的操作，和元素的所有邏輯在js中，導(dǎo)致性能有影響。小程序還有一個(gè)h5 canvas轉(zhuǎn)原生性能莫名其妙的慢的問(wèn)題。Hero中元素的所有操作都在原生代碼中，只有業(yè)務(wù)明確需要某個(gè)操作結(jié)果才會(huì)調(diào)用到j(luò)s代碼。

• 布局能力 CSS幾乎可以表示一切形式的界面，無(wú)設(shè)計(jì)語(yǔ)言約束，但是最終效果有時(shí)候與平臺(tái)的沖突會(huì)造成編程的困惑與體驗(yàn)的變差，react native 和weex的css依賴webview的渲染，再將結(jié)果發(fā)送給原生導(dǎo)致性能損失很大。微信在自家產(chǎn)品中的約束樣式反而還不錯(cuò)。Hero是另辟蹊徑定義了一套擴(kuò)展后的frame布局，并且在各平臺(tái)原生實(shí)現(xiàn)這套方案，布局能力達(dá)到并兼容原生app。

• 設(shè)備能力 微信提供了有限受控的設(shè)備能力，其它皆有完全的設(shè)備能力(系統(tǒng)支持)

• 開(kāi)發(fā)成本 由于react native開(kāi)發(fā)門檻較高，學(xué)習(xí)曲線很陡，特別是對(duì)移動(dòng)開(kāi)發(fā)人員，很難適應(yīng)web開(kāi)發(fā)模式，而web工程師對(duì)iOS本身的接口不熟悉，很難做出原生體驗(yàn)的app出來(lái)，weex應(yīng)該也類似。還有不管是react native 還是weex所開(kāi)發(fā)出來(lái)的頁(yè)面不是完全跨平臺(tái)的，它們只是開(kāi)發(fā)方式是跨平臺(tái)的，具體頁(yè)面還是要分開(kāi)開(kāi)發(fā)。導(dǎo)致開(kāi)發(fā)人員需求依舊那么多，甚至更多。而hero是一種依賴 定義<->實(shí)現(xiàn) 的開(kāi)發(fā)方案，所開(kāi)發(fā)的界面是平臺(tái)無(wú)關(guān)的，再加上統(tǒng)一的元素定義格式，對(duì)于具體的頁(yè)面開(kāi)發(fā)人員來(lái)說(shuō)，只是在配制顯示的元素，非常簡(jiǎn)單。

• 開(kāi)發(fā)工具 目前Hero的開(kāi)發(fā)沒(méi)有限定開(kāi)發(fā)工具，sublime和atom都可以，調(diào)試就在chrome里面調(diào)試web頁(yè)面就好了。集成編碼、調(diào)試、托管服務(wù)端的Hero開(kāi)發(fā)者工具正在開(kāi)發(fā)過(guò)程當(dāng)中。開(kāi)發(fā)者工具本身也是用hero框架開(kāi)發(fā)，目錄在hero-js／heroapp當(dāng)中。只需要切換到heroapp目錄，使用nwjs .即可打開(kāi)預(yù)覽版本。

• 框架代碼量 hero框架技術(shù)上并不復(fù)雜，核心邏輯代碼不過(guò)200行。

• 入門難度 Hero框架中只有一個(gè)固定的controller，其它全部都是element，相比其它的MVP、MVVM、MVC有著復(fù)雜的邏輯關(guān)系，Hero中的模式就是* e , *ee, ?eeeeee...,通通都是element，controller除了用來(lái)顯示element，給element傳遞json數(shù)據(jù)之外就沒(méi)有額外的邏輯了。element 中只有一個(gè)函數(shù)處理json對(duì)象，除此之外再無(wú)其它接口。每個(gè)element 都是絕對(duì)獨(dú)立的，與其它元素毫無(wú)瓜葛。這樣開(kāi)發(fā)、測(cè)試元素都是及其簡(jiǎn)單的。

Hero 框架圖