林增坦
(仰恩大學 福建 泉州 362000)
隨著掌上設備的普及和移動4G服務的推廣,高校學生群體獲取網絡信息的方式已經從桌面設備轉移到了掌上設備,因原生開發(fā)要實現跨平臺,開發(fā)和維護的成本很高,而Web開發(fā)的設備訪問能力差。為此,引入Hybrid混合開發(fā),解決設備多樣化帶給傳統(tǒng)移動開發(fā)的諸多限制,它是一種新的移動開發(fā)模式,它所開發(fā)產生的應用稱為Hybrid App。Web開發(fā)產生的應用稱為Web app。Hybrid App(混合模式移動應用)兼具“Native App良好用戶交互體驗的優(yōu)勢”和“Web App跨平臺開發(fā)的優(yōu)勢”[1]。
本系統(tǒng)APP架構設計采用三層結構設計見圖1所示。
圖1 混合的總體架構設計圖示
混合開發(fā)中,通信層的設計是首先要解決的內容,系統(tǒng)的邏輯性工作是以通信層為基礎的。簡單地講就是完成Native和H5之間的信息往來,其具體通信方法見圖2所示[2]。
圖2 通信層的原理圖示
私有協議實現通信,當一個APP被安裝完成,會在手機操作系統(tǒng)上注冊一個私有協議,手機瀏覽器無法全部識別,其將不識別部分交給操作系統(tǒng)去處理,操作系統(tǒng)幫忙查找能夠識別該私有協議的APP。
為了解決JavaScript中引發(fā)的進程阻塞問題,確保有序地調用H5。將兩者之間的通訊接口設計,模仿JSONP的通信思路,將信息請求方法模仿request對象的方法,將信息回復方法模仿response對象方法[3]。則一次通信的回路涉及的操作:
Step1:請求方法調用一個接口,發(fā)送一個同時 帶有相關參數和自身生成的簽名的請求給被請求方;
Step2:被請求方對該請求信息做出相應并處理,并發(fā)送一個帶有相關參數及其自身生成的簽名的回復給請求方;
Step3:請求方憑借其簽名查找回調方法入口,并執(zhí)行該方法。
混合開發(fā)的目的:全面綜合H5和Native的優(yōu)點,營造更好地用戶體驗。其中跨平臺、快速迭代能力是H5的優(yōu)勢,流暢性、系統(tǒng)API調用能力是Native的優(yōu)勢[4]。因此,如果要盡量發(fā)揮兩者的優(yōu)點,前端展示的內容盡可能多地用H5來完成,針對JS語言在交互上的缺點,盡可能用Native本身的高交互性和并行處理、高的輸入輸出的性能等來彌補JS的缺點。概括說來,前者有內容呈現上的優(yōu)勢,后者更具交互操作上的優(yōu)點,并根據具體情況對原生的WebView進行整合與優(yōu)化,以加強H5的呈現效果。
重要的界面、多交互的界面用Native來開發(fā);APP中的導航類UI依托原生開發(fā)來完成。通用類型的UI設計系統(tǒng)交給Native完成,系統(tǒng)的默認UI設計交給Native完成。當H5出項加載失敗或延遲時,系統(tǒng)會調用默認UI,以免出現假死現象。
Native要完成重要類型、導航類型、通用類型、公共類型的UI設計,還要充當H5的運行管理者的作用,它要提供H5運行的資源管理、狀態(tài)監(jiān)控等功能,保證H5運行的穩(wěn)定性和健壯性。
系統(tǒng)對H5提供離線訪問的策略來解決web app高延遲問題。離線訪問,就是把所需的H5在APP安裝時提前下載到用戶手機的存儲空間中,這大大提高了訪問H5的速度[5]。但是這必須考慮H5的動態(tài)更新問題,否則H5的可用性無法保證。
首先,服務器必須要有H5的線上備份,用戶本地的H5被刪除或丟失時,可在線向服務器提取H5的線上備份,確保H5能用。另外,對一下兩種情況不使用前述的策略。一種是動態(tài)的活動頁面,更新頻率很大,開發(fā)成本很高;另一種是基本不用更新頁面,可節(jié)省存儲空間。
其次,通過原聲代碼對H5的資源類的多項請求操作實現動態(tài)管理,完成線上與本地的H5靜態(tài)資源的同步,即形成一張兩處資源的映射表。
發(fā)布之前,H5以手機端HTTP代理的方式訪問本地資源。發(fā)布之后,H5被發(fā)送到離線包管理器,在這里完成進行編譯打包,最后由離線包管理器借助相應的推送通道把H5的更新傳送到手機端,手機端接收到對應的更新指令后,執(zhí)行相應的下載與校驗工作。
然后,使用分包處理策略,解決H5資源多樣性的問題,分包時,將H5資源分兩大類,一類為高頻率更新代碼;另一類為低頻率更新的代碼[6]。執(zhí)行分包時,先將代碼進行分類,再按其具體類型進行分別分包,最后在手機存儲空間中進行分類存儲。
最后,通過解析線上與離線資源的同步映射表解決離線資源調用。系統(tǒng)中借鑒了較好的解決方案,讓H5生成映射規(guī)則,即線上與離線資源的同步映射表,而Native作為H5的容器通過解析這張映射表就可輕松地使用本地資源了。系統(tǒng)內部的資源訪問流程見圖3所示。
圖3 系統(tǒng)內部的資源訪問流程圖示
上圖中,代理服務表示發(fā)布之前H5以手機端HTTP代理的方式訪問本地資源。
系統(tǒng)的安全,指的是埋點數據輸入與傳送的安全,及本地硬件資源的訪問安全,都是安全要考慮的基本問題。
在系統(tǒng)中,用戶與系統(tǒng)交互的過程中所輸入的埋點數據及頁面跳轉的痕跡統(tǒng)一讓Native負責記錄和報備。另外將Native對本地資源的調用能力封裝成接口;H5調用這些接口對本地的資源進行間接訪問,如截屏、喇叭、麥克風、攝像頭、定位等功能的調用都一次需要調用相應的接口。
(1)書籍信息實體結構圖如下:
圖4 書籍信息實體結構圖
(2)已借書籍信息實體結構E-R圖如下:
圖5 借出記錄信息實體結構圖
(3)實體之間的關系E-R圖如下:
圖6 實體之間的關系E-R圖
APP界面設計采用簡潔易用的理念,配色與本學院的網站主頁相搭配協調,主界面及關鍵界面的設計見圖7、8所示。
圖7 個人信息中心界面設計圖示
圖8 當前借閱界面設計圖示
總之,Hybrid開發(fā)的高效帶來了開發(fā)低預算,加之其跨平臺的亮點;其增量式的版本更新,為舊版的BUG修復帶來便捷,這些足以讓很多開發(fā)者爭先去嘗試。
但是,Hybrid開發(fā)不是萬能鑰匙,用戶對APP的體驗上,與Native APP相比是有差別的,本課題中分析了使用Hybrid開發(fā)圖書館APP的詳細過程,歸結起來無非就是在解決如下4個問題:
(1)如何劃分Native與HTML5之間的服務點
(2)如何解決Native與HTML5之間通信
(3)如何設計離線更新過程、系統(tǒng)分包、系統(tǒng)資源訪問等邏輯過程
(4)如何封裝底層的通信API接口
雖然Hybrid開發(fā)是一種好的解決方案,但不是必選方案,在其應用還沒有十分成熟之前,要慎重選擇。