Hybrid框架UI重構之路：1、師其長技以自強

時間 2020-04-23

原文原文鏈接

這兩年在支撐公司的Hybrid框架的運維發展，讓人確認這種移動開發方式確實是一條不錯的路。混合應用這種開發方式下降開發難度，極大的提升開發效率，最重要的一點效果能夠接近原生應用。框架的自己是須要持續不斷髮展的，這裏開始我講述我重構Hybird框架的UI的這三個月（2014-11——2015-1），而在重構以前，預先調查了目前所瞭解的幾個混合應用的框架，師其長技以自強。css

PS：Hybrid應用是web頁面與原生殼（Android、IOS）的結合最後打成安裝包的應用。

重構的前奏曲：

ApiCloud

這個移動端混合應用框架產品我是最熟悉的，爲了理解深刻理解還作了一個示例應用。apiCloud的開發環境仍是不錯的，有自定義的IDE，但沒有模板工程，同時也有svn控制項目，與其Web站點相同步。而他將他的api分爲「雲」端api，「終」端api。他的原生的殼作得很是好，插件分模塊（可選），且支持用戶自定義原生插件，但我對他的UI控件、組件的實現方式不是那麼贊同。由於這次我是針對自身Hybrid框架的UI部分進入重構的，因此我更關注的是這方面的東西。html

apicloud的控件是絕大部分原生實現的，沒錯，是原生顯示的，不管是菜單、列表仍是頁面效果，都是原生實現的。不是說原生實現的很差，相反，原生實現的控件的兼容性更好，更流暢，也有更好的體驗。但問題來了，原生實現的控件是固定的，除了提供出來的接口去設置控件的樣式、狀態，沒有其餘辦法修改，這就致使一個問題，如今互聯網的應用的需求變幻無窮，可能在使用控件時候須要作一些小調整（加一行日期或說明什麼的），但原生沒法改變，動都動不了。前端

我曾經諮詢過apicloud這種問題怎麼解決，他們告訴的解決辦法是本身能夠寫web前端代碼實現（沒法改原生提供的），但我想說的是，用戶都是很「傻」的，若是你提供了東西，他們就會想去用，一旦用不了要本身實現就會很煩。因此我想說，原生實現的固定性致使即便有原生以前提到的優勢，我UI部分的控件我也不想用原生實現，web實現更適合微調和自定義（作過框架運維的我深入體會,到，UI的可微調是很重要的）。而UI控件原生實現有另一個問題，就是定位的問題，是絕對定位，使用控件時候須要設置x、y軸，這會出現——例如頁面有三個塊A、B、C，A、C是使用原生實現的控件，B是本身的HTML塊，那問題來了，Ｃ須要設置x、y的值，當B是動態高度怎麼辦（我到如今也沒搞明白怎麼弄，我以爲終端仍是要本身實現C）。web

apicloud因爲控件都是原生實現的，他就乾脆連UI使用什麼依賴庫都不建議。官方是說用戶能夠本身使用任意的前端框架，看似是爲了放大自由度，但我以爲是在減輕產品UI部分的負擔，不提供、不建議UI使用的css、js，產品的運維成本將會大大下降（我如今運維的框架80%都是UI的問題），這點不得不說是apicloud的聰明之處。api

Appcan

Appcan是我最喜歡的Hybrid框架，最近還開源了。不管是開發環境，仍是框架自己，在我看來是最符合用戶需求的。特別是提供了四種示例模板，新聞、OA、閱讀、電商，新聞是最有表明性的，以外還有衆多的示例頁面。固然控件是由web實現的，雖然樣式的命名實在是看不懂，但貴在可微調。前端框架

在這裏必須講一下appcan、apicloud共有的優勢，也是一個重要的特色，就是頁面加載速度很是快。這點其實很是重要。服務器

例若有A、B兩個頁面，A切換到B，正常的切換是直接切整一個B的頁面，header、content、footer以及全部依賴的文件，而appcan實際上是將頁面分爲兩個部分，header、footer和 content，當A切換到B時，先加載header、footer部分並切換頁面，頁面切換完後再加載content部分。這樣作會給用戶一個假象，就是B頁面加載速度很快，儘管B頁面真正加載還須要一段時間（等待content完成）。app

對於appcan的原生，我也不甚瞭解，就很少說。框架

Exmobi

這個框架是另一個同事去探究的，我關注的是他的UI部分，但並無多大的驚喜，他是參照某個移動端框架（Jingle）作的，雖然是示例工程改頭換面了一下，但抄的影子仍是太深了。而在這裏也是提醒個人一點，好的東西能夠抄（抄是沒有問題的，別人實現了，你爲何還要實現一次，浪費時間），但必須符合本身的需求，別讓本身的思路被引導了。運維

Jingle

這是國內一個前端人員作的UI框架，僅有UI部分，對於這個框架我有仔細研究，甚至還通讀了源碼。其代碼結構、模塊劃分、控件的寫法都是比較完善的，學習他的框架學到的東西更超出了UI框架自己。他提供的UI的東西並不複雜，相比appcan是一種精簡版。而裏面最重要的一點是單頁模式。在這裏簡單說說單頁模式是什麼。

單頁模式

單頁模式（Single-Page Application）即在一個HTML5移動應用中只包含一個HTML頁面，而不一樣視圖的顯示實際是在一個頁面中採用動態顯隱實現，而其中最重要的技術的就是Ajax，不一樣視圖的獲取都是經過Ajax從本地或遠程服務器中獲取。

也就是說，不一樣的視圖都是一個HTML片斷，而不是完整的HTML頁面。

在 SPA 模式中，主頁面（完整HTML頁面）是能夠獨立加載、更新和替換的一些可視元素的組合（HTML片斷）。經過這種方式，能夠沒必要在每次用戶操做後從新加載整個頁面。在任什麼時候候，都只顯示與應用程序當前階段相關的可視元素和內容。其餘全部內容均被隱藏；但只要應用程序流程中須要用到它，它就會顯示出來。

優勢

1.共用的依賴庫沒必要重複加載，只需在主頁面加載一次，其餘（HTML片斷）不須要，這也間接提高頁面加載速度。

2.使用CSS3作頁面之間的切換，速度比原生切換webview快不少。

缺點

1.由於全部的HTML最終都是加載在主頁面，因此可能存在js、css命名衝突。(因此JS和CSS的命名都須要進行有效管理，這一點須要時刻注意)

2.單頁模式會使一個界面不斷加載新的元素而致使界面邏輯複雜和頁面膨脹

3.其實有一個很嚴重的一點，就是內存泄露的問題。

多頁模式

多頁模式（Multi-page Application）是相對於單頁模式而言，應用中的每個頁面都是一個獨立HTML頁面，而不是HTML片斷。

缺點

1.每一個頁面可能都會重複加載一些數據（JS、CSS、部分HTML代碼等）

2.頁面切換速度慢