Android Flux架構初探

時間 2019-11-08

原文原文鏈接

序言

以前寫過一篇關於Android項目如何架構的，有MVC和MCVP，前幾天又看到了新的一種架構，固然並非新出的，出了有一段時間，當前被應用的並非很廣泛，接下來從其特色和使用上來介紹Flux架構。本文主要目的是讓你對Flux的一個架構大致面貌有個瞭解。web

Flux 架構介紹

Flux 架構被Facebook使用來構建他們的客戶端web應用。跟Clean Architecture同樣，它不是爲移動應用設計的，可是它的特性和簡單可讓咱們很好的在安卓項目中採用。

要理解Flux，有兩個關鍵的特色網絡

數據流老是單向的
一個單向的數據流是 Flux 架構的核心，也是它簡單易學的緣由。就以下面討論的，在進行應用測試的時候，它提供了很是大的幫助。架構
應用被分紅三個主要部分：併發
- View: 應用的界面。這裏建立響應用戶操做的action。app
- Dispatcher: 中心樞紐，傳遞全部的action，負責把它們運達每一個Store。dom
- Store: 維護一個特定application domain的狀態。它們根據當前狀態響應action，執行業務邏輯，同時在完成的時候發出一個change事件。這個事件用於view更新其界面。ide
- 這三個部分都是經過Action來通訊的：一個簡單的基本對象，以類型來區分，包含了和操做相關的數據。函數

Flux Android 架構

在安卓開發中使用Flux設計規範的目的是創建一個在簡單性與易擴展易測試之間都比較平衡的架構。
第一步是找到Flux元素和安卓app組件之間的映射。
其中兩個元素很是容易找到與實現。
View: Activity o或者Fragment
Dispatcher: 一個事件總線（ event bus），在個人例子中將使用Otto，可是其它任何實現都應該是ok的。
Actions
Actions也不復雜。它們的實現和POJO同樣簡單，有兩個主要屬性：
Type: 一個String，定義了事件的類型。
Data: 一個map，裝載了本次操做。
Store是Flux理論中最難的部分。
Stores響應Dispatcher發出的Action，執行業務邏輯併發送change事件。Stores的惟一輸出是這單一的事件：change。其它對Store內部狀態感興趣的組件必須監聽這個事件，同時使用它獲取須要的數據。最後，stores必須對外公開一個獲取application狀態的接口。這樣，view元素能夠查詢Stores而後相應的更新UI。post

這裏經過一個簡單的小demo來說述整個流程。咱們的界面上有一個Button和一個TextView,點擊Button後讓TextView顯示出文字。常規的實現，直接在Activity中完成邏輯，MVP模式，在Presenter層來進行，對於Flux架構，咱們要怎麼實現呢。經過上圖咱們能夠看到，View會產生Action，而後被Dispatcher進行調度，通過Store相應處理，將數據顯示出來。測試

如何產生Action

首先要知道Action是什麼樣

public class Action {

    private final String type;
    private final HashMap<String, Object> data;

    public Action(String type, HashMap<String, Object> data) {
        this.type = type;
        this.data = data;
    }

    public static Builder type(String type) {
        return  new Builder().with(type);
    }

    public String getType() {
        return type;
    }

    public HashMap getData() {
        return data;
    }

    public static class Builder {
        private String type;
        private HashMap<String, Object> data;

        Builder with(String type) {
            if(type == null) {
                throw  new IllegalArgumentException("Type may not be null.");
            }
            this.type = type;
            this.data = new HashMap<>();
            return this;
        }

        public Builder bundle(String key, Object value) {
            if (key == null) {
                throw  new IllegalArgumentException("Key may not be null.");
            }
            if(value == null) {
                throw new IllegalArgumentException("Value may not be null.");
            }
            data.put(key, value);
            return this;
        }

        public Action build() {
            if (TextUtils.isEmpty(type)) {
                throw  new IllegalArgumentException("At least one key is required.");
            }
            return new Action(type, data);
        }
    }
}

每個Action有兩個屬性，一個來標記Type，另外一個字段來存儲傳送的數據，經過Map來存放。
對於Action Type，咱們能夠經過一個接口或者類來進行記錄，將全部的類型保存在其中。方便咱們的調用。

public interface ShowActions {
    String TODO_SHOW = "todo-show";
    String GET_TEXT = "get-text";
}

如何建立Action，定義一個類，專門用來根據咱們可能會出現的各類View的事件，定義出來各類Action。

public class ActionsCreator {

    private  static ActionsCreator instance;

    final Dispatcher mDispatcher;

    ActionsCreator(Dispatcher dispatcher){
        mDispatcher = dispatcher;
    }

    public static ActionsCreator get(Dispatcher dispatcher) {
        if (instance == null) {
            instance = new ActionsCreator(dispatcher);
        }
        return instance;
    }

    public void create(String text) {
        mDispatcher.dispatch(ShowActions.TODO_SHOW, ShowActions.GET_TEXT, text);
    }

在咱們準備用ActionsCreator來建立Action的時候，咱們並無直接new Action這種方式來作，而是將其經過調度器，對其進行了分發。這裏的事件分發，咱們使用的是Otto的Bus來進行事件的分發。

public class Dispatcher {

    private final Bus bus;
    private static Dispatcher instance;

    Dispatcher(Bus bus){
        this.bus = bus;
    }

    public static  Dispatcher get(Bus bus) {
        if (instance == null) {
            instance = new Dispatcher(bus);
        }
        return instance;
    }

    public void register(final Object cls) {
        bus.register(cls);
    }

    public void unRegister(final Object cls) {
        bus.unregister(cls);
    }

    public void emitChange(Store.StoreChangeEvent o) {post(o);}

    public void dispatch(String type, Object... data) {
        if(TextUtils.isEmpty(type)) {
            throw new IllegalArgumentException("Type must not be empty");
        }

        if (data.length % 2 != 0) {
            throw  new IllegalArgumentException("Data must be a valid list of key");
        }

        Action.Builder actionBuilder = Action.type(type);
        for (int i = 0; i < data.length; i++) {
            String key = (String) data[i++];
            Object value = data[i++];
            actionBuilder.bundle(key, value);
        }
        post(actionBuilder.build());
    }

    private boolean isEmpty(String type) {
        return TextUtils.isEmpty(type);
    }

    private void post(final Object event) {
        bus.post(event);
    }
}

在調度的過程當中，咱們將傳遞進來的數據進行一個解析，而後根據數據建立出相應的Action，而後對Action進行分發，這個時候關注了相應的Action的Store就會開始根據相應的Action開始執行相應的操做。在Store中，聲明瞭一個抽象方法onAction來負責進行對於Action的判斷和分發，而後定義了StoreChangeEvent接口做爲事件變化，當有變化的時候，經過這個進行傳遞，咱們能夠本身實現這個接口，而後在裏面添加一些方法和字段用來攜帶數據。

public abstract class Store {
    final Dispatcher mDispatcher;

    protected Store(Dispatcher dispatcher) {
        this.mDispatcher = dispatcher;
    }

    void emitStoreChange() {
        mDispatcher.emitChange(changeEvent());
    }

    abstract StoreChangeEvent changeEvent();

    public abstract void onAction(Action action);

    public interface StoreChangeEvent {}

}

咱們自定義的Store類

public class ShowStore extends Store {

    private static ShowStore instance;
    private String showText;

    public ShowStore(Dispatcher dispatcher){
        super(dispatcher);
    }

    public static ShowStore get(Dispatcher dispatcher) {
        if (instance == null) {
            instance = new ShowStore(dispatcher);
        }
        return instance;
    }

    @Subscribe
    public void onAction(Action action) {
        switch (action.getType()) {
            case ShowActions.TODO_SHOW :
                showText = ((String)action.getData().get(ShowActions.GET_TEXT));
                Log.i("showText", showText);
                emitStoreChange();
                break;
            default:
                break;
        }
    }

    public String getShowText(){
        return showText;
    }

    @Override
    StoreChangeEvent changeEvent() {
        return new ShowChangeEvent();
    }

    public class ShowChangeEvent implements StoreChangeEvent {

    }
}

而後咱們在View也就是Activity中訂閱了變化時間的方法，這個時候就能夠實現對於View中的數據的一個動態更新。

@Subscribe
    public void showText (ShowStore.ShowChangeEvent event){
        mTextView.setText(mShowStore.getShowText());
    }

從架構的角度看Flux

站在總體架構的角度來看，對於咱們Activity，Fragment中，當咱們的View很是的豐富，涉及到的邏輯很是多的時候，這個時候，在MVP的架構下，P層將會變的很是臃腫，後期的維護將會很難了，咱們能夠採用的方式是將其拆分爲多個p層，分別用來處理整個屏幕下的不一樣的View，負責響應View的事件，處理相應的邏輯，還一個問題是在咱們的不一樣的model中，可能會有些一些相同的操做，而咱們卻須要將其放在不一樣的module下的P層中，而經過Flux方式，咱們能夠將這些共有的邏輯徹底的解耦出來，放到Store中，而後經過單向數據流傳遞的方式，將要處理的數據傳遞給Store，而後返回處理後的結果。

總結

經過Flux架構，使用的流程是，咱們的View的事件會攜帶數據，經過一個ActionsCreate建立一個Type的Action，實際完成過程是在Dispatcher的dispatch中，而後再將這個Action丟給訂閱了該Action的Store方法中，在這裏完成各類邏輯，處理，甚至是能夠發起網絡請求獲取數據，處理完成，能夠將結果封裝成一個事件，而後這個事件會再次經過調度器中的emitChangeEvent將事件傳遞給訂閱了該事件的函數，而這個接收響應事件的函數被咱們定義在咱們View中，從而實現對於咱們View的更新。