架构Android App总结

历时两个多月，自己架构的一个App快要完成了，有很多可以总结的地方：

1， 各个模块尽可能独立，不要直接调用，用消息机制解耦。包括页面跳转不要直接startActivity，而是用消息跳转；业务模块请求网络、数据库、异步任务等都不要直接调用，而是用发消息请求，收消息获取响应。

2， 设计好消息框架，为第1条里说的提供基础。我用的是greenrobot/EventBus这个包，关于这个包的使用也有很多体会和总结，会再单独写一篇文章。

3，MVC设计，对一个页面来说，Activity是Controller，ViewHolder是View，Model看情况可有可无。

4，最好是最小单位的MVC，一个小的MVC整体再参与到另一个大的MVC中去，而不要MMMMM, VVVVV, CCCCC这样来布局。

5，设计HttpRequestMessage和HttpResponseMessage。App一般都是从网络请求数据，设计好发包和收包对象至关重要。在我的设计里，HttpRequestMessage做为消息被业务代码发出去，由专门负责网络请求的模块去监听然后处理，完成后再发一个对应的HttpResponseMessage消息出去，由感兴趣的业务代码去监听。关于这部分，会单独再写一篇文章。

6，定义好数据对象。一般来说，一个App中会多次用到相似的数据对象（很多字段相同），每次都在HttpResponseMessage中解析会造成很多重复代码，可维护性太差。所以最好是提前定义好数据对象，让数据对象自己解析自己的字段，这样很多业务模块都可以共用数据对象并且不用自己关心数据解析。还可以根据字段多少进行分层定义，比如一个数据，在列表中展示的字段必然不多，可定义为父类，点击列表的一个项目进入详情页的时候，之前的字段必然还需要，并且会新增很多字段，可以继承刚才的父类。

7，抽象BaseActivity，BaseFragmentActivity，BaseViewHolder，BaseFragment等。每个页面有很多工作都是重复的，一个一个写不仅费工夫，还造成重复代码太多，不好维护。并且，有了Base类，有很多打断性的事件处理可以直接由Base类给截断，具体业务类无需关心。

8，设计好MainTabActivity。MainTab一般要SingleTask，所以一定要重写onNewIntent方法。跳转到MainTab的时候一般也要clear top或者clear task。MainTab一般会承载多个Fragment，每个Fragment和MainTab的生命周期和切换事件一定要设计好，免得数据加载混乱，过多加载数据或者不加载。

9，设计好LoginActivity。先确定应用是强登录还是弱登录。对LoginActivity来说，强登录的逻辑比弱登录要简单。要提前想好这些事情：哪些页面可以或者需要跳转到LoginActivity；登录成功后是返回呢还是跳转到别的页。这些问题都牵涉到LoginActivity的设计，一般来说这个也得SingeTask和clear top。

10，设计健壮的Activity。比如每个Activity都写好onSaveInstance，在onCreate中要先判Bundle为空再用Intent初始化参数，不然就用Bundle初始化参数。还有很多良好的习惯，让Activity无懈可击。当然也可以由BaseActivity强制业务Activity去做这些事情。

11，下拉刷新，上拉加载更多的ListView。因为手机应用的数据很多都是一个List。有List的页面，要设计好分页加载，下拉刷新，上拉加载更多这些逻辑。这些可以封装成一个共用的类。一般对于一个含有list的页面来说，我会包含以下几个类：

A， Activity，页面Activity;

B， ViewHolder，页面的View holder;

C， Adapter，页面的List的Adapter；

D， ItemViewHolder，页面的List的一个Item的ViewHolder。

12， 设计好适配。安卓的适配有多个维度。从版本到屏幕尺寸等。要先定好自己的目标，dimens和drawable的适配规则要跟UI设计人员沟通好。

13，resource的使用不要太随意，不要随意添加颜色，不要随意添加字体大小，不要随意添加间距等。这些随意最后会造成整个应用的代码脏乱差。能公用的一定要抽取成共用的，这样不仅代码好维护，也让整个应用的不同页面都有一致的用户体验。

14，及时重构，架构应用免不了有些地方设计得不合理，发现这样的问题要及时重构，不要在一个不合理的框架上试图写合理的代码。