共计 2557 个字符，预计需要花费 7 分钟才能阅读完成。
回顾
上一次参加 GMTC 还是 2017 年。那时的我还是刚刚参加工作并在试用期辞职的菜鸟。
2017 年的 GMTC 还是真正的 Global Mobile Tech Conference，2019 年的会议早已经把英文全称去掉，改称全球大前端技术大会。
2017 年的 GMTC 还在推广 PWA、讲 Vue、React、Angular2、Weex、RN 的实践和探索，2019 年的 GMTC 小程序和铺天盖地的 Flutter。
2017 年的 GMTC 还在讲工程化的问题，2019 年的 GMTC 已经向围绕 node 的服务形式、客户端、监控等周边辐射。
2017 年面试还在问会不会 ES6，2019 年的 GMTC 的 Demo 都成了 TypeScript。
2017 年的我还听不太懂全部的前端相关的内容，2019 年以为自身没有什么显著的成长，回顾才发现，旧的东西已经胸有成竹，新的东西也都有所应用。
两年的时间，一些技术成了基础设施没了推广的必要，一些技术已经被充分验证了具备大规模使用的能力，一些技术被淘汰或水土不服，还有一些新的东西冒了出来，不知道在不久之后会给大前端带来翻天覆地的变化还是被迅速淘汰。
结束对历史的感慨，逐个场谈谈启发，因为我只听了第二天的场，那么我就讲讲第二天的，启发可能来自各个奇怪的点。
B 站的视频体验进化之路
这场是 B 站带来的分享的是名为 “video first” 的优化，涉及了产品的改造、资源加载的改造、核心技术（视频、弹幕）的选型切换。其实从标题也能看出来，很多优化措施是和视频相关的，我并不是 100% 的受众。
带来启发的点是产品改造部分，一般技术更加关注性能指标，产品更关注用户行为。
性能指标方面，其实就是缩短关键渲染路径，一般会从减少首屏加载、优先加载首屏渲染资源方式入手。
但是从用户行为方面来讲，用户关注的“首屏”可能并不是真正完整的首屏，如 B 站的视频播放部分才是用户更关注的点，我们可以称之为用户关注的关键路径。
那么怎么做更高效的优化呢，需要技术和产品从各自的角度紧密结合。从用户行为入手，将用户关注的关键再次从首屏渲染路径中剥离，做更高优先级的加载，如 B 站优先加载视频播放这一关键路径上的资源，其他资源主动避让，在具备视频播放能力时再加载。同时与产品协作从产品设计方面突出关注点，做产品设计方面的优化，如 B 站新版改造减少页面元素，将播放器窗口直接显示在第一屏。
那么再发散一下，针对复杂、资源较多的页面，能不能做成几条功能的关键路径出来，在不同的来源场景下优先加载不同关键路径的资源呢？
0.3 秒完成渲染！信息流内容页“闪开”优化总结和思考
这场是 UC 信息流带来的消除白屏的优化方式，名为 NSR（Native Side Render）。
方向是数据预取、预渲染，实现为在 Native 中做了一套机制，满足页面可以提前渲染，丢入 内存缓存 ，在用户需要时直出。
具体到 UC 信息流的场景，是依靠 Native 做 Render 的工作，Native 缓存固定的模板，在用户浏览时提前加载对应数据，并在 Native 中执行模板和数据的混合，渲染出真实页面，存入缓存，在用户点击时匹配拦截请求直出，完全避免掉浏览器渲染页面前的请求工作。
由于 UC 信息流优化强烈依托于内核，所以他们取舍掉的一些非最优解其实还是用在其他优化场景中的，比如舍弃 HttpCache，使用依赖内核的内存缓存。
思路可以扩展到 Weex 这种寄生在 Native 的环境，在浏览器端也可以依靠 Service Worker 做些尝试。
Event Loop、Future 与 Isolate – 单线程模型下的 Dart 异步编程模式
讲了 Dart 下的异步运行机制，Event Loop 和 JS 的 Event Loop 一样（插一句，node 11 之前的 Event Loop 和浏览器端还是不同的，在 node 之后已经趋于相同了），Future 可以类比 Promise，Isolate 可以类比 Worker。
其实对懂 js 的 Event Loop 的前端来说不会有太多收获，但是看 Dart 中 Future 的示例代码，确实纠正了我一个关于 promise then 经常忘的点，真是神奇的 then。
Using webpack to make Apps fast at Microsoft
webpack 的维护者 Sean Larkin 带来的围绕异步加载的优化。
使用 import() 语法，依托浏览器的 Coverage 分析首屏 Unused 代码，做异步加载处理，从而减少首次有意义渲染（First Meaningful Paint）时间和可交互（Time to Interactive）时间。
我司基于 FMP、TTI 的性能监控也已经运行了一段时间了，也协助业务做过基于 Coverage 的加载优化，所以分享的内容听起来比较亲切。
对我带来启发的，第一点是受运行时控制的异步加载 (name) => import(`path/${name})，我感觉实现思路可能对我们自己的微服务架构的服务关联关系有帮助。第二点是有人问到的加速构建的问题，我司业务中会遇到需要一次构建上百个入口的情况，这时构建会特别的慢，我们一般从提供减少构建入口的能力这一角度做优化，Sean 提到了一个插件 cpuprofile-webpack-plugin 不知道会不会对我们分析构建耗时有帮助。
从一到无穷大：前端工程化中的实践与臆测
阿里巴巴 Just 工程体系，由前端开发的演变对应到工程化的对应演变，从稳定与高效（版本控制，代码检查），标准与定制（研发流程的制定，流程节点的定制），通用与易用（开箱即用、分层增强）角度分享了工程化实践中对前端开发的赋能、提供良好的前端开发体验。
没有特别的启发，但链路很全，在做提供相关服务能力的时候可以做参考。
工作 10 年，我在前端专业成长路上的探索（一）
讲的还是比较积极风趣的，呼吁大家要节约时间高效学习。
快手游戏直播 Web 站的工程进化之路
如题，从第一阶段 - 开发上线（技术选型与初级架构设计），第二阶段 - 持续交付（提高扩展性、降低业务开发思考成本），第三阶段 - 开发质量（开发、构建、部署流程），第四阶段 - 精细化运营（数据监控，包括错误、构建、关键业务指标）进行了分享。
主线和《从一到无穷大：前端工程化中的实践与臆测》比较类似，没有特别启发的地方，在做提供相关服务能力的时候可以做参考。
同时不得不感慨一句，快手的技术发展、应用真的很迅猛。
