架构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,及时重构,架构应用免不了有些地方设计得不合理,发现这样的问题要及时重构,不要在一个不合理的框架上试图写合理的代码。