論移動端Hybid開發

　　如下內容code地址：https://github.com/wytings/Hybrid

 

　　背景：公司業務的發展和開發需求升級，咱們須要Hybrid了。市面上有不少開源的Hybrid框架給咱們直接使用，可是通過一段時間的嘗試與研究，我司最終選擇本身開發一套相對簡潔的Hybrid框架。不少人會疑惑，爲何還要造輪子？由於咱們以爲這些「輪子」，並非很適合咱們，咱們評估後，以爲再造一個「輪子」反倒成本更低。

　　前言：咱們應該要時刻注意到不要讓本身的開發被新技術所引導或者迷惑！咱們要明白咱們開發一款產品的根本目的是幹嗎的？是爲了使用這些技術嗎？不是！咱們是爲了更好的實現咱們產品的需求和用戶的需求，從而更好的服務咱們的客戶。因此，除了單純技術上的研究外，產品開發必定要「按需」。咱們這麼作須要什麼樣的技術去實現是最適合的就用哪個。實際開發過程當中是很難有最好的解決方案，更多的是隻有最適合你的解決方案。

　　So that's why we do it , and it's also the main purpose of《論移動端Hybid開發》……

　　我打算從 Why（爲何使用H5的緣由）、WhyNot（爲何不使用其餘框架）、How（怎麼進行H5與Native的交互）這三個主要方面來闡述這個問題。

　　補充備註：這裏用H5來描述可能比較狹隘，其實更準確來講應該是Web。可是如今移動端一提到Web就H5，也就順應潮流一波。同時也想吐槽一下，居然有H5開發工程師這種職位……是否是之後也會有Java8開發工程師、Android7.0開發工程師、Python3開發工程師……

　　1、爲何APP要使用H5

　　使用H5的優勢是很是明顯的，大體有如下幾點：

1. 提升開發效率和敏捷迭代頻率。一套代碼多端使用，維護成本低。
2. 能夠繞過應用市場的審覈。這點可能Android端體會沒那麼明顯，但iOS端每次提交App Store的成本仍是蠻高的。
3. 遠程更新代碼。雖然Native經過必定的方式也能夠進行不更應用進行局部一些代碼的更新，可是相比H5就差太遠了。
4. 更強的組件化和複用率。因爲一套代碼多端使用，從而避免了Android端和IOS端都須要各開發一套。

　　使用H5的優勢這麼明顯，這也是爲何H5被捧上天的緣由（坦白說，我也以爲之後H5的將來比native要光明……）但爲何你們不全使用H5呢？這裏就不得不在褒獎的同時也要打擊一下H5。由於它也有一些天生的缺點是當前沒辦法避免的。

1. 流暢性沒有native好。這也是爲何H5不能替代App最主要的緣由。這個流暢性不只僅是指操做上的，也包括頁面顯示，要知道Web的開發基本都是默認以一個比較穩定的網絡情況下進行的。這可不是移動App能保證的。
2. 用戶交互性比較差。簡單說就是體驗性不如Native好。並且因爲移動端系統操做的差別性，Android和iOS有着不同的使用習慣和操做。Web所謂的統一的一致交互性就很難與系統保持一致。

　　在用戶體驗至上的時代，H5的這些缺點使得它不能替代Native的開發，而且很是不適合作一級頁面的展現。可是又不得不認可它的優勢如上所敘倒是很是的誘人。咱們想保留native更好的體驗，同時也想使用H5的靈活性，意味着咱們得讓H5具有必定的Native能力，也就是H5得有能力調用一些Native的接口，也正由於如此，Hybrid框架便應用而生。若是是單純的網頁顯示，是不須要什麼Hybrid框架的。因爲H5更多的是App開發的一種輔助性開發工具，因此H5一般狀況下會使用在某個模塊，或者某個類型的頁面等等。

　　另外，我之因此以爲H5要比Native要光明一些，是由於我相信之後H5的運行環境必定會比如今好不少。因此，以前沒怎麼學習過H5的同窗能夠抽空多學習學習～

　　2、爲何不使用其餘框架

　　咱們依然選擇去開發一套本身的框架，是由於咱們以爲市面上所謂的成熟產品對於咱們來講不是太複雜就是太臃腫了，咱們拿Cordova 來講吧，要使用Cordova須要倒入不少Cordova的文件，並且還要實現不少所謂的plugin才能使用，咱們測試發現Cordova的性能是很是不友好的。要知道，JavaScript和Native 的通訊性能都是幾十毫秒級別的，因此這是Cordova自己的問題……這些還不是主要的，更主要的是Cordova內存泄漏很是之嚴重，特別是iOS端，打開個網頁分分鐘100M……

　　而其餘的，各個都標榜本身很強大如同宇宙航母同樣，可是其實咱們真正須要的真的就是幾輛自行車，撐死也就是三輪車，這也是引入其餘框架帶來的一些不可控的地方。Hybrid帶來的彈性與代價老是並存的，要恰到好處是很是的難的，只能儘可能最優。

　　當你要引入一個框架的時候，你想一想咱們真的有那麼大的需求頻繁更新代碼嗎？一套代碼多端使用，看似節約成本，可是實際操做的過程當中，真的節約了嗎？各個公司可能有差別，可是咱們當前現狀的答案是沒那麼頻繁，爲了支持Web的native功能，咱們也沒發現有多節約成本。更多時候出現的狀況是：這個仍是Native來實現比較適合……因此，咱們選擇本身實現！即沒有多少開發的代價，同時也可以充分保證使用的靈活性。

　　3、H5與APP怎麼交互（以Android爲例子）

　　當咱們決定要本身作了之後，咱們就須要知道JavaScript是怎麼跟Native進行溝通的。Native和Web的交互實現原理其實仍是蠻簡單的。

1. Native －> Web：就是WebView注入JavaScript，直接執行Js代碼，在Android形如：「javascript:[js執行代碼]」；
2. Web －> Native：就是利用WebView攔截私有協議請求進行相關的操做並返回，由於Web能夠執行特定的url從而觸發咱們Native的過濾條件；

　　由於Native和Web之間的交互都是以一個字符串進行的因此咱們就只能約定某些字符串格式，使得其包含要進行的操做以及相應的數據；

　　就單向請求來講是很簡單，可是如何支持回調操做呢？

　　首先一點，咱們已經肯定了Native和Web的交互就是上面描述的這個惟一的形式。因此，大概的思路就是以下：

　　一、App接收到Web的請求，執行完指定的動做後，執行一個所謂的回調方法；

　　二、該回調方法實際上執行的是一個JavaScript注入，去通知Web，該操做已執行完；

　　三、Web收到這個消息後，即可以執行相應的方法而後完成所謂的回調操做；

　　同理，Web接收到App的請求也是如此；

　　

　　按照上面的邏輯，咱們即可以在App向Web發送消息時，把回調接口保存在一個Map<Integer,CallBack>中，而後Web執行完後即可以向Native發送一個特定的消息來觸發Native中Map保存的回調接口實現一個邏輯上的回調操做！

　　原本想貼代碼上來，可是往回一滾，已經洋洋灑灑這麼多行了……直接去看代碼吧……