Android开发论架构重要性

在我看完《编程艺术》之后就产生了一种程序生命的观念

也看过一些关于架构方面的文章和DEMO，也有一些自己的理解：

现在比较流行的架构有：MVP MVC  MVVM 等等还有一些。

其实架构的意义都是基于软件分层的思想，就是让程序看起来有生命，每个层次都有一个特定的职能，通过接口等隔离处理，降低耦合，减少迭代过程的改动，增强稳定性，减少项目维护成本。

单元测试也会减少一些工作，只需要分层测试。

实际开发中可能很多人会忽略这些，到底采用什么架构或是如何去分层的问题。

其实当你开发到一半或是收尾的时候，你会发现，其实有一些功能或是模块你已经分层了。至少你不会把util或是tools类跟Activity或是fragment放到一块吧？

那我们该怎么去分层呢？

我的理解是：

1、根据业务分层

2、根据模块分层

3、根据数据或是功能块分层

没必要一定要按照一个固定的架构或是什么模式去分层，完全没有那个必要。但一定要有思路，就像一棵树，每一根树枝的发展或是树根的伸张，都要有一个规律或是路线一样。无论是新增功能或是更新某个功能都不会满地找code，至少你可以清晰而准确的找到你想要修改的位置。

分层也不是一定要分多少层，只要搭好架子，包括预判的扩展型模块，都预留好。后期扩展起来不会太麻烦，维护起来也会很轻松。

目前市面上的大部分app基本上都是从服务器拉取数据，然后客户端展示。so 像这种情况，一般MVP或是MVVM基本上都是可以的，当然 大神级别的架构师你们就请忽略

如果涉及到安全、支付、双验证等特殊的业务逻辑，可以单独分离一个层级，这个很有必要，如果混着的话，基本上后期优化的时候就会疯掉了。

我的做法是所有第三方都单独分层（即时通讯、微信、登录、推送等等一系列），所有特定功能块单独分层（网络封装、图片处理、相册、绘图等等这样可以单独使用存的功能模块建议单独分层，后期使用和维护都比较方便，也可以直接抽取出来），所有自定义单独分层...

code规范或是架构使用都是为了提升开发效率，降低耦合的一种技术方案，无论你采用什么新技术 都不要影响整个分层的思路去设计开发。保持一个清晰的思路架构路线，就算砍掉某些分支，程序都不会立刻处于瘫痪状态。

我的原则是：

1、尽可能的简洁

2、单次版本开发完成后注意整理code（相当于轻微重构，让code保持简洁）

3、业务逻辑和view层彻底分离（UI层、data层、控制层）

4、activity、fragment、logcat、toast、sharepreference、eventbus、asynctask、异常捕捉、统计、升级等管理

5、业务逻辑扩展支持同步或异步处理

6、尽可能的预留相关扩展，利用服务器数据控制

架构和设计模式只是一种思路或是参考，每个程序都有自己的生命，code的发展和走向不是产品的一句话或是无理的要求，而是接口和模式的设计合理性。

我们在开发的过程中经常会出现这样的情况，产品说我们最近要做一个活动，需要加个活动的功能，活动结束后就不需要了，需要我们加个功能进去。又或是我们现在需要一个广告位，现在只需要做一个图，别的都不需要，点击之后直接一个web展示... 等等这样的需要很常见

作为开发者你又能怎么办呢？没问题呀，做呗！

其实新增并不是什么难事，如果我们事先开发的是考虑到了后期可能会出现这些情况时，是不是我们就可以把程序写的活一点呢？也就是说我们预留一个可能扩展这样的功能放在这里，只需要服务器传相关的数据过来就可以实现，而不是每次需要的时候我们就新增一下这个功能，不需要的时候又干掉，作为用户来说，每次都升级很麻烦，至少我作为一个用户就会很反感，甚至会卸载。

一个理想的架构其实就是一个主枝干，每一次的开枝散叶都不会对主干支产生影响。

大神请忽略！！！