标签:hit fragment 控件 迭代 strong 新闻 忽略 com ref
在架构一个App时,大家往往都在关注新潮的技术,却忽略了一点,那就是分包。很多人可能没有一套分包的原则,凭感觉甚至随心所欲地创建package或将代码放到任意的package中。
虽然最终不会影响App功能,但这个问题其实非常严重。一种不好的分包策略带来的影响将会一直持续在App的开发迭代周期中,主要表现为以下几点:
根据个人多年App开发经验及项目实践,现推荐一种Android分包策略,虽并非最优,但基本适合绝大多数的android应用开发。
先来看一个“反例”(已加引号,如此分包者轻拍)。曾见过一些第三方项目或开源项目,它们的分包策略是这样的:
相信有相当一部分开发者是这样分包的,来分析下其优缺点。
优点呢?或许说分类特别清晰,如所有的Activity都在一起,但是仔细想想,这样又有什么意义呢?
缺点却非常明显:
分包并没有官方原则,因此是自由的,但完全自由等于没有自由。
先抛出个人推荐的分包原则:按功能模块分包。
这样说有点抽象,我们细化到一个App示例中去,假设一个App具有如下功能:
基础支持功能
业务功能
对于以上示例App,我们按照功能模块来分包:
基于上述分包策略,在Android Studio中一个App的层次结构示意图如下:
java
|--- com
|---example
|--- base
| |--- BaseActivity.java
| |--- BaseFragment.java
| |--- xxx.java
|
|--- network
| |--- HttpClient.java
| |--- xxx.java
|
|--- image
| |--- ImageManager.java
| |--- xxx.java
|
|--- db
| |--- DbManager.java
| |--- xxx.java
|
|--- news
| |--- NewsActivity.java
| |--- NewsFragment.java
| |--- xxx.java
|
|--- movie
| |--- MovieActivity.java
| |--- MovieFragment.java
| |--- xxx.java
|
|--- music
| |--- MusicActivity.java
| |--- MusicFragment.java
| |--- xxx.java
|
|--- entity
| |--- Movie.java
| |--- News.java
| |--- xxx.java
|
|--- adapter
| |--- AbsAdapter.java
| |--- MovieAdapter.java
|
|--- widget
| |--- CircleImageView.java
| |--- xxx.java
|
|--- util
|--- ToastUtil.java
|--- xxx.java
使用上述分包策略后,主要优点如下:
分包本身就是一个开放性的问题,没有固定或最优的方案,上面推荐的策略也只是一些基本原则,具体细节可根据App实际情况制定,欢迎探讨。
标签:hit fragment 控件 迭代 strong 新闻 忽略 com ref
原文地址:http://www.cnblogs.com/qijiq/p/7197405.html