Android 工程师眼里的大前端：GMTC 2018 参会总结

本文由玉刚说写作平台提供写作赞助

原作者：两位低调的 Android 高手

版权声明：本文版权归微信公众号玉刚说所有，未经许可，不得以任何形式转载

概述

2018年的GMTC大会于6月22号在北京刚刚拉下帷幕，GMTC会议是由极客邦科技和InfoQ中国主办的顶级技术盛会，主要涉猎前端、移动端、终端AI等多个技术领域，从16年到目前总共举办了3届，从今年的火爆程度也能看出GMTC全球大前端开发者技术大会算是大前端的最重要的垂直会议之一了。

有幸参加了这届GMTC大会，会议的14个专场基本覆盖了大前端的方方面面，满满的日程对于体力也是消耗非常大，不过也收获颇多，除了能够了解到各大公司面临的技术难题与解决思路，还能了解到当前最前沿的技术热点与未来方向。趁热打铁谈谈个人的一些收获与感想，这次会议的专题包括Android新技术专场、iOS新技术专场、Node专场、Web框架专场、UI与动画、PWA专场、终端AI、工程化、跨平台专场、性能优化与监控等14个专题。由于专题比较多，多个专题都是并行演讲，分身乏术，这里主要聊聊个人比较关心的2个专题。

1）Android新技术专场

2）性能优化与监控专场

Android新技术专场

新技术代表着当前的技术热点与未来方向，作为一个大前端的RD，不得不时刻关注着大前端技术的方向。Android新技术专场主要有三个主题分享，分别是《Android 研发的昨天今天明天》、《当插件化遇上Android P》与《快应用开发与实现指南》。

《Android 研发的昨天、今天、明天》

作者具有丰富的软件研发经验，推动了App组件化、动态部署、热补丁等技术的发展和制定相关的机制，改善了Android设备的体验，包括绿色联盟(Greenify)应用公约、Android6.0-Doze&App Standby/Android7.0-部分限制静态广播注册/Android8.0-全面限制静态广播注册和后台服务等。

首先，作者认为Android发展的昨天是属于一种流量圈地的时代，起初由简单的WebApp的流量入口，到最后大多数都转到NativeApp的入口；因为流量是互联网的基础概念，有了流量，有了用户，才有更加深入的转换，所以说流量是关键的第一步，因此昨天属于抢占流量入口的时代。

其次，作者认为Android发展的今天是流量攻守的时代，随着各大应用功能越来越复杂，规模越来越大，获得了流量的入口，那么就需要攻守兼备，对于攻采用从大型应用到免安装应用的过度，例如像PWA、Google Play Instant、小程序等，对于守采用启动图标+推送的方式，例如Shortcut、Contextual Push、Rich Notification等。

最后，作者认为Android发展的明天是心智渗透的时代，需要针对不同的群体塑造差异化的认知。作者认为将到来的根本性变更是移动互联网的范式转移和移动应用的技术栈跃迁。

总结，作者认为从技术层面简单来说：昨天是从Web到Native，今天是跨平台，明天是跨终端。

《当插件化遇上Android P》

首先，作者介绍了Android P的时间表，今天3月谷歌发布了Android P的预览版，预计今年Q3会发布最终的release版本；Android P中发布了禁令：禁止调用非SDK的接口，各种访问非SDK接口的方式都会产生错误或者其他不希望的后果，如果下表中详细说明了各种访问方式及相应的结果。

针对上述的后果，对于开发者来说是相当糟糕了，幸好在Android P中有三个名单来帮助开发者进行相关工作，具体如下表所示。

其次，作者介绍了实现插件化的黑科技，主要包括Hook App运行时的一些关键点，通过反射将插件的dex加入到BaseDexClassLoader中的pathList中，资源加载这块通过反射调用AssertManager中的addAssertPaths方法加载插件中的资源，如下图所示。

再次，作者介绍了下为什么京东业务要实现插件化，以及他们业务的需求和未来的方向：

作者对插件化、Android App Bundles、组件化和前端进行了对比：

最后，作者针对京东的插件化框架Aura，进行了升级，原来单纯的插件化框架升级后由插件化和组件化共同组成Aura Plus。京东重构后的架构图如下，包括了业务组件和业务插件两部分。

《快应用开发与实现指南》

快应用是九大手机厂商基于硬件平台共同推出的新型应用生态，用户无需下载安装，即点即用，享受原生应用的性能体验。
首先，作者用2段小视频展示了快应用的使用场景和多场景融入的一个示例。快应用与H5均由脚手架生成项目，作者进行了对比和分析，如下图。

项目脚手架的整个工程结构如下图所示。

通过简单的例子展示了静态页面的编写和布局的调整。

其次，作者讲解了下开发过程中的模板渲染、事件响应、整个页面的生命周期、组件化的使用和导入和动画的使用等，通过一段视频展示了快应用开发过程中debug调试的使用方式。以上主要是快应用开发过程中需要掌握的一些基础知识，作者进行了详细的介绍。作者聊了下快应用的整个架构思路，主要包括编译时和运行时两部分，编译时由输入的html+style+script、ux页面等转为json+js、js页面和rpk压缩文件，运行时由编译时的产物生成DOM树、UI页面和最终的应用程序。

快应用编译时的主要架构如下图，可以看到从下层到上层主要包括：hap-toolkit工具->脚手架+编译器+调试器+服务器->模块化+数据模块等->ux页面文件+其他类型文件->手机运行平台：

快应用运行时的主要架构为：

快应用JS层的架构为：

快应用样式计算引擎为：

快应用页面渲染结构为：

最后作者总结了下整个快应用的架构：数据驱动+DOM模型+应用管理。

性能优化与监控专场

尤其是这两年，性能优化与监控方向越来越受到各大公司的重视，从现场的火爆程度也能反应出来，一整个下午的演讲，会场坐满了人，还有不少是直接坐在地上的，讲台边的，甚至门口还有一大波实在是挤不进来了在门外听的。性能优化与监控专场主要有4个主题的分享，对于这4个主题的最终目标是一致的，所用手段不尽相同，但是整体思路差不多，限于篇幅的关系，这里主要分享一下《LinkedIn移动应用的性能优化之道》。

《LinkedIn移动应用的性能优化之道》

首先介绍了为什么要做性能优化，作者的观点是用户第一，接着展示了当前LinkedIn注册用户超5亿，20多个业务线，团队开发人员200多人，代码行数累积400万；然后作者引出性能问题往往是项目规模太大引起的，因此认为合理的架构设计可以将问题化繁为简，要解决好性能问题，首先就需要好的架构设计；如下图所示，项目组件化应该算是任何项目架构变更的必经之路，将不同的模块分离出来，拆成独立的组件，可以独立的运行。

其次，作者介绍了合理的架构下也要有一个针对性能的监控方案，作者认为线上性能监控主要包括：发现问题、分析问题、解决问题和验证效果四大模块。Crash率、业务异常属于一个App是否可用的重要指标；启动时间和包大小作为App的基础性能；页面FPS、页面渲染度是页面流畅性的重要指标；CUP使用率、内存占用情况以及流量消耗等是资源消耗监控的关键点。
下图是监控的地方和监控的链路，作者提到他们会在关键链路中的每个地方都会打点，从网络初始化，到网络握手，到发送第一个字节，接收到第一个字节，以及数据的解析，到UI的展示，都进行了打点计时，为此做了一个专用的网络库。

在数据采集方面，作者也提出一些较好的见解：

1）面向切面编程，尽量避免侵入业务，做到业务层面无感知；

2）数据采集不仅仅是包括性能指标的数据，有时候需要采集发生性能问题的上下文数据，同时需要划分业务线和责任人；

3）数据采集完成后最终都是要上传到服务器上，在上传的过程中，如果速度太快就会对服务器造成太大的压力，而且可能会把主业务的流量淹没掉，太慢又可能对问题不能及时修复，因此在数据上传的过程中需要权衡服务器压力与实效性；

4）由于采集的日志量非常大，我们不可能去分析所有的日志，因此需要对日志做优先级的选择。对实效性要求比较高的数据，例如Crash日志、实时下发的一些自定义事件，希望很快的上传到服务器，不重要的日志先暂存在客户端，最后经过压缩批量上传；

再次，作者展示了领英从数据采集、存储、上报到数据可视化的整个方案。如下图所示：首先是客户端进行数据采集，经过后台提供的数据上传Api接口把数据上传到后台，后台服务把数据写入到Kafka，接着把数据分发到下游的订阅者：Samza实时任务和HDFS，Samza实时任务主要是流式处理，具有较高的实时性；HDFS是每天或者每个小时的一个定时任务处理，主要是对离线数据进行批量操作，处理大量的数据，但是实时性就差一些了；当处理完成之后，会把实时数据和定时数据写到数据库里，通过数据可视化工具，就能看到不同数据对应的表格；最后通过设置数据的性能报警阈值，可以对性能问题进行实时监控。

有了性能日志，那么接下来就是对日志进行分析。首先我们看下是否能够对当前问题进行重现；然后检测当前网络、数据开关等是否正常；最后再通过一些分析工具对当前获取的日志进行分析并定位问题。问题定位到后，就需要对问题进行修复，常用的解决方式主要有：后台服务进行降级处理、客户端发补丁进行热修复、发布新的小版本。问题修复完成后，最后一步就是对刚刚修复的问题进行验证，验证线上是否已经完全进行修复并且不会对其他功能模块产生影响。

最后，作者介绍了下性能优化在LinkedIn中的具体实践；如下图所示，主要包括：

1）网络优化

2）数据简化

3）布局优化

1）网络优化主要是从Mux转为HTTP/2，同时作者也在尝试Google的QUIC；

2）数据优化使用了采用数据精简工具Frontend Deco，删除无用字段，精简数据的模型等；

3）布局优化作者首先分析了下Auto Layout的性能问题，针对布局优化，作者开发了一套LayoutKit框架，通过对比统计要比AotoLayout性能高出很多。LayoutKit的思路主要借鉴于Flexbox，把布局的计算局限于在一个轴上，使布局计算的复杂度能够大大下降，LayoutKit的开源地址：https://github.com/linkedin/LayoutKit。

最后作者进行了一个总结，就不多描述了，附图一张。

总结

GMTC从16年第一届的移动端发展到现在第三届的大前端，知名度也越来越高，专题数也扩大至当前的14个。个人感觉大方向主要有3个：

• 第一个是端上的深根细作，比如性能优化与监控等；
• 第二个是端上的跨界融合，比如端上AI与音视频等的结合；
• 第三个是大前端的一统江湖，国外从FaceBook推出的RN到现在Google发布的Flutter，国内从微信的小程序到现在的九大厂商联合推出的快应用，国内外厂商在大前端一统的路上百花齐放，充分说明未来一定是前端、Android与iOS大统一的趋势。

以上内容仅代表个人观点，有什么问题欢迎探讨指正。

欢迎关注我的微信公众号，接收第一手技术干货