GMTC观后感（二）

本篇是GMTC的前端的性能优化与监控，最火爆的场之一，因为没去过其他的场，也可能是没有之一。有图有真相，反正人是冒出去了，门口全是人，这个图是我听了第三节课后才混到了门口的座位。

性能优化现场

这场是第一天下午的场，一共分为四个分享课，分别是LinkedIn移动应用的性能优化之道、大前端时代前端监控的最佳实践、爱奇艺APP极致体验之路、美团客户端监控与异常排查实践。各家有各家的特长，有各家的方法，不过看起来究极之路的思路方法都差不多，下面我们一起看看他们说了些什么，附大会的PPT下载网址，可能没多久会失效：https://gmtc.geekbang.org/schedule。

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

大会首先提到了为什么要做性能优化，引出了LinkedIn的价值观是用户第一，姑且我们认为这句话也是干货。接着说道项目的规模，5亿月活，200人团队，20业务线，400W代码行数。当项目复杂体量很大的时候，需要进行架构的变更，合理的架构能够解决很多问题，也会避免很多问题，能够化繁为简。

项目组件化应该算是任何项目架构变更的必经之路，将不同的模块分离出来，拆成独立的组件，可以独立的运行。一般来说都是进行业务拆分，而通用的无业务相关性的都会下沉到基础组件库，比如网络层、持久层、公共类、工具类等等。在iOS平台上进行组件的拆分，可以利用Pods将拆分后的组件进行集成，能够很好解决项目的复杂性和耦合性，也方便多组协作，好处不言而喻。组件之间可以用不同的语言开发也互不影响。

性能优化，架构先行

有了合理的架构，也要有一个针对性能的监控方案，下图是监控的地方和监控的链路，讲师提到了他们会在链路中的每个地方都会打点，从网络初始化，到网络握手，到发送第一个字节，接收到第一个字节，以及数据的解析，到UI的展示，都进行了打点计时，为此做了一个专用的网络库。

端上性能监控

关键链路

对于数据采集的方式也给出了几点建议

1.对于通用的性能数据采集，尽量做到避免让业务层感知，避免侵入业务层代码。做到面向切面的编程方式，以iOS为例可以利用runtime来做这个事情。 

2.采集的数据不仅仅是包括性能指标的数据，还需要发生性能问题的时候的上下文采集下来，上下文可能是当时发生问题页面的某一个文字， 根据这个来指定业务线和责任人。

3.采集到数据后最终都是要上传到服务器上， 什么时候上传呢？如果上传的太快就会对服务器造成太大的压力，而且会对主业务的流量淹没掉，太慢又可能对问题的修复不能及时。是一个对服务器的压力和实效性的选择。

4.实践过程中就是对不同类型的日志做了一个优先级的选择。对实效性要求比较高的，像crash,实时推荐的一些自定义事件， 就希望很快的上传到服务器。 不重要的就存在客户端，最后经过压缩批量上传。

数据采集之后，会经过前段的api作为数据的生产者，写入到Kafka，然后会把数据分发到下游的订阅者，Samza 实时任务主要是流式处理，主要是实时性比较高的。另外一个下游是hdfs,是一个每天或者每个小时的一个定时任务处理，这 是一个离线批量的操作，他能够处理的数据量会很大，实效性会差一些。当处理完成之后，会把数据写入到数据库里，然后经过数据的可视化，就能看到各种各样的表格。有了数据就可以进行性能的报警，针对不同的业务种类，就可以制定不同的报警阀门。

数据流

当手机了数据日志之后，要怎么分析定位问题呢？首先通过上下文操作尽量去复现应用的场景。 另外还有一些线程堆栈，这是获取线程的重要信息。此外还做了一些数据的洞察，因为很多问题都是一个局部的问题， 可能只有北京的用户只有这个问题，通过这个数据洞察，就可以发现背后的一个规律。每上线一个feature的时候，有做服务端的开关来做灰度发布和AB的实验，开关也是线上问题的一个保障。当发现性能问题的时候，把服务端的每个开关的状态控制存储上来，通过数据聚合定位到具体是几个开关打开的状态下定位到具体的feature.还有一些分析定位的工具，客户端也有一些诊断日志，发生问题时候，会把诊断日志拉出来。

定位到问题，首先用了服务端开关控制问题的出现，热修复也能够解决问题，但是现在苹果并不能使用这个功能，最后实在没办法只能通过发布新版本解决。

每上线一个feature，都会有AB的实验。性能优化也是一样，都会做一个AB。原理比较简单，把用户分成两拨，一拨是能看到新的功能，另一拨不能看到。通过数据的对比分析，就可以看到实验对我们带来哪些影响。主要是通过工具来进行AB实验，Lix&XLNT是一个创建和维护AB的平台，预先定义了一些丰富的规则，针对用户的身份或者应用的版本。

AB实验

性能优化实践：

监控发现的问题

1.首先针对网络的优化，以前用的是mux，会有多个HTTP Request走到server，增加了一层应用层面的多路复用。

曾经的MUX

在2017年的时候已经全面的接入到http2.0，因为这个天然的支持多个http请求复用一个连接。在连接上分为多个二进制的流，这些流可以并行的处理数据。头部压缩也进行了改进，对传送的数据也变得小一些。切换到http2.0后，页面加载时间缩短 ~7.5%。

最近也在尝试Google的QUIC，为此针对web和iOS做了写改进。

QUIC

2.数据简化。

数据简化

数据的精简这里也做了工具来优化，这里使用了Frontend Deco。首先定义一个data model,有abcde五个字段，在页面上用到了abc是哪个字段，而通过Frontend Deco来获取指定的只有abc的一个轻量化的data model。这个的思想跟上一文中提到的GraphQL是一样的。

3.布局优化

针对布局优化，做了一个layoutkit框架，经过统计要比aotolayout性能高出很多。LayoutKit的思路主要借鉴于flexbox，把布局的计算局限于在一个轴上，使布局计算的复杂度能够大大下降。Layoutkit是一个swift框架已经开源，附github地址：https://github.com/linkedin/LayoutKit

最后总结：