美团外卖，大家都很熟悉，与我们的生活已经紧密相连了。今天有机会读到了关于美团外卖架构的文章。都说打败方便面企业的不是另一家方便面企业，而是先在的互联网外卖公司，下面，根据自己读了美团外卖框架介绍，谈一谈自己的美团外卖框架的一些认识。
美团外卖自2013年创建以来，业务一直高速发展。目前美团外卖日完成订单量已突破1800万，成为美团点评最重要的业务之一。美团外卖的用户端入口，从单一的外卖独立App，拓展为外卖、美团、点评等多个App入口。美团外卖所承载的业务，也从单一的餐饮业务，发展到餐饮、超市、生鲜、果蔬、药品、鲜花、蛋糕、跑腿等十多个大品类业务。业务的快速发展对客户端架构不断提出新的挑战。
很早之前，外卖作为孵化中的项目只有美团外卖App（下文简称外卖App）一个入口，后来外卖作为一个子频道接入到美团App（下文简称外卖频道），两端业务并行迭代开发。早期为了快速上线，开发同学直接将外卖App的代码拷贝出一份到外卖频道，做了简单的适配就很快接入到美团App了。
早期外卖App和外卖频道由两个团队分别维护，而在随后一段时间里，两端代码体系差异越来越来大。最后演变成了从网络、图片等基础库到UI控件、类的命名等都不尽相同的两套代码。尽管后来两个团队合并到一起，但历史的差异已经形成，为了优先满足业务需求，很长一段时间内，我们只能在两套代码的基础上不断堆积更多的功能。维护两套代码的成本可想而知，而业务的迅猛发展又使得这一问题越发不可忍受。
好的架构源于不停地衍变，而非设计。对于外卖Android客户端的平台化架构构建也是经历了同样的过程。我们从考虑如何解决代码复用的问题，逐渐的衍变成如何去解决代码复用和平台化的两个问题。而实际上外卖平台化正是解决两端代码复用的一剂良药。我们通过建立外卖平台，将现有的外卖业务降级为一个频道，将外卖业务以aar的形式分别接入到外卖平台和美团平台，这样在解决外卖平台化的同时，代码复用的问题也将得到完美的解决。
平台化架构
经过了整整一年的艰苦奋斗，形成了如图所示的美团外卖Android客户端平台化架构：
从底层到高层依次为平台层、业务层和宿主层。
- 平台层的内容包括，承载上层的数据通信和页面跳转；提供外卖核心服务，例如商品管理、订单管理、购物车管理等；提供配置管理服务；提供统一的基础设施能力，例如网络、图片、监控、报警、定位、分享、热修、埋点、Crash上报等；提供其他管理能力，例如生命周期管理、组件化等。
- 业务层的内容包括，外卖业务和垂直业务。
- 宿主层的内容包括，Waimai App壳和美团外卖频道Waimai-channel壳，这一层用于Application的初始化、dex加载和其他各种必要的组件或基础库的初始化。
在构建平台化架构的过程中，我们遇到这样一个问题，如何长久的维持我们平台化架构的层级边界。试想，如果所有的代码都在一个工程里面开发，通过包名、约定去规范层级边界，任何一个紧急的需求都可能破坏层级边界。维持层级边界的最好办法是什么？我们的经验是工程隔离。平台化的每一层都去做工程隔离，业务层的每个业务都建立自己的工程库，实现工程隔离。同时，配套编译脚本，检查业务库之间是否存在相互依赖关系。工程隔离的好处是显而易见的：
- 每个工程都可以独立编译、独立打包；
- 每个工程内部的修改，不会影响其他工程；
- 业务库工程可以快速拆分出来，集成到其他App中。
但工程隔离带来的另一个问题是，同层间的业务库需要通信怎么办？这时候就需要提供业务库通信框架来解决这个问题。
业务库通信框架