移动开发中的软件架构

在移动开发领域，我们往往会遇到软件的可扩展性、可复用性以及可维护性等问题，这就涉及到如何做好软件的架构设计或者重构优化工作。结合实践与思考，本文对其中的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文件体积、组件的配套使用等因素，后面继续探讨。

最后

以上就是欣喜小懒虫为你收集整理的移动开发中的软件架构的全部内容，希望文章能够帮你解决移动开发中的软件架构所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。