程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> 網頁編程 >> PHP編程 >> 關於PHP編程 >> Hybrid app開發歷程分享

Hybrid app開發歷程分享

編輯:關於PHP編程

Hybrid app開發歷程分享


關於這個話題,本文並不准備詳述移動開發相關的一些通用技術,例如:viewport、rem、flexbox、媒體查詢等。這裡主要講述我們的hybrid產品策略、開發流程與規范、性能優化以及我們踩過的坑。而往往就是這些,網上相關的資料相對比較匮乏的,又缺少類似經驗文章,所以希望通過此篇文章,跟大家分享一些魅族團隊關於hybrid產品開發的經驗。

產品背景

  1. 我們希望這一類產品具備比較強大的運營能力;
  2. 接口數據來自於cp數據整合,可能會有一定的差異性,甚至需要一定的容錯能力;
  3. 要求能夠實現快速更新和迭代。

Android與H5集成方案

在以上背景下面,我們最終選擇了Hybrid App這個方案。那麼,接踵而來的問題就是,客戶端該如何訪問網頁前端資源?能不能就采用以前浏覽器訪問服務器網頁的方式呢?答案不是絕對的,當然也可以采用上述的方式。根據不同的業務需求,方式總是會有不一樣的。我們采用最多的是以下兩個方案:

靜態資源本地化

該方案,會先在app裡面內嵌一份靜態資源,然後在用戶啟動app或者訪問html頁面並且符合一定條件的情況下,會發送請求去後台,詢問資源的情況。如果發現有更新,那麼就把最新的資源下載到本地,然後接下來用戶訪問的都是本地的靜態資源了。如果更新失敗,那麼他訪問的就是內嵌的或者已經下載好的靜態資源。

HTML 5 應用程序緩存

這個方案,其實就是采用HTML5的應用程序緩存(HTML5 Cache Manifest )。在這裡就不詳述了,網上關於這個的資料很多。值得注意的點,就是manifest的配置文件,需要配置正確的MIME-type,即 "text/cache-manifest" 。

一般是在開發一些活動或者專題頁面(上線時間短,ui變化多端)的時候,采用第二個方案。

而大多數的app頁面都是相對穩定,或者說是迭代開發,定期更新的,具備規律性,這種情況下,我們采用的是第一個方案。采用這個方案的時候,我們需要嚴格控制資源文件的大小,除了必要的壓縮之外,還可以把長期固定的資源提取出來,提前內置到app裡面。那麼,用戶每次更新資源時,只需要去服務器獲取變化的部分,大大減小了流量使用。

以上兩個方案,相對於每次都訪問服務器靜態資源來說,具有明顯的優點:

  1. 離線訪問
  2. 資源加載快
  3. 服務器負載低

頁面加載

首先,客戶端加載某頁面,加載完成後(pagefinish),客戶端會調用前端提供的初始化方法(initParams)。通過該方法實現參數的傳遞和頁面的初始化。

資源構建

我們目前使用fis3進行資源的壓縮、合並、添加 md5 戳等構建功能,對於使用了es6的項目,還需要用到Babel。在此基礎上,我們還開發了一些內部使用的基於fis3的插件。最終的目的,就是為了實現一條命令行,完成全部構建工作。

開發環境搭建

搭建本地web服務,使用的是nodejs+express。

開發流程

從上圖我們可以看出,視覺設計、前端開發、客戶端開發、後台開發都在很大程度上實現了並行開發。

接下來,簡單描述一下前端開發怎麼實現和後台,還有和客戶端解耦,然後實現並行開發的。

首先,接口文檔(後台接口文檔和客戶端接口文檔)是不阻塞的前提。有了後台接口文檔,我們就可以依此構建相應的假數據,並且模擬相應的接口請求。而有了android接口文檔後,我們也可以模擬調用客戶端接口,至少保證了基本的邏輯是順暢的。所以,只要有了接口文檔,在進行到真正的聯調之前,前端、後台、客戶端這3者都是獨立開發,互不阻塞的。

然後聯調的話分三個階段:

模擬假數據聯調

這個階段的話其實只需要編寫一些假數據在本地,然後用ajax請求就行了。而android接口的調用,也是模擬調用便可。在這一階段,主要是為了確保前端邏輯基本跑通。

後台真實接口調用

到了這已階段,我們需要的是訪問本地靜態資源,調用的卻是遠程服務器的接口。此種情況下,主要是要解決ajax的跨域請求問題。實現方式也挺多的,最簡單的就是設置一下浏覽器支持跨域。當然,你也可以使用nginx或者apache的反向代理來實現ajax的跨域請求。

三方聯調

這一步,已經到了提測前的最後一個步驟。這個時候,客戶端已經和靜態資源集成,然後調用的接口,無論是android接口還是後台服務器接口,都不再是模擬的了。

3種聯調狀態的切換,無論是在開發、bug定位、頁面調試等情況下,都是經常需要使用的。比如你在修改某個js邏輯bug的時候,首先,你一般都是從第二種聯調步驟開始的,畢竟在pc浏覽器上面調試bug還是要方便挺多的。然後,等到bug改得差不多了,才會把靜態資源push到手機上面,進行真機調試。

接下來就產生了一個問題,如何實現這3種聯調狀態的靈活切換呢?我們來看一段代碼:

2345678910111213141516171819202122

為了實現3種聯調狀態的切換,我們基於fis3開發了一個插件,這個插件的功能也很簡單,就是處理上面這段代碼。

如何處理呢?首先看一下上面這段代碼,它可以分為兩個模塊,第一個是模擬代碼模塊(用和包起來),第二個是真實代碼模塊(用包起來)。模擬代碼模塊包括了一個模擬android接口的js文件引入、假數據的路徑以及模擬android調用初始化接口。真實代碼模塊可以寫一些真正上線需要使用到的路徑。這兩個模塊都不是必需的。

插件需要做的,就是把模擬代碼模塊去除,把真實代碼模塊釋放。

再來說說這樣做的好處,在模擬假數據聯調的階段,不需要使用到該插件,那麼此時根據上面的那段代碼,運行的就是模擬代碼模塊。而一旦我們要進行真正的接口聯調的話,就需要在fis3的parser階段調用該插件,以實現去除模擬代碼並使用真實代碼。而插件的使用,是在fis3的配置文件裡面進行配置的,通過fis3的media api,我們可以實現動態控制插件是否使用。

性能優化和坑

這是一個比較大的話題,像那些大家已經耳熟目染的雅虎十四條等頁面優化准則和資料,那是非常之多。我在這裡,會盡量從我們的項目角度出發,列舉部分我們所做的優化和解決的一些難題。

圖片

能不用的情況下,盡量不用。非得用的話,可以從多個角度進行優化。比如:

  1. 放在cdn,讓資源離用戶近一點,同時也減少了cookie等非必要數據的傳輸。
  2. 采用CSSSprites減少請求量。
  3. 使用WebP減少圖片體積。
  4. 小的icon可以使用base64:URL圖片。
  5. 有些情況,你是沒辦法從技術角度進行優化的,可能需要在盡量不影響用戶體驗的情況下,調整ui或者產品方案。比如ui同學設置了一個不規則模糊漸變的背景圖片。那麼這種情況下,就不得不通過保留模糊漸變,但是讓其有規律性,這樣可以通過截取小部分的圖片,然後通過平鋪的方式來實現了。有時候不得不做這樣的權衡,選擇一個折中的方案。

viewport

關於視口寬度的設置,目前比較通用的兩種方式:

  1. 寫死固定的寬度
  2. 設置為設備寬度

第一種方式,簡單方便,不需要媒體查詢,不需要rem等,一個版本,適配所有機型。而且關於頁面精細度的問題,當視口寬度設置的比較大的時候,線條、字體等可以實現更加精細化的控制。

關於第二種方式,目前大部分大公司的移動端都是采用這種方式的。這種方式性能要比上一種高,畢竟少了一個縮放的過程,然後兼容性方面也是比較好的。

所以經過上述比較後,我們推薦第二種方式的。但是我們也發現,在和一些其他公司的人溝通過程,他們由於各種原因,還是采用了第一種方式。同時,我們也有一些項目,也是采用的第一種方式實現的。

而在采用第一種方式的情況下,我們發現,有些時候頁面加載的時候,繪制效果不是很好,會有一個從左到右平鋪的過程(其實就是一個縮放的過程)。關於這一點,其實是可以通過opacity的控制來優化效果的。

動畫

動畫這一塊,想必就是Hybrid app的一個痛點。想要在android內置的webview裡面,實現和android差不多效果的動畫,其難度實在是太難了,而且還會遇到挺多坑的。

比如,在做影院訂座頁面的時候,座位的選擇區域是要能夠進行縮放的。有了這個功能需求後,我們就要開始開發了。

關於縮放,我們首先想到的就是css3裡面transform屬性的scale值。接下來,我們就采用了scale方案進行開發。

動畫開發的歷程總是坎坷的,果然,問題出現了。選座區域的座位,在進行了手動放大後,變得相當的模糊。

也許你會想,是不是由於采用了圖片,然後圖片進行放大變得模糊,那也是情理之中的。好的,那麼接下來,我們嘗試著,直接使用css設置背景顏色的方式進行座位繪制。但是,這樣做的結果是,放大的時候,還是模糊了。

在這種情況下,我們就需要靜下心來思考一下了。到底是為什麼呢。

在描述原因之前,先要引入另外一個古老的css屬性zoom,並分別講一下這兩者的區別:

  1. zoom一開始只是ie浏覽器的私有屬性,後來大部分的浏覽器都兼容了該屬性的使用,但是畢竟還是沒能寫入規范。而scale則是寫入w3c標准的。
  2. 渲染順序不同。scale先宣染後縮放,zoom縮放後進行渲染。
  3. scale相關的控制參數較多,比如縮放原點、縮放方向等。而zoom默認的縮放原點就是左上角,然後也沒有直接的參數能進行縮放原點的修改。

根據上面列舉的幾點區別,我們可以得出以下結論:

  1. 使用zoom進行縮放,視覺效果會變得銳利。而采用scale進行縮放,視覺效果會變模糊。
  2. 使用zoom進行縮放,可能會引起頁面重排。而采用scale進行縮放,不會引起頁面重排。
  3. 使用zoom進行縮放,受限於html渲染規則,比如字體最小是12px的話,你再怎麼縮小,字體還是12px。而scale則不會。

接下來講一下座位放大後變模糊這個問題應該怎麼解決。根據以上結論,得出兩個解決方案:

  1. 使用zoom進行縮放,這樣就可以解決放大模糊的問題。
  2. 使用scale進行縮放,但是第一次的時候scale值設置得大一點,比如3(3倍大小)。然後再偷偷(setTimeout之類的)的把scale設置為1倍。

關於動畫的優化,就先講這一個列子,但是實際上,在我們的hybrid app開發過程中,還有很多的優化歷程,當然也踩了很多的坑。有興趣要了解的,可以試用一下魅族的生活服務,活動中心,電話黃頁等app,這些都或多或少的使用了hybrid方案進行開發。

結語

目前前端技術日新月異,我們在不斷的嘗試一些新的技術(react、es6等),不斷的緊扣一些細節,不斷的優化再優化。這一切,不是短短一篇博文所能講完,後續我們會有新的內容加入進來一起討論學習。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved