从一开始做Android的时候就发现，一个app有很多个窗体（或者页面）堆积而成。由于Android自身对MVC的结构抽离得十分清晰，对布局，数据控制，逻辑处理都进行了一定的分离，大大方便了整个开发流程以及降低了开发成本。
但是由此而导致一定的问题，很多初学者开发一个app经常会落入只是重复的写activity的固定思维中。这样的结果就是一个app随着业务量的上升，重复劳动越来越厚重。同时也会伴随越来越多的逻辑错乱无序，或者有些逻辑根本无法实现。面对复杂业务的时候只能是用一个坑来填补另外一个坑。这对app来说本身就是一种灾难。
因此，我打算从这几年的工作经验中来对一个成熟app应该具有的整体架构以及基本知识点进行一个梳理，同时也希望从这些基本的分析中会给广大app开发者一些思考。

App原始开发方式

一个activity+view+自身逻辑处理。ok完成当前页面的处理；
从这样的简单工作来看，当前页面的UI和逻辑控制以及数据都是存在activity中。那么也就是说这实际上是一个数据、UI和逻辑强关联的关系。
如果当我另外一个页面需要上一个页面的数据的时候，很多开发者选用了intent传输的方式，但是如果要在下一个页面去修改上一个页面的数据的时候。你们又会怎么样来实现呢？
曾经我遇到过有这样的处理方式：

1.采用static的方式来保存这些数据；
2.采用sp的方式长久持有这些数据。

是的，这些方式都可以达到这样的业务需求。不过static方式会消耗更多的内存；sp的方式长久持有临时数据，经常出现问题的表现就是重启，如果未删除某些数据那么后面得到的数据当然也就错乱了。
因此，为自己的app做一个细致的规划是很有必要的。

app不是说非做一个很复杂很NB的框架，从app对内存以及性能上的更高要求。其实一个适中的架构对app来说是不错的选择。切忌过度设计，假如让一个本身业务就很简单的app使用各种高级框架完成本来就很简单的一个业务逻辑，那无疑这是一个过度设计。（不过很多人喜欢这么干，觉得很NB的设计就非得死板硬套）

好了言归正传

在接下来的章节中我会持续写一写一个成熟app的整体解决方案（包括整体框架结构，基本知识以及第三方对比以及选择）。

1.MVC和MVP在app中的对比分析以及实际应用；
2.UI的整体设计思路（避免臃肿的UI）；
3.OKHttp源码解析;
4.OKHttp源码解析-ConnectionPool对Connection重用机制&Http/Https/SPDY协议选择;
5.Retrofit源码解析;
6.从Eclipse到Intellij;
7.Android统一风格 —— 主题;
8.依赖注入思路以及如何选择（Dagger、RoboGuice和ButterKnife）；
9.事件总线（otto的bus和eventbus对比分析）；
10.数据存储（包括缓存）；
11.插件化解决思路（一些动态加载框架的分析）；
12.app的自我保护方案（如何做到防止数据接口的泄漏和逆向编译，保护自己的核心代码）；