一個一線前端攻城獅的快應用開發之路：2、我與WebView的鬥智鬥勇
一、場景
在我們的產品的業務場景中，必須要引用一個特殊的第三方API：
- 這個API不能服務端封裝，只能客戶端自己引用SDK、自己初始化、自己呼叫。
- 初始化的過程比較慢，但一旦初始化過一次，在單次訪問中可以一直呼叫不失效。然而如果快應用每個需要用到這個API的頁面都初始化一次，則會等待時間較長，使用者體驗較差。
二、框架改造（1）：創造單頁快應用
當時的想法很簡單，想要一個全域性可用的、唯一的Web元件，那麼我就開始動手改造，大概步驟如下：
- 核心頁面就一個Container.ux頁面，裡面引入了很多元件，每個元件其實就是一個單獨的頁面，例如Home.ux、WebView.ux等。
- 新增加每個頁面的配置項，例如標題等，全域性配置項全域性儲存一個 [ 當前活動頁面資訊 ] ，只有一個頁面是顯示的；
- 我重寫了Redirect、Replace、Reload、Back、RemovePage等方法，自己模擬了頁面堆疊，當用戶點選頁面上的跳轉按鈕時，將新新頁面的頁面資訊寫入堆疊中，Container中由於data中的資料變化，則會自動顯示新頁面，隱藏原頁面。
- 當A頁面需要跳轉到B頁面時，A頁面需要傳送訊息給Container.ux，Container再呼叫同一封裝的PageHandler，PageHandler會做特定操作。
this.$dispatch('redirectTo',{ Url: 'Detail',Params:JSON.stringify({pid:1132, img:false})});
Container.ux監聽
that.$on('redirectTo',function (args) {controller.pageRedirectTo(that, args.detail.Url , args.detail.Params||'')});
二、框架搭建（2）：WebView通訊（基於1010版本）
單頁應用的形式改造好之後，我發現當前版本(1010)居然沒有網頁通訊的介面？如果兩邊無法通訊的話將會造成很多資料上和互動上的麻煩。當時一度以為：完了，感覺要涼涼。
雖然在群裡和論壇裡有收到回覆說後續新版本會有專門的通訊的介面，但是專案開發不能幹等SDK更新，因為即使官方立馬更新了SDK，十大廠商的覆蓋率也是個問題，新屬性新介面很可能沒辦法一下子投入使用。
於是我就開始研究現有介面，是否有可能通過現有介面來實現網頁雙向通訊？
最終研究出了這個方案：
實現原理
- 快應用端的Web元件的src從一開始就固定了，並且已進入應用實際上就開始執行那個特殊API的初始化。
- 快應用端通知H5：可以動態修改錨點，例如#login、#delete。也可以攜帶引數#get?id=1，#後一律視為錨點，因此引數需要在H5單獨解析。修改錨點不會引起網頁重新重新整理，因此不會存在重新整理後需要重新初始化的情況。
- H5端通知快應用：修改title，筆者是按照這種格式：
應用名-DELETE
解析後執行對應的DELETE事件，也可以攜帶簡單的引數：
應用名-ADD-sandklasnmd
第二個-斜槓後代表某個id值。格式不唯一，總之就是H5通過document.title來發送訊息。 - 快應用端監聽titleReceive，並對title進行解析，然後執行對應的操作。
綜合 [ 單頁應用搭建方案 ] 和 [ 通訊方式搭建方案 ]，我終於實現了WebView的理想操作，筆者內心可謂是激動不已：
WebView全域性可用，且只初始化一次,並且可以實現雙向通訊
三、框架優化（3）：WebView新通訊（基於1020版本）
在產品上線一段時間後，終於迎來了1020新版本，這次我立馬關注到了新增的message雙向通訊，看似非常好用的樣子！
但是！但是根據廠商釋出的最新的覆蓋率統計，目前仍有至少3個廠商完全不支援1020。支援1020的廠商，目前支援率也有高有低，如果直接使用的話，就意味著1010的使用者會無法使用我們的產品。因此，產品和市場的同事們並不同意我們立馬使用新特性……其實也在意料之中啦。
又過了一段時間，一方面官方最新統計的覆蓋率有了些許地提升，另一方面市場的同事說貌似不支援1020的廠商市場佔有率也不高，我們可以使用1020來主推幾個大的廠商，還有就是部分廠商在1010版本中有未解決的BUG，希望我們升級到1020，一方面可以解決前面版本已知BUG，另一方面可以使用1020很多新特性來優化自己產品的體驗。
終於，我就開始改造通訊方式，快應用和H5分別都有自己的postmessage和receiveMessage寫法，使用起來蠻方便的。並且我開始嘗試大資料傳輸，比如把一個列表資料從H5傳到快應用，完全沒有問題。想起來如果之前使用title傳遞的話，會不會位元組數就有限制了呢？這個倒沒嘗試過。
四、總結
總的來說，改造單頁應用和Web通訊其實還是蠻有意思的，的確在某個時間段解決了很大問題，真的感覺我在跟Web元件鬥智鬥勇，哈哈。如果有哪裡錯誤或者問題歡迎大家不吝騷擾~
快應用這門技術在不斷成長中，作為一個基層前端開發，我願意相信他會越來越好，也希望它能夠越來越好。
其實這筆者的這份分享並沒有大段的程式碼，想傳遞的還是一個思路、一個方案，能給大家一些啟發最好了。
預告下：後面筆者會專門做一篇 [ 音訊 ] 的分享，主要講的就是關於快應用音訊的種種操作，哈哈~