2019 TWeb 腾讯前端技术大会精彩回顾
分享主题: Flutter在腾讯企鹅辅导上的实践之路
讲师: 涂金林 - 腾讯教育 Flutter 负责人
讲师先是介绍了 flutter, 接着讲了腾讯企鹅辅导上的实践, 包括了安卓, iOS 和 Pad 上的原生应用如何嵌入 flutter 以及原生页面与 flutter 页面混合切换的实践, 另外还讲了 flutter 的性能优化与 flutter for web 在生产环境的实践. 这里边的技术细节限于篇幅就不再赘述, 感兴趣的可以到公众号回复 tweb 领取 ppt.
为了更好的了解 flutter 在腾讯的落地情况, 大家可以看这个视频:
分享主题: 大型Web项目可用性提升优化方案
讲师: 郭林烁 - 腾讯 AlloyTeam 高级前端工程师
讲师所在的项目是腾讯文档, 是一个大型的团队, 一个页面就有很多人开发, 在遇到问题时, 得先指定人排查, 排查出问题, 再交接给相应的人解决, 比较低效, 这次分享讲了如何解决这个问题，主要分以下三个方面
脚本错误监控、优化、持续跟进
讲师所在的团队, 通过脚本错误监控, 结合代码 sourceMap, 自动定位到出错文件的具体位置, 通过自动化脚本与 git blame 命令, 找出当前报错行的历史提交者, 通过内部工单系统, 自动提 bug 单给历史提交者, 因为工单有内部流程保证会被处理.
在开发阶段, 如果有脚本报错, 也会自动弹窗, 阻断开发.对报错量级进行了监控, 如果突然上涨, 也会有相应告警.
经过以上几个措施, 线上的报错量越来越少了.
前端日志系统搭建、优化与打通
经过上面的错误监控, 优化与持续跟进, 已经解决了脚本错误的问题, 但如果有些逻辑问题, 在大型项目里也是很难定位. 这个时候就要依靠日志了.
因为是个大型的项目, 前端也会产生很多日志, 通过前端上报不靠谱, 容易在上传时丢失. 我们来看看腾讯文档做了哪些内容解决日志问题
- 利用了客户端(微信, QQ)的接口, 通过客户端上报到内部的日志系统
- 为了不阻塞用户的交互, 利用 worker 线程进行上报.
- 将所有的异步请求做了拦截监控, 相当于是前端的一个远程抓包, 通过一个 id 即可查找到页面的所有请求.
- 接入了 "吐个槽" 服务, 可以方便地收到真实用户的反馈
- 将所有遇到的问题落地为测试用例, 防止之后再犯
腾讯文档“白屏”监控体系与优化
- 增加 loading, 减缓用户的焦虑
- 对加载失败的静态文件进行加载重试, 并结合 wait-external-webpack-plugin 插件确保重试后, 代码的依赖顺序依然正确
- 在重试加载后, 如果还没加载成功, 就弹框提示用户网络可能存在问题, 让用户刷新或反馈
- 为了检测加载到的资源与发布的资源是一致的, 还在 script 标签的 integrity 属性加了 js 文件的 sha1 值做一致性检测
- 为了防止运营商劫持, 采用了内容安全策略(CSP)进行预防
分享主题: Headless CMS——小微项目的业务中台解决方案
讲师: 张云龙 - 巧子科技创始人
分享中, 讲师着重介绍了 strapi, 这是一个开源的 Node.js Headless CMS 框架. 该框架通过简单的几行 npm 命令, 即可生成一个 CMS 系统, 该系统通过界面操作, 可以生成数据库表, node 增删改查的代码和相关路由. 以下是 strapi 的视频介绍:
分享主题: 《腾讯 OMI +》 - OMI 框架前端生态赋能与创新实践
讲师: 张磊 - 知名开源框架 OMI 作者
该分享的 PPT 就有 80 多页, 现场分享更是一度超时, 这里就长话短说, 讲一些核心的内容
Cross-Frameworks Framework
OMI 是一个跨框架的框架, 也就是 OMI 可以结合 react, vue, Web Component, Kbone, Preact, Three.js 等框架使用. 用 OMI 编写的组件, 也可以被 react, vue, preact 等框架直接使用, 反过来, react, vue, preact 等框架也可以使用 OMI 编写的组件.
OMI-THREE
另外比较有趣的是 OMI-THREE, 如果纯基于 three.js 编写游戏或 3D 场景, 我们需要创建很多实例, 比如 new 一个场景, new 一个立方体, 这里放一个光效, 这里加一个旋转, 这些都需要我们编写一些命令式的代码来处理. 但 OMI-THREE 可以让我们以声明式的写法完成以上内容, 来看个 demo:
实现以上效果的代码是声明式的, 很清晰:
关于 OMI 还有其他内容, 如 OMI + React, OMI + Vue, OMI + Kbone, OMIX, OMIM 以及 OMI 设计哲学, 感兴趣的可以在公众号回复 tweb 查看 PPT
分享主题: 极致SSR：高效率构建高性能Web同构页面
讲师: 段隆贤 - Vue 语法编译引擎 aga 作者
为什么需要 SSR
- 更好的搜索引擎优化(SEO: Search Engine Optimization)
- 更快的首次有效绘制(FMP: First Meaningful Paint)
SSR 的现状
- 一般SSR, 首屏(FMP)依赖页面所有接口， 首屏不一定快，同时分块传输有额外的工作量
- 开发效率低: 传统的SSR, 需要操作DOM, 开发效率低， 难维护， 同构页面可响应时间（TTI）长
- SSR页面切换无法渐进式加载， 页面切换时不能定义过渡动画
什么是分块传输
不需要等待页面所有的接口返回， 页面头部接口响应即可响应页面， FP(首字渲染 first paint)和FCP(首次内容渲染: first contentful paint)更快
例如一个 v.qq.com 的请求, 利用分块传输, 可以先返回首屏内容, 后面的内容等数据拉取好后再返回, 注意这里是一个请求
讲师团队的实践
在 Vue 编译时, 将 Vue 语法编译为字符串拼接, 通过自动化分块传输, 并做到了同构开发.
分块传输自动化
- 程序分析模板的异步数据， 自动拆分模板
- 根据模板上下的依赖关系 , 自动收集数据依赖
- 自动把局部模板和数据关联
分享主题: Serverless SSR 实践
讲师: 水澜 - 阿里巴巴前端技术专家
要做 SSR 并不容易, 首先我们要保障 Node 服务的稳定性, 期间我们可能会遇到如下问题:
- 磁盘占用过多
- 内存负载变高
- 内存溢出
- Node 服务发生错误
- Node 宕机
- 扩缩容, 机器裁撤
另外还要考虑如何让一套代码两端共用:
- 渲染机制的差异
- 端上环境的限制
- 如何处理数据请求
- 如何避免状态污染
- 开发调试环境的打通
第一部分, 讲师的实践是将 node 服务落地到 serverless 中, 有如下好处
- 函数即服务 (Faas, Function as a service), 开发者可以更关注业务逻辑本身
- 天然的隔离性, 动态修复，函数间相互独立
- 无需运维, 全托管服务、按需执行、弹性伸缩
第二部分, 讲师使用阿里开源的 Rax 来解决一套代码两端共用的问题
Rax 是一套遵循 React 标准的跨端解决方案, 并且通过 Rax 的脚手架, 执行一条命令便可以部署到阿里的 serverless (fc) 或国外的 now serverless 提供商中
这里比较值得关注的是, 在 Rax 中, 请求的发起与路由的映射, 是可以做到前后端同构的, 限于篇幅, 感兴趣的同学可以查看 ppt 或 google: Rax
分享主题: 腾讯教育 Serverless 实践及探索
讲师: 蒋林源 - 腾讯IMWeb前端工程师
Serverless 逻辑架构
Serverless = Faas + Baas
初探 serverless
如上图所示, 用户在腾讯云的 serverless 平台上, 上传云函数的代码(或直接用在线编辑器编写)
保存后, 我们可以设置触发器,
也就是上面的 Event Source, 可以是 api gateway, 也就是通过请求来触发, 其它触发器还有: 定时触发, COS 触发(COS 收到上传时触发, 比如上传了一张图片, 触发某个云函数进行压缩), 消息队列触发等等.
而后边在提供支持的 BaaS, 则提供了很多后端服务, 像 AI, 我们可以调用语音图像的识别接口, 还可以轻易地调用云 DB, 而云 DB 也不需要我们人工维护, 还有对象存储, 诸如图片, 视频上传, 回源到 CDN等, 简直太方便了.
冷启动
目前我体验到腾讯云的冷启动做得还不错, 只要在一定时间阈值内有访问, 就不存在冷启动慢的问题, 但如果云函数长期都没人访问, 此后的第一次访问, 就会慢一些, 但还可以接受.
腾讯教育相关业务的落地
讲师提到了两个完全使用腾讯云 serverless 的业务, 如下
企鹅背单词
腾讯课堂 - 新人专属礼包
腾讯云 serverless devOps
腾讯教育在内部的实践中, devOps 也很完善了, 整个流程如下:
开发完 push 代码到 git, 自动触发代码的构建 (yarn && yarn build 等), 自动触发云函数的部署, 此外, 预发布和发布环境也能通过内部的交付系统流畅地部署
分享主题: 阿里控制台系统提效之路
讲师: 潕量 - 阿里前端技术专家
以上即为控制台系统
一句话概括该分享: 通过内部物料系统(可以理解为 npm 的公共 UI 组件库积累), 阿里自研了一套 Fusion 系统, 可以方便设计师配置设计稿, 该系统的配置粒度几乎满足设计师的所有需求, 配置的每一个参数都会记录下来, 设计师在提交设计稿时, 会根据配置内容, 发布到 npm, 前端开发更新 npm 包, 即可拿到设计师的成果, 该成果是基于物料系统的, 也就是代码生成后, 基于 react 可读(阿里统一使用 react), 此后便可在这个基础上增加业务逻辑, 与设计师沟通扯皮的问题被解决得很彻底.