为了账号安全,请及时绑定邮箱和手机立即绑定

小前端眼里的大前端:GMTC 2018 参会小结

标签:
资讯

刚刚在北京落下帷幕的 GMTC 2018 应该算是近期国内前端圈子里最高规格(门票最贵)的活动之一了。那么这两天的分享有什么值得一提的地方呢?下面是一份小小的总结。

行程流水账

我们周三晚上从厦门出发飞抵北京,在鸟巢边上的会场里参与了周四和周五为期两天的密集技术分享。除了第一天早上所有参会者都在同一个会场以外,各个细分主题下的内容都是并行地在不同地分会场内讲解的。因此,一个人显然无法听完所有的主题的,我们也对想听的主题做了一些取舍。

我们此行最后选择的主题还是偏向 Web 前端,覆盖了混合应用、图形学应用、Node 和音视频应用等主题。虽然我们来了两个同学,最后参与的主题实际上也只覆盖了全部主题的 70% 左右。下面我们尝试从这些主题中抽取一些亮点和大家分享 XD

新技术动向

实际上 GMTC 本身的名称缩写和「前端」并没有直接的关系,而是一个面向移动端技术的会议。但在现在「大前端」的浪潮下,这次会议的议题已经在相当大程度上偏向了 Web 前端 / 全栈开发者。我们在现场感受到反响较好的一些分享主题,其内容取向也能印证这一点:

混合应用开发

虽然大会中也有不少 RN / HTML5 混合应用的高质量分享,但要说这个话题里现场气氛最热烈的分享主题,应该非 Flutter 莫属了。与其它分享中常见的「内部框架定制」和「业务系统演进」主题不同,Google Flutter 团队的于潇老师分享了他们所实现的这样一套能带来全新开发体验的开源框架。这个分享显然是经过精心准备的,有着良好的节奏和精美的互动 Demo,也收获了现场的一波波掌声~

Flutter 所对标的应当是 React Native 和 Weex 这样的混合开发方案,但不同的是,Flutter 不仅采用了 Dart 这样来自 Google 的编程语言,底层还从 RN 这样桥接原生 UI 组件的方案换成了基于 OpenGL / Vulkan 这样的图形库,保证了跨平台的稳定性。现场的演示中带来的惊艳之处有这么几个:

  • Dart 语言机制提升了开发体验。如调试期 JIT + 运行期 AOT 的性能优化、Tree Shaking 的包体积优化等。并且在 Demo 中,基于 Dart 的 Hot Reload 能够保留错误状态,而非像 Web 与 RN 那样在出错时只能刷新重置。对难以重入的页面状态,这能极大地提升调试效率。

  • Flutter 不依赖原生组件,可以在命令行中方便地运行 Headless 的测试。

  • Flutter 使用 Dart 重写了从底层的绘图、动画、手势到顶层 UI 组件的一整套技术栈,并且实现了充分的组件化。这样一来许多需要强控制力的效果就能直接在 Dart 生态下实现,而非 RN 那样动辄需要依赖原生库。

https://img1.sycdn.imooc.com//5b33451300014ca408110489.jpg

至于迁移到 Flutter 的成本,主要的顾虑集中在 Dart 的学习曲线和与 Native 项目的集成上。这两者实际上在当天下午闲鱼的 Flutter 实践分享中都有提到。对于前者,我们得到的回复是 Dart 实际上很接近 JS 和 Java,它的组件也很接近 React,因此学习曲线并不会十分陡峭。而对于 Native 项目集成,从闲鱼团队的分享上确实看到了还有不少现阶段暂时只能 workaround 的坑,但从 Flutter 团队的支持力度下来看,应当是可以期待持续的改进优化的。

下面这张图里你能看到闲鱼团队分享 Flutter 实践时,在第一排吃瓜庆祝的两位 Flutter 团队老板,自己亲手做的东西得到了广泛的关注,想必很高兴吧 XD

https://img1.sycdn.imooc.com//5b33452800012ff506530441.jpg

中后台与工程化

既然是「大前端」,那么 Node 全栈及其对应的 NPM 生态就是个不可或缺的话题。我们也在业务中使用了 Node,因此对这个话题我们还是比较关注的。

不过要评价起这次 GMTC 上 Node 与工程化相关的分享的话,个人理解应该更接近「稳定」吧。这次大会上这方面的多数分享,并非像 Flutter 这样「从 0 到 1」的新工具发布,而是主要集中在「从 100 到 1000」这样基于前端技术保证业务演进的总结上。当然了在纯粹的工具方面,这次的议题里也不是一片空白。比如来自 Apollo 团队的老板就详细介绍了 GraphQL 和 Apollo 全家桶。对于 REST 缺乏可扩展性的问题,GraphQL 的按需获取机制更加易用;对于嵌套的复杂数据,我们无需多次调⽤即可按需获取,从而减少⽹络开销;在缓存和预读取等通用的优化层面,GraphQL 层也可以实现不少对业务透明的优化。

虽然 GraphQL 这样下一代 API Gateway 的方案呼声一直很大,但不可否认的是它在国内还没有达到 Vue 这样「飞入寻常百姓家」的普及程度。在技术选型时,迁移到 GraphQL 的成本和收益始终是值得仔细权衡的。在这方面 Apollo 平台下以 apollo-client 为代表的一系列 GraphQL 工具是很值得推荐的:如果我们能够在不对后端服务做出侵入性改动的前提下,将 Redux / Saga 或 Vuex / MobX 的一系列胶水代码用简洁的声明式 GraphQL Query 取代,是不是能够解决一部分数据对接的痛点呢?在其他国内团队的分享中,也提到了将后端繁多的接口服务统一为「对应用透明的 API 层」的探索,比如阿里的 Node 团队就提出了 BFF(Backend For Frontend) 的概念,让微服务架构有了更多的发挥空间。借助于 BFF 的轻便性,我们甚至可以为每个业务开发一个 API Gateway。期待他们更多的成果呀。

在一些中后台的系统的积累和工程化上,这次大会上还是看到了不少的实践分享。几个大厂对业务的监控、异常排查、报警、问题定位、日志等系统已经逐一落地,前后端分离与 SSR 的开发模式也已经相当成熟。可能正是因为成熟度已经较高的原因,这个领域的分享较少涉及到具体的代码层面,而是一些「道」的高层次总结。当然了,也有些主题是非常接近于商业广告的,这里就不细说啦。最后放张 Twitter 的工程化分享现场图,供各位了解一下「道」的氛围:

https://img1.sycdn.imooc.com//5b33453c00010cfa05360375.jpg

性能优化与监控

这个议题下基本上就是大厂同学们秀肌肉的地方了:对于各种国民级应用的核心业务,它们背后的持续打磨优化和大量的支撑系统,是没有处理过这个量级问题的同学所难以想象的。我们可能常常认为,只要应用了常见在面试题中出现的那几种「前端性能优化方式」,就已经做到了性能优化。但在这些分享中,我们对于自以为的「已优化过」有了重新的审视,也了解了更多考虑性能问题的维度。

以爱奇艺团队的分享为例,一般对于客户端而言,除了崩溃率之外开发同学最关心的可能就是流畅度和首屏启动速度,分享中的实践在此抛弃了我们惯用的打点记时方式,转而以录屏的方式让测试更准确也更接近实际。再比如电量的消耗一般不是应用开发者所操心的,但真实世界中,流畅度往往直接和电量的消耗负相关。分享中引入的 PowerMonitor 不仅能够检测能耗,更能够据此量化地判断出优化前后对流畅程度的提升。对于我们熟悉的 WebView,它在应用中几乎始终是慢的代名词。这里我们在分享中看到了通过「离线化 + 异步化 + 缓存化」的一套方案,大大提升了 WebView 初始化的速度,这方面分享团队所开源的 liteapp 项目值得关注。我们原本以为时下大热的 AI 潮流和传统的应用开发没有特别大的关系,但出乎意料的是分享中我们看到了 AI 技术在自动提升视频清晰度上的应用,不得不佩服技术团队跟进落地新技术的实力。最后在安卓机型碎片化的问题上,我们也确认了「没有捷径可走」的结论,目前最有效的方式仍然是采购各种机型,在各个机型下进行完备的测试。

图形学与音视频

拜 winter 老师的气场所赐,这次大会中的图形学话题获得了不少额外的关注:

https://img1.sycdn.imooc.com//5b334554000111c406540435.jpg

虽然是个细到了数学公式和代码细节的分享,但分享过程比想象的要有趣得多,不愧是计算机之子啊 XD。事实上我们现在自研的编辑器基础库中也已经遇到了一些 DOM 和 Canvas 的表达力瓶颈,而这些瓶颈应当是可以通过更加底层的 Shader 开发来克服的。在一定层面上,我们可以认为这些基础从来就不会过时。不过 winter 老师前面非常细粒度的分享最后似乎还是为了介绍 GCanvasG3D这两个轮子(在去年的 D2 上我其实已经听过了一遍安利啦),要是有什么新进展的消息就更好啦。

相比之下,和图形学同样处于较为底层的音视频开发领域,受到的关注就要少那么一些。印象中音视频分会场的主持人还有「在座各位想必都身价不菲」这么一说。这个领域确实有些曲高和寡,如腾讯微视的分享就提到了多 pass 渲染、双边滤波等图形学经典技术。这部分内容已经属于典型的客户端开发范畴了,短期内前端同学对音视频的掌控力可能还是会限制在浏览器环境的这一套已有体系上,难以有较大的突破。

好消息是,大会中已经有了国内的 WASM 分享,基于 WASM 的一些视频特效应用在 Web 前端也已经有了实验性的落地。这部分内容由于我们之前也摸过,因此也和主讲的老师做了一些交流:现阶段 WASM 确实有调试和构建上的难度和瓶颈,但好在从宏观趋势上来看自去年下半年起社区热度已经有了显著增加,也希望它能够早日落地到我们的业务中去创造价值吧~

总结与展望

最后我们列出一些不分先后的参会小心得与评价吧:

  • 从 2015 年的深 JS 大会到今年的 GMTC,能明显感觉到 JS 端的发力,这在 Node.js 上很有体现:从最开始介绍 koa 这样的 web 服务框架,到现在阿里的 Pandora.js 这样的一个可管理、可度量、可追踪的 Node.js 应用管理器,我们能感受到的是一个生态的进化。在 2015 年 Node.js 刚刚起步,大家都在热衷于实现一个后端的 "jQuery" 来 hold 住基本的业务需求。而到了现在,大家所追求的是要构建一个生态,毕竟后端服务需要有完善的一套基础设施才能长久稳定地运行。当然了由于 Node.js 本身的限制,前端同学较难深入到更低的 DB 乃至 OS 等层面去打磨生态,也可以说前端同学在后端领域确实还不够深入。但这不代表我们没有在思考,没有想如何做到更好。

  • 国内技术分享者的节奏把控普遍还有不少的优化空间,很多分享还是很容易使得现场气氛沉闷下来,也确实会有些「新瓶装旧酒」的内容有些老调重弹的感觉。国外讲师普遍明显要更老司机一些(可能与国内技术岗日常交流偏少有关系)。

  • 国内对前端工程的关注点仍然主要放在对业务应用的支撑上。对于比较「低层面」的编程语言、VM、游戏引擎等的基础,除了商业产品外,开源出来的东西仍然还不是特别丰富。

  • 对于现代规模不断增长的项目,想要做好已经不是单枪匹马或是有一技之长就能够 hold 得住的了。对更长的业务链路,我们需要一个能够统筹全局且快速组合各类能力的组织,才能控制得住链路上各个节点的复杂度。

  • 除了基本的工具选型外,Code Review / Case Study 等技术团队的制度也能很大程度地影响团队的工程质量甚至氛围,这方面国内还有很长的路要走。

  • 不论客户端与 Web 前端关系如何发展,它们背后的计算机基础都是相对稳定的。伴随着我们对性能的「压榨」,图形学一类的基础可能会更加重要。

  • GMTC 相比 D2,商业化气息明显更浓了。不过不管商业气息重不重,希望大家都能闷声发大财,这才是坠吼的 :-)


作者:doodlewind
链接:https://juejin.im/post/5b330bcde51d4558ce5eabb5
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

点击查看更多内容
1人点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消