1. Building Web Apps With Cloud And AI

Microsoft。主要内容偏machine learning 和deep learnning的应用，（说实话英语太渣听的云里雾里）。但微软提出的各种应用场景都很贴近生活，还有一些非常具有社会推动价值，例如如何利用ai帮助残疾人。

整体感觉不像是讲前端技术或工程的题目，而是偏研究性质，如何用AI的思维去解决问题。

例如这向年各种币（如比特币）很火，他们用ai去分析数据拿到各种货币的发现趋势。

讲一个盲人c#工程师用一个AI的眼镜，可以很好的生活甚至写代码，眼镜可以分析图像告诉用户眼前的场景，如：有个孩子在滑滑板，开会中对方的表情是怎么样的，菜单上可以点哪些菜等等。

介绍了AzSearch.js，配合Azure（微软研发的云搜索服务）使用的前端UI框架，可以定制搜索目标和结果展示样式等。

2. PWA(Progressive Web Appi[lication)

百度，演讲者是基于vue的PWA框架LAVAS的作者。概念的部分在框架官网上都有。我觉得最主要的两点第一弄懂app shell架构,包含app shell和app skeleton的概念，第二理解service worker的在pwa中的作用及生命周期。

印象最深的点是，百度对每一个技术难点的探究都会抽象成通用框架，把最佳实践梳理成行为规范。LAVAS的官网上不仅包含框架的内容，还包括总结出的非常全面的pwa的知识，给我们以后做这种网站提供了好的思路。

现在百度搜索已经实现了pwa，链家大C移动端如果支持了pwa也可以使用户体验更上一层楼，不想下载app的用户可以通过加入桌面快捷方式得到一个更轻量的入口，前期准备工作需要网站升级到https的来支持service worker。最后作者讲了ssr配合pwa的渲染流程，ServerSideRendering可以解决单页应用的SEO问题，也是值得尝试的一个技术点。

2.1 pwa的定义

包含主屏图标，离线可用，离线通知等功能的渐进式的网页应用程序。

演讲者强调应用体验才是pwa的核心，progressive（渐近式）体现在它的功能和开发过程都是渐进的，国内还不支持消息推送，但并不影响我们实现它其他的特性。

有个demo(请用移动端浏览器打开)来演示，把他添加到桌面后，断网后从桌面icon进入，页面仍然有内容。

2.2 强调pwa的三个特点

可靠:运行在可靠的https下，离线可用特性使得网络不可靠时pwa也可靠
体验:快速响应，能做到接近Native App的体验
用户粘性: 例如消息推送，chrome可放到主屏等功能，可增加用户依赖度

2.3 pwa的技术点

pwa一般都是spa的,如何让白屏时间变短？
两个主要概念

app shell: 是可以让网站运行起来的最小的集合，在手机app里一般就是header，footer,menu这些部分，不包含content。可以缓存起来缩短白屏时间。

app skeleton: 主要内容区域，在实际内容加载出来之前的占位图片叫做app skeleton。

分析：页面加载时html顶部的css会阻碍下面skeleton的展现，导致白屏时间长

解决：把css link加入preload属性、使之不会阻止skeleton的渲染

桌面快捷方式（主要讲manifest支持的兼容性）
通过配置app manifest.json文件中的start_url，点击桌面icon将会在浏览器中打开start_url指定的地址。

1<link rel="manifest" href="path-to-manifest/manifest.json">

Chrome和Firefox已经实现了这个功能，safari旧版还不支持这种方式，但是提供了自有的属性同样达到效果，随着iOS 11.3 的发布，苹果悄悄的支持了PWA理念背后的Service Worker和Web App Manifest。

图1.ios兼容属性设置 3) servise worker 是浏览器在后台独立于网页运行的脚本，是一个独立于网页的线程，负责处理并拦截请求，操作缓存等,国内各大浏览器微信都支持。在pwa主要用来控制请求走server还是cache，如果首次请求就走server并且缓存起来。 Service Worker的缓存机制依赖Cache API、HTML5 fetch API，以及Promise。

sw的生命周期包含五个阶段，分别有不同的状态及职责：

安装中(installing)：sw注册之后进入此过程，触发install事件回调，本阶段利用Cache API指定静态资源进行离线缓存。

安装后(installed)：完成安装，等待其他的SW线程被关闭。

激活中(activating)：清除其他的worker以及关联缓存的旧缓存资源，等待新的SW线程被激活。

激活后(activated)：可以处理功能性的事件，包括fetch (请求)、sync (后台同步)、push (推送)。

废弃(redundant)：结束

开发时在主页面中注册sw：

js
if ('serviceWorker' in navigator) {
   navigator.serviceWorker.register('/sw.js')

}

1在`sw脚本`（sw.js）中, 监听生命周期回调和事件回调，进行资源拦截和缓存：

js

this.addEventListener('install', function (event) {
   // 利用catch API（caches.open）缓存资源app shell等关键文件
});

this.addEventListener('fetch', function (event) {
   // 处理请求，可从caches里读缓存，没有则从网络拉取
})

作者提出serviceworker+app shell是完美的组合，可以通过如下逻辑来优化页面的展示速度：

缓存 app shell所需静态文件

拦截页面请求，均返回app shell对应html

app shell判断当前url,渲染不同页面

判断当前请求状态，返回不同页面

servise worker如何更新
sw脚本控制着页面资源的缓存及更新，它自身也可能需要更新。sw脚本内容更新时，浏览器会逐字节对比新旧内容，如果不同会再次安装并走一套完整的生命周期。因此作者提出sw脚本的更新策略：

浏览器每天至少更新一次SW

注册新的SW,带上版本号，如 /sw.js?t=20180421

可手动更新registration.update()

需要注意的点：sw更新需要等待所有被旧版本控制的页面都关闭后，第二次进入才会生效。如果想强制立即更新，sw脚本需要通知所有在控的页面去刷新。

图2.强制更新逻辑 5）SSR 最后讲了LAVAS中的ssr模式，使用SSR流程处理html请求仅限于浏览器缓存中不存在app shell时，也就是第一次访问时。后续访问即便是刷新页面，因为shell的存在也不会再走ssr流程了，这和传统的ssr模式是不同的。

面向未来的原生化Web开发（web assembly）
作者是广发证券的技术专家，所以他后来的例子是用wasm去重构了股票K线的h5展示效果。这种技术适合前端语言不擅长的复杂的数据计算，不知我们是否能将它用于教主方向的VR看房等业务场景。

前端Js的性能问题在于从最初的设计它就是一种解释型语言。性能问题可以由原生化来解决，即把js转成更底层代码去执行。但是这类私有技术如activex插件有安全问题所以需要提示安装。

2015年webassembly出现，使用它可以在浏览器中运行一些高性能、低级别的编程语言，它本身是二进制的。可用它将大型的C和C++代码库导入Web平台，这样前端也可以实现游戏、物理引擎甚至是桌面应用程序了。

作者演示示了js及wasm编写的同一个复杂算法的demo，运行时间上有4至5倍的性能差。后面又介绍了开发wasm的emscripten编辑器，讲解了一些他们遇到的问题和解决办法，大部分是一些api的支持。例如

浏览器运行环境是异步的，受限于安全沙箱，并没有权利读直接存取主机的文件，Emscripten编辑器提供的fs api帮助解决了这个问题。编译代码时带上–preload-file参数，指定需要加载的文件。

如何去解决受限io的问题，Emscripten提供了emscripten_async_wget等api可以解决。

图3.wasm编译原理

最后提及了rust，它也能被编译成wasm具有高效、表达能力强，零成本抽象等特点，高效体现在编译过程中不会产生中间变量。我不太懂就不作评论了，大家可自行学习。

4. quic在收集微博的应用实践

微博。偏通信及运维方向。初忠是他们想在微博app链接时在网络层面请求后端业务时再快一点，以弱网环境下能满足用户基本需求，解决移动端TCP连接不稳定的问题。我们的移动端也可以接入，但是感觉链家app线上主要是搜索展示型的业务，不像微博用户交互那么频繁，是否适合我司存疑。

从tcp加密通道的问题讲为什么选择quic，tcp链接需要三次握手是一次rtt，如果是http需要保证安全性需要增加tls,还会增加握手次数，建立成本高。

udp协议是无连接协议，但是传输不可靠，应用层需要去保证包的顺序。

quic是构建在udp之上的传输层协议。可以在1到2次握手完成链接，如果浏览器支持握手缓存，可进一步减少rtt次数，目的是为了整合tcp的可靠性和udp的速度和效率。quic有数据加密、拥塞控制的特性，把http2的优点克隆了，并实现了真正的多路复用。http1串型的，quic在udp上是并行的，一个包丢失后不影响其他包的发送。前向冗余纠错适用于youtube这样的视频网站。

它们的关系找一张图展示：

图4.http,tcp,udp,quic关系第二部分讲了一些服务部署时的实践经验，例如

需要解决udp 在lvs dr模式下端口问题

怎么监测两个端口 8.8.8.8:443, 10.10.10.10:443?可以做代理

实践中ngix处理https 和caddy合作

实践中第一次是两次rtt不是理论的一次=〉解决：caddy源码对客户端不信任把源码改掉

第二次链接换机房了怎么办？解决=〉全局级握手缓存把握手信息缓存在memery cache 共享密钥机制

这部分有些偏离前端就不作深入分析了，网上找到一篇微博讲quic的文章(http://www.sohu.com/a/225800602_100061531)，有兴趣的同学可以阅读。

作者介绍：
马琳，17年6月加入链家网，平台大前端研发部，任职前端高级开发工程师，专注于B端平台化前端技术。

本文转载自公众号贝壳产品技术（ID：gh_9afeb423f390）。

原文链接：

https://mp.weixin.qq.com/s/GHgJRVkU3hsrSLy-Rhviwg

创作场景

QCon 前端参会分享