开发一个项目，软件架构是第一步，而我认为项目的分层是软件架构中重要的一步。
项目分层是指代码的组织方式，说的直白点就是如何去组织文件和文件夹，好的项目分层使项目具有很好的可读性和扩展性。
一般说来，项目的分层分为两种：按类别和按功能。
一、项目分层方式
1. 按类别
在 Android 开发早期，很多项目都是按照类别分层的，就是按照 activity、fragment、adapter 等来进行分层，按照类别进行分层的项目的目录结构大概是下面这种：
相信大家对这种结构非常熟悉，这种分层方式的好处是：
- 简单明了，很容易知道每个子包下存放的是什么。
- 一旦项目采用这种分层方式，将来项目无论怎么迭代和变化，目录结构都不需要做太大的改动。
但这种方式缺点也是很明显的，如果项目太大，有上百个界面，那么在 activity 子包下会有上百个类，那样要定位到具体某个功能模块的 activity 会变得很困难，也就是说这种方式不够精细，随着项目迭代功能越来越多，会导致代码导航越来越困难。
2. 按功能
这种分包方式是按照模块划分的，同一功能模块相关的类都在一个文件夹下，项目的目录结构大概如下：
以上的分层可以看到有一个叫feature的包，这里面包含了 app 的一些功能，如 freshnews、login分别代表 app 内部的新鲜事、登录等一些功能模块，这种按功能模块的分层好处很明显：
- 很直观，可以很方便的根据 app 的功能模块定位到具体的代码。
- 扩展性良好，如果想在此基础上再按照 MVC、MVP的模式去进一步分层，或者想在此基础上再按照类别去分层，依然可以，只需要 feature 包下某个具体的功能下面再加一层就好了。
- 高度的模块化，也就是所谓的“高内聚”。随着 app 的迭代，如果 app 过于庞大，想要实现插件化、组件化，这种分层模式可以省不少事。
但是这种方式也有一些缺点，比如有些项目初期功能一直在变化，如果按照功能木块划分，会导致项目结构一直在变化。另一方面，如果项目很小，本身就没多少界面，按照这么分层感觉颗粒度太细，有点大材小用的感觉。
综合以上分析，使用场景如下：
- 对于小型项目，推荐按照第一种分层方式。
- 对于大中型项目，推荐按照第二种分层方式。
当然，这只是我自己一些想法，具体在项目中可以自己决定。随着项目的庞大，会导致按照功能分层的每个目录下也会有很多文件，不易于定位功能代码，这种情况可以按照功能+类别的方式进行分层，看起来像这样：
二、软件架构方式和项目分层的关系
现在流行的软件架构方式，比如 MVC、MVP、MVVM等，这些是软件架构方式，和项目分层是两个维度的概念。
项目分层是指如何去组织文件夹和文件，而软件架构是指类职责的划分、类之间的通信方式、类的依赖关系以及数据在类之间的流转等。
如果你采用MVP模式，如果按照类别进行分层，项目结构看起来可能是如下这样：
而如果按照功能分包的方式，结构可能是这样：
三、小结
以上就是关于项目分层的两种形式以及使用场景，值得强调的是，这种分层方式不是标准和固定的，完全可以结合实际场景进行选择和变通。对项目进行分层是整个架构的一部分，但项目架构远不止于此，接下来的文章会介绍架构相关的知识，以及目前Android开发领域比较流行的一些软件架构模式，比如 MVC、MVP、MVVM和Clean。
