小程序架構設計(一)

標簽：dev   如何   云端   src   pen   繪制   業務   url   qpi   

在微信早期，我們內部就有這樣的訴求，在微信打開的H5可以調用到微信原生一些能力，例如公眾號文章里可以打開公眾號的Profile頁。所以早期微信提供了Webview到原生的通信機制，在Webview里注入JSBridge的接口，使得H5可以通過它調用到原生能力。

我們可以通過JSBridge微信預覽圖片的功能：

WeixinJSBridge.invoke(‘imagePreview‘, {
  current: https://img1.gtimg.com/1.jpg‘,
  urls: [
    ‘https://img1.gtimg.com/1.jpg‘,
    ‘https://img1.gtimg.com/2.jpg‘,
    ‘https://img1.gtimg.com/3.jpg‘
  ]
})

早期微信官方是沒有暴露這些接口的，都是騰訊內部業務在使用，很多外部開發者發現后，就依葫蘆畫瓢地使用了。

從另外一個角度看，JSBridge是微信和H5的通信協議，有一些能力可能要組合不同的能力才能完整調用。如果我們直接開放這套API，相當于所有開發者都要直接理解這樣的接口協議，顯然是很不合理的。

所以在2015年初的時候，微信就發布了JSSDK，其實就是隱藏了內部一些細節，包裝了幾十個API給到上層業務直接調用。

前邊的代碼就變成了：

wx.previewImage({
  current: https://img1.gtimg.com/1.jpg‘,
  urls: [
    ‘https://img1.gtimg.com/1.jpg‘,
    ‘https://img1.gtimg.com/2.jpg‘,
    ‘https://img1.gtimg.com/3.jpg‘
  ]
})

開發者可以用JSSDK來調用微信的能力，來完成一些以前H5做不到或者難以做到的事情。

能力上得到了更多的支持，但是微信里的H5體驗卻沒有改善。
第一點是加載H5時的白屏。在微信里打開鏈接后會看到白屏，有一些H5的服務不穩定，這個白屏現象會更嚴重。

第二點是在H5跳轉到其他頁面時，切換的效果也很不流暢，只能看到頂部綠色進度條在走。

隨著JSSDK的開放，還出現了更不好對付的問題。

微信上越來越多干壞事的人，有人做假紅包，有人誘導分享，有偽造一些官方活動。他們會利用JSSDK的分享能力變相的去裂變分享到各個群或者朋友圈，由于JSSDK是根據域名來賦予api權限的，運營人員封了一個域名后，他們立馬用別的域名又繼續做壞，要知道注冊一個新的域名的成本是很低的。

龍哥在2016年微信公開課上提出了應用號的概念，我們要重新設計一個新的移動應用開發模式，同時我們要解決剛剛提到的一些問題。

至此，我們回顧一下目前移動應用開發的一些特點：

1. Web開發的門檻比較低，而App開發門檻偏高而且需要考慮iOS和安卓多個平臺；
2. 剛剛說到H5會有白屏和頁面切換不流暢的問題，原生App的體驗就很好了；
3. H5最大的優點是隨時可以上線更新，但是App的更新就比較慢，需要審核上架，還需要用戶主動安裝更新。

我們更想要的一種開發模式應該是要滿足一下幾點：

1. 像H5一樣開發門檻低；
2. 體驗一定要好，要盡可能的接近原生App體驗；
3. 讓開發者可以云端更新，而且我們平臺要可以管控。

很多人可能會第一時間想到Facebook的React Native(下邊簡稱RN)，是不是RN就能解決這些問題呢？

是的，React Native貌似可以解決剛剛那些問題，我們也曾經想用RN來做。但是仔細分析了一下，我們發現了采用RN這個機制做開放平臺還是存在一些問題。

1. RN只支持CSS的子集，作為一個開放的生態，我們還要告訴外邊千千萬萬的開發者，哪些CSS屬性能用，哪些不能用；
2. RN本身存在一些問題，這些依賴RN的修復，同時這樣就變成太過依賴客戶端發版本去解決開發者那邊的Bug，這樣修復周期太長。
3. RN前陣子還搞出了一個Lisence問題，對我們來說也是存在隱患的。

所以我們舍棄了這樣的方案，我們改用了Hybrid的方式。簡單點說，就是把H5所有代碼打包，一次性Load到本地再打開。這樣的好處是我們可以用一種近似Web的方式來開發，同時在體驗上也可以做到不錯的效果，并且也是可以做到云端更新的。

現在留給我們的最后一個問題就是，平臺的管控問題。

怎么理解呢？我們知道H5的界面結構是用HTML進行描述，瀏覽器進行一系列的解析最終繪制在界面上。

同時瀏覽器提供了可以操作界面的DOM API，開發者可以用這些API進行一些界面上的變動，從而實現UI交互。

既然我們要采用Web+離線包的方式，那我們要解決前邊說過的安全問題，我們就要禁用掉很多危險的HTML標簽，還要禁用掉一些API，我們要一直維護這樣的白名單或者黑名單，實現成本太高了，而且未來瀏覽器內核一旦更新，對我們來說都是很大的安全隱患。

這就是小程序一開始遇到的問題，在下篇文章《小程序架構設計(二)》，我們再詳細展開一下小程序是如何解決以上這個問題的。

小程序架構設計(一)

標簽：dev   如何   云端   src   pen   繪制   業務   url   qpi   

原文地址：https://www.cnblogs.com/feng9exe/p/15000300.html