
目前 按照 APP 開發分類,分為以下三大類
- 原生
[APP
Android
]Swift
-
WEB APP
-
[混合Hybrid App
]APP
在找工作的當中,很多崗位 要求 會開發
H5 App
,那到底什麼是
H5 APP
呢?
一開始我也有點疑惑,沒接觸這塊,按自己了解 就是 采用
HTML5
技術開發出的頁面應用 跑在移動端當中。
下面引用 阮一峰對
H5
開發解釋。
真正了解 H5 開發,需要先搞清楚什麼是原生 App、什麼是 Web App,因為混合 App 是在它們的基礎上誕生的
H5 這個詞,可以了解成就是混合 App 模型,隻不過它特指混合 App 的前端部分。
因為混合 App 的前端就是 HTML5 網頁,是以簡稱 H5。這個詞是國内獨有的,基本上都是前端程式員在用,國外不用這個詞,就直接叫混合 App。
來對比一下 三種開發模式差別
原生APP
在這裡就不讨論原生APP的優點了,想必大家都知道。主要圍繞缺點來說
- 需要 開發 兩套 代碼
和Android
IOS
- 舊版本出現
無法更新修改,必須使用者 下載下傳 更新bug
- 發版稽核時間長,無法随時更新
Web APP
優點
- 入門簡單,成本低 (前端三件套)
- 可以同步更新
- 可以跨平台
缺點
- 不能直接通路裝置硬體和離線存儲,功能受限( 相機,藍牙.......)
- 音視訊體驗不好
混合APP
優點
- 開發效率高
- 更新和部署友善,不需要稽核,隻需要在伺服器端部署
- 代碼維護友善,版本更新快,成本低
缺點
- 需要了解
才能更好的開發原生開發
。H5
- 需要熟知
與原生開發
的各種通信和相容性問題。H5
什麼是 Hybrid App
Hybrid App
[ 混合 APP] 指 原生
APP
和
WEB APP
的結合體。它主要是以
JavaScript
+
Native
[ APP 原生] 兩者結合互相調用使用。
混合 App 的原生外殼稱為"容器",内部隐藏的浏覽器,通常使用系統提供的網頁渲染控件(即 WebView 控件),也可以自己内置一個浏覽器核心。結構上,混合 App 從上到下分成三層:HTML5 網頁層、網頁引擎層(本質上是一個隔離的浏覽器執行個體)、容器層。
為什麼要采用 Hybrid App
Hybrid App 主要是用來優化 原生
APP
WEB APP
的缺點誕生的新技術,但也有自己的不足。
優點
-
跨平台
Web 技術是跨平台的,開發者隻寫一次頁面,就能支援多個平台。也就是說,混合 App 隻需要一個團隊就夠了,開發成本較低。
-
靈活性
混合 App 的靈活性大,很容易內建多種功能。一方面,混合 App 很容易加載外部的 H5 頁面,實作 App 的插件結構;另一方面,Web 頁面可以友善地調用外部的 Web 服務。
-
開發友善
Web 頁面的調試和建構,遠比原生控件簡單省時。頁面的更新也容易,隻要在伺服器上釋出新版本,觸發容器内更新就可以了。另外,Web 開發人員也比較容易招聘,傳統的前端程式員可以承擔開發任務。
缺點
- 性能不如
, 但相對原生原生 APP
輕量
- 頁面跨平台,無法保證多平台統一。
- 需要 前端人員有 原生開發(IOS/Android) 經驗,才能完美的上手開發出體驗比較好的 混合APP。
什麼時候 采用 Hybrid App 應用
- 對于原生性能要求沒那麼高
- 企業會根據團隊前端技術進行選型
- ......
混合開發任務配置設定原則
- 業務關聯性強的
做H5
-
H5
都能做的,盡量使用原生
來做H5
-
做不了的,H5
原生
- 互動性強的
做 [ 體驗佳 ]原生
原生 與 H5
互動
H5
H5
互動主要是采用
JSBridge
它給 JavaScript 提供調用 Native 功能的接口,讓混合開發中的前端部分可以友善地使用 Native 的功能(例如:位址位置、攝像頭)。JSBridge 的功能不止調用 Native 功能這麼簡單寬泛。實際上,JSBridge 就像其名稱中的Bridge的意義一樣,是 Native 和非 Native 之間的橋梁,它的核心是建構 Native 和非 Native 間消息通信的通道,而且這個通信的通道是雙向的。
雙向通信的通道:
- JS 向 Native 發送消息: 調用相關功能、通知 Native 目前 JS 的相關狀态等。
- Native 向 JS 發送消息: 回溯調用結果、消息推送、通知 JS 目前 Native 的狀态等。
最後
相信看到這裡的朋友,對于 APP 技術選型 有 大概了解了,每項技術都有優缺點,主要看這項技術是否滿足目前項目業務大部分場景,小部分單獨優化處理。
關于 APP 開發,你有何看法?