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

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

PS:Hybrid應用是web頁面與原生殼(Android、IOS)的結合最後打成安裝包的應用。
 
 
重構的前奏曲:
ApiCloud

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

apicloud的控件是絕大部分原生實現的,沒錯,是原生顯示的,無論是菜單、列表還是頁面效果,都是原生實現的。不是說原生實現的不好,相反,原生實現的控件的兼容性更好,更流暢,也有更好的體驗。但問題來了,原生實現的控件是固定的,除了提供出來的接口去設置控件的樣式、狀態,沒有其他辦法修改,這就導致一個問題,現在互聯網的應用的需求千變萬化,可能在使用控件時候需要做一些小調整(加一行日期或說明什麼的),但原生無法改變,動都動不了。

我曾經諮詢過apicloud這種問題怎麼解決,他們告訴的解決辦法是自己可以寫web前端代碼實現(無法改原生提供的),但我想說的是,用戶都是很「傻」的,如果你提供了東西,他們就會想去用,一旦用不了要自己實現就會很煩。所以我想說,原生實現的固定性導致即使有原生之前提到的優點,我UI部分的控件我也不想用原生實現,web實現更適合微調和自定義(做過框架運維的我深刻體會,到,UI的可微調是很重要的)。而UI控件原生實現有另外一個問題,就是定位的問題,是絕對定位,使用控件時候需要設置x、y軸,這會出現——例如頁面有三個塊A、B、C,A、C是使用原生實現的控件,B是自己的HTML塊,那問題來了,C需要設置x、y的值,當B是動態高度怎麼辦(我到現在也沒搞明白怎麼弄,我覺得終端還是要自己實現C)。

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

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完成)。

對於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.頁面切換速度慢
 
總結

不同的框架,有不同的優點,在這裏找到了幾點可用於自身的東西,也是希望能增強自身。

 

本文爲原創文章,轉載請保留原出處,方便溯源,如有錯誤地方,謝謝指正。

本文轉自 海角在眼前 博客園博客,原文鏈接:http://www.cnblogs.com/lovesong/p/4296694.html    ,如需轉載請自行聯繫原作者