商用Android 工程化实践，摆脱小做坊式开发

做者：张涛

你们好，今天跟你们分享的主题是：从小做坊到大工厂，一条电商的 Android 工程化开发实践

我是张涛，就任于一条生活馆，咱们公司是一家电商新零售公司，目前移动端的一些开发管理工做都是由我在负责。 对今天的分享有哪些值得探讨的也都欢迎与我交流。

Android 做为一个诞生近十一年的移动操做系统，占据了近 80% 的市场份额。
我相信在座的不少朋友，都是从2013-2015年开始从事 Android 开发的，可能晚一点的有2016年的。这也正是 Android 生态发展最快速的3年，现在咱们再回过头来看一下这几年。

这是咱们曾经的 APP，携程、美团、京东、淘宝，这是我在网上找的四张图片，时间都是在2014年2015年的，主要是再久一点的也找不到了。

从前咱们的应用，这四个应该是很典型了的，由于他们栏目多，业务也多。能够看到，携程四行三列，其余的：美团、京东、淘宝，都是两行四列。

大家都知道，接下来我要放如今的了：这是我最近才从我手机上截的四张图，依然是携程、美团、京东、淘宝。

在这四五年里，互联网公司大幅增长，而这样的老牌互联网公司，新业务也不断增多，咱们看到，携程的：WiFi 电话卡、保险签证、以及上面主业务细分更加精细。
美团那就更是如此了，骑单车、叫外卖、美团打车、美团买菜，相信你们都是有所感觉的。

再日后京东淘宝我就不用说了，你们也都看获得。
前面从业务角度回顾了咱们这几年APP的发展，接下来咱们从技术架构角度看一下现代的APP

这张图，是咱们一条生活馆的移动架构图，这张图应该能够覆盖现在百分之九十 APP 的架构模型。最上层是业务层，常见的 APP 各个业务模块，好比咱们一条生活馆的最重要的几个业务，CMS首页、内容相关模块、电商的商品购物、还有拍卖等等。

第二层，是服务于业务的通用业务层，最多见的浏览器web容器、路由功能。UI 统1、咱们的 APP 越作越大，可能一个 APP 由多个设计团队去负责，那设计就须要有一个统一的控件风格。广告，各类闪屏页、内插页弹窗、小红点等等。还有 RN、Weex、Flutter这种多端共用业务。

最下层，是一些基础服务。这里我列出来了8种，你们能够发现一个特色就是这8种都是与用户无关的服务，好比数据上报、异常统计，我做为一个普通的用户彻底不在意我用的应用是否有异常统计，他不会影响个人使用。

侧边是一个贯穿咱们整个应用的综合性技术，像 Kotlin 的 Coroutine(协程)、Google 新推出的相似 SwiftUI 的 Jetpack Compose、模块化、国际化、插件化等等，都是改动一块，整个应用可能都会发生变更的技术点。
咱们现在的应用已经到了如此惊人的一个庞大致量，可是……

回到咱们今天的主题：如何完成做坊到工厂的转变？把上面那些技术全都用一遍吗？哪怕你说插件化 Kotlin 都不适合咱们，我找出适合咱们的技术都用上，就是大工厂了吗？

不是的，至少我认为不是的。
自从我投身到创业公司之后，常常有人问我大公司和小公司的差异是什么。 在我看来程序员能力的差距都不是最大的问题，固然这是前端，后端可能会由于性能问题形成比较多的损失噢。

在我看来最大的差距就是在基础设施建设上。小公司每每会由于老板的眼界、公司资源等各类各样的缘由，缺失一套成体系的工程化平台

那么何谓工程化平台，就是经过标准化流程的方式，去作的可以批量生产的能力。

好比说咱们前面介绍的一个应用有多个功能模块，包含基础模块和业务模块，这也是近几年被喊的很火的移动端模块化技术。

第二点，数据驱动模块重组，咱们为何要让这些模块独立是如何选择的。
第三点，咱们的研发作好了各个需求，这些需求要如何测试如何上线。
固然，一个前端工程化平台不止这三点能力，好比线上的APM、日志监控等等，只是这三点是我认为做为一个做坊到工厂转变必不可少的三点。

接下来咱们从应用架构的角度去一个一个的详细聊聊，首先是业务模块独立。

不管任何一个应用，想要作到模块化拆分，都必不可少要面临这三个问题：跨模块函数调用、跨模块界面跳转、跨模块消息传递。 固然，若是这是一个业界常见问题，必定会有开源的解决方案，好比前面两个，咱们能够经过阿里开源的ARouter解决，后一个我相信作Android的没有人不知道EventBus。可是这两个框架在咱们真正用起来的时候，都会碰上一些问题。好比ARouter，他从一开始设计就是为了淘宝这样大型的APP去作的，他在应用首次启动的时候要把全部类遍历一遍而这个时间是很是长的，即使是经过分组懒加载也依然很慢。

固然还要一个更重要的缘由，是由于咱们在ARouter开源以前，就已经有了一套完整的路由框架，因此就没有再使用ARouter了。 另外一个EventBus也是订阅者模式都会遇到的问题，就是消息泛滥的状况。当应用内消息过多的时候，会形成消息难以追踪，调试问题的复杂度也随之增大了。

YitBridge 使用了与后端 SOA 设计思路相似的方式：将模块之间的主动依赖倒置，变为功能的提供与使用。 那什么是 SOA 的设计思路呢，咱们看到一张我画的漫画图：SOA 它是一种面向服务的架构模型。

例如图上左边有一个对外提供媒体功能的服务提供者，他告知YitBridge我提供媒体服务：“嘿，老铁，我这有个媒体服务，你那边有谁要用的时候能够用个人。”
到了另外一边，若是此刻有模块说是，我须要媒体服务：“老铁，你那有没有媒体服务，我这边须要播一个铃声啊！”。
“有的，给你。”

YitBridge 就会将以前服务提供者与服务使用者作一个桥接完成服务的调用。

接下来咱们来看具体到代码上是如何使用的：首先是做为服务使用方，也就是上一张图右半部分的Client。咱们看到上面是传统的作法，首先声明一个借口类型，而后new出接口的实现类给他赋值。而使用了YitBridge的时候，你是不须要关心接口的实现类究竟是谁的。这就是YitBridge惟一的用处，隐藏实现类，作到完全的面相接口编程。

以前说过，YitBridge将模块之间依赖倒置，由以前的服务提供方被动的接受调用方调用变为，服务方主动提供服务给调用方。那做为服务提供方须要作些什么事呢，很是简单，你只须要给你的对象提供方法加上一个@Creator注解，告诉YitBridge这是一个建立器方法就能够了。

前面讲YitBridge实现完美实现了模块间的解耦，而YitBridge的内部实现就是经过这个APT来完成的。Annotation Processing Tool，相信你们都有据说过这个APT，即使是你没据说过，你也确定早就用过了，只是你不知道。 Android 上有一个注明的注解绑定框架叫 Butterknife，他的内部实现就是经过APT来作的，还有 Google 出品的 Dtabinding、Dagger2，这些也都是APT来作的。那这个注解处理器在 YitBridge 中作了些什么呢，咱们来看这段代码。

这是 YitBridge 在编译之后生成的一段类：仍是继续咱们前面讲的那段示例来继续，在运行时，他会根据你传入的 get() 方法的参数，来判断你所须要的是哪一个接口的实现，而后去调用对应的建立器方法。

那么除了这个问题，还有就是多版本协做开发时候的模块依赖问题。 Android 使用的是 Gradle 构建，若是出现基础接口更新，上层全部依赖都跟着从新更改一下，再作一次兼容。这种事原本是无可避免的，可是若是咱们有多个版本同时开发，这个问题就大大提高了版本管理的复杂度问题。因此咱们引入了一个 baseVersion 的概念，也就是你当前模块构建的目标版本号。只要依赖的模块的目标版本号一致，就能够不用考虑兼容性问题直接更新，若是baseVersion 不一致，那说明这是一次不兼容升级，须要上层模块处理完兼容性问题后再发布。

这就是前面 moduleApi的实现，其实就是判断了一下baseVersion是否一致，若是一致，那么就直接引用最新版本，若是不一致，则抛异常退出编译。从而将运行时的错误在编译期就直接发现。

第二部分，数据驱动模块重组

数据这里，我能跟你们聊的很少。

第一个，RMF模型。
RFM 模型是电商衡量用户价值和用户创利能力的一个重要数据，分别指三个纬度：最近一次消费 (Recency)、消费频率 (Frequency)、消费金额 (Monetary)。从这三个维度综合评分最终就能够量化出一个用户的价值，那么这个价值就能够辅助咱们在线下创建线下店、用户社群等等数据化运营了。

第二个，商品曝光与转化统计。
也是电商公司会常用的统计商品转化率的方式，好比一个商品他在用户手机上被展现了多少次，展现了之后用户点击了多少次，这些点击又有多少是收藏或加入购物车了的，以及最终下单购买等等一系列流程，最终就能够分析出每一个商品的转化率，慢慢的咱们确定会优先选择跟转化率高的供应商合做。

第三部分，标准化持续集成与交付

这里是咱们目前使用的模块依赖构建工具，你们能够从这张图中感觉一下。 构建工具，主要的功能是很明显的，就是用于构建模块，在这之上，还有隐含的功能，就是集中了构建模块的权限，能够更便于统一管理； 固然还有最重要的优点就在于模块版本的管理，你能够很清晰的知道当前主应用所接入的模块的版本是哪一个，当前最新构建的SNAPSHOT是哪一个，以及每一个版本的更新日志； 这样作了之后，在跨团队协做上的沟通就大大下降了，若是你已经接入或者即将接入的模块是另外一个团队开发的模块组件，那你能够直接关注它，它的全部版本变更日志，最新版本全都一目了然； 而且能够经过平台简化模块的测试与模块发布的流程，好比提测的时候，若是是一次兼容版本的发布，你只须要告诉测试提测分支，测试能够本身根据如今线上应用的tag，同时引入当前提测的模块替换老版本的模块从新编译，很容易就能控制变量。

第二个就是，经过平台化的构建工具，能够很方便的动态选择模块依赖，好比咱们在测试某个模块的时候，能够排除部分已经保证没有问题的模块，那么在测试的时候就能够更聚焦，让测试只看咱们发生改动了的模块，最终集成测试只须要简单看一下就好了。

接下来咱们再看看发布效率。最先咱们的代码，是很是严格的 N 周一个迭代的发布。可是随着业务愈来愈多，团队也愈来愈大。不少时候不得不 delay 一两天来照顾到全部的业务团队。

以后，就有了咱们模块化解耦，每一个业务按照本身的迭代排期计划好，若是 delay 了那么这个版本大家的新需求就得放到下个版本再发布了，这样主 APP 的发版再也不依赖哪一个业务线，同时业务组件能够提早打包，这也加快了打包时所用的时间。

再到最后，经过用户画像精准推送。咱们能够作到代码随时发版，只要你认为你的需求作完了，测试经过了，就能够发布 APP。可是这个版本并不必定是每一个用户都会接收到，而是咱们提早已经分析过用户行为，那些愿意主动使用最新应用的用户才会收到应用更新。你们打开手机里面的微信、QQ 等等，点一下检查更新看看，基本上都是提示已是最新版本了，但你用的却不必定是最新的版本，你能够去官网再本身下载一个 apk 装上看看版本号。

在以后就是我前面提过的，工厂化发布一个APP。咱们能够根据业务须要任意组装业务模块，最后拼成一个APP，快速发布到线上，查看这个应用的数据反馈，若是这个应用从数据层面看运行的很是好，那么就能够考虑引导流量到这个应用。若是数据很差，那么尽早放弃下降研发成本，准备其余的业务也更灵活。

Android学习PDF+架构视频+面试文档+源码笔记

---

感谢你们能耐着性子看完啰里啰嗦的文章

在这里我也分享一份私货，本身收录整理的Android学习PDF+架构视频+面试文档+源码笔记，还有高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料帮助你们学习提高进阶，也节省你们在网上搜索资料的时间来学习，也能够分享给身边好友一块儿学习

若是你有须要的话，能够点赞+评论，关注我， 加Vx：15388039515（备注思否，须要资料）