騰訊IMweb Conf 2017大會圖文筆記 — 下

AleCC發表於2019-03-03

Web筆記

下午的乾貨就比較多，我主要是在Node分場+小程式架構剖析，其他的沒有整理了。

早上的整理連結《騰訊IMweb Conf 2017大會圖文筆記 — 上》。

《Egg&node從小工坊走向企業級開發》– 天豬@阿里巴巴
《WebIM大流量柔性微服務實戰》 — 唐俊俊@騰訊
《小程式你所不知道的：核心架構剖析》– 王躍@騰訊
《大前端全棧修煉之道–愈演愈烈的Node.js》 — 狼叔@得到/羅輯思維
圓桌會議分享 — 問與答

分享是最好的學習，IMweb Conf 收穫良多。

——————————————————–

一、《Egg&node從小工坊走向企業級開發》– 天豬

— 寫著寫著筆記：突然發現講師的PDF已經出來了，傳送門：[github]《Egg & Node.js 從小工坊走向企業級開發.pdf》。

大會上說了阿里的Node使用情況、Egg是如何跨團隊構建的，Egg版本Timeline，作為補充。

— Egg 寓意“孵化新生”，在它之上可以快速的孕育出各式各樣的 Web 應用。官網eggjs.org/

— 一直以來，Node.js以其靈活、快速迭代的特性在阿里內部得到了廣泛的應用。Node.js現在不僅替代了過去使用PHP和Jave Web的部分場景，而且還成為了阿里整個框架內基礎設施和接入設施的橋樑。但是隨著Node應用和Node開發者的數量不斷增加，一些問題也隨之暴露出來。這裡主要體現在以下三點：基建缺失、重複建設和各自為戰。

二、《WebIM大流量柔性服務》– 唐俊俊

— 旁邊美女說，臺上的講師是不是在念稿子的啊，怎麼可能說的那麼快呢？

主要是講在區域網網環境中開發第三方即時IM，沒接觸過的樓主在下面聽得有點蒙（閒魚呆滯），介紹企業WebIM的特點，Socket.IO架構/技術選型，跨進程式訊息傳送和nconp框架。

(我沒記錯的話，所謂柔性化處理是在對在websocket佔用服務端資源峰值與低估差的距大時採取長輪詢減少峰值、低估，以達到穩定的區間。)

三、《小程式你所不知道的：核心架構剖析》– 王躍

(感謝王躍老師分享的ppt)

王躍老師：大家好，我今天分享的主題叫：《小程式你所不知道的：核心架構剖析》，首先宣告下，我不是知識的原創者，我只是知識的搬運工，為什麼這麼說呢，大家都知道，我
們小程式的同事每天都忙著在半夜給大家釋出新功能（這不昨晚又釋出了1.0beta版開發者工具），自然也就沒時間給大家做分享了，所以今天呢，我就自告糞勇，幫大家把小程式底層實現的一些邏輯和涉及到的關鍵技術給梳理了下，算是拋磚引玉，希望能對各位現在或者今後的工作有幫助。講得不好呢，大家噴我就行，與小程
序的同事無關哈。

我想，在做的各位應該都不熟悉我，雖然斷斷續續做了10多年了前端，但是作為這麼牛逼的前端會議的分享嘉賓，實屬首次，所以有點緊張，請大家見諒，接下來還是按照慣例，給大家做下自我介紹！

我叫王躍，來自騰訊互娛，對，沒錯，就是那個傳說年終獎幾百萬的部門（當然我沒這麼多啦）我學的就是計算機，畢業後一直從事開發的工作，在搜狐做過SNS白社會，在新浪做過微博，現在在騰訊做道聚城專案，中途還創了2次業。有想交流創業經歷的朋友下來我們也可以單聊哈。那閒話不多說，接了下來我們進入正題。

今天分享包括3部分，xxx，會很快帶過去，xxx和xxx會重點講，好。。。。

一、基本概況

非官方統計，騰訊內部各個部門釋出的小程式呢，已經超過***款，後面會給大家展示一下。

而整個小程式生態，無官統，敏感，沒預估的火爆，但看到，整行的關投都在不斷的增加，而微信與微信生態整合，畢竟微信有近10億使用者，1~2年後，小程式會成為新產品釋出的首選形式和渠道，特別是對於創業公司，所以今分很有價值。(此處省略N字…)

已經發布的小程式整體體驗來說，還是很不錯的，唯一需要積累和改變的就是使用者習慣。比如我之前很多時候還是習慣用摩拜app來掃碼，而不是微信，唯一阻礙我的其實就是習慣，但是在各種渠道持續提醒我使用小程式的時候，我現在也就開始使用膜拜小程式了。

chrome相關的技術：webkit，v8，nwjs，devtools,extension等，涉及很多種框架，整個實現，相對還是比較複雜的，當然我們今天不會細講涉及到每一種技術啦，關鍵還是分析小程式整體架構和核心技術點。

開發者工具，整體基於nwjs平臺，用react前端框架實現，並且綜合了chrome
devtools，extension和Monaco線上程式碼編輯器整合而成，自從atom出來後，很多客戶端都可以基於web平臺和技術來實現，跨平臺，元件化，開放生態，所以非常方便。

不知道在座有多少人做過小程式開發，然後又有多少人把釋出後的小程式包解壓後研究過，不過沒看過也關係，這裡我們就一起來看下：開發目錄，wxa的壓縮包，解壓看到，目錄結構基本一致，然後主要注入了提供基礎能力的庫檔案。具體檔案的功能這裡給大致介紹一下。

二、整體架構

樹形結構圖，粗粒度拆分下的話，小程式由三部分來組成，看得見的部分view，看不見的部分service，附屬配置（看得見和看不見），先分析View，到native，再分享service到native，然後再講view，service到native的雙向通訊，view到service的雙向通訊，native到view，service的單向通訊。

眾所周知，小程式的每一個page，有4個檔案，WXML，WXSS,
JS,JSON，我們這裡把WXML和WXSS定義為View部分，由一個webview承載，幾個page就會開啟幾個webview，而JS和JSON的程式碼我們定義為Service部分，也就是我們的主要的業務邏輯部分，它承載環境這裡沒有標註，後面我會詳細講，因為平臺不同有不同的承載方式，最下面是Native部分，提供基礎能力，三部分之間的通訊是通過訊息的方式來實現的，這個後面也會詳細講到訊息的流動路徑。

前面講到，view和service是分開的，我想問下，$(‘#id’)這種方式還能用嗎？不用著急回答，大家可以思考一下，如果不能用，那是從技術上是否以實現，怎麼實現？

第二部分，實現的技術細節，也是今天最重要的部分，希望大家還沒睡著~~~沒睡著的同學可以叫一下旁邊已經睡著的同學們，接下來都是乾貨哦。。。。

涉及三個平臺，而不同平臺的實現又不一致，所以我這裡會按平臺分開了來分析。

首先搞清楚哪部分是View

還是回到我們之前解壓的這個檔案包來看。。。。我們這裡把View具化到檔案上，主要就三個檔案，wawebview,page-frame,xxxx.html,那這裡的View問題就變成了在不同的平臺下小程式是用什麼環境來執行他們的，並且怎麼和其它部分通訊的，很明顯在pc上，開發者工具是基於nwjs，node+webkit實現的，所以。。。。

所有頁面都用一個模板檔案來負責載入,相關的js都會注入到這個模板檔案。

wkwebview+webview，這個其實跟webkit原理一樣jscore webcore webkit。

記得將多個webview的好處，並行，隔離，簡單，高效，以記憶體換效率。（紅色表示最重要、最核心的部分）

搞清楚哪部分是Service，還是回到我們之前解壓的這個檔案包來看。。。。我們這裡把Service具化到檔案上，主要就三個js檔案，waservice,app-config,app-service.js,這裡的Service問題就變成了在不同的平臺下小程式是用什麼環境來執行他們的，並且怎麼和其它部分通訊的。

PC的Serivice也是一個執行在Chrome中的一個html頁面，這個頁面載入了三部分JS，這裡我們可以清晰的看到。

JavaScriptCore是webkit的一個重要組成部分，主要是對JS進行解析和提供執行環境。程式碼是開源的。iOS7後蘋果在iPhone平臺推出，極大的方便了我們對js的操作。我們可以脫離webview直接執行我們的js。

V8是一個由丹麥Google開發的開源JavaScript引擎，用於Google
Chrome中，V8在執行之前將JavaScript編譯成了機器碼，而非直譯它，以此提升效能。這裡的v8不是原版的v8系統，而是x5提取出來的一個版本。（紅色表示最重要、最核心的部分）

模組實現，App，Page，getApp，getCurrentPages等，wx.xxx下面所有的方法，

Message

通過window.postMessage實現（使用chrome擴充套件的介面注入一個contentScript.js，它封裝了postMessage方法，實現tab之間的通訊，並且也它通過chrome.runtime.connect直接操作chrome
native原生）

傳送訊息：

window.postMessage(data, ‘*’);，// data裡指定 webviewID複製程式碼

接收訊息：

window.addEventListener(‘message’, messageHandler);複製程式碼

在contentScript裡面看到一句話，證實了appservice也是通過一個webview實現的，實現原理上跟view一樣，只是處理的業務邏輯不一樣

`webframe` === b ? postMessageToWebPage(a) : `appservice` === b && postMessageToWebPage(a) 複製程式碼

通過 WKWebview的

window.webkit.messageHandlers.NAME.postMessage

實現,微信navite程式碼裡實現了兩個handler訊息處理器

1、invokeHandler: 呼叫原生能力

2、publishHandler: 訊息分發

通過 WKWebview的

window.webkit.messageHandlers.NAME.postMessage

實現,微信navite程式碼裡實現了兩個handler訊息處理器

1、invokeHandler: 呼叫原生能力

2、publishHandler: 訊息分發

Compent — 對比Polymer與小程式

王躍老師：“這裡有人應該會問小程式為什麼沒有采用Polymer？這裡微信團隊同事說喚醒WebView也需要消耗的，大概耗費300ms，所以效能是瓶頸。然後他們自己重寫了類Polymer的形式，效能差不多（王躍老師說他們謙虛了）”。

以下截圖為分析內容：

Optimize

page：一般不超過5個，超過後小程式就會自動複用
size：一般不超過2M
Dom：一般不超過16000
Data：會佔用記憶體，資料傳輸jsBridge會耗時，只要setData自己有用的資源就可以了
動畫：可以用css3解決
請求：小程式使用的是service worker
渲染：diff演算法

預載入優化
- 小程式會在開啟一個頁面的時候，先載入下一個頁面的page_frame，載入時會自動拷貝page物件，因此，我們可以提前在page物件裡注入資料。
- 開發者可以自己預測使用者可能會點選的下一個頁面，並將數值快取到localstorage
- 對媒體資源如圖片等設定長寬，防止reflow的時候畫面閃動（AMP）