下午的乾貨就比較多,我主要是在Node分場+小程序架構剖析,其餘的沒有整理了。css
早上的整理連接《騰訊IMweb Conf 2017大會圖文筆記 -- 上》。html
--------------------------------------------------------前端
-- 寫着寫着筆記:忽然發現講師的PDF已經出來了 ,傳送門:[github]《Egg & Node.js 從小工坊走向企業級開發.pdf》。node
大會上說了阿里的Node使用狀況、Egg是如何跨團隊構建的,Egg版本Timeline,做爲補充。react
-- Egg 寓意「孵化新生」,在它之上能夠快速的孕育出各式各樣的 Web 應用。官網eggjs.org/android
-- 一直以來,Node.js以其靈活、快速迭代的特性在阿里內部獲得了普遍的應用。Node.js如今不只替代了過去使用PHP和Jave Web的部分場景,並且還成爲了阿里整個框架內基礎設施和接入設施的橋樑。可是隨着Node應用和Node開發者的數量不斷增長,一些問題也隨之暴露出來。這裏主要體如今如下三點:基建缺失、重複建設和各自爲戰。ios
--- 旁邊美女說,臺上的講師是否是在念稿子的啊,怎麼可能說的那麼快呢?css3
主要是講在局域網網環境中開發第三方即時IM,沒接觸過的樓主在下面聽得有點蒙(閒魚呆滯),介紹企業WebIM的特色,Socket.IO架構/技術選型,跨進進程消息發送和nconp框架。git
(我沒記錯的話,所謂柔性化處理是在對在websocket佔用服務端資源峯值與低估差的距大時採起長輪詢減小峯值、低估,以達到穩定的區間。)github
(感謝王躍老師分享的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問題就變成了在不一樣的平臺下小程序是用什麼環境來執行他們的,而且怎麼和其它部分通訊的。
搞清楚哪部分是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消息處理器
一、invokeHandler: 調用原生能力
二、publishHandler: 消息分發
經過 WKWebview的
window.webkit.messageHandlers.NAME.postMessage
實現,微信navite代碼裏實現了兩個handler消息處理器
一、invokeHandler: 調用原生能力
二、publishHandler: 消息分發
Compent --- 對比Polymer與小程序
王躍老師:「這裏有人應該會問小程序爲何沒有采用Polymer? 這裏微信團隊同事說喚醒WebView也須要消耗的,大概耗費300ms,因此性能是瓶頸。而後他們本身重寫了類Polymer的形式,性能差很少(王躍老師說他們謙虛了)」。
如下截圖爲分析內容:
Optimize
setData
本身有用的資源就能夠了
page_frame
,加載時會自動拷貝page
對象,所以,咱們能夠提早在page
對象裏注入數據。localstorage
reflow
的時候畫面閃動(AMP)ios 300ms
android 更多一點
merge,data和function
騰訊內部團隊測試過,若是增長到100個屬性,iphone6上渲染會延遲150ms,若是是複雜的數組就更多了.
LOADING 設置門檻值,超過500ms才顯示Loading,那501ms的怎麼辦,強制顯示1s,有個過渡,不會閃過.
------ 分割線 ----
(1)會後請教王老師到底可否實現 $('#ID') 這種形式呢?
果真在小程序文檔裏面找到了相關查找Dom節點的東西。傳送門:WXML節點信息 API 列表。
(2)菊花圖優化加載體驗不一致
會上王老師說loading狀態有快有慢,會出現loading一下嗖的就出現內容,給人體驗不夠友好,就能夠強制使得loading動畫加載1s或者1.5s(機智)。其實以爲css加載模仿頭條/網易的形式也可行的。
(3) 獲取編譯後代碼來剖析
王老師建議把安卓手機Root,進入微信目錄尋找小程序相關文件就好。
最後感謝王躍老師的乾貨分享和樂於解答。
---------
狼叔的開場有趣,整場很是活躍,並且最後一場了還有不少人來聽,可是筆記...太有趣了沒作完整 哈哈~ (這不能怪我~ 啊嗚~)
有趣的開場,色彩分明的標籤,哇喔~
技術棧演變與發展
就只有這麼些?
我的發展趨勢
你必定不知道的應用場景。
更完整內容 在 《一名全棧工程師Node.js之路》和 高可用架構專用《全棧工程師之路-Node.js》https://github.com/i5ting/nodejs-fullstack/
----------------
選兩個有意思的回答:
(1) 問w3c經理Philippe Le Hegaret:先入境前端發展愈來愈快,W3C會不會跟不上前端界的新技術的蓬勃發展。
Philippe很自信的回答:不會的,瀏覽器廠商一直在抱怨咱們的標準制定的太快了,他們來不及實現。就如PWA六七年前已經提出來了。年輕人,先有標準,纔有瀏覽器實現。
(2) 一個大三女孩子的提問(先爲她來到這裏、而後聽到最後的勇氣鼓掌):
如何準備實習和進入前端這個領域呢?
他們的答案,從兩個點來講,第一個就是說從知識面來準備,就是走T字形路線,以前說的從廣度跟深度,慢慢延伸。另外一個回答的就是找名企實習,一般的話基本上在前一年就開始準備了,一說就是大二大三就開始準備。
------
爲何昨天沒整理完呢?
職業病犯了啥都都幹不了,脖子疼的真是~
有紕漏歡迎指出,參加IMWeb2017仍是收穫挺多的 ,很高興與你分享!