一种Android分包策略推荐

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/u014738140/article/details/75090340

分包的重要性

在架构一个App时，大家往往都在关注新潮的技术，却忽略了一点，那就是分包。很多人可能没有一套分包的原则，凭感觉甚至随心所欲地创建package或将代码放到任意的package中。

虽然最终不会影响App功能，但这个问题其实非常严重。一种不好的分包策略带来的影响将会一直持续在App的开发迭代周期中，主要表现为以下几点：

1. 代码混乱，功能模块界限模糊
2. 不易阅读与维护，尤其对新人来说
3. 功能扩展与重用困难
4. 包间耦合比较高

根据个人多年App开发经验及项目实践，现推荐一种Android分包策略，虽并非最优，但基本适合绝大多数的Android应用开发。

一种分包策略

反例分析

先来看一个“反例”（已加引号，如此分包者轻拍）。曾见过一些第三方项目或开源项目，它们的分包策略是这样的：

1. 把应用中所有的Activity放到一个包中，如com.example.activities
2. 把应用中所有的Fragment放到另一个包中，如com.example.fragments
3. ……

相信有相当一部分开发者是这样分包的，来分析下其优缺点。

优点呢？或许说分类特别清晰，如所有的Activity都在一起，但是仔细想想，这样又有什么意义呢？

缺点却非常明显：

1. 当看到这样的一个App分包结构时，大家可能都不知道该App有哪些功能、应用入口在哪里
2. 代码混乱，杂糅在一起，没有清晰的模块界限
3. 可读性差，查找一个功能页面时，可能需要跨多个包才能找到
4. 修改维护则更加麻烦，根本不知道某个类是否在其他包中使用
5. ……

分包原则

分包并没有官方原则，因此是自由的，但完全自由等于没有自由。

先抛出个人推荐的分包原则：按功能模块分包。

这样说有点抽象，我们细化到一个App示例中去，假设一个App具有如下功能：

基础支持功能

扫描二维码关注公众号，回复： 3368466 查看本文章

1. 网络请求
2. 图片处理
3. 数据库
4. ……

业务功能

1. 新闻相关功能模块
2. 电影相关功能模块
3. 音乐相关功能模块
4. ……

对于以上示例App，我们按照功能模块来分包：

1. 将网络功能相关代码归到一个包，如com.example.network，至于具体用OkHttp还是Volley或者自己封装HttpURLConnection都无所谓。
2. 将图片加载、缩放、缓存等相关功能代码归到一个包，如com.example.image，同样跟使用哪种图片框架无关。
3. 将Sqlite数据库相关操作的代码归到一个包，如com.example.db。
4. 将新闻功能模块的相关业务代码归到一个包，如com.example.news，同时新闻功能相关的所有Activity和Fragment都放到这个包中。
5. 将电影功能模块的相关业务代码归到一个包，如com.example.movie，同时电影功能相关的所有Activity和Fragment都放到这个包中。
6. 将音乐功能模块的相关业务代码归到一个包，如com.example.music，同时音乐功能相关的所有Activity和Fragment都放到这个包中。
7. 对于adapter，如是封装的通用的adapter，则可归到com.example.adapter中，如仅仅是某个Activity自己用的adapter，也可放到业务模块的包中，这里推荐所有adapter放到一个独立的包中，因为我们查找代码时，往往从功能模块角度入口，根据功能分包原则，可以快速找到对应包中的Activity，找到了Activity，其用到的adapter、entity便也可以迅速找到，因此不必也放到功能模块的包中。
8. 对于自定义控件，可以统一归到一个包，如com.example.widget。
9. 对于某些基类，如BaseActivity和BaseFragment等可以放到一个叫com.example.base的包中。
10. 对于数据对象实体，可统一放到com.example.entity中，不要放到具体功能模块的包中，原因第7点已提及，另外实体还可能重用、继承等。
11. 对于业务无关的公用方法和工具类，可以放到com.example.util中。
12. ……

基于上述分包策略，在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

优点

使用上述分包策略后，主要优点如下：

1. 从分包结构就能大概了解该App的功能
2. 高度模块化，可读性及可维护性大大提升
3. 功能模块导航清晰，很容易查找相关功能代码，哪怕是新人也能快速找到对应代码
4. 包与包之间的耦合性降低，添加或删除功能模块变得简单
5. 修改代码时，一般仅涉及某个功能，一般不用担心影响到其他包中的功能实现
6. 更加抽象化、模块化，方便扩展和重用，尤其是基础功能模块
7. 从代码访问权限角度来看，包内调用权限可替代包间调用，安全性也会提高

总结

分包本身就是一个开放性的问题，没有固定或最优的方案，上面推荐的策略也只是一些基本原则，具体细节可根据App实际情况制定，欢迎探讨。