美团技术团队-Android系列文章

各位伙伴好，欢迎关注「美团技术团队」微信公众号。在这里，已经有30万小伙伴与大家一起学习成长。本文系Android系列文章汇总，我们也会不断更新这里的内容，点击下面的各个标题就可以查看原文了，Enjoy！

好的架构要不断演变，进而去适应业务的发展。美团在移动端上的架构，也经历了组件化、平台化、RN混合化，到现在开始向容器化变迁。容器化架构充分地利用了现在的跨端技术，将动态化的能力最大化地赋予了业务。

作为美团最为重要的业务之一，美团外卖移动端的架构演进是怎样的呢？本文将为你揭开背后的思考、技术细节以及实践。

DevOps实践中，我们在CI(Continuous Integration)持续集成过程主要包含了代码提交、静态检测、单元测试、编译打包环节。其中静态代码检测可以在编码规范，代码缺陷，性能等问题上提前预知，从而保证项目的交付质量。Android项目常用的静态扫描工具包括CheckStyle、Lint、FindBugs等，为降低接入成本，美团内部孵化了静态代码扫描插件，集合了以上常用的扫描工具。

在项目初期，引入公司内部基建时我们接入了代码扫描插件，在PR（Pull Request）流程中借助Jenkins插件来触发自动化构建，从而达到监控代码质量的目的。初期单次构建耗时平均在1~2min左右，对研发效率影响甚少。但是随着时间推移，代码量随业务倍增，项目也开始使用Flavor来满足复杂的需求，这使得我们的单次PR构建达到了8~9min左右，其中静态代码扫描的时长约占50%，持续集成效率不高，对我们的研发效率带来了挑战。

本文主要阐述了Lambda表达式及其底层实现（invokedynamic指令）的原理、Android第三方插件RetroLambda对其的支持过程、Android官方最新的dex编译器D8对其的编译支持。通过对这三个方面的跟踪分析，以Java 8的代表性特性——Lambda表达式为着眼点，将Android如何兼容Java8的过程分享给大家。

配送骑手端App是骑手用于完成配送履约的应用，帮助骑手完成接单、到店、取货及送达，提供各种不同的运力服务，也是整个外卖闭环中的重要节点。由于配送业务的特性，骑手App对于应用稳定性的要求非常高，体现App稳定性的一个重要数据就是Crash率，而在众多Crash中最棘手最难定位的就是OOM问题。

对于骑手端App而言，每天骑手都会长时间的使用App进行配送，而在长时间的使用过程中，App中所有的内存泄漏都会慢慢累积在内存中，最后就容易导致OOM，从而影响骑手的配送效率，进而影响整个外卖业务。

于是我们构建了用于快速定位线上OOM问题的组件——Probe，下图是Probe组件架构，本文主要分享Probe组件是如何对线上OOM问题进行快速定位的。

MTFlexbox是美团内部应用的非常成熟的一种跨平台动态化解决方案，它遵循了CSS3中提出的Flexbox规范来抹平多平台的差异。MTFlexbox适用于重展示、轻交互的业务场景，与现有HTML、React Native、Weex等跨平台方案相比，MTFlexbox具备着性能高、渲染速度快、兼容性高、原生功能支持度高等优势。但其缺点在于不支持复杂的交互逻辑，不适合复杂交互的业务场景。目前，MTFlexbox已经广泛应用在美团首页、搜索、外卖等重要业务场景。本文主要介绍在MTFlexbox中使用Litho优化性能的实践经验。

跨平台动态化技术是目前移动互联网领域的重点关注方向，它既能节约人力，又能实现业务快速上线的需求。经过十年的发展，美团App已经变成了一个承载众多业务的超级平台，众多的业务方对业务形态的快速迭代和更新提出了越来越高的要求。传统移动端”静态“的开发方式存在一系列问题，比如包体积增长过快、线上Bug修复困难、发版周期长等，已经不能满足高速发展的业务需要。因此，美团平台自研了一套跨平台动态化方案——MTFlexbox。

目前，MTFlexbox已经广泛应用于美团首页、搜索、外卖等多个业务场景，并且已稳定运行两年有余。在MTFlexbox规范下，只需要写一份布局文件，就可以适用多端。在实际开发中，客户端开发同学开发布局的同时也要添加好埋点信息，帮助产品同学来评估上线后的效果。但现有布局埋点存在成本过高、准确率较低等痛点，为了解决这些问题，我们充分了解数据组开发人员和产品对数据统计的诉求，结合对MTFlexbox原理的深入理解，围绕MTFlexbox的埋点上报做了很多持续、有针对性的自动化工作，帮助多个项目的效率得到了显著提升。本文主要介绍美团在MTFlexbox自动化埋点方向所进行的一些探索，希望对大家能够有所帮助。

Litho是Facebook推出的一套高效构建Android UI的声明式框架，主要目的是提升RecyclerView复杂列表的滑动性能和降低内存占用。Litho是一套完全不同于传统Android的UI框架，它继承了Facebook一向大胆创新的风格，突破性地在Android上实现了React风格的UI框架。

组件化作为Android客户端技术的一个重要分支，近年来一直是业界积极探索和实践的方向。美团内部各个Android开发团队也在尝试和实践不同的组件化方案，并且在组件化通信框架上也有很多高质量的产出。本文介绍了美团行业收银研发组Android团队的组件化实践，以及业界首创强约束组件消息总线modular-event的原理和使用。

Logan是美团移动端基础日志组件，这个名称是Log和An的组合，代表个体日志服务。此前我们公众号发布过一篇文章《Logan：美团移动端基础日志库揭秘》，主要讲述了Logan的很多技术细节。本文重点阐述了Logan的整体框架。

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

GitHub上的项目地址：https://github.com/Meituan-Dianping/Logan。

beeshell 是一个 React Native 应用的基础组件库，基于 0.53.3 版本，提供一整套开箱即用的高质量组件，包含 JavaScript组件和复合组件（包含 Native 代码），涉及前端（FE）、iOS、Android 三端技术，兼顾通用性和定制化，支持自定义主题，用于开发和服务企业级移动应用。

GitHub 上的项目地址：https://github.com/meituan/beeshell。

美团外卖App和美团App外卖频道业务基本一样，但由于历史原因，两端代码差异较大，造成同样的子业务需求在一端上线后，另一端几乎需要重新实现，严重浪费开发资源。在《美团外卖Android平台化架构演进实践》一文中，将美团外卖Android客户端平台架构分为平台层、业务层和宿主层，我们希望能够在平台化架构中实现平台层和业务层的多端复用，从而节省子业务需求开发资源，实现多端部署。

两端业务虽然基本一致，但是仍旧存在差异，UI、基础服务、需求差异等。这些差异存在于美团外卖平台化架构中的平台层和业务层各个模块中，给平台化复用带来了巨大的挑战。

WMRouter是一款Android路由框架，基于组件化的设计思路，功能灵活，使用也比较简单。

WMRouter最初用于解决美团外卖App在业务演进过程中的实际问题，之后逐步推广到了美团其他App，因此我们决定将其开源，希望更多技术同行一起开发，应用到更广泛的场景里去。GitHub项目地址与使用文档详见：https://github.com/meituan/WMRouter 。

本文先简单介绍WMRouter的功能和适用场景，然后详细介绍WMRouter的发展背景和过程。

Flutter是Google开发的一套全新的跨平台、开源UI框架，支持iOS、Android系统开发，并且是未来新操作系统Fuchsia的默认开发套件。自从2017年5月发布第一个版本以来，目前Flutter已经发布了近60个版本，并且在2018年5月发布了第一个“Ready for Production Apps”的Beta 3版本，6月20日发布了第一个“Release Preview”版本。

本文介绍了全新移动UI框架Flutter的架构、特色功能（Hot Reload、插件等）和Dart语言，并分享了美团外卖Flutter版全品类页面的实践。

对于Android系统来说，消息传递是最基本的组件，每一个App内的不同页面，不同组件都在进行消息传递。消息传递既可以用于Android四大组件之间的通信，也可用于异步线程和主线程之间的通信。对于Android开发者来说，经常使用的消息传递方式有很多种，从最早使用的Handler、BroadcastReceiver、接口回调，到近几年流行的通信总线类框架EventBus、RxBus。Android消息传递框架，总在不断的演进之中。

本文提供了一个新的消息总线框架——LiveDataBus，利用LiveDataBus，不仅可以实现消息总线功能，而且对于订阅者，他们不需要关心何时取消订阅，极大减少了因为忘记取消订阅造成的内存泄漏风险。

随着移动互联网的快速发展，移动应用越来越注重用户体验。美团技术团队在开发过程中也非常注重提升移动应用的整体质量，其中很重要的一项内容就是页面的加载速度。如果发生冷启动时间过长、页面渲染时间过长、网络请求过慢等现象，就会直接影响到用户的体验，所以，如何监控整个项目的加载速度就成为我们部门面临的重要挑战。

对于测速这个问题，很多同学首先会想到在页面中的不同节点加入计算时间的代码，以此算出某段时间长度。然而，随着美团业务的快速迭代，会有越来越多的新页面、越来越多的业务逻辑、越来越多的代码改动，这些不确定性会使我们测速部分的代码耦合进业务逻辑，并且需要手动维护，进而增加了成本和风险。于是通过借鉴公司先前的一些方案，分析其存在的问题并结合自身特性，我们实现了一套无需业务代码侵入的自动化页面测速插件，本文将对其原理做一些解读和分析。

Kotlin有着诸多的特性，比如空指针安全、方法扩展、支持函数式编程、丰富的语法糖等。在实际的使用过程中，我们发现看似写法简单的Kotlin代码，可能隐藏着不容忽视的额外开销。本文剖析了Kotlin的隐藏开销，并就如何避免开销进行了探索和实践。

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

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

ProGuard是2002年由比利时程序员Eric Lafortune发布的一款优秀的开源代码优化、混淆工具，适用于Java和Android应用，目标是让程序更小，运行更快，在Java界处于垄断地位。

在我们实施插件化、热补丁修复时，为了让插件、补丁和原来的宿主兼容，必须依赖ProGuard的applymapping功能的进行增量混淆，但在使用ProGuard的applymapping时会遇到部分方法混淆错乱的问题，同时在ProGuard的日志里有这些警告信息Warning: ... is not being kept as ..., but remapped to ...针对这个问题我们进行了深入的研究，并找到了解决的方案，本文会对这个问题产生的缘由以及修复方案一一介绍。

Lint是Google提供的Android静态代码检查工具，可以扫描并发现代码中潜在的问题，提醒开发人员及早修正，提高代码质量。除了Android原生提供的几百个Lint规则，还可以开发自定义Lint规则以满足实际需要。

在美团外卖Android App的迭代过程中，线上问题频繁发生。开发时很容易写出一些问题代码，例如Serializable的使用：实现了Serializable接口的类，如果其成员变量引用的对象没有实现Serializable接口，序列化时就会Crash。我们对一些常见问题的原因和解决方法做分析总结，并在开发人员组内或跟测试人员一起分享交流，帮助相关人员主动避免这些问题。

Toast是Android平台上的常用技术。从用户角度来看，Toast是用户与App交互最基本的提示控件；从开发者角度来看，Toast是开发过程中常用的调试手段之一。此外，Toast语法也非常简单，仅需一行代码。基于简单易用的优点，Toast在Android开发过程中被广泛使用。

本文介绍了使用传统Toast存在的问题和对应的解决方案，并详细讲解了美团最终实现的用Snackbar替换Toast的方案。

美团外卖自2013年创建以来，业务一直高速发展。目前美团外卖日完成订单量已突破1800万，成为美团最重要的业务之一。美团外卖的用户端入口，从单一的外卖独立App，拓展为外卖、美团、点评等多个App入口。美团外卖所承载的业务，也从单一的餐饮业务，发展到餐饮、超市、生鲜、果蔬、药品、鲜花、蛋糕、跑腿等十多个大品类业务。业务的快速发展对客户端架构不断提出新的挑战。

本文介绍了美团外卖Android客户端平台化过程中的架构演进。

线上用户产生Bug，根据现象很难快速定位问题的原因，由于用户个性化环境的差异导致问题很难准确定位，而且常规办法很难解决这些问题。为此，我们开发了动态日志系统Holmes，希望它能像大侦探福尔摩斯那样帮我们顺着线上bug的蛛丝马迹，发现背后真相。

在移动端，如何快速定位并解决线上问题提高用户体验给我们带来了极大挑战。线上偶尔会发生某一个页面打不开、新活动抢单按钮点击没响应、登录不了、不能下单等现象，由于Android碎片化、网络环境、机型ROM、操作系统版本、本地环境复杂多样，这些个性化的使用场景很难在本地复现，加上问题反馈的时候描述的往往都比较模糊，快速定位并解决问题难度不小。

为此，我们开发了动态日志系统Holmes，希望它能像大侦探福尔摩斯那样帮我们顺着线上bug的蛛丝马迹，发现背后真相。本文主要介绍如何对Android平台上的Xposed Installer和Cydia Substrate两种Hook手段进行防范。

我们经常需要在主线程中读取一些配置文件或者缓存数据，最常用的结构化存储数据的方式就是将对象序列化为JSON字符串保存起来，这种方式特别简单而且可以和SharedPrefrence配合使用，因此应用广泛。但是目前用到的Gson在序列化JSON时很慢，在读取解析这些必要的配置文件时性能不佳，导致卡顿启动速度减慢等问题。

Gson的问题在哪里呢？笔者用AndroidStudio的profile工具分析了activity.onCreate方法的耗时情况。

持续更新中......

----------  END  ----------