关于Android中App的整体解决方案的一些思考

从一开始做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的自我保护方案(如何做到防止数据接口的泄漏和逆向编译,保护自己的核心代码);