下午的干货就比较多，我主要是在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 应用。官网https://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问题就变成了在不同的平台下小程序是用什么环境来执行他们的，并且怎么和其它部分通信的。

搞清楚哪部分是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）