在移动开发领域，我们往往会遇到软件的可扩展性、可复用性以及可维护性等问题，这就涉及到如何做好软件的架构设计或者重构优化工作。结合实践与思考，本文对其中的Android应用软件架构做些梳理，首先是层次结构划分，其次是技术选型的考虑。
这里层次结构的划分，可以从横向和纵向两个维度来考虑。
横向上的结构层次，主要指代码文件目录结构或者与之对应的“包”（Package）的划分。
对于使用了MVP架构的应用软件，结合实现方案，可以分为ui、presenter、model、server、utils等。其中ui包括各种Activity、Fragment，以及自定义的视图组件、布局组件等。而model包括业务模型、相关数据的定义等，server负责处理软件和服务器的通信接口实现、JSON数据解析等工作。
在ui中，还可以按照业务功能来对Activity、Fragment加以进一步的划分，这样更方便团队分工维护。因为业务功能相关的UI大都体现在Activity或者与之关联的Fragment，这样划分比较简明直观。
纵向上的层次结构，更侧重逻辑调用和依赖关系，可分为业务层和组件层。
其中业务层，用于实现该软件对应的UI界面以及相关的功能逻辑，和用户操作、展示关联较多，可以选择性地使用MVP架构来实现。
因为该架构会增加类的数量并且至少涉及到三个层次的逻辑调用（在业务层之内），建议只用在业务逻辑较多、UI显示相对复杂，或者后续更有可能需要扩展的地方。
具体到相关实现，又有不同的策略，例如我们可以使用Activity/Fragment/Adapter等组件来封装扩展Presenter，规避其复杂的生命周期变化、资源/变量的初始化和释放等操作对业务逻辑的影响。也可以将Activity/Fragment作为视图层主体，通过接口和Presenter实现互相调用。这里还是需要结合业务特点，在架构实现复杂度与可读性、可维护性之间加以权衡，选择合适的实现方案，满足要求即可。
组件层，主要是独立于上述业务逻辑之外的，但与之有一定关联的功能组件，例如推送服务、图像识别、社会化分享以及支付组件等，通常作为模块组件的方式支持业务层。如果进一步细分，组件层还可以分为功能组件和基础组件层。例如网络连接管理、日志管理等组件，相对更为通用，和业务逻辑的直接关联也更少一些，可以认为是基础组件。
在架构设计过程中，通常还涉及到各种技术选型，这也是为了避免重复造轮子，更好地利用已有成果、提高开发效率。例如，业务层选用MVP还是MVVM架构？在哪些子模块使用？组件层，图像异步加载使用UIL还是Picasso？网络连接管理采用OkHttp还是Volley？诸如此类。
这部分涉及较多的开源项目、相关组件以及第三方服务商的优缺点分析，例如不同组件的性能、sdk文件体积、组件的配套使用等因素，后面继续探讨。
网友评论