Android 十年，还有哪些可以做的 － 小专栏

Android 十年，还有哪些可以做的 － 小专栏

这篇文章是我在【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变量，那么当我用路由直接启动当前界面的时候，这个变量还没被初始化怎么办？