GMTC全球大前端技术大会感想

GMTC@2019于06.20在北京举办，关注前端，移动，AI应用等多个技术领域，本人（编者注：本文做者为陈光通）以一个学习者的身份参与了本次会议，在这里简单介绍一些本次的见闻以及感想。

会议涉及的技术方向包含前端工程化，性能优化，Node，编程语言等14个主题，因为时间有限，我在参会前肯定了本身感兴趣的场次与时间，并在时间表上作好了标记。

关于NodeJS

NodeJS场包括基础设施的完善，开发运维体系，Serverless，复杂应用的框架与开发模式等方面的探讨。目前，NodeJS在各个大厂中大体存在如下几种应用方式：

• SSR，提高首屏体验。
• 做为服务端与前端之间的中间层，也就是所谓的BFF。这样的开发模式无疑是更加温馨的，服务端同窗能够更加专一本身的领域模型，而无需太过于关心视图的变化，而前端同窗也能够自由组装视图层的数据，不须要事事都求问服务端。
• 全栈，由前端同窗自行开发一些内部的工具系统，甚至C端服务。

不得不说，NodeJS打破了前端与服务端的边界，对前端同窗来讲，如何维护好本身的NodeJS服务？如何与服务器打交道？如何应对海量的请求以及服务端错误排查？成为了前端同窗不得不面对的一些问题。

海量Node.js云服务的DevOps实践

来自腾讯云开发团队，主张打破开发，测试与运维的边界，提出了DevOps，简单来讲就是开发也必须具有运维的能力，其中比较印象比较深入的有以下2点：

1.基础设施的管理：传统的云主机因为雪花服务器，时间侵蚀，集群漂移等缘由，存在各类服务不一致的风险，也难以进行自动化管理。针对这些问题，做者提出了基础设施即代码的概念，也就是基础设施的搭建转换成了配置文件的编写，经过配置文件来保证高度统一，具体落地能够分如下几点：

• Docker：以Linux容器的形式对操做系统上的进程进行隔离，经过一份dockfile配置文件便可快速在系统上生成服务所需容器，而服务的一致性彻底交给了dockfile来决定。
• k8s：基于容器的集群管理平台，帮助咱们进行容量的规划，管理，监控。
• 动态网关：快速完成API的注册，并提供统一的流量控制，筛选，熔断等手段。

2.日志监控：日志格式必须遵循when,what,how,where等几个基本准则。针对复杂链路的日志，能够经过在请求头部增长traceId的形式进行记录，方便全链路问题的定位。

总体下来感受腾讯云团队的基础设施仍是比较完善的，但分享更可能是基于大方向，流程方面的介绍，没有太多技术细节透露，不过不得不认可演讲者的思路很是清晰，哪怕是以前没有Node运维的经验的同窗，应该也能清楚地认识到各个基础设施，流程存在的必要性以及一些简单的运维技巧。

基于TypeScript的NodeJS开发实践

阿里封装的Midway框架，主要解决的是如何在Node应用愈来愈复杂的状况下保持代码良好的可维护性，印象比较深的有以下几点：

• 引入的Java开发中 Ioc(控制反转) 的概念，经过装饰器与xml的定义，在应用启动时生成实例，从而直接注入到Class里。
• 经过大范围使用ts的interface定义来约束项目数据模型的规范，以模块的形式划分目录结构。
• 做者在使用上抽离了核心逻辑与框架适配逻辑，经过针对egg,koa,express开发适配层，保证无缝嵌入各个不一样的业务场景。

当Node应用变得愈来愈复杂时，咱们不得不向传统服务端去借鉴一些思路，从而减轻应用的复杂度，以便面对更广阔的场景。

跨端：Flutter

Flutter：最新进展和将来展望

不得不说，Flutter在本次大会中仍是占据了至关多的篇幅，来自Google的研究员董韬也向咱们介绍了Flutter将来的一些规划：Flutter for web的多平台愿景，状态管理方案的建设，IDE上的改进。

我的感受Flutter在跨端问题上的解决思路仍是很是好的，全新定义的渲染引擎让一套代码在不一样平台上依然能保持高度一致以及接近原生的体验，真正作到一次写，处处跑。代价就是引入了Dart这样一套全新的语言，然而Dart单线程的运行方式，基于Eventloop实现的异步机制，让它看上去和JS极为类似，相信熟悉JS的前端开发直接上手Dart也不会遭遇很大阻碍。

相对而言，Flutter for web彷佛就不是那么让人看好了，它的原理是经过Dart2js将Dart语言编译成JS进行运行，将Flutter的Widget转换成浏览器可理解的Html，Css，canvas，具体流程以下图所示。考虑到浏览器的版本复杂多样，这个过程不可避免会出现一致性的缺失。官方也建议Flutter for web能够做为App在web端的预览版本，而核心的功能仍是在App中进行开发。

状态管理方面，社区提供了名为Provider的状态管理库，被官方所采纳，这也从侧面反映了Dart语言目前在生态上仍是有待完善的，放弃JS意味着就放弃了NPM丰富的第三方库，这也是咱们想要入坑Flutter所必须考虑的。

基于跨平台框架 Flutter 的动态化平台建设

Flutter在渲染上虽然有独到之处，但失去了动态下发能力让App的更新也变得困难，每次的更新都依赖发版，对于频繁更新的复杂App来讲是难以接受的。

美团对此的解决思路利用ios与android动态更新JS脚本的能力，将App中的动态下发模块分为逻辑层与渲染层2部分：

逻辑层：经过JScore运行JS脚本，生成相似于Virtual Dom的对象

渲染层：以流的形式将该对象输入C++引擎，将其转换成Flutter的Widget，经过Flutter引擎进行渲染。

这套方案既保证了Flutter的渲染性能，又能保证动态下发的能力，因为不提供PPT下载，我按照本身的理解画了下大体思路。

相似的方案在微信小程序中的分享中也有提到，可见如何实现Flutter的动态下发仍是你们比较关注的话题，但二者在实现上都对Flutter官方库进行了必定程度的改造，实现成本比较大，这彷佛是在催促Flutter官方提供更合理的动态下发方案。

体验优化

0.3秒完成渲染！信息流内容页“闪开”优化总结和思考

UC团队针对信息流内容页秒开的实践，核心是利用Native的能力进行渲染和资源缓存。流程上在Webview列表初始化的时候进行详情页资源的预加载，同时针对视图内的信息流列表进行内容页的预渲染，从而在用户点击详情页的时候能够直接从内存中读出HTML，达到闪开的效果。做者将这种渲染方式命名为NSR(Native Side Render)，用以对比以前的SSR(Server Side Render)与CSR(Client Side Render)。

本人在团队中也实践过离线包的思路，但针对HTML的渲染，以前考虑过SSR与构建预渲染，都存在必定的缺陷。

• SSR：强依赖Node服务的稳定性，当页面流量较大时，前端不得不创建起比较完善的Node运维设施。
• 构建预渲染：构建的时候提早渲染好模版，但只能渲染HTML骨架，由于这个阶段即便模拟用户访问拿到了数据，也和真实用户访问时的数据存在差别。

从这个角度看NSR(Native Side Render)却是一种全新的思路，它将渲染的损耗分摊到了客户端，从而保证渲染不会受高流量访问的影响。但因为它强依赖客户端的能力，如何让这个能力更加通用，让每一个Webview均可以定制本身预渲染的时机，这多是大范围实践这套方案须要解决的问题。

其余

• B站的视频体验进化之路：总体听下来感受仍是在解决资源加载顺序的合理分配，简单来讲就是让用户最关注的内容前置加载。另外分享者还提到了经过MPEG-DASH对视频流播放进行优化，但因为以前对web端的视频播放不太熟悉，这场就没有太多印象深入的点。
• Event Loop、Future与Isolate - 单线程模型下的Dart异步编程模式：Dart语法课的感受，分享者介绍了Dart的单线程模型以及经过Future(相似JS的Promise)来实现异步。

总结

• 首次参与这样的会议，整体来讲，不管是当前的一些趋势走向，仍是各个大厂的实践思路，都仍是带给我很多的收获与启发。
• 建议你们在参与会议以前针对本身挑选的议题作一些简单的调研和预习，避免在演讲时陷入一脸懵逼的状态（好比我此次在听midway框架的分享时，因为不太清楚其诞生的背景，全程就有点迷）。
• 最大的遗憾是没能去跟讲师多作沟通，我的感受分享的内容再怎么精彩，能带来的收获终归仍是有限的，能与技术大牛现场直接沟通技术细节才是参与大会最大的优点，惋惜此次没能好好利用。