基于路由机制设计的app架构思路

转载请注明出处:王亟亟的大牛之路

有差不多接近一个多月没发文了，最近事情比较多。各种会，写各种计划，解决各种问题，以及团队内部扩招那些事(每天邮箱各种简历眼花缭乱)

先安利:我的Git 之后会把内容都往git book等地方迁移，所以对我写的东西感兴趣的小伙们可以follow我的git,以获取最新内容！

---

对架构的理解

最近聊了许多小伙报价从高到低的各式各样的都有(这里只是举个例子，没有任何贬低的意思)
一提架构张嘴就来 MVC MVP MVVM等等等，如果简历写有大项目的架构经验并且要价偏高的我一般默认这样的小伙不是太可用(先看，别急后面有解释),或者说你之前的项目”不够大”。

如果要价不是很高，经验不是写的很丰富的话那我还可以理解。

为什么这么”默认”？

1. 太笼统
   MVC那套从写Web时期就一直使用至今，你抓个写java web的也能给你说的头头是道,纸上谈兵没有实际意义
2. 实用性不足
   每个”重量级”的项目都有不同的实现方式，简单的拿几个英文单词硬套是否真的合理,真的适合自己的应用场景
3. 知识点滞后
   从国内android/iOS热更(组件化)大潮(15年)出现后各式各样基于分包,插件化等等的内容层出不穷，还指望一套架构吃死那是不可能了。

---

简易组件化设计

把共同属性的代码提取出来制作成各种基础库,把单独的功能封装成Library包，不同业务通过分包结构分到不同module下，组内每人开发自己的module。

把纯业务模块和非业务模块以及一些”刚需”的代码做了简易的分包，库与库之间的关系看似很完美
写各个模块的小伙伴们可以各做各的，没有任何交集

于是有一天，来了个不可描述的场景
(只是举例子)
直到有一天产品说，我们要集成 TalkingData，我们要Ui库的各个控件必须做埋点！

那怎么办？

ui库的小伙伴去依赖 第三方统计库，去写里面的埋点业务

还有,ui组件的细节我要计算(你别管合理不合理，产品就说要算,我们就模拟这是个必做的业务)

ui库还得去依赖工具库，然后这个架构图成了这样

这只是一轮迭代，后面还有各种不可描述的复杂姿势，导致最后你的项目又一团糟，可维护性又像所有代码在一个包里那样差了

基于”路由的架构设计”

经过重新设计后大致长这样

因为基础功能库确实是一个被依赖可能性极大的库所以我们让他依赖着”路由”库
所有的子包，包括主项目都去依赖这个库，而基础功能库依赖于工具库和”路由”库
工具库放进去的意义就不说了，贯穿整个app过程都有大概率调用工具类，无论是主项目还是子工程包

着重说一下这个”路由”体系对于各个包/内容的意义

对于页面:
提供统一的跳转规则,更可控的跳转拦截，更大的延展性等等等(这部分可以看我之前写的一篇关于ARouter的文章:http://blog.csdn.net/ddwhan0123/article/details/54409574)

对于子包:
所有的包之间的相互调用关系就不存在了，耦合性降低，所有的通信统一都交给路由来处理分发(并且持有规则)，而注册工作则交由主工程去进行初始化。无论子包怎么变化(数量与内容)，只要在统一的路由规则下都可以畅通无阻地运行，而不是改一处则动全身！

在子包的概念里，路由是规则，是关系链。

这么做的目的很简单

• 可测试性增强–只测自己想测的包就行，根本不用管其他包的关系链
• 复用性增强–类似的基础组件可以在不同的事业群下使用
• 支持并行开发–你写你的我写我的
• 耦合降低–除了基础库外，其他库没有了依赖关系

该设计不考虑多进程场景，庞大集群项目需另外考虑考虑

更多架构选择/知识点:
https://github.com/googlesamples/android-architecture
http://www.infoq.com/cn/articles/ctrip-android-dynamic-loading
http://www.open-open.com/lib/view/open1436316754208.html
http://keeganlee.me/post/architecture/20160222

有问题可以联系我：