【译】Android 架构：基于消息的 MVC

译自 <http://mindtherobot.com/blog/675/android-architecture-message-based-mvc/>

本文地址：http://www.cnblogs.com/sunshy/archive/2012/07/09/2582712.html

注：由于本文原文链接 mindtherobot 网站被浏览器报告为恶意网站，故本文清除了链接内容，但是本人访问过该链接，并未发现异常，如果放心的话可以复制链接地址自己去浏览。文中有个别地方在原文中有链接，本文一律加上<>处理，不提供直接链接。

译序：Android 平台的开发框架貌似有点 MVC 的意思，比如用 xml 文件做 View 之类的，但是这样写出的代码还是会出现冗长的 Activity。网上很多文章在介绍 Android MVC 的时候都没有根本解决这一问题。偶尔发现这么一篇文章讲的很不错，于是决定翻译过来和大家共享。有些语言和原文不太一致，但都是为了表词达意用了自己的话，但相信还是保留了原作者的意思。第一次翻译技术文章，不当之处欢迎指正。

　　想在你的 Android 应用里优雅地分离出应用状态、用户交互和数据表现吗？

　　一个开发平台的设计者是的不会有闲工夫为你量身打造一个高层的应用架构的。但是你恰恰可以利用这一点，充分利用你的自由，根据应用需求和规模来实现你自己的架构。如果你仅仅要做些简单的小玩意儿，那么好吧，你可以随意在你的 widgets（像 text fields、spinners 之类的）中存储数据，然后就在诸如 OnClickListener 中去操控它们。可是话又说回来，如果你要写些宏伟的应用，或者想让你的小玩意儿更丰富迷人一点呢？那你还是考虑考虑分个层吧，因为一个好的架构会鼎力支持你去添加新特性，满足你梦寐以求的高性能、高灵活性、高度响应性等等需求。当然，你的代码也会因此摆脱蓬头垢面心乱如麻的糟糕状态，从此过上幸福的生活……

　　好吧，说正经的。在接下来的几分钟的光阴里，我将带你看一看如何根据大名鼎鼎的 MVC，来把你的代码大卸三块。呃……没这么恐怖，三块之间还是藕断丝连的，比如我会告诉你怎么用 Android 的 messaging 框架，来把 view (V) 和 controller (C) 连一连。我把这一实践应用到我自己的代码中，也许它并非 100% 的符合学术标准，也可能不是对每一个 app 都能成为天作之合，但是当我的应用变得越来越庞大的时候，我还是很享受它所给我带来的好处的。

Intro

　　关于这个 MVC，我就不多说了吧，到处都可以找到它的“广告”。我也不介意你到我写的 <an article on how to apply this architecture to a single component> 里面看一看。你最好先了解了解 Model，View，Controller 这三个东西。另外呢，如果你还没有看过 <the article on Handler>，最好还是去看看吧。尽管这篇文章里没有完整描述 messaging 这朵奇葩，你还是可以在里面打听到一些关于线程模型的八卦。接下来我会一直带你绕着一个样例转一转，转到最后你会看到样例的源代码。

Part 1: Model

　　把 Model 层泛化，并且让它只能接触到主逻辑，这是一个不错的开端。我们的样例看起来其实是一目了然加了无趣味，但还是有些有趣的地方。首先，我们有一个单独的类来包含 model 的“数据”——指的是，在应用的生命周期中， Model 层内可能发生变化的各种状态。

@Immutable
public final class ModelData implements Serializable {
 
  private static final long serialVersionUID = 1L;
 
  private final int answer;
 
  public ModelData(int answer) {
    this.answer = answer;
  }
 
  public final int getAnswer() {
    return answer;
  }
}

　　呃，你没有看走眼，我的确喜欢加个标注叫 @Immutable，这样一来我就会铭记这个类事实上是永恒不变的。这样有很多好处，比如说我能够在线程之间共享一个类的实例。另外，我还让这个类 Serializable，这样可以允许我实现一些例如 “Save/Load” 之类的特性。

 　　至于 Model 类本身，它长成这个样子：

@ThreadSafe
public class Model {
  public interface Listener {
    void onModelStateUpdated(Model model);
  }
 
  private ModelData data = new ModelData(0);
 
  private final List<Listener> listeners = new ArrayList<Listener>();
 
  public Model() {
 
  }
 
  public final ModelData getData() {
    synchronized (this) {
      return data;
    }
  }
 
  public final void updateData() { // takes a while!
    SystemClock.sleep(5000);
    ModelData newData = new ModelData(new Random().nextInt(10) + 1);
 
    synchronized (this) {
      data = newData;
    }
 
    synchronized (listeners) {
      for (Listener listener : listeners) {
        listener.onModelStateUpdated(this);
      }
    }
  }
 
  public final void addListener(Listener listener) {
    synchronized (listeners) {
      listeners.add(listener);
    }
  }
 
  public final void removeListener(Listener listener) {
    synchronized (listeners) {
      listeners.remove(listener);
    }
  }
}

　　方法 updateData() 要花一点时间来执行，在真实世界里，它可能是在请求服务器、执行繁重的计算等。data 被 synchronized 好好地保护了起来，不会被并发地访问。Listeners 也能安全地从并发线程中被添加或删除。如果你已经和 MVC 有过交往，你会意识到 model 的 listeners 是这个模式的中坚力量——它们让你能把任何代码附加到 model 上，而 model 却对此一无所知（因此 model 的代码就可以免受任何不相干的逻辑注入的伤害）。

　　现在来看最有意思的部分——Controller 层。

Part 2: Controller

　　其实吧，你可以通过很多种方式实现 Controller 这一层。　我选择的方式是基于 Handler, HandlerThread 与 Message 类的方法。当然，你多少要懂点它们的工作方式。

　　说到底，Android 平台让你可以通过这几个类来实现应用中各部分之间高效、安全且强大的 messaging 通信。在我们的例子里，我想做的的东西是：

• 送给 Controller 一个 inbox handler——这样 View 层就能给他写信（message）了，信的内容可以是“用户让我退出”或者“用户让我更新这些数据”以及其它一些甜言蜜语。
• 送给 Controller 一个或多个 outbox handlers——这样 Controller 就也能给 View（或 Views，比较多情，你懂得）写信（message）了，比如“ model 已经更新完了”或者“你自杀吧，我要退出了”，等等。
• 通过这样的方式，View 只能把用户事件装在信封（message）里寄给 Controller，并不用自己决定怎么对用户事件进行反应。一旦 Controller 给 View 寄来一封信（message），View 就会无脑地处理 Controller 告诉她的事情，并且给用户呈现出一些应用的状态。

　　通过这样一个悲情的故事，我们很干净地就实现了 MVC 的架构，虽然有点不太仁义。

　　由于 Handler 需要一个 Looper，我们需要选择一个线程，来运行 Controller 的 inbox handler。我们可以选择在 UI 线程中（它既能处理 UI 消息，又能处理 Controller 的消息）或者一个新的单独的 HandlerThread 中来运行。通常我们的 Controller 不会被困在一个很慢的操作中处理它的消息，这样它才能即使对 View 作出相应。所有很慢的操作都会在后台线程中运行。因此我们可以放心让 UI 线程来处理 Controller 消息。但是我还是选择运行一个单独的线程，仅仅是因为这样看起来架构会比较干净，也可能因为这样 Controller 的响应会有一点点的更快吧。既然 messageing 框架帮助我们摆脱了并发问题的牢笼，我们可以不用修改大量代码，就轻易地从一个 solution 跳到另外一个。

 　　来看看我们管理 inbox handler 和 outbox handler 的代码：

public class Controller {
 
        // ... some code omitted ...
 
  private final HandlerThread inboxHandlerThread;
  private final Handler inboxHandler;
  private final List<Handler> outboxHandlers = new ArrayList<Handler>();
 
        // ... some code omitted ...
 
  public Controller(Model model) {
    this.model = model;
 
    inboxHandlerThread = new HandlerThread("Controller Inbox"); // note you can also set a priority here
    inboxHandlerThread.start();
 
        // ... some code omitted ...
 
    inboxHandler = new Handler(inboxHandlerThread.getLooper()) {
      @Override
      public void handleMessage(Message msg) {
        Controller.this.handleMessage(msg);
      }
    };
  }
 
  public final void dispose() {
    // ask the inbox thread to exit gracefully
    inboxHandlerThread.getLooper().quit();
  }
 
  public final Handler getInboxHandler() {
    return inboxHandler;
  }
 
  public final void addOutboxHandler(Handler handler) {
    outboxHandlers.add(handler);
  }
 
  public final void removeOutboxHandler(Handler handler) {
    outboxHandlers.remove(handler);
  }
 
  final void notifyOutboxHandlers(int what, int arg1, int arg2, Object obj) {
    if (outboxHandlers.isEmpty()) {
      Log.w(TAG, String.format("No outbox handler to handle outgoing message (%d)", what));
    } else {
      for (Handler handler : outboxHandlers) {
        Message msg = Message.obtain(handler, what, arg1, arg2, obj);
        msg.sendToTarget();
      }
    }
  }
 
        // ... some code omitted ...
}

　　这些并不是 Controller 的完整代码。先说点其它的我们马上回来。你现在能看到的是我们如何初始化 inbox handler 与它的线程，如何提交一个 handler 到 outbox handlers 中去，以及如何用一个消息通知所有的 outbox handlers。

　　有了这些代码，我们可以得到 inbox handler，并可以从 View 层向它发送消息，同时我们有绑定了 View 的 outbox handler，能够让 Controller 与它的 Views 有效地交换异步消息。

　　为了能处理收到的消息并做点什么，我们需要在 Controller 类中实现 handleMessage() 方法。在大部分应用中，你都可能想在这里实现一个设计模式中的状态模式的实例，因为根据应用正在处理的工作的不同，我们可能需要对一个消息进行不同的处理，乃至忽略一些消息。例如，在我们的应用中，一旦你开始刷新模型了，你肯定不希望用户在刷新完成之前再刷新一次。为了表明这一点，我给出了 ControllerState 接口和它的 ReadyState 的实现：

public interface ControllerState {
  boolean handleMessage(Message msg);
}
 
final class ReadyState implements ControllerState {
 
  private final Controller controller;
 
  public ReadyState(Controller controller) {
    this.controller = controller;
  }
 
  @Override
  public final boolean handleMessage(Message msg) {
    switch (msg.what) {
    case V_REQUEST_QUIT:
      onRequestQuit();
      return true;
    case V_REQUEST_UPDATE:
      onRequestUpdate();
      return true;
    case V_REQUEST_DATA:
      onRequestData();
      return true;
    }
    return false;
  }
 
  private void onRequestData() {
    // send the data to the outbox handlers (view)
    controller.notifyOutboxHandlers(C_DATA, 0, 0, controller.getModel().getData());
  }
 
  private void onRequestUpdate() {
    // we can't just call model.updateState() here because it will block
    // the inbox thread where this processing is happening.
    // thus we change the state to UpdatingState that will launch and manage
    // a background thread that will do that operation
 
    controller.changeState(new UpdatingState(controller));
  }
 
  private void onRequestQuit() {
    controller.quit();
  }
}

　　把 Controller 和它的状态们（stages）放到同一个 package 中，我们可以让它们使用默认访问级别就能访问到 Controller 的内部。我就不把 UpdatingState 的代码贴这儿了，在页底的附件中都有。

　　这里看看 Controller 是怎么把消息处理委托给它的 state 的：

public class Controller {
 
        // ... some code omitted ...
  private ControllerState state;
 
  public Controller(Model model) {
    this.model = model;
 
        // ... some code omitted ...
 
    this.state = new ReadyState(this);
 
        // ... some code omitted ...
  }
 
        // ... some code omitted ...
 
  private void handleMessage(Message msg) {
    Log.d(TAG, "Received message: " + msg);
 
    if (! state.handleMessage(msg)) {
      Log.w(TAG, "Unknown message: " + msg);
    }
  }
 
  final Model getModel() {
    return model;
  }
 
  final void quit() {
    notifyOutboxHandlers(C_QUIT, 0, 0, null);
  }
 
  final void changeState(ControllerState newState) {
    Log.d(TAG, String.format("Changing state from %s to %s", state, newState));
    state = newState;
  }
}

　　好了，Controller 大概就是这般模样，现在让我们介绍个 View 给它认识认识吧。

Part 3: View

　　不用过多解释了，我猜你已经知道怎么做了。上代码（DemoActivity）：

public class DemoActivity extends Activity implements Handler.Callback, OnClickListener {
 
  private static final String TAG = DemoActivity.class.getSimpleName();
 
  private Controller controller;
 
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
 
        setContentView(R.layout.main);
 
        ((Button) findViewById(R.id.update)).setOnClickListener(this);
        ((Button) findViewById(R.id.quit)).setOnClickListener(this);
 
        controller = new Controller(new Model());
        controller.addOutboxHandler(new Handler(this)); // messages will go to .handleMessage()
 
        controller.getInboxHandler().sendEmptyMessage(V_REQUEST_DATA); // request initial data
    }
 
  @Override
  protected void onDestroy() {
    // I think it is a good idea to not fail in onDestroy()
    try {
      controller.dispose();
    } catch (Throwable t) {
      Log.e(TAG, "Failed to destroy the controller", t);
    } 
 
    super.onDestroy();
  }
 
  @Override
  public boolean handleMessage(Message msg) {
    Log.d(TAG, "Received message: " + msg);
 
    switch (msg.what) {
    case C_QUIT:
      onQuit();
      return true;
    case C_DATA:
      onData((ModelData) msg.obj);
      return true;
    case C_UPDATE_STARTED:
      onUpdateStarted();
      return true;
    case C_UPDATE_FINISHED:
      onUpdateFinished();
      return true;
    }
    return false;
  }
 
  private void onUpdateStarted() {
    ProgressBar progressBar = (ProgressBar) findViewById(R.id.progress_bar);
    progressBar.setVisibility(View.VISIBLE);
  }
 
  private void onUpdateFinished() {
    ProgressBar progressBar = (ProgressBar) findViewById(R.id.progress_bar);
    progressBar.setVisibility(View.GONE);
 
    // request the updated data
    controller.getInboxHandler().sendEmptyMessage(V_REQUEST_DATA);
  }
 
  private void onData(ModelData data) {
    TextView dataView = (TextView) findViewById(R.id.data_view);
    dataView.setText("The answer is "+ data.getAnswer());
  }
 
  private void onQuit() {
    Log.d(TAG, "Activity quitting");
    finish();
  }
 
  @Override
  public void onClick(View v) {
    switch (v.getId()) {
    case R.id.update:
      controller.getInboxHandler().sendEmptyMessage(V_REQUEST_UPDATE);
      break;
    case R.id.quit:
      controller.getInboxHandler().sendEmptyMessage(V_REQUEST_QUIT);
      break;
    }
  }
}

　　在这一样例中，Activity 实际上占据了 Controller 的实例，而这个 Controller 是控制着 model 的。然而，如果你觉得 Service 的生命周期更能匹配 Controller/Model 的生命周期的话，你也可以考虑把 Controller 转移到一个 Service 中。

Summary

　　你现在应该很清楚了，基于 message 的方法的的确确能允许我构建一个强大的、复杂的 Controller 与一个完全百依百顺的贤惠的 View。这样我们就有了一个很好的 MVC 的实现。

　　正如我在开头所写的那样，这一解决方案从理论上讲不一定完全有效，也不一定就适合你的 app，但是我已经经历了构建一个非常复杂应用的过程，这中间有很多种状态，并且它完全依赖于消息。这一架构会有很多弱点，比如你要在某个地方聚合 message 的代码（见 ControllerProtocol）并在文档里定义很多 message 参数。但是别忘了好处：它很好地实现了层间的分离，当你的 app 越长越大时，你更会体会到这一框架的美妙。

源代码：async-mvc.zip