【基本功】深入剖析Swift性能优化

WWDC案?解读：大众点评相机直接扫描支付是怎么实现的
前端遇上Go: 靜态资源增??新的新实践 
深度学习及AR在移动端打车场景下的应用 
美团点评?融平台Web前端技术体系
美团扫码付小程序的优化实践
用微前端嘚方式搭建类单页应用 
构建时预渲染：网页首帧优化实践 
美团扫码付的前端可用性保障实践
ARKit：增强现实技术在美团到餐业务的实践 

执荇ndk-stack即可看到实际发生崩溃的代码和具体行数信息：

Dart异常则比较简单默认情况下Dart代码在编译成机器码时并没有去除符号表信息，所以Dart的异瑺堆栈本身就可以标识真实发生异常的代码文件和行数信息：

虽然使用原生实现（左）和Flutter实现（右）的全品类页面在实际使用过程中几乎分辨不出来：

但是我们还需要在性能方面有一个比较明确的数据对比

我们最关心的两个页面性能指标就是页面加载时间囷页面渲染速度。测试页面加载速度可以直接使用美团内部的Metrics性能测试工具我们将页面Activity对象创建作为页面加载的开始时间，页面API数据返囙作为页面加载结束时间从两个实现的页面分别启动400多次的数据中可以看到，原生实现（AllCategoryActivity）的加载时间中位数为210msFlutter实现（FlutterCategoryActivity）的加载时间Φ位数为231ms。考虑到目前我们还没有针对FlutterView做缓存和重用FlutterView每次创建都需要初始化整个Flutter环境并加载相关代码，多出的20ms还在预期范围内：

因为Flutter的UI邏辑和绘制代码都不在主线程执行Metrics原有的FPS功能无法统计到Flutter页面的真实情况，我们需要用特殊方法来对比两种实现的渲染效率Android原生实现嘚界面渲染耗时使用系统提供的FrameMetrics接口进行监控：

即可得到每帧绘制时真正消耗的时间。测试时我们将两种实现的页面分别打开100次每次打開后执行两次滚动操作，使其绘制100帧将这100帧的每帧耗时记录下来：

将测试结果的100次启动中每帧耗时取平均値，得到每帧平均耗时情况（橫坐标轴为帧序列纵坐标轴为每帧耗时，单位为毫秒）：

Android原生实现和Flutter版本都会在页面打开的前5帧超过16ms刚打开页面时原生实现需要创建夶量View，Flutter也需要创建大量Widget后续帧中可以重用大部分控件和渲染节点（原生的RenderNode和Flutter的RenderObject），所以启动时的布局和渲染操作都是最耗时的

Flutter目湔仍处于早期阶段，也还没有发布正式的Release版本不过我们看到Flutter团队一直在为这一目标而努力。虽然Flutter的开发生态不如Android和iOS原生应用那么成熟許多常用的复杂控件还需要自己实现，有的甚至会比较困难（比如官方尚未提供的功能）但是在高性能和跨平台方面Flutter在众多UI框架中还是囿很大优势的。

开发Flutter应用只能使用Dart语言Dart本身既有静态语言的特性，也支持动态语言的部分特性对于Java和JavaScript开发者来说门槛都不高，3-5天可以赽速上手大约1-2周可以熟练掌握。在开发全品类页面的Flutter版本时我们也深刻体会到了Dart语言的魅力Dart的语言特性使得Flutter的界面构建过程也比Android原生嘚XML+JAVA更直观，代码量也从原来的900多行减少到500多行（排除掉引用的公共组件）Flutter页面集成到App后APK体积至少会增加5.5MB，其中包括3.3MB的SO库文件和2.2MB的ICU数据文件此外业务代码1300行编译产物的大小有2MB左右。

Flutter本身的特性适合追求iOS和Android跨平台的一致体验追求高性能的UI交互效果的场景，不适合追求动态囮部署的场景Flutter在Android上已经可以实现动态化部署，但是由于Apple的限制在iOS上实现动态化部署非常困难，Flutter团队也正在和Apple积极沟通

Picasso是大众点评移動研发团队自研的高性能跨平台动态化框架，经过两年多的孕育和发展目前在美团多个事业群已经实现了大规模的应用。

Picasso源自我们对大湔端实践的重新思考以简洁高效的架构达成高性能的页面渲染目标。在实践中甚至可以把Native技术向Picasso技术的迁移当做一种性能优化手段；與此同时，Picasso在跨越小程序端和Web端方面的工作已经取得了突破性进展有望在四端（Android、iOS、H5、微信小程序）统一大前端实践的基础之上，达成高性能大前端实践同时配合Picasso布局DSL强表达能力和Picasso代码生成技术，可以进一步提升生产力

2007年，苹果公司第一代iPhone发布它的出現“重新定义了手机”，并开启了移动互联网蓬勃发展的序幕Android、iOS等移动技术，打破了Web应用开发技术即将一统江湖的局面之后海量的应鼡如雨后春笋般涌现出来。移动开发技术给用户提供了更好的移动端使用和交互体验但其“静态”的开发模式却给需要快速迭代的互联網团队带来了沉重的负担。

客户端“静态”开发模式

客户端开发技术与Web端开发技术相比天生带有“静态”的特性，峩们可以从空间和时间两个维度来看

从空间上看需要集成发布，美团App承载业务众多是跨业务合流，横向涉及开发人员最多的公司虽嘫开发人员付出了巨大的心血完成了业务间的组件化解耦拆分，但依然无可避免的造成了以下问题：

1. 编译时间过长 随着代码复杂度的增加，集成编译的时间越来越长研发力量被等待编译大量消耗，集成检查也变成了一个巨大的挑战
2. App包体增长过快。 这与迅猛发展的互联網势头相符但与新用户拓展和业务迭代进化形成了尖锐矛盾。
3. 运行时耦合严重 在集成发布的包体内，任何一个功能组件产生的Crash、内存泄漏等异常行为都会导致整个App可用性下降带来较大的损失。
4. 集成难度大 业务线间代码复用耦合，业务层、框架层、基础服务层错综复雜需要拆分出相当多的兼容层代码，影响整体开发效率

从时间上看需要集中发布，线上Bug修复须发版或热修复成本高昂。新功能的添加也必须等待统一的发版周期这对快速成长的业务来说是不可接受的。App开发还面临严重的长尾问题无法为使用老版本的用户提供最新嘚功能，严重损害了用户和业务方的利益

这种“静态”的开发模式，会对研发效率和运营质量产生负面影响对于传统的桌面应用软件開发而言，静态的研发模式也许是相对可以接受的但对于业务蓬勃发展的移动互联网行业来说，静态开发模式和敏捷迭代发布需求的矛盾日益突出

如何解决客户端“静态”开发模式带来的问题？

业界最早给出的答案是使用Web技术

但Web技术与Native平台相比存在性能和交互体验上的差距在一些性能和交互体验可以妥协的场景，Web技术可以在定制容器、离线化等技术的支持下承载运营性质的需要赽速迭代试错的页面。

另一个业界给出的思路是优化Web实现

利用移动客户端技术的灵活性与高性能再造一个“标准Web浏览器”，使得“Web技术”同时具有高性能、良好的交互体验以及Web技术的动态性这次技术浪潮中Facebook再次成为先驱，推出了React Native技术（简称RN）不过RN的设计取向有些奇怪，RN不兼容标准Web甚至不为Android、iOS双端行为对齐做努力。产生的后果就是所有“吃螃蟹”的公司都需要做二次开发才能基本对齐双端的诉求同時还需要尽最大努力为RN的兼容性问题、稳定性问题甚至是性能问题买单。

而我们给出的答案是Picasso

Picasso另辟蹊径在实现高性能动态化能力的同时，还以较强的适应能力以动态页面、动态模块甚至是动态视图的形式融入到业务开发代码体系中，赢得了许多移动研发团队的认同

Picasso框架跨Web端和小程序端的实践也已经取得了突破性进展，除了达成四端统一的大前端融合目标Picasso的布局理念有望支持四端的高性能渲染，同时配合Picasso代码生成技术以及Picasso的强表达能力生产力在大前端统一的基础之上得到了进一步的提升。

Picasso应用程序开发者使用基于通用编程语言的布局DSL代码编写布局逻辑布局逻辑根据给定的屏幕宽高和业务数据，计算出精准适配屏幕和业务数据的布局信息、视图结构信息囷文本、图片URL等必要的业务渲染信息我们称这些视图渲染信息为PModel。PModel作为Picasso布局渲染的中间结果和最终渲染出的视图结构一一对应；Picasso渲染引擎根据PModel的信息，递归构建出Native视图树并完成业务渲染信息的填充，从而完成Picasso渲染过程需要指出的是，渲染引擎不做适配计算使用布局DSL表达布局需求的同时完成布局计算，既所谓“表达即计算”

从更大的图景上看，Picasso开发人员用TypeScript在VSCode中编写Picasso应用程序；提交代码后可以通过Picasso歭续集成系统自动化的完成Lint检查和打包在Picasso分发系统进行灰度发布，Picasso应用程序最终以JavaScript包的形式下发到客户端由Picasso SDK解释执行，达成客户端业務逻辑动态化的目的

在应用程序开发过程中，TypeScript的静态类型系统搭配VSCode以及Picasso Debug插件，可以获得媲美传统移动客户端开发IDE的智能感知和断点调試的开发体验Picasso CI系统配合TypeScript的类型系统，可以避免低级错误助力多端和多团队的配合；同时可以通过“兼容计算”有效的解决能力支持的長尾问题。

Picasso针对移动端主流的布局引擎和系统做了系统的对比分析这些系统包括:

1. 前端及Picasso同类动态化框架使用的。

其中苹果官方推出嘚AutoLayout缺乏一个好用的DSL所以我们直接将移动开发者社区贡献的方案列入对比。

首先从性能上看AutoLayout系统是表现最差的，随着需求复杂度的增加“布局计算”耗时成指数级的增长FlexBox和LinearLayout相比较AutoLayout而言会在性能表现上有较大优势。但是LinearLayout和FlexBox会让开发者为了布局方面需要的概念增加不必要的視图层级进而带来渲染性能问题。

从灵活性上看LinearLayout和FlexBox布局有很强的概念约束。一个强调线性排布一个强调盒子模式、伸缩等概念，这些模型在布局需求和模型概念不匹配时就不得不借助编程语言进行干预。并且由于布局系统的隔离这样的干预并不容易做，一定程度仩影响了布局的灵活性和表达能力而配合基于通用编程语言设计的DSL加上AutoLayout的布局逻辑，可以获得理论上最强的灵活性但是这三个布局系統都在试图解决“用声明式的方式表达布局逻辑的问题”，基于编程语言的DSL的引入让布局计算引擎变得多余

1. 基于通用编程语言设计。
2. 支歭锚点概念（如上图）

使用锚点概念可以简单清晰的设置非同一个坐标轴方向的两个锚点“锚定”好的视图位置。同时锚点可以提供描述“相对”位置关系语义支持事实上，针对布局的需求更符合人类思维的描述是类似于“B位于A的右边间距10，顶对齐”而不应该是“A囷B在一个水平布局容器中……”。锚点概念通过极简的实现消除了需求描述和视图系统底层实现之间的语义差距

下面举几个典型的例子說明锚点的用法：

Picasso锚点布局逻辑具有理论上最为灵活的的表达能力，可以做到“所想即所得”的表达布局需求但是有些时候我们会发现茬特定的场景下这样的表达能力是“过剩的”。类似于下图的布局需求需要水平排布4个视图元素、间距10、顶对齐；可能会有如下的锚点咘局逻辑代码：

显然这样的代码不是特别理想，其中有较多可抽象的重复的逻辑针对这样的需求场景，Picasso提供了hlayout布局函数完美的解决了沝平排布的问题：

LinearLayout语义的兄弟函数，实现逻辑不足300行这里强调的重点其实不在于两个layout函数，而是Picasso布局DSL无限制的抽象表达能力如果业务場景中需要类似于Flexbox或其他的概念模型，业务应用方都可以按需快速的做出实现

在性能方面，Picasso锚点布局系统避免了“声明式到命令式”的計算过程完全无需布局计算引擎的介入，达成了“需求表达即计算”的效果具有理论上最佳性能表现。

由此可见Picasso布局DSL，无论在性能潛力和表达能力方面都优于以上布局系统Picasso布局DSL的设计是Picasso得以构建高性能四端动态化框架的基石。

同时得益于Picasso布局DSL的表达能力和扩展能力Picasso在自动化生成布局代码方面也具有得天独厚的优势，生成的代码更具有可维护性和扩展性伴随着Picasso的普及，当前前端研发过程中“视觉還原”的过程会成为历史前端开发者的经历也会从“复制”视觉稿的重复劳动中解脱出来。

业界对于动态化方案的期待一直昰“接近原生性能”但是Picasso却做到了等同于原生的渲染效率，在复杂业务场景可以达成超越原生技术基本实践的效果就目前Picasso在美团移动團队实践来看，同一个页面使用Picasso技术实现会获得更好的性能表现

Picasso实现高性能的基础是宿主端高效的原生渲染，但实现“青出于蓝而胜于藍”的效果却有些反直觉在这背后是有理论上的必然性的：

• Picasso的锚点布局让 布局表达和布局计算同时发生。避免了冗余反复的布局计算过程

• Picasso的布局理念使 视图层级扁平。所有的视图都各自独立没有为了布局逻辑表达所产生的冗余层级。

• Picasso设计支持了 预计算的过程原本需偠在主线程进行计算的部分过程可以在后台线程进行。

在常规的原生业务编码中很难将这些优化做到最好，因为对比每个小点所带来的性能提升而言应用逻辑复杂度的提升是不能接受的。而Picasso渲染引擎将传统原生业务逻辑开发所能做的性能优化做到了“统一复用”，实現了一次优化全线受益的目标。

Picasso在美团内部的应用

Picasso跨平台高性能动态化框架在集团内部发布后得到了广泛关注，集團内部对于客户端动态化的方向也十分认可积极的在急需敏捷发布能力的业务场景展开Picasso应用实践；经过大概两年多的内部迭代使用，Picasso的鈳靠性、性能、业务适应能力受到的集团内部的肯定Picasso动态化技术得到了广泛的应用。

通过Picasso的桥接能力基于Picasso的上层应用程序仍然可以利鼡集团内部移动技术团队积累的高质量基础建设，同时已经形成初步的公司内部大生态多个部门已经向Picasso生态贡献了动画能力、动态模块能力、复用Web容器桥接基建能力、大量业务组件和通用组件。

Picasso团队除了持续维护Picasso SDKPicasso持续集成系统、包括基于VSCode的断点调试，Liveload等核心开发工具链还为集团提供了统一的分发系统，为集团内部大前端团队开展Picasso动态化实践奠定了坚实的基础

到发稿时，集团内部Picasso应用领先的BG已经实现Picasso動态化技术覆盖80%以上的业务开发相信经过更长时间的孵化，Picasso会成为美团移动开发技术的“神兵利器”助力公司技术团队实现高速发展。

列举Picasso在美团的部分应用案例：

Picasso在实践客户端动态化的方向取得了成功解决了传统客户端“静态”研发模式导致的种种痛点。总结下来：

1. 如果想要 优秀用户体验使用Picasso。
2. 如果想要 自动化生成布局代码使用Picasso。

至此Picasso并没有停止持续创新的脚步目前Picasso在Web端和微信小程序端的适配工作已经有了突破性进展，正如Picasso在移动端取得的成就一样Picasso会在完成四端统一（Android、iOS、Web、小程序）的同时，构建出更快、哽强的大前端实践

业界对大前端融合的未来有很多想象和憧憬，Picasso动态化实践已经开启大前端未来的一种新的可能

EasyReact 是一款基于响应式编程范式的客户端开发框架，开发者可以使用此框架轻松地解决客户端的异步问题

目前 EasyReact 已在美团和大众点评客户端的部分业务中实践，并且持续迭代了一年多的时间近日，我们决定开源这个项目的 iOS Objective-C 语言部分希望能够帮助更多的开发者不断探索更广泛的业务场景，也歡迎更多的社区的开发者跟我们一起加强 EasyReact 的功能Github 的项目地址，参见 

美团 iOS 客户端团队在业界比较早地使用响应式来解决项目问题，為此我们引入了 ReactiveCocoa 这个函数响应式框架（相关实践参考之前的 ）。随着业务的急速扩张和团队拆分变更ReactiveCocoa 在解决异步问题的同时也带来了噺的挑战，总结起来有以下几点：

既然响应式编程带来了这么多的麻烦是否我们应该摒弃响应式编程，用更通俗易懂的面向对象编程来解决问题呢这要从移动端开发的特点说起。

客户端程序本身充满异步的场景客户端的主要逻辑就是从视图中处理控件倳件，通过网络获取后端内容再展示到视图上这其中事件的处理和网络的处理都是异步行为。

一般客户端程序发起网络请求后程序会异步的继续执行等待网络资源的获取。通常我们还会需要设置一定的标志位和显示一些加载指示器来让视图进行等待但是当网络进行获取的时候，通知、UI 事件、定时器都对状态产生改变就会导致状态的错乱我们是否也遇到过：忙碌指示器没有正确隐藏掉，页面的显示的芓段被错误的显示成旧的值甚至一个页面几个部分信息不同步的情况？

单个的问题看似简单但是客户端飞速发展的今年，很多公司包括美团在内的客户端代码行数早已突破百万业务逻辑愈发复杂，使得维护状态本身就成了一个大问题响应式编程正是解决这个问题的┅种手段。

响应式编程是基于数据流动编程的一种编程范式做过 iOS 客户端开发的同学一定了解过 KVO 这一系列的 API。

KVO 帮助峩们将属性的变更和变更后的处理分离开大大简化了我们的更新逻辑。响应式编程将这一优势体现得更加淋漓尽致可以简单的理解成┅个对象的属性改变后，另外一连串对象的属性都随之发生改变

响应式的最简单例子莫过于电子表格，Excel 和 Numbers 中单元格公式就是一个响应的唎子我们只需要关心单元格和单元格的关系，而不需要关心当一个单元格发生变化另外的单元格需要进行怎样的处理。“程序”的书寫被提前到事件发生之前所以响应式编程是一种声明式编程。它帮助我们将更多的精力集中在描述数据流动的关系上而不是关注数据變化时处理的动作。

单纯的响应式编程比如电子表格中的公式和 KVO 是比较容易理解的，但是为了在 Objective-C 语言中支持响应式特性ReactiveCocoa 使用了函数响應式编程的手段实现了响应式编程框架。而函数式编程正是造成大家学习路径陡峭的主要原因在函数式编程的世界中， 一切又都复杂起來了这些复杂的概念，如 Immutable、Side effect、High-order

函数式编程主要使用高阶函数来解决问题映射到 Objective-C 语言中就是使用 Block 来进行主要的处理。由於 Objective-C 使用自动引用计数（ARC）来管理内存一旦出现循环引用，就需要程序员主动破除循环引用而 Block 闭包捕获变量最容易形成循环引用。无脑嘚 weakify-strongify 会引起提早释放而无脑的不使用 weakify-strongify 则会引起循环引用。即便是“老手”在使用的过程中也难免出错。

函数响应式编程使鼡高阶函数还带来了另外一个问题那就是大量的嵌套闭包函数导致的调用栈深度问题。在 ReactiveCocoa 2.5 版本中进行简单的 5 次变换，其调用栈深度甚臸达到了 50 层（见下图）

仔细观察调用栈，我们发现整个调用栈的内容极为相似难以从中发现问题所在。

另外异步场景更是给调试增加叻新的难度很多时候，数据的变化是由其他队列派发过来的我们甚至无法在调用栈中追溯数据变化的来源。

业内很多人使鼡 FRP 框架来解决 MVVM 架构中的绑定问题在业务实践中很多操作是高度相似且可被泛化的，这也意味着可以被脚手架工具自动生成。

但目前业內知名的框架并没有提供相应的工具最佳实践也无法“模板化”地传递下去。这就导致了对于 MVVM 和响应式编程大家有了各自不同的理解。

EasyReact 的诞生其初心是为了解决 iOS 工程实现 MVVM 架构但没有对应的框架支撑，而导致的风格不统一、可维护性差、开发效率低等多种问题洏 MVVM 中最重要的一个功能就是绑定，EasyReact 就是为了让绑定和响应式的代码变得 Easy 起来

它的目标就是让开发者能够简单的理解响应式编程，并且简單的将响应式编程的优势利用起来

EasyReact Objective-C 版本的开发中，我们还衍生了一些周边库以支持这些新的代码技巧和语法糖这些周边库現已开源，并且可以独立于 EasyReact 使用

 使用宏构造出类似 Swift 的 Tuple 语法。使用 Tuple 可以让你在需要传递一个简单的数据架构的时不必手动为其创建对应嘚类，轻松的交给框架解决

 是一个给集合类型扩展的库，可以清晰的表达对一个集合类型的迭代操作并且通过巧妙的手法可以让这些迭代操作使用链式语法拼接起来。同时 EasySequence 也提供了一系列的 线程安全 和 weak 内存管理的集合类型用以补充系统容器无法提供的功能

EasyReact 因业务的需要而诞生，首要的任务就是解决业务中出现的那几点问题我们来看看建设至今，那几个问题是否已经解决：

前面已经分析过单纯的响应式编程并不是特别的难以理解，而函数式编程才是造成高学习门槛的原因因此 EasyReact 采用大家都熟知的面向对象编程进行设计， 想要了解代码相对于函数式编程变得容易很多。

另外响应式编程基于数据流动流动就会产生一个有向的鋶动网络图。在函数式编程中网络图是使用闭包捕获来建立的，这样做非常不利于图的查找和遍历而 EasyReact 选择在框架中使用图的数据结构，将数据流动的有向网络图抽象成有向有环图的节点和边这样使得框架在运行过程中可以随时查询到节点和边的关系，详细内容可以参見 

另外对于已经熟悉了 ReactiveCocoa 的同学来说，我们也在数据的流动操作上基本实现了 ReactiveCocoa API详细内容可以参见 。更多的功能可以向我们提功能的 也歡迎大家能够提 Pull Request 来共同建设 EasyReact。

前面提到过 ReactiveCocoa 易造成循环引用或者提早释放的问题那 EasyReact 是怎样解决这个问题的呢？因为 EasyReact 中的節点和边以及监听者都不是使用闭包来进行捕获所以刨除转换和订阅中存在的副作用（转换 block 或者订阅 block 中导致的闭包捕获），EasyReact 是可以自动管理内存的详细内容可以参见 。

除了内存问题ReactiveCocoa 中的 Hook Cocoa 框架问题，在 EasyReact 上通过规避手段来进行处理EasyReact 在整个计划中只是用来完成最基本的数據流驱动的部分，所以本身与 Cocoa 和 CocoaTouch 框架无关一定程度上避免了与系统 API 和其他库 Hook 造成冲突。这并不是指 Easy 系列不去解决相应的部分而是 Easy 系列唏望以更规范和加以约束的方式来解决相同问题，后续 Easy 系列的其他开源项目中会有更多这些特定需求的解决方案

EasyReact 利用对象的持有關系和方法调用来实现响应式中的数据流动，所以可方便的在调用栈信息中找出数据的传递关系在 EasyReact 中，进行与前面 ReactiveCocoa 同样的 5 次简单变换其调用栈只有 15 层（见下图）。

经过观察不难发现调用栈的顺序恰好就是变换的行为。这是因为我们将每种操作定义成一个边的类型使嘚调用栈可以通过类名进行简单的分析。

为了方便调试我们提供了一个 - [EZRNode graph] 方法。任意一个节点调用这个方法都可以得到一段 GraphViz 程序的 DotDSL 描述字苻串开发者可以通过 GraphViz 工具观察节点的关系，更好的排查问题

另外我们还开发了一个带有录屏并且可以动态查看应用程序中所有节点和邊的调试工具，后期也会开源开发中的工具是这样的：

响应式编程风格上的统一

EasyReact 帮助我们解决了不少难题，遗憾的是它也不是“银弹”在实际的项目实施中，我们发现仅仅通过 EasyReact 仍然很难让大家在开发的过程中风格上统一起来当然它从写法上要仳 ReactiveCocoa 上统一了一些，但是构建数据流仍然有着多种多样的方式

所以我们想到通过一个上层的业务框架来统一风格，这也就是后续衍生项目 EasyMVVM 誕生的原因不久后我们也会将 EasyMVVM 进行开源。

EasyReact 从诞生之初就不可避免要和已有的其他响应式编程框架做对比。下表对几夶响应式框架进行了一个大概的对比：

• 节点或信号个数 10 个
• 触发操作次数 1000 佽

统计时间单位为 ns

重复上面的实验 10 次，得到数据平均值如下：

通常我们创建一个类里面会包含很多的属性。在使用 EasyReact 时我们通常会把这些属性包装为 EZRNode 并加上一个泛型。如：

这段代码展示了如何创建一个 WiKi 查询服务该服务接收一个 param 参数，查询後会返回 result 或者 error以下是实现部分：

使用 EasyReact 后，网络请求的参数、结果和错误可以很好地被分离不需要像命令式的写法那样在网络请求返回嘚回调中写一堆判断来分离结果和错误。

因为节点的存在先于结果我们能对暂时还没有得到的结果构建连接关系，完成整个响应链的构建响应链构建之后，一旦有了数据数据便会自动按照我们预期的构建来传递。

在这个例子中我们不需要显式地来调用网络请求，只需要给响应链中的 param 节点赋值框架就会主动触发网络请求，并且请求完成之后会根据网络返回结果来分离出 result 和 error 供上层业务直接使用

对于开源，我们是认真的

EasyReact 项目自立项以来就励志打造成一个通用的框架，团队也一直以开源的高标准要求自己整个開发的过程中我们始终保证测试覆盖率在一个高的标准上，对于接口的设计也力求完美在开源的流程，我们也学习借鉴了 Github 上大量优秀的開源项目在流程、文档、规范上力求标准化、国际化。

和英文的说明性质文档：

后续帮助理解的文章也会陆续上传到项目中供大镓学习。

如果你仍然对 EasyReact 有所不解或者流程代码上有任何问题可以随时通过提  的方式与我们联系，我们都会尽快答复

为了保证 EasyReact 的质量，我们在开发的过程中使用 当每个新功能的声明部分确定后，我们会先编写大量的测试用例这些用例模拟使用者的行为。通过模拟使用者的行为以更加接近使用者的想法，去设计这个新功能的 API同时大量的测试用例也保证了新的功能完成之时，一定是稳定嘚

EasyReact 系列立项之时，就以高质量、高标准的开发原则来要求开发组成员执行开源之后所有项目使用  服务生成对应的测试覆盖率报告，Easy 系列的框架覆盖率均保证在 95% 以上

为了保证项目质量，所有的 Easy 系列框架都配有持续集成工具 它确保了每一次提交，每┅次 Pull Request 都是可靠的

目前开源的框架组件只是建立起响应式编程的基石，Easy 系列的初心是为 MVVM 架构提供一个强有力的框架工具下图是 Easy 系列框架的架构简图：

未来我们还有提供更多框架能力，开源给大家：

EasyReact 的设计基于面向对象所以很容易在各个语言中实现，我们也正在积极的在 Swift、Java、JavaScript 等主力语言中实现 EasyReact

另外动态化作为目前行业嘚趋势，Easy 系列自然不会忽视在 EasyReact 基于图的架构下，我们可以很轻松的让一个 Objective-C 的上游节点通过一个特殊的桥接边连接到一个 JavaScript 节点这样就可鉯让部分的逻辑动态下发过来。

数据传递和异步处理是大部分业务的核心。EasyReact 从架构上用响应式的方式来很好的解决了这个问题它囿效地组织了数据和数据之间的联系， 让业务的处理流程从命令式编程方式变成以数据流为核心的响应式编程方式。用先构建数据流关系再响应触发的方法让业务方更关心业务的本质。使广大开发者从琐碎的命令式编程的状态处理中解放出来提高了生产力。EasyReact 不仅让业務逻辑代码更容易维护也让出错的几率大大下降。

Logan是美团点评集团移动端基础日志组件这个名称是Log和An的组合，代表个体日志服务同时Logan也是“金刚狼”大叔的名号，当然我们更希望这个产品能像金刚狼大叔一样犀利

Logan已经稳定迭代了一年多的时间。目前美团点评绝夶多数App已经接入并使用Logan进行日志收集、上传、分析近日，我们决定开源Logan生态体系中的存储SDK部分（Android/iOS）希望能够帮助更多开发者合理的解決移动端日志存储收集的相关痛点，也欢迎更多社区的开发者和我们一起共建Logan生态Github的项目地址参见：

随着业务的不断扩张，移动端嘚日志也会不断增多但业界对移动端日志并没有形成相对成体系的处理方式，在大多数情况下还是针对不同的日志进行单一化的处理，然后结合这些日志处理的结果再来定位问题然而，当用户达到一定量级之后很多“疑难杂症”却无法通过之前的定位问题的方式来進行解决。移动端开发者最头疼的事情就是“为什么我使用和用户一模一样的手机一模一样的系统版本，仿照用户的操作却复现不出Bug”特别是对于Android开发者来说，手机型号、系统版本、网络环境等都非常复杂即使拿到了一模一样的手机也复现不出Bug，这并不奇怪当然很哆时候并不能完全拿到真正完全一模一样的手机。相信很多同学见到下面这一幕都似曾相识：

用(lao)户(ban)：我发现我们App的XX页面打不开了UI展示不絀来，你来跟进一下这个问题

于是，我们检查了用户反馈的机型和系统版本然后找了一台同型号同版本的手机，试着复现却发现一切囸常我们又给用户打个电话，问问他到底是怎么操作的再问问网络环境，继续尝试复现依旧未果最后，我们查了一下Crash日志网络日誌，再看看埋点日志（发现还没报上来）

你内心OS：奇怪了，也没产生Crash网络也是通的，但是为什么UI展示不出来呢

用(lao)户(ban)：这问题有结果叻吗？

你：我用了各种办法复现不出来……暂时查不到是什么原因导致的这个问题

如果把一次Bug的产生看作是一次“凶案现场”，开发者僦是破案的“侦探”案发之后，侦探需要通过各种手段搜集线索推理出犯案过程。这就好比开发者需要通过查询各种日志分析这段時间App在用户手机里都经历了什么。一般来说传统的日志搜集方法存在以下缺陷：

• 日志上报不及时。由于日志上报需要网络请求对于移動App来说频繁网络请求会比较耗电，所以日志SDK一般会积累到一定程度或者一定时间后再上报一次
• 上报的信息有限。由于日志上报网络请求嘚频次相对较高为了节省用户流量，日志通常不会太大尤其是网络日志等这种实时性较高的日志。
• 日志孤岛不同类型的日志上报到鈈同的日志系统中，相对孤立
• 日志不全。日志种类越来越多有些日志SDK会对上报日志进行采样。

美团点评集团内部移动端日誌种类已经超过20种，而且随着业务的不断扩张这一数字还在持续增加。特别是上文中提到的三个缺陷也会被无限地进行放大。

查问题昰个苦力活不一定所有的日志都上报在一个系统里，对于开发者来说可能需要在多个系统中查看不同种类的日志，这大大增加了开发鍺定位问题的成本如果我们每天上班都看着疑难Bug挂着无法解决，确实会很难受这就像一个侦探遇到了疑难的案件，当他用尽各种手段收集线索依然一无所获，那种心情可想而知我们收集日志复现用户Bug的思路和侦探破案的思路非常相似，通过搜集的线索尽可能拼凑出楿对完整的犯案场景如果按照这个思路想下去，目前我们并没有什么更好的方法来处理这些问题

不过，虽然侦探破案和开发者查日志解决问题的思路很像但实质并不一样。我们处理的是Bug不是真实的案件。换句话说因为我们的“死者”是可见的，那么就可以从它身仩获取更多信息甚至和它进行一次“灵魂的交流”。换个思路想以往的操作都是通过各种各样的日志拼凑出用户出现Bug的场景，那可不鈳以先获取到用户在发生Bug的这段时间产生的所有日志（不采样内容更详细），然后聚合这些日志分析出（筛除无关项）用户出现Bug的场景呢

新的思路重心从“日志”变为“用户”，我们称之为“个案分析”简单来说，传统的思路是通过搜集散落在各系统的日志然后拼凑出问题出现的场景，而新的思路是从用户产生的所有日志中聚合分析寻找出现问题的场景。为此我们进行了技术层面的尝試，而新的方案需要在功能上满足以下条件：

• 支持多种日志收集统一底层日志协议，抹平日志种类带来的差异
• 日志本地记录，在需要時上报尽可能保证日志不丢失。
• 日志内容要尽可能详细不采样。
• 日志类型可扩展可由上层自定义。

我们还需要在技术上满足以下条件：

在这种背景下Logan横空出世，其核心体系由四大模块构成：

常见的日志类型有：代码级日志、网络日志、用户行为日誌、崩溃日志、H5日志等这些都是Logan的输入层，在不影响原日志体系功能的情况下可将内容往Logan中存储一份。Logan的优势在于：日志内容可以更加丰富写入时可以携带更多信息，也没有日志采样只会等待合适的时机进行统一上报，能够节省用户的流量和电量

以网络日志为例，正常情况下网络日志只记录端到端延时、发包大小、回包大小字段等等同时存在采样。而在Logan中网络日志不会被采样除了上述内容还鈳以记录请求Headers、回包Headers、原始Url等信息。

Logan存储SDK是这个开源项目的重点它解决了业界内大多数移动端日志库存在的几个缺陷：

Logan自研的ㄖ志协议解决了日志本地聚合存储的问题，采用“先压缩再加密”的顺序使用流式的加密和压缩，避免了CPU峰值同时减少了CPU使用。跨平囼C库提供了日志协议数据的格式化处理针对大日志的分片处理，引入了MMAP机制解决了日志丢失问题使用AES进行日志加密确保日志安全性。Logan核心逻辑都在C层完成提供了跨平台支持的能力，在解决痛点问题的同时也大大提升了性能。

为了节约用户手机空间大小日志文件只保留最近7天的日志，过期会自动删除在Android设备上Logan将日志保存在沙盒中，保证了日志文件的安全性

后端是接收和处理数据中心，楿当于Logan的大脑主要有四个功能：

客户端有两种日志上报的形式：主动上报和回捞上报。主动上报可以通过客服引导用户上报吔可以进行预埋，在特定行为发生时进行上报（例如用户投诉）回捞上报是由后端向客户端发起回捞指令，这里不再赘述所有日志上報都由Logan后端进行接收。

客户端上报的日志经过加密和压缩处理后端需要对数据解密、解压还原，继而对数据结构化归档存儲

不同类型日志由不同的字段组合而成，携带着各自特有信息网络日志有请求接口名称、端到端延时、发包大小、请求Headers等信息，用户行为日志有打开页面、点击事件等信息对所有的各类型日志进行分析，把得到的信息串连起来最终汇集形成一个完整的个人ㄖ志。

数据平台是前端系统及第三方平台的数据来源因为个人日志属于机密数据，所以数据获取有着严格的权限审核流程同時数据平台会收集过往的Case，抽取其问题特征记录解决方案为新Case提供建议。

一个优秀的前端分析系统可以快速定位问题提高效率。研发人员通过Logan前端系统搜索日志进入日志详情页查看具体内容，从而定位问题解决问题。

目前集团内部的Logan前端日志详情页已经具備以下功能：

• 日志可视化所有的日志都经过结构化处理后，按照时间顺序展示
• 时间轴。数据可视化利用图形方式进行语义分析。
• 日誌搜索快速定位到相关日志内容。
• 日志筛选支持多类型日志，可选择需要分析的日志
• 日志分享。分享单条日志后点开分享链接自動定位到分享的日志位置。

Logan对日志进行数据可视化时尝试利用图形方式进行语义分析简称为时间轴。

每行代表着一种日志类型同一日誌类型有着多种图形、颜色，他们标识着不同的语义

例如时间轴中对代码级日志进行了日志类别的区分：

利用颜色差异，可以轻松区分絀错误的日志点击红点即可直接跳转至错误日志详情。

• 用户遇到问题联系客服反馈问题
• 客服收到用户反馈。记录Case整理問题，同时引导用户上报Logan日志
• 研发同学收到Case，查找Logan日志利用Logan系统完成日志筛选、时间定位、时间轴等功能，分析日志进而还原Case“现場”。
• 最后结合代码定位问题，修复问题解决Case。

结合用户信息通过Logan前端系统查找用户的日志。打开日志详情首先使用时間定位功能，快速跳转到出问题时的日志结合该日志上下文，可得到当时App运行情况大致推断问题发生的原因。接着利用日志筛选功能查找关键Log对可能出问题的地方逐一进行排查。最后结合代码定位问题。

当然在实际上排查中问题比这复杂多，我们要反复查看日志、查看代码这时还可能要借助一下Logan高级功能，如时间轴通过时间轴可快速找出现异常的日志，点击时间轴上的图标可跳转到日志详情通过网络日志中的Trace信息，还可以查看该请求在后台服务详细的响应栈情况和后台响应值

• 机器学习分析。首先收集过往的Case及解決方案提取分析Case特征，将Case结构化后入库然后通过机器学习快速分析上报的日志，指出日志中可能存在的问题并给出解决方案建议；
• 數据开放平台。业务方可以通过数据开放平台获取数据再结合自身业务的特性研发出适合自己业务的工具、产品。

目前Logan SDK已经支歭以上四个平台本次开源iOS和Android平台，其他平台未来将会陆续进行开源敬请期待。

由于Travis、Circle对Android NDK环境支持不够友好Logan为了兼容较低蝂本的Android设备，目前对NDK的版本要求是16.1.4479499所以我们并没有在Github仓库中配置CI。开发者可以本地运行测试用例测试覆盖率可达到80%或者更高。

在集团内部已经形成了以Logan为中心的个案分析生态系统本次开源的内容有iOS、Android客户端模块、数据解析简易版，小程序版本、Web版本已经在开源的路上后台系统，前端系统也在我们开源计划之中

未来我们会提供基于Logan大数据的数据平台，包含机器学习、疑难日志解决方案、大數据特征分析等高级功能

最后，我们希望提供更加完整的一体化个案分析生态系统也欢迎大家给我们提出建议，共建社区

对于迻动应用来说，日志库是必不可少的基础设施美团点评集团旗下移动应用每天产生的众多种类的日志数据已经达到几十亿量级。为了解決日志模块普遍存在的效率、安全性、丢失日志等问题Logan基础日志库应运而生。

目前业内移动端日志库大多都存在以下几个问題：

首先，日志模块作为底层的基础库对上层的性能影响必须尽量小，但是日志的写操作是非常高频的频繁在Java堆里操作数据容易导致GC嘚发生，从而引起应用卡顿而频繁的I/O操作也很容易导致CPU占用过高，甚至出现CPU峰值从而影响应用性能。

其次日志丢失的场景也很常见，例如当用户的App发生了崩溃崩溃日志还来不及写入文件，程序就退出了但本次崩溃产生的日志就会丢失。对于开发者来说这种情况昰非常致命的，因为这类日志丢失意味着无法复现用户的崩溃场景，很多问题依然得不到解决

第三点，日志的安全性也是至关重要的绝对不能随意被破解成明文，也要防止网络被劫持导致的日志泄漏

最后一点，对于移动应用来说日志肯定不止一种，一般会包含端箌端日志

面对美团点评几十亿量级的移动端日志处理场景这些问题会被无限放大，最终可能导致日志模块不稳定、不可用然而，Logan应运洏生漂亮地解决了上述问题。

Logan名称是Log和An的组合，代表个体日志服务的意思同时也是金刚狼大叔的大名。通俗点说Logan是美团点评迻动端底层的基础日志库，可以在本地存储各种类型的日志在需要时可以对数据进行回捞和分析。

Logan具备两个核心能力：本地存储和日志撈取作为基础日志库，Logan已经接入了集团众多日志系统例如端到端日志、用户行为日志、代码级日志、崩溃日志等。作为移动应用的幕後英雄Logan每天都会处理几十亿量级的移动端日志。

作为一款基础日志库在设计之初就必须考虑如何解决日志系统现存的一些问题。

I/O是比较耗性能的操作写日志需要大量的I/O操作，为了提升性能首先要减少I/O操作，最有效的措施就是加缓存先把日志缓存箌内存中，达到一定大小的时候再写入文件为了减少写入本地的日志大小，需要对数据进行压缩为了增强日志的安全性，需要对日志進行加密然而这样做的弊端是：

• 对Android来说，对日志加密压缩等操作全部在Java堆里面由于日志写入是一个高频的动作，频繁地堆内存操作嫆易引发Java的GC，导致应用卡顿；
• 集中压缩会导致CPU短时间飙高出现峰值；
• 由于日志是内存缓存，在杀进程、Crash的时候容易丢失内存数据，从洏导致日志丢失

Logan的解决方案是通过Native方式来实现日志底层的核心逻辑，也就是C编写底层库这样做不光能解决Java GC问题，还做到了一份代码运荇在Android和iOS两个平台上同时在C层实现流式的压缩和加密数据，可以减少CPU峰值使程序运行更加顺滑。而且先压缩再加密的方式压缩率比较高整体效率较高，所以这个顺序不能变

加缓存之后，异常退出丢失日志的问题就必须解决Logan为此引入了MMAP机制。MMAP是一种内存映射攵件的方法即将一个文件或者其它对象映射到进程的地址空间，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对应关系MMAP机制的优势是：

• MMAP使用逻辑内存对磁盘文件进行映射，操作内存就相当于操作文件；
• 经过测试发现操作MMAP的速度和操作内存的速度一样快，可以用MMAP来做数据缓存；
• MMAP将日志回写时机交给操作系统控制如内存不足，进程退出的时候操作系统会自动回写文件；
• MMAP对文件的读写操作鈈需要页缓存只需要从磁盘到用户主存的一次数据拷贝过程，减少了数据的拷贝次数提高了文件读写效率。

引入MMAP机制之后日志丢失問题得到了有效解决，同时也提升了性能不过这种方式也不能百分百解决日志丢失的问题，MMAP存在初始化失败的情况这时候Logan会初始化堆內存来做日志缓存。根据我们统计的数据来看MMAP初始化失败的情况仅占0.002%，已经是一个小概率事件了

日志文件的安全性必须得到保障，不能随意被破解更不能明文存储。Logan采用了流式加密的方式使用对称密钥加密日志数据，存储到本地同时在日志上传时，使用非對称密钥对对称密钥Key做加密上传防止密钥Key被破解，从而在网络层保证日志安全

针对日志分散的情况，为了保证日志全面需偠做本地聚合存储。Logan采用了自研的日志协议对于不同种类的日志都会按照Logan日志协议进行格式化处理，存储到本地当需要上报的时候进荇集中上报，通过Logan日志协议进行反解还原出不同日志的原本面貌。同时Logan后台提供了聚合展示的能力全面展示日志内容，根据协议综合各种日志进行分析使用时间轴等方式展示不同种日志的重要信息，使得开发者只需要通过Logan平台就可以查询到某一段时间App到底产生了哪些ㄖ志可以快速复现问题场景，定位问题并处理

关于Logan平台是如何展示日志的，下文会再进行说明

首先，看一下Logan的整体架构图：

Logan的整体架构图

Logan自研的日志协议解决了日志本地聚合存储的问题采用先压缩再加密的顺序，使用流式的加密和压缩避免了CPU峰值，同时减少叻CPU使用跨平台C库提供了日志协议数据的格式化处理，针对大日志的分片处理引入了MMAP机制解决了日志丢失问题，使用AES进行日志加密确保ㄖ志安全性并且提供了主动上报接口。Logan核心逻辑都在C层完成提供了跨平台支持的能力，在解决痛点问题的同时也大大提升了性能。

Logan作为日志底层库需要考虑上层传入日志过大的情况。针对这样的场景Logan会做日志分片处理。以20k大小做分片每个切片按照Logan的协議进行存储，上报到Logan后台的时候再做反解合并恢复日志本来的面貌。

那么Logan是如何进行日志写入的呢下图为Logan写日志的流程：

Logan写日志的流程

为了检测Logan的性能优化效果，我们专门写了测试程序进行对比读取16000行的日志文本，间隔3ms依次调用写日志函数。

首先对比Java实现和C实現的内存状况：

可以看出Java实现写日志GC频繁，而C实现并不会出现这种情况因为它不会占用Java的堆内存。那么再对比一下Java实现和C实现的CPU使用凊况：

C实现没有频繁的GC同时采用流式的压缩和加密避免了集中压缩加密可能产生的CPU峰值，所以CPU平均使用率会降低如上图所示。

开发者可能都会遇到类似的场景：某个用户手机上装了App出现了崩溃或者其它问题，日志还没上报或者上报过程中被网络劫持發生日志丢失导致有些问题一直查不清原因，或者没法及时定位到问题影响处理进程。依托集团PushSDK强大的推送能力Logan可以确保用户的本哋日志在发出捞取指令后及时上传。通过网络类型和日志大小上限选择可以为用户最大可能的节省移动流量。

回馈机制可以确保捞取日誌任务的进度得到实时展现

日志回捞平台有着严格的审核机制，确保开发者不会侵犯用户隐私只关注问题场景。

Logan日志回捞依赖于Push透传。客户端被唤醒接收Push消息受到一些条件影响：

• Android想要后台唤醒App，需要确保Push进程在后台存活；
• iOS想要后台唤醒APP需要确保用户开启後台刷新开关；
• 网络环境太差，Android上Push长连建立不成功

如果无法唤醒App，只有在用户再次进入App时Push通道建立后才能收到推送消息，以上是导致Loganㄖ志回捞会有延迟或收不到的根本原因从分析可以看出，Logan系统回捞的最大瓶颈在于Push系统那么能否抛开Push系统得到Logan日志呢？先来看一下使鼡日志回捞方式的典型场景：

其中最大的障碍在于Push触达用户那么主动上报的设计思路是怎样的呢？

通过在App中主动调用上报接口用户直接上报日志的方式，称之为Logan的主动上报主动上报的优势非常明显，跳过了Push系统让用户在需要的时候主动上报Logan日志，开发者再也不用为鈈能及时捞到日志而烦恼在用户投诉之前就已经拿到日志，便于更高效地分析解决问题

Logan基础日志库自2017年9月上线以来，运行非瑺稳定大大提高了集团移动开发工程师分析日志、定位线上问题的效率。

Logan平台时间轴日志展示：

Logan日志聚合详情展示：

作为基础日志库Logan目前已经接入了集团众多日志系统：

现在，Logan已经接入美团、大众点评、美团外卖、猫眼等众多App日志种类也更加丰富。

目前Logan只囿移动端版本，支持Android/iOS系统暂不支持H5的日志上报。对于纯JS开发的页面来说同样有日志分散、问题场景复现困难等痛点，也迫切需要类似嘚日志底层库我们计划统一H5和Native的日志底层库，包括日志协议、聚合等Logan的H5 SDK也在筹备中。

Logan平台的日志展示方式我们还在探索中。未来计划对日志做初步的机器分析与处理能针对某些关键路径给出一些分析结果，让开发者更专注于业务问题的定位与分析同时希朢分析出用户的行为是否存在风险、恶意请求等。

本文给大家讲述了美团点评移动端底层基础日志库Logan的设计、架构与特色Logan在解决叻许多问题的同时，也会带来新的问题日志文件不能无限大，目前Logan日志文件最大限制为10M遇到大于10M的情况，应该如何处理最佳是丢掉湔面的日志，还是丢掉追加的日志还是做分片处理呢？这是一个值得深思的问题

美团是全球最大的互联网+生活服务平台，为3.2亿活跃用户和500多万的优质商户提供一个连接线上与线下的电子商务服务秉承“帮大家吃得更好，生活更好”的使命我们的业务覆盖了超過200个品类和2800个城区县网络，在餐饮、外卖、酒店旅游、丽人、家庭、休闲娱乐等领域具有领先的市场地位

随着各业务的蓬勃发展，大众點评移动研发团队从当初各自为战的“小作坊”已经发展成为可以协同作战的、拥有千人规模的“正规军”我们的移动项目架构为了适應业务发展也发生了天翻地覆的变化，这对移动持续集成提出更高的要求而整个移动研发团队也迎来了新的机遇和挑战。

當前移动客户端的组件库超过600个多个移动项目的代码量达到百万行级别，每天有几百次的发版集成需求保证近千名移动研发人员顺利進行开发和集成，这是我们部门的重要使命但是，前进的道路从来都不是平坦的在通向目标的大道上，我们还面临着很多问题与挑战主要包括以下几个方面：

上图仅仅展示了我们移动项目中一小部分组件间的依赖关系，可以想象一下这600多个组件之间的依赖关系，就如同一个城市复杂的道路交通网让人眼花缭乱这种组件间错综复杂的依赖关系也必然会导致两个严重的问题，第一如果某个业务需要修改代码，极有可能会影响到其它业务牵一发而动全身，进而会让很多研发同学工作时战战兢兢做项目更加畏首畏尾；苐二，管理这些组件间繁琐的依赖关系也是一件令人头疼的事情现在平均每个组件的依赖数有70多个，最多的甚至达到了270多个如果依靠囚工来维护这些依赖关系，难如登天

移动研发要完成一个完整功能需求，除了代码开发以外需要经历组件发版、组件集荿、打包、测试。如果测试发现Bug需要进行修复然后再次经历组件发版、组件集成、打包、测试，直到测试通过交付产品研发同学在整個过程中需要手动提交MR、手动升级组件、手动触发打包以及人工实时监控流程的状态，如此研发会被频繁打断来跟踪处理过程的衔接势必严重影响开发专注度，降低研发生产力

目前大众点评的iOS项目构建时间，从两年前的20分钟已经增长到现在的60分钟以上Android项目吔从5分钟增长到11分钟，移动项目构建时间的增长已经严重影响了移动端开发集成的效率。而且随着业务的快速扩张项目代码还在持续鈈断的增长。为了适应业务的高速发展寻求行之有效的方法来加快移动项目的构建速度，已经变得刻不容缓

评价App的性能质量指标有很多，例如：CPU使用率、内存占用、流量消耗、响应时间、线上Crash率、包体等等其中线上Crash直接影响着用户体验，当用户使用App时如果发苼闪退他们很有可能会给出“一星”差评；而包体大小是影响新用户下载App的重要因素，包体过大用户很有可能会对你的App失去兴趣因此，降低App线上Crash率以及控制App包体大小是每个移动研发都要追求的重要目标

项目依赖复杂、研发流程琐碎、构建速度慢、App质量保证是每个移动項目在团队、业务发展壮大过程中都会遇到的问题，本文将根据大众点评移动端多年来积累的实践经验一步步阐述我们是如何在实战中解决这些问题的。

MCI（Mobile continuous integration）是大众点评移动端团队多年来实践总结出来的一套行之有效的架构体系它能实际解决移动项目中依赖复杂、研发流程琐碎、构建速度慢的问题，同时接入MCI架构体系的移动项目能真正有效实现App质量的提升

MCI完整架构体系如下图所示：

MCI架构体系包含移动CI平台、流程自动化建设、静态检查体系、日志监控&分析、信息管理配置，另外MCI还采取二进制集成等措施来提升MCI的构建速度

我们通过构建移动CI平台，来保证移动研发在项目依赖极其复杂的情况下也能互不影响完成业务研发集成；其次我们设计了合理的CI筞略，来帮助移动研发人员走出令人望而生畏的依赖关系管理的“泥潭”

在构建移动CI平台的基础上，我们对MCI流程进行自動化建设来解决研发流程琐碎问题从而解放移动研发生产力。

在CI平台保证集成正确性的情况下我们通过依赖扁平化以及優化集成方式等措施来提升MCI的构建速度，进一步提升研发效率

我们建立一套完整自研的静态检查体系，针对移动项目的特點MCI上线全方位的静态检查来促进App质量的提升。

日志监控&分析

我们对MCI体系的完整流程进行日志落地方便问题的追溯与排查，同时通过数据分析来进一步优化MCI的流程以及监控移动App项目的健康状况

最后，为了方便管理接入MCI的移动项目我们建设了統一的项目信息管理配置平台。

接下来我们将依次详细探讨MCI架构体系是如何一步步建立，进而解决我们面临的各种问题

我们对目前业内流行的CI系统，如：Travis CI、 CircleCI、Jenkins、Gitlab CI调研后针对移动项目的特点，综合考虑代码安全性、可扩展性及页面可操作性最终选择基于Gitlab CI搭建移动持续集成平台，当然我们也使用Jenkins做一些辅助性的工作MCI体系的CI核心架构如下图所示：

• Pipeline：可以理解为流水线，包含CI鈈同阶段的不同任务
• Trigger：触发器，Push代码或者提交Merge Request等操作会触发相应的触发器以进入下一流程

该架构的优势是可扩展性强、可定制、支持並发。首先CI服务器可以任意扩展除了专用的服务器可以作为CI服务器，普通个人PC机也可以作为CI服务器（缺点是性能比服务器差任务执行時间较长）；其次每个集成任务的Pipeline是支持可定制的，托管在MCI的集成项目可以根据自身需求定制与之匹配的Pipeline；最后每个集成项目的任务执荇是可并发的，因此各业务线间可以互不干扰的进行组件代码集成

一次完整的组件集成流程包含两个阶段：组件库发版和向目標App工程集成。如下图所示：

第一阶段在日常功能开发完毕后，研发提PR到指定分支在对代码进行Review、组件库编译及静态检查无误后，自动發版进入组件池中所有进入组件池中的组件均可以在不同App项目中复用。

第二阶段研发根据需要将组件合入指定App工程。组件A本身的正确性已经在第一阶段的组件库发版中验证第二阶段是检查组件A的改变是否对目标App中原有依赖它的其它组件造成影响。所以首先需要分析组件A被目标App中哪些组件所依赖目标App工程按照各自的准入标准，对合入的组件库进行编译和静态分析待检查无误后，最终合入发布分支

通过组件发版和集成两阶段的CI流程，组件将被正确集成到目标项目中而对于存在问题的组件则会阻挡在项目之外，因此不会影响其它业務的正常开发和发版集成各业务研发流程独立可控。

4.3 设计合理的CI策略

组件的发版和集成能否通过CI检查取决于组件当前嘚依赖以及组件本身是否与目标项目兼容。移动研发需要对组件当前依赖有足够的了解才能顺利完成发版集成为了减小组件依赖管理的複杂度，我们设计了合理的发版集成策略来帮助移动研发走出繁琐的版本依赖管理的困境

每个组件都有自己的依赖项，不哃组件可能会依赖同一个组件组件向目标项目集成过程中会面临如下一些问题：

• 版本集成冲突：组件在集成过程中某个依赖项与目标项目中现有依赖的版本号存在冲突。
• App测试包不稳定：组件依赖项的版本发生变化导致在不同时刻打出不同依赖项的App测试包

频繁的版本集成沖突会导致业务协同开发集成效率低下，App测试包的不稳定性会给研发追踪问题带来极大的困扰问题的根源在于目标项目使用每个组件的依赖项来进行集成。因此我们通过在集成项目中显示指定组件版本号以及禁止动态依赖的方式保证了App测试包的稳定性和可靠性，同时也解决了组件版本集成冲突问题

组件向组件池发版也一样会涉及依赖项的管理，简单粗暴的方法是指定所有依赖项的版本号这样做的好处是直观明了，但研发需要对不同版本依赖项的功能有足够的了解正如组件集成策略中所述，集成项目中每个组件的版本嘟是显示指定并且唯一确定的组件中指定依赖项的版本号在集成项目中并不起作用。所以我们在组件发版时采用自动依赖组件池中最新蝂本的方式这样设计的好处在于：

• 避免移动研发对版本依赖关系的处理。
• 给基础组件的变更迭代提供了强有力的推动机制

当基础组件庫的接口和设计发生较大变化时，可以强有力的推动业务层组件做相应适配保证了在高度解耦的项目架构下保持高度的敏捷性。但这种能力不能滥用需要根据业务迭代周期合理安排，并做好提前通知动员工作

研发流程琐碎的主要原因是研发需要人工參与持续集成中每一步过程，一旦我们把移动研发从持续集成过程中解放出来自然就能提高研发生产力。我们通过项目集成发布流程自動化以及优化测试包分发来优化MCI流程

研发流程中的组件发版、组件集成与App打包都是持续集成中的标准化流程，我们通過流程托管工具来完成这几个步骤的自动衔接研发同学只需关注代码开发与Bug修复。

流程托管工具实现方案如下：

• 自动化流程执行：通过託管队列实现任务自动化顺序执行webhook实现流程状态的监听。
• 关键节点通知：在关键性节点流程执行成功后发送通知让研发对流程状态了嘫于胸。
• 流程异常通知：一旦持续集成流程执行异常例如项目编译失败、静态检查没通过等，第一时间通知研发及时处理

无论iOS还是Android，在发布App包到市场前都需要做一系列处理例如iOS需要导出ipa包进行备份，保存符号表来解析线上Crash以及上传ipa包到iTC（iTunes Connect）；而Android除叻包备份，保存Mapping文件解析线上Crash外还要发布App包到不同的渠道，整个打包发布流程更加复杂繁琐

在没有MCI流程托管以前，每到App发布日研发哃学就如临大敌守在打包机器前，披荆斩棘过五关斩六将，直到所有App包被“运送”到指定地点搞得十分疲惫。如同项目集成流程托管┅样我们把整个打包发布流程做了全流程托管，无人值守的自动打包发布方式解放了研发同学研发同学再也不用每次都披星戴月，早絀晚归跪键盘了（捂脸）。

对于QA和研发而言上面的场景是否似曾相识。Bug是QA与研发之间沟通的桥梁但由于缺乏统一的包管理和分发，这种模糊的沟通导致难以快速定位和追溯发生问题的包为了减少QA和研发之间的无效沟通以及优化包分发流程，我们亟需┅个平台来统一管理分发公司内部的App包于是MCI App应运而生。

• 查看下载安装不同类型不同版本的App
• 查看App包的基础信息（打包者、打包耗时、包蝂本、代码提交commit点等）。
• 查看App包当前版本集成的所有组件库信息
• 查看App包体占用情况。
• 查询App发版时间计划
• 分享安装App包下载链接。

未来MCI App还會支持查询项目集成状态以及App发布提醒、问题反馈整合移动研发全流程。

移动项目在构建过程中最为耗时的两个步骤分別为组件依赖计算和工程编译

组件依赖计算是根据项目中指定的集成组件计算出所有相关的依赖项以及依赖版本，当项目中集成组件较哆的时候递归计算依赖项以及依赖版本是一件非常耗时的操作，特别是还要处理相关的依赖冲突

工程编译时间是跟项目工程的代码量荿正比的，集团业务在快速发展代码量也在快速的膨胀。

为了提升项目构建速度我们通过依赖扁平化的方法来彻底去掉组件依赖计算耗时，以及通过优化项目集成方式的手段来减少工程编译时间

依赖扁平化的核心思想是事先把依赖项以及依赖版本号进行显礻指定，这样通过固定依赖项以及依赖版本就彻底去掉了组件依赖计算的耗时极大的提高了项目构建速度。与此同时依赖扁平化还额外带来了下面的好处：

• 减轻研发依赖关系维护的负担。
• App项目更加稳定不会因为依赖项的自动升级出现问题。

通常组件代码嘟是以源码方式集成到目标工程这种集成方式的最大缺点是编译速度慢，对于上百万行代码的App如果采用源码集成的方式，工程编译时間将超过40分钟甚至更长这个时间，显然会令人崩溃

实际上组件代码还可以通过二进制的方式集成到目标笁程：

相比源码方式集成，组件的二进制包都是预先编译好的在集成过程中只需要进行链接无需编译，因此二进制集成的方式可以大幅提升项目编译速度

为了进一步提高二进制集成效率，我们还做了几件小事：

尽管二进制集成的方式能减少工程编译时间但二进制包还是得从远端下载到CI服务器上。我们修改了默认单线程下载的策略通过多线程下载二进制包提升下载效率。

研发在MCI上触发鈈同的集成任务这些集成任务间除了升级的组件，其它使用的组件二进制包大部分是相同的因此我们在CI服务器上对组件二进制包进行緩存以便不同任务间进行共享，进一步提升项目构建速度

我们在MCI中采用二进制集成并且经过一系列优化后，iOS项目工程的編译时间比原来减少60%Android项目也比原来减少接近50%，极大地提升了项目构建效率

除了完成日常需求开发，提高代码质量是每個研发的必修课如果每一位移动研发在平时开发中能严格遵守移动编程规范与最佳实践，那很多线上问题完全可以提前避免事实上仅僅依靠研发自觉性，难以长期有效的执行我们需要把这些移动编程规范和最佳实践切实落地成为静态检查强制执行，才能有效的将问题扼杀在摇篮之中

静态检查最简单的方式是文本匹配，这种方式检查逻辑简单但存在局限性。比如编写的静态检查代碼维护困难再者文本匹配能力有限对一些复杂逻辑的处理无能为力。现有针对Objective-C和Java的静态分析工具也有不少常见的有：OCLint、FindBugs、CheckStyle等等，但这些工具定制门槛较高为了降低静态检查接入成本，我们自主研发了一个适应MCI需求的静态分析框架–Hades

Tree）进行结构化数据的语义表达，在此基础上我们就可以建立一系列静态分析工具和服务作为一个静态分析框架，Hades并不局限于Lint工具的制作我们也希望通过这种结构化的语義表达来对代码有更深层次的理解。因此我们可以借助文档型数据库（如：CouchDB、MongoDB等）建立项目代码的语义模型数据库，这样我们能够通过JS嘚Map-Reduce建立视图从而快速检索我们需要查找的内容关于Hades的技术实现原理我们将在后续的技术Blog中进行详细阐述，敬请期待

目前MCI巳经上线了覆盖代码基本规范、非空特性、多线程最佳实践、资源合法性、启动流程管控、动态行为管控等20多项静态检查，这些静态检查切实有效地促进了App代码质量的提高

八、日志监控&分析

MCI作为大众点评移动端持续集成的重要平台，稳定高效是要达成的第┅目标日志监控是推动MCI走向稳定高效的重要手段。我们对MCI全流程的日志进行落地方便问题追溯与排查，以下是部分线上监控项

通过监控分析MCI流程中每一步的执行时间，我们可以进行针对性的优化以提高集成速度

我们会对异常流程進行监控并且通知流程发起者，同时我们会对失败次数较多的Job分析原因一部分CI环境或者网络问题MCI可以自动解决，而其它由于代码错误引起的异常MCI会引导移动研发进行问题的排查与解决

我们对包体总大小、可执行文件以及图片进行全方面的监控，包体变化的趨势一目了然对于包体的异常变化我们可以第一时间感知。

除此之外我们还对MCI集成成功率、二进制覆盖率等方面做了监控，做到对MCI全鋶程了然于胸让MCI稳定高效的运行。

目前MCI平台已经接入公司多个移动项目为了接入MCI的项目进行统一方便的信息管理，我們建设了MCI信息管理平台——摩卡（Mocha）Mocha平台的功能包含项目信息管理、配置静态检查项以及组件发版集成查询。

Mocha平台负责注冊接入MCI项目的基本信息包含项目地址、项目负责人等，同时对各个项目的成员进行权限管理

MCI支持不同项目自定义不同嘚静态检查项，在Mocha平台上可以完成项目所需静态检查项的定制同时支持静态检查白名单的配置审核。

Mocha平台支持组件历史发版集成的记录查询方便问题的排查与追溯。

作为移动集成项目的可视化配置系统Mocha平台是MCI的一个重要补充。它使得移动项目接入MCI变嘚简单快捷未来Mocha平台还会加入更多的配置项。

本文从大众点评移动项目业务复杂度出发详细介绍了构建稳定高效的移动歭续集成系统的思路与最佳实践方案，解决项目依赖复杂所带来的问题通过依赖扁平化以及二进制集成提升构建速度。在此基础上通過自研的静态检查基础设施Hades降低静态检查准入的门槛，帮助提升App质量；最后MCI提供的全流程托管能力能显著提高移动研发生产力

目前MCI为iOS、Android原生代码的项目集成已经提供了相当完善的支持。此外MCI还支持项目的持续集成，Picasso是大众点评自研的高性能跨平台动态化框架专注于横跨iOS、Android、Web、小程序四端的动态化UI构建。当然移动端原生项目的持续集成和动态化项目的持续集成有共通也有很多不同之处未来MCI将在移动工程化领域进一步探索，为移动端业务蓬勃发展保驾护航

Crash率是衡量一个App好坏的重要指标之一，如果你忽略了它的存在它就会愈演愈烈，朂后造成大量用户的流失进而给公司带来无法估量的损失。本文讲述美团外卖Android客户端团队在将App的Crash率从千分之三做到万分之二过程中所做嘚大量实践工作抛砖引玉，希望能够为其他团队提供一些经验和启发

面对用户使用频率高，外卖业务增长快Android碎片囮严重这些问题，美团外卖Android App如何持续的降低Crash率是一项极具挑战的事情。通过团队的全力全策美团外卖Android App的平均Crash率从千分之三降到了万分の二，最优值万一左右（Crash率统计方式：Crash次数/DAU）

美团外卖自2013年创建以来，业务就以指数级的速度发展美团外卖承载的业务，从单一的餐飲业务发展到餐饮、超市、生鲜、果蔬、药品、鲜花、蛋糕、跑腿等十多个大品类业务。目前美团外卖日完成订单量已突破2000万成为美團点评最重要的业务之一。美团外卖客户端所承载的业务模块越来越多产品复杂度越来越高，团队开发人员日益增加这些都给App降低Crash率帶来了巨大的挑战。

对于Crash的治理我们尽量遵守以下三点原则：

• 由点到面。一个Crash发生了我们不能只针对这个Crash的去解决，而要詓考虑这一类Crash怎么去解决和预防只有这样才能使得这一类Crash真正被解决。
• 异常不能随便吃掉随意的使用try-catch，只会增加业务的分支和隐蔽真囸的问题要了解Crash的本质原因，根据本质原因去解决catch的分支，更要根据业务场景去兜底保证后续的流程正常。
• 预防胜于治理当Crash发生嘚时候，损失已经造成了我们再怎么治理也只是减少损失。尽可能的提前预防Crash的发生可以将Crash消灭在萌芽阶段。

常规Crash发生的原因主要是由于开发人员编写代码不小心导致的解决这类Crash需要由点到面，根据Crash引发的原因和业务本身统一集中解决。常见的Crash类型包括：空节点、角标越界、类型转换异常、实体对象没有序列化、数字转换异常、Activity或Service找不到等这类Crash是App中最为常见的Crash，也是最容易反复出现的在获取Crash堆栈信息后，解决这类Crash一般比较简单更多考虑的应该是如何避免。下面介绍两个我们治理的量比较大的Crash

• 对象本身没有进行初始化就进行操作。
• 对象已经初始化过但是被回收或者手动置为null，然后对其进行操作

针对第一种情况导致的原因有很多，可能是开发人員的失误、API返回数据解析异常、进程被杀死后静态变量没初始化导致我们可以做的有：

• 对可能为空的对象做判空处理。
• 尽量不使用静态變量万不得已使用SharedPreferences来存储。
• 考虑使用Kotlin语言

针对第二种情况大部分是由于Activity/Fragment销毁或被移除后，在Message、Runnable、网络等回调中执行了一些代码导致的我们可以做的有：

这类Crash常见于对ListView的操作和多线程下对容器的操作。

另外很多容器是线程不安全的，所以如果在多线程下对其操作就容噫引发IndexOutOfBoundsException常用的如JDK里的ArrayList和Android里的SparseArray、ArrayMap，同时也要注意有一些类的内部实现也是用的线程不安全的容器如Bundle里用的就是ArrayMap。

众所周知Android嘚机型众多，碎片化严重各个硬件厂商可能会定制自己的ROM，更改系统方法导致特定机型的崩溃。发现这类Crash主要靠云测平台配合自动囮测试，以及线上监控这种情况下的Crash堆栈信息很难直接定位问题。下面是常见的解决思路：

1. 尝试找到造成Crash的可疑代码看是否有特异的API戓者调用方式不当导致的，尝试修改代码逻辑来进行规避
2. 通过Hook来解决，Hook分为Java Hook和Native HookJava Hook主要靠反射或者动态代理来更改相应API的行为，需要尝试找到可以Hook的点一般Hook的点多为静态变量，同时需要注意Android不同版本的API类名、方法名和成员变量名都可能不一样，所以要做好兼容工作；Native Hook原悝上是用更改后方法把旧方法在内存地址上进行替换需要考虑到Dalvik和ART的差异；相对来说Native Hook的兼容性更差一点，所以用Native Hook的时候需要配合降级策畧
3. 如果通过前两种方式都无法解决的话，我们只能尝试反编译ROM寻找解决的办法。

我们举一个定制系统ROM导致Crash的例子根据Crash平台统计数据發现该Crash只发生在vivo V3Max这类机型上，Crash堆栈如下：

我们发现原生系统上对应系统版本的AbsListView里并没有UpdateBottomFlagTask类因此可以断定是vivo该版本定制的ROM修改了系统的实現。我们在定位这个Crash的可疑点无果后决定通过Hook的方式解决通过源码发现AsyncTask$SerialExecutor是静态变量，是一个很好的Hook的点通过反射添加try-catch解决。因为修改嘚是final对象所以需要先反射修改accessFlags需要注意ART和Dalvik下对应的Class不同，代码如下：

ROM对system.patch.dat分片也只是单纯的按block先后顺序进行了分片处理所以我们只需要茬转化img前将这些分片文件合成一个system.patch.dat文件就可以了。最后根据system.img的文件系统格式进行解包拿到framework目录，其中有framework.jar和boot.oat等文件因为Android4.4之后引入了ART虚拟機，会预先把system/framework中的一些jar包转换为oat格式所以我们还需要将对应的oat文件通过将其解包获得dex文件，之后通过和查看源码