这篇文章是我在【2018安卓巴士开发者大会】技术分享时所讲内容的文字版本，修改删减了演讲时的冗余言语。 希望能给买不到票参加大会的朋友带来帮助。

Android 作为一个诞生近十年的移动操作系统，占据了近 80% 的市场份额。然而随着时代变迁，技术迭代，作为 Android 开发者的我们，却渐渐迷茫，我们还能在 Android 上做些什么？
本次分享将从大前端、移动应用等视角，宏观的对 Android 开发中常用的项目架构、平台能力、开发模式等进行分析，为听众提供一个前瞻者的观察和建议。

首先自我介绍一下：我是张涛，目前在携程无线平台研发部，从事 APP 基础服务建设相关工作。可能有些朋友认识我，我之前也会在我博客【开源实验室】写一些 Android 相关的技术点，如果对今天讲的内容，你觉得有什么问题或者可以深入探讨的，也欢迎加我微信 kymjs123 详聊。

我相信在座的很多朋友，都是从2013-2015年开始从事 Android 开发的，可能晚一点的有2016年的。这也正是 Android 生态发展最快速的3年，如今我们再回过头来看一下这几年。

这是我们曾经的 APP，携程、美团、京东、淘宝，这是我在网上找的四张图片，时间都是在2014年2015年的，主要是再久一点的也找不到了。
从前我们的应用，这四个应该是很典型了的，因为他们栏目多，业务也多。可以看到，携程三行四列，其他的：美团、京东、淘宝，都是两行四列。
你们都知道，接下来我要放现在的了：这是我最近才从我手机上截的四张图，依然是携程、美团、京东、淘宝。

在这四五年里，互联网公司大幅增加，而这样的老牌互联网公司，新业务也不多增多，我们看到，携程的：WiFi 电话卡、保险签证、以及上面主业务细分更加精细。
美团那就更是如此了，美团外卖、美团打车、还有近期才收购的摩拜单车，相信大家都是有所感受的。
京东的发展，一直很低调，懂得闷声发大财，可能相比京东的业务，东哥跟奶茶妹才是京东的重点新闻。但即便是低调的京东，我们看一下，京东到家，现在被达达全资收购叫新达达；京东超市、京东生鲜，布局新零售业务，传统线上业务也多了 plus 会员，机票酒店，再看一下过去的京东，就是一个很传统的购物商城；再往后淘宝我就不说了，大家也都看得到。

这是从业务上我们说移动端发生的变化，再从 Android 技术角度看一下： 这些年我们做了些什么。

2013 下拉刷新，侧滑菜单，工具类集合
2014 快速开发框架，Material Design
2015 插件化，Hybrid，MVP，MVVM，volley 2016 RN、Weex，热修复
2017 模块化，Kotlin
2018 DAPP？ AI？

我们从5年前，2013年开始说，再早也没有意义。
2013年，我们都在忙着写什么？自定义控件。因为那时候没有现在这么好的生态，什么东西都得自己写。再之后有了一些快速开发框架，开发起来方便很多了。
到了14年，Google IO 推出 Material Design 我们才算有了一个可以参考的设计风格。同年也有了 Volley 这个网络请求框架。
再往后，15年的插件化，相信大家都记忆犹新，就算是到现在面试还经常有人问插件化相关的东西。
有人想用插件化解决动态化的问题，有人想用 Hybrid 解决动态化的问题，16年应用 web 化大面积产生，越来越多的应用开始重度依赖 H5，同样也是同一年 RN、Weex 等框架推出。到中下旬，MDCC 上腾讯开源热修复框架tinker，于是大家又都去研究热修复是个什么东西。
再到17年甚至现在，还有很多人在做模块化的东西。

这么多的技术汇集到我们的 APP 里，如今我们的 APP 是个什么样的架构呢？

这张图，应该可以覆盖如今百分之九十 APP 的架构模型。最上层是业务层，常见的 APP 四个 tab 页，前两个是业务相关的各种列表页详情页，第三个是发现页，第四个就是用户中心，设置、个人信息、关于等等内容。
第二层，是服务于业务的通用业务层，最常见的推送、路由功能，路由是什么我之后还会讲。UI 统一、我们的 APP 越做越大，可能一个 APP 由多个团队去负责，那设计就需要有一个统一的控件风格。广告，各种闪屏页、内插页弹窗、小红点等等。
最下层，是一些基础服务。这里我列出来了8种，大家可以发现一个特点就是这8种都是与用户无关的服务，比如数据上报、异常统计，我作为一个普通的用户完全不在乎我用的应用是否有异常统计，他不会影响我的使用。
侧边是一个综合区域，我把 kotlin 也列在这里，实际上他只是一个语言而已，并不算某个特殊技术。其他的模块化、国际化、插件化等等，都是改动一块，整个应用可能都会发生变动的技术点。

这里面几个技术点我简单跟大家分析一下，因为我今天讲的内容比较宏观，不会很细致的跟大家分析所有的东西，也不可能分析的了，这里面任何一个内容单独拿出来都能当成一次分享来讲了，这里我就只讲两个：

第一个，路由库。
路由库是指：通过一个唯一值，可以是一个 URL、page id、也可以是某一个参数值，通过这个值能跳转到一个指定的页面。
把路由库玩到最出神入化的，应该算是支付宝了，支付宝的吱口令。一个 id 值，可以用来抢红包，可以用来加好友，可以用于分享或打开一个页面。

那么，如果要你设计一个路由库，需要注意些什么呢？
我认为需要注意这四点：

• 一、界面与 scheme 对应，界面至少要保证跟 scheme 是一对一或一对多的关系吧。多个 url 可以启动一个界面，但是同一个 url，如果能启动多个界面那就乱套了。
• 二、界面的参数要如何传递？我们曾经有个例子，比如 scheme://xxx.com?key=value 这是一个很常见的路由协议样式，但如果此刻 value又是一个网络链接的时候怎么办？比如scheme://xxx.com?key=value&url=https://kymjs.com?page=1&user=kymjs，那么请问，后面的 user=kymjs 这样的一段内容，他是属于https://这个协议呢还是属于scheme://这个协议？
• 三、界面中的全局变量没有初始化时，怎么做？假设我们某个界面引用了一个全局的public static变量，那么当我用路由直接启动当前界面的时候，这个变量还没被初始化怎么办？
• 四、这个就是一个安全性的问题了，通常我们在做防刷的时候，都是需要从接口层判断用户操作。比如一个正常的用户肯定是先登录，获取用户信息，获取列表信息，注销。如果有一个IP，没经过登录，没有获取用户信息，直接获取列表，这肯定是一个爬虫在爬数据。那这种情况，我们通过路由启动界面的时候要如何处理。

第二个，数据上报。
数据上报是指将客户端的开发日志、用户操作等信息，上报到服务端做数据分析。这应该是成熟的互联网公司都具备的能力。

数据上报与其他库不同，他重点在于数据的准确性。
而这个准确性又可以被细分为：

• 数据上报的实时性

实时性其实非常难做到，并不是我们想象的那样可以直接通过一个网络请求就完成了。因为数据上报一定是一个频繁的过程，如果每次上报都发起一次网络请求，就会非常耗费用户流量和电量。而如果想通过本地创建的 buffer 去做，又会碰上数据不及时的问题。这里如果大家自己的应用中本身已经使用了长链接来维持客户端与服务端的通信，那么肯定不会被这个问题烦到，但你又得要考虑应用后台等情况长连接失败怎么办；但如果没有长连接，使用的是普通的 okhttp，那你就要思考很多了，这里我不展开细讲，一个是时间关系另一个就是这个只有动手实践过才知道问题在哪，我空讲没有用。

• 重复率与丢失率

这也是数据准确性的一个必要审核点，我们曾经碰上过使用长连接的时候，数据明明传给后端了，后端也把数据响应返回了，但是客户端没有收到服务端的响应，然后认为是超时了，又重新发一遍；而服务端以为你又重新发的这一遍，是之前上传失败了，再上传的一条新数据，然后在最后查询的时候，数据库中就有很多重复数据，还得去重。

• 还有多线程多进程存储数据的问题

这也是只有自己操作过才能有切身体会的，我推荐大家使用 mmap 自己定义存储内容的格式，这样可以最大性能的保证存储效率和稳定性。

• SDK 的易用性

这个可能很多做应用的同学都会有所体会，为什么从 github 上找来一个开源库用到自己项目里面的时候，总是要改一大堆的东西。为什么架构组(或者框架组)的同事给了一个 SDK，在用的时候还得自己封装一层。
这其实就是做 SDK 的人并没有考虑到接入环境的各种特殊情况，这个问题并不是这个数据上报库会碰上的，应该是所有我前面那张图中底层模块都需要考虑的问题。

前面我通过几个例子跟大家讲了我们目前市面上的 Android 应用整体结构是怎样的，相信大家都有所感想了。
接下来我们再回到我们的主题，看一下 Android 近几年的发展，想想我们还能够做些什么。

从这张图大家应该可以体会到，我们的开发效率在不断的提升。从最早的自己写各种各样的 UI 控件、动画效果，网络请求图片加载等UI 逻辑，到之后关注起工程结构，插件化、Hybrid 等等技术，再到近几年热修复，模块化。我们的项目工程化越来越明确，离最初的小作坊式办公越来越远。
所以接下来很重要的一个发展方向就是提升研发效率。

提升研发效率在 Android 上基本可以从这三点考虑：提升迭代效率、提升发布效率、降低研发成本，也是降低无用功。
我们挨个看一下这些都是应该怎么做，有哪些能够帮到我们的。

迭代效率，这个从组件化如今这么重要的地位就能看出来了。我们的组件化就是为了提升迭代效率推出的，包括早前的插件化，都是这个目的。
这三个步骤可以看做是组件化技术的三个阶段：最早我们单纯把各个模块解耦，每个模块当成一个 aar，就算是组件化完成了。这也是如今市面上各种各样五花八门的组件化框架和文章都在讲怎么解耦的原因，因为他们觉得除了解耦没别的可讲的了。
但其实，在 2017 年 Google IO 后，Google 为我们提供了一种更方便实现组件化的结构，叫做feature module。大家自己去研究一下这种技术能帮助你对组件化有更深的认知。这个feature module也是为了帮助应用搭建Instant App必备的。
再到今年的Google IO，Google 又更进一步的推出了Android APP bundle，一种能够动态下发模块的技术，虽然这个需要 Google Service 支持。如果你有自习看过他内部的实现，其实跟我们早些年的一些插件化方案 splitAPK 很像，只不过这是官方推出的方案，要稳定很多，当然，限制也很多。对于这种方案，我推荐大家去学习一下阿里的 atlas 就能有很深的理解了。

讲完迭代效率，我们再看看发布效率。最早我们的代码，是非常严格的 N 周一个迭代的发布。但是随着业务越来越多，团队也越来越大。很多时候不得不 delay 一两天来照顾到所有的业务团队。
之后，就有了我们模块化解耦，每个业务按照自己的迭代排期计划好，如果 delay 了那么这个版本你们的新需求就得放到下个版本再发布了，这样主 APP 的发版不再依赖哪个业务线，同时业务组件可以提前打包，这也加快了打包时所用的时间。
再到最后，通过用户画像精准推送。我们可以做到代码随时发版，只要你认为你的需求做完了，测试通过了，就可以发布 APP。但是这个版本并不一定是每个用户都会接收到，而是我们提前已经分析过用户行为，那些愿意主动使用最新应用的用户才会收到应用更新。大家打开手机里面的微信、QQ 等等，点一下检查更新看看，基本上都是提示已经是最新版本了，但你用的却不一定是最新的版本，你可以去官网再自己下载一个 apk 装上看看版本号。

最后一点，通过技术降低研发成本。
比如大家都知道的我一直在推的 Kotlin。
这门语言可以极大的提升你的编码效率，同时还能降低你代码出错的概率，比如他的协程，你在做多线程的时候，直接使用协程，很大程度上能减少代码出错，而且效率一般情况下也会提升（除非你乱用）。
同时还有，RN、WEEX这种跨平台的开发，以前两个人写一个需求 Android iOS 各一个，现在还可以是两个人写一个需求，一人写一半，一个写上半部分，一个写下半部分，然后代码拼起来，再做一下各端的兼容性就好了，效率是大大的提升了。
机器写代码，这是我们作为开发最喜欢的，但我想告诉大家的是，放弃吧，现在还是达不到的。我们说，“一顿操作猛如虎，生成代码咋维护”先不说能不能写出来，就说需求改了的时候，谁去维护他。那代码就不是给人看的，它就不是人写的，你说是不是。
但是我们还有一条路，让别人帮我们写代码。大家熟悉的 airbnb 开源的 Lottie、微软开源的 Sketch2Code 都是走的这个方向，让设计师帮我们写代码，有兴趣的同学可以去详细了解一下。

最后，今天的分享《Android 十年，还有哪些可以做的》就到这里，相信大家心中都已经有了一个自己的答案，知道了自己还缺少哪些可以做的东西了，谢谢大家。