本文由
玉刚说写作平台提供写作赞助原作者：
两位低调的 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接口的方式都会产生错误或者其他不希望的后果，如果下表中详细说明了各种访问方式及相应的结果。
《快应用开发与实现指南》
快应用是九大手机厂商基于硬件平台共同推出的新型应用生态，用户无需下载安装，即点即用，享受原生应用的性能体验。 首先，作者用2段小视频展示了快应用的使用场景和多场景融入的一个示例。快应用与H5均由脚手架生成项目，作者进行了对比和分析，如下图。
最后作者总结了下整个快应用的架构：数据驱动+DOM模型+应用管理。
性能优化与监控专场
尤其是这两年，性能优化与监控方向越来越受到各大公司的重视，从现场的火爆程度也能反应出来，一整个下午的演讲，会场坐满了人，还有不少是直接坐在地上的，讲台边的，甚至门口还有一大波实在是挤不进来了在门外听的。性能优化与监控专场主要有4个主题的分享，对于这4个主题的最终目标是一致的，所用手段不尽相同，但是整体思路差不多，限于篇幅的关系，这里主要分享一下《LinkedIn移动应用的性能优化之道》。
《LinkedIn移动应用的性能优化之道》
首先介绍了为什么要做性能优化，作者的观点是用户第一，接着展示了当前LinkedIn注册用户超5亿，20多个业务线，团队开发人员200多人，代码行数累积400万；然后作者引出性能问题往往是项目规模太大引起的，因此认为合理的架构设计可以将问题化繁为简，要解决好性能问题，首先就需要好的架构设计；如下图所示，项目组件化应该算是任何项目架构变更的必经之路，将不同的模块分离出来，拆成独立的组件，可以独立的运行。
1）面向切面编程，尽量避免侵入业务，做到业务层面无感知；
2）数据采集不仅仅是包括性能指标的数据，有时候需要采集发生性能问题的上下文数据，同时需要划分业务线和责任人；
3）数据采集完成后最终都是要上传到服务器上，在上传的过程中，如果速度太快就会对服务器造成太大的压力，而且可能会把主业务的流量淹没掉，太慢又可能对问题不能及时修复，因此在数据上传的过程中需要权衡服务器压力与实效性；
4）由于采集的日志量非常大，我们不可能去分析所有的日志，因此需要对日志做优先级的选择。对实效性要求比较高的数据，例如Crash日志、实时下发的一些自定义事件，希望很快的上传到服务器，不重要的日志先暂存在客户端，最后经过压缩批量上传；
再次，作者展示了领英从数据采集、存储、上报到数据可视化的整个方案。如下图所示：首先是客户端进行数据采集，经过后台提供的数据上传Api接口把数据上传到后台，后台服务把数据写入到Kafka，接着把数据分发到下游的订阅者：Samza实时任务和HDFS，Samza实时任务主要是流式处理，具有较高的实时性；HDFS是每天或者每个小时的一个定时任务处理，主要是对离线数据进行批量操作，处理大量的数据，但是实时性就差一些了；当处理完成之后，会把实时数据和定时数据写到数据库里，通过数据可视化工具，就能看到不同数据对应的表格；最后通过设置数据的性能报警阈值，可以对性能问题进行实时监控。
有了性能日志，那么接下来就是对日志进行分析。首先我们看下是否能够对当前问题进行重现；然后检测当前网络、数据开关等是否正常；最后再通过一些分析工具对当前获取的日志进行分析并定位问题。问题定位到后，就需要对问题进行修复，常用的解决方式主要有：后台服务进行降级处理、客户端发补丁进行热修复、发布新的小版本。问题修复完成后，最后一步就是对刚刚修复的问题进行验证，验证线上是否已经完全进行修复并且不会对其他功能模块产生影响。
最后，作者介绍了下性能优化在LinkedIn中的具体实践；如下图所示，主要包括：
1）网络优化
2）数据简化
3）布局优化
2）数据优化使用了采用数据精简工具Frontend Deco，删除无用字段，精简数据的模型等；
最后作者进行了一个总结，就不多描述了，附图一张。
总结
GMTC从16年第一届的移动端发展到现在第三届的大前端，知名度也越来越高，专题数也扩大至当前的14个。个人感觉大方向主要有3个：
第一个是端上的深根细作，比如性能优化与监控等；第二个是端上的跨界融合，比如端上AI与音视频等的结合；第三个是大前端的一统江湖，国外从FaceBook推出的RN到现在Google发布的Flutter，国内从微信的小程序到现在的九大厂商联合推出的快应用，国内外厂商在大前端一统的路上百花齐放，充分说明未来一定是前端、Android与iOS大统一的趋势。
以上内容仅代表个人观点，有什么问题欢迎探讨指正。