下午的干货就比较多,我主要是在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仍是收获挺多的 ,很高兴与你分享!