[乾貨] 有了微信小程序，誰還學ReactNative？

版權聲明：本文由賀嘉原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/145

來源：騰雲閣 https://www.qcloud.com/community

 

最近2天，互聯網圈和技術圈的熱點話題非微信「小程序」莫屬。有些文章從產品角度探討哪些類型的服務適合作成應用號，也有直接發佈內應用號的開發教程的。作爲騰訊雲的技術佈道師，我想換個不同的角度，從我熟悉和關注的移動開發技術棧的演進角度，講講移動開發技術下來可能會發生的變化，以及對於移動應用開發者可能帶來的三點重大影響。

HTML5在國內的流行與微信息息相關，一個小小的創業團隊用業餘時間開發的「圍住神經貓」這樣一個輕遊戲輕鬆就得到了上億次訪問，作爲一款現象級的產品直接拉動了國內企業與市場對於H5開發者的需求。核心的優點在於開發過程的足夠輕量，但同時這樣輕的技術語言自己也不是天衣無縫，「圍住神經貓」 這款遊戲自己沒有創建本身的用戶體系，帶來的實際問題就是上億次的用戶訪問並未沉澱在這個創業團隊手上，成爲他們真正的用戶資產。

React-Native作爲Facebook開源的移動開發語言，基本的理念是能不能JavaScript類的語法作移動端的開發，開發者只要去寫一次代碼，就能同時在ios和Andriod兩類手機操做系統上運行，減小移動APP開發的工做量。

咱們能夠看到應用號應該是經過API的方式將部分系統級的權限和微信獨有的社交和支付接口開放給了應用號，同時實現了React-native設計的初衷，一次開發，兩端運行。應用號所提供緩存、文件操做和websocket等接口，讓騰訊雲上的移動開發者有機會把本身的「小程序」作的比H5遊戲更重一些，這也意味着開發者能夠更好地在微信應用號的平臺上沉澱屬於本身的用戶資產。

圖1 移動開發技術棧的演進

微信應用號的開發語言是HTML標籤語言的子集，並且語言設計上有着React-Native的影子，有這兩種語言基礎的開發者學習應用號開發會更容易

今天，我在國內主流搜索引擎搜索「應用號開發「結果 2,660,000個，搜索」ReactNtive「 結果 2,140,000個。結果也能夠看出，已經流行了1-2年的react-native技術在熱度上比不上新出的應用號開發。個人預期是會有很多學React Native的人開始轉向應用號開發學習，沒有內測資格的會先學習微信服務號開發。

圖2 Html5-應用號開發語言-ReactNative三種語言接口、功能對比
注：以上應用號信息來自於騰訊科技報道

微信應用號所開放的手機LBS、文件處理、重力感應等「系統級接口」 加上微信自身的社交、支付接口，將會爲移動開發者極大賦能，開發者能夠更輕量級地開發出更多新的玩法

經過上表開發語言的對比看出，HTML5語言裏面雖然設計了必定的地理定位、系統信息獲取等涉及手機客戶端的底層能力，但實際上因爲手機操做系統的權限設計限制，這些接口的訪問都是須要系統受權的。
下圖是我分別在Safari瀏覽器和微信內置瀏覽器中運行HTML5的 獲取地理位置方法的結果：

1) Safari瀏覽器中getCurrentPosition的系統受權請求被屏蔽了，沒有提示，也沒法返回結果。
2) 微信中可以彈出getCurrentPosition的系統受權請求，在點擊「贊成」後，能夠反饋出手機對應的經度緯度。

圖3【LBS位置讀取】Safari瀏覽器 vs 微信內置瀏覽器

小程序（應用號）可讓你的應用火，而云計算可讓你在火了以後不會宕機

下圖是我我的預計大部分應用號的先後臺技術架構，應用號的前端的開發語言基本上應該是應用號擴展的HTML標籤語言+CSS+JavaScript，後臺服務的開發其實不管是用Python或者是Node.js應該都是能夠的。

可是對於預計訪問量較大，須要實現HA高可用的應用號而言，就須要考慮使用CLB負載均衡，CDN內加速，雲緩存等服務來保證應用的訪問體驗；若是涉及電商秒殺場景還能夠考慮使用騰訊雲的CMQ消息隊列；對於安全性要求較強的金融與遊戲類應用，則須要考慮接入大禹服務來抗DDOS攻擊、接入天御防刷服務來抵禦惡意用戶。

圖4 預期的應用號技術架構

小結：

微信小程序（應用號）的出現，伴隨着更開放的手機「系統級」接口和微信社交+支付接口，讓創業者有機會和H5時代同樣，打造出下一批現象級的互聯網應用。但云計算可以給這些受歡迎的應用號，提供高可用、高擴展與安全性。

一句話總結，「小程序可讓你火，雲計算可讓你在火了以後，不會宕機」。

附：咱們這邊寫的一個小程序demo，1小時就能夠快速搭建。