移动App架构设计

83 阅读 0 评论 55 点赞

我是靠谱客的博主拼搏纸鹤，最近开发中收集的这篇文章主要介绍移动App架构设计，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

这一篇，我们谈谈如何做App的架构设计。不包含游戏类App。

之前介绍了MVC-IC的架构模式，它是一种在MVC的基础上特别强调了控制流和信息流（IC Stream）的架构模式，其实也不是什么新东西，只是因为清晰的控制流和信息流对于保持App的健壮性和可维护性非常重要，特别是逻辑复杂的App。因此单独将IC提取出来，放到和MVC同等重要的位置，进而提醒我们的架构设计者在这方面时刻保持警惕。

回到App的架构设计的问题，收到一款App的开发任务，我们应该从哪里开始着手做设计？

首先我们可以对App做一个简单的划分，这种划分只是让我们的设计大概有一个方向。因此不需要特别精确。比如我们可以把App划分为数据型，功能型以及两者并重型三类。

1、数据型App

这类App大部分工作是围绕数据展开的，完成对各种数据的获取、加工以及呈现。新闻阅读类的APP基本上都是这种类型的，比如网易新闻。这类应用可能要面对精心设计Cache的问题。

2、功能型App

不会涉及到非常多的数据，偏向于实现某种功能，比如Camera，VOIP类应用。这类应用可能需要精心维护某些核心模块的状态机，或者PipeLine。

3、数据功能型App

会对两者都有比较大的侧重。

这样划分的目的对我们面临的任务做到心里有数，二是方便我们进行初期的方案选定，比如可以用那些开源项目来加快开发。

有了大概的方向之后我们可以按照下面的步骤来完成对APP的设计：

1、StoryBoard

所谓StoryBoard实际上就是产品设计人员交给我们的设计原型，这里包含了这个App有多少个界面，每个界面展示什么样的信息，每个界面提供什么样的操作，界面之间的切换关系等。

在这一步，我们基本可以确定这样的信息：

每个界面需要哪些数据信息（如界面上的ListView需要什么数据，数据从哪里来等）， 每个界面接受哪些控制信息（别的模块可能对界面上的某些元素发出指令，比较show/hide等），以及 每个界面可以出发哪些控制（主要对应用户的输入，比如Button的按下，Pager的翻动等），通过这些信息我们就可以抽象出Interface来代表这个界面行为。让我们的Controller和这个Interface打交道，而不是直接和View打交道，这样可以更加方便的改变界面UI。这里的Interface其实就是Controller和View之间信息流和控制流的通道。

同时对应Android开发来说，这一步也大致可以确定我们需要哪些Activity。

这一步主要完成的是MVC-IC中的View以及View相关的IC。

2、功能模块

这里说的功能模块，指的是MVC-IC架构中的Model部分。

通过第一步对StoryBoard的分析，对于Android开发来说我们基本可以确定需要有哪些Activity了，通常一个Activity应该对应有一个Controller（MVC-IC架构中的Controller），所以在这一步，我们要根据各个Activity要实现的功能，来确定它的Model。

比如，一个Activity包含一个Button和一个ListView，点击Button获取网络数据，然后通过ListView将获取的数据展现出来。那么根据此Activity提供的功能，我们可以大致给出这样几个Model：完成网络请求的Model（Network Model），数据处理模块（Data Parser Model），如果数据需要缓存的话还需要缓存模块（Cache Model）等，那么这个Activity的Controller就需要维护Network Model，Data Parser Model，Cache Model等这些模块。

这样分析下来，基本上每个Activity所需要的功能模块就都清楚了。在这个过程中我们需要考虑到模块的通用性，比如Data Parser Model模块应该是可以可以通用的模块。同时考虑每个模块的控制流和信息流，设计好接口。

这部分主要完成的是MVC-IC中的Model以及Model相关的IC。

3、Controller

这里侧重于MVC-IC中的Controller，但这部分和上一步应该是可以并行进行的，可以下大概确定了Model之后就开始Controller的工作，Model/Controller同时进行。 Controller主要完成对Model和View之间控制流和信息流的Dispatch，以及Model生命周期和相互关系的维护。

在Android开发中，通常Controller存在于Activity中，因此Controller需要提供一个接口来接收Activity生命周期的事件，进而根据这些事件来安排Model的生命周期。如果Controller存在于Fragment中，那么它可能需要接收Fragment的生命周期事件。

通过上面的三个步骤，App的整体架构基本就出来了，记住一个模式三个步骤。不过各个Model的设计，也是一件很有挑战的事情。