Android Architecture Components的应用架构

Android Architecture Components 是一个由Google官方推出的库，它能够帮助你去构建一个健壮，易测，可维护的应用。用于管理UI组件生命周期以及处理数据持久性等问题。

架构原则

应用中的关注点分离。
Activity或Fragment内只处理UI相关逻辑，任何与此无关的代码都不该堆在其内。
也就是类的单一职责化。尽可能保持精简可以避免许多生命周期相关的问题。基于用户交互或其他因素（如低内存），Android系统可能随时销毁它们。最好尽量减少对它们的依赖，以提供好的用户体验。
数据模型驱动 UI
做到数据持久化，这样至少有两个好处：
1.用户不会因为系统销毁我们的应用而导致丢失数据。
2.我们的应用可以在网络状况不好甚至断网的情况下继续工作。

主要模块

包含Lifecycles, LiveData, ViewModel, Room, and Paging.
下面主要讲解一下Lifecycles,LiveData以及ViewModel

Lifecycles

在 android.arch.lifecycle 包中提供了可以构建生命周期感知的组件的类和接口，这些组件可以根据 Activity/Fragment 的生命周期自动调整它的行为。

Lifecycle.jpg

从图中我们可以看到 LifecycleOwner 是 Lifecycle 的持有者，通常是一个 Activity 或 Fragment。想要获取 Lifecycle 只能通过 LifecycleOwner 的 getLifecycle 方法。Lifecycle 是可观察的，它可以持有多个 LifecycleObserver。

  • Lifecycle：它是一个持有 Activity/Fragment 生命周期状态信息的类，并且允许其他对象观察此状态。Lifecycle 内部维护了两个枚举，一叫 Event，另一个叫 State。Event 是对 Android 组件（Activity 或 Fragment）生命周期函数的映射，当 Android Framework 回调生命周期函数时，Lifecycle 会检查当前事件和上一个事件是否一致，如果不一致，就根据当前事件计算出当前状态，并通知它的观察者（LifecycleObserver）生命状态已经发生变化。观察者收到通知后，通过 Lifecycle 提供的 getCurrentSate 方法来获取刚刚 Lifecycle 计算出来的当前状态，观察者根据这个状态来决定要不要执行某些操作
    lifecycle-states.png

LifecycleOwner

  • LifecycleOwner：是一个具有单一方法的接口。如果一个类实现了此接口，则该类中需要持有一个 Lifecycle 对象，并通过LifecycleOwner#getLifecycle() 方法返回该对象。Support Library 26.1+ 已经集成了此组件。

并不是只有 Activity 和 Fragment 才可以实现 LifecycleOwner 接口的，任何和 Activity/Fragment 生命周期有关系的类都可以实现此接口。通过实现此接口，该类完全是生命周期可感知的，只需要对它进行初始化，它就可以进行自己的初始化和清理操作，而不受其 Activity/Fragment 的管理。详细可以参看官方文档说明：LifecycleOwner 实践

LifecycleObserver
可以使用 Lifecycle 的类被称为生命周期感知组件。（也就是继承实现LifecycleObserver 的类）。

谷歌提倡那些需要和 Android 生命周期协作的类库提供生命周期感知组件，这样客户端代码就可以很容易集成这些类库，而不需要客户端手动管理类库中和 Android 生命周期相关的代码。

class MyObserver implements LifecycleObserver {
    private boolean enabled = false;
    public MyObserver(Context context, Lifecycle lifecycle, Callback callback) {
       ...
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    void start() {
        if (enabled) {
           // connect
        }
    }

    public void enable() {
        enabled = true;
        if (lifecycle.getCurrentState().isAtLeast(STARTED)) {
            // connect if not connected
        }
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    void stop() {
        // disconnect if connected
    }
}

通过注解就可以监听对应的生命周期事件，同时别忘了调用 owner.getLifecycle().addObserver() 把观察者（MyObserver）注册到 Lifecycle.

LiveData

LiveData 是一个 observable 数据的持有类，和普通的 observable 不同，LiveData 是生命周期感知的，意味着它代表其它应用组件譬如 Activity、Fragment、Service 的生命周期。这确保了 LiveData 只会更新处于活跃状态的组件。

LiveData 通过内部类的形式实现了 LifecycleObserver，它整个工作流程大概是这样的：

  1. 将实现了 LifecycleObserver 的内部类注册到 owner 的 Lifecycle。
  2. LifecycleObserver 监听了 Lifecycle 所有的生命周期事件
  3. 当有生命周期事件发生时，检查 Lifecycle 的状态是否至少是 STARTED 来判断 lifecycle 是否处于活跃状态
  4. 当维护的值被改变时，如果 Lifecycle 处于活跃状态，通知观察者(实现了 android.arch.lifecycle.Observer 接口的对象)，否则什么也不做
  5. 当 Lifecycle 从非活跃状态恢复到活跃状态时，检查维护的值是否在非活跃期间有更新过，如果有，通知观察者
  6. 当 Lifecycle 处于完结状态 DESTROYED 时，从 Lifecycle 中移除 LifecycleObserver。

很显然，LiveData 是响应式的，令人惊艳的是，它有效解决了后台回调和 Android 生命周期的上古谜题。

LiveData 使用起来是这样的：

public class NameViewModel extends ViewModel {

// Create a LiveData with a String
private MutableLiveData<String> mCurrentName;

    public MutableLiveData<String> getCurrentName() {
        if (mCurrentName == null) {
            mCurrentName = new MutableLiveData<String>();
        }
        return mCurrentName;
    }

// Rest of the ViewModel...
}

现在，Activity 可以访问这个列表如下：

public class MyActivity extends AppCompatActivity {
    public void onCreate(Bundle savedInstanceState) {
        MyViewModel model = ViewModelProviders.of(this).get(MyViewModel.class);
        model.getUsers().observe(this, users -> {
            // update UI
        });
    }
}

它还提供了 Transformations 来帮助我们转换 LiveData 所持有的数据。

Transformations.map()
在LiveData数据的改变传递到观察者之前，在数据上应用一个方法：

LiveData<User> userLiveData = ...;
LiveData<String> userName = Transformations.map(userLiveData, user -> {
    user.name + " " + user.lastName
});

Transformations.switchMap()
与Transformations.map()类似，只不过这里传递个switchMap()的方法必须返回一个LiveData对象。

private LiveData<User> getUser(String id) {
  ...;
}

LiveData<String> userId = ...;
LiveData<User> user = Transformations.switchMap(userId, id -> getUser(id) );

ViewModel

看到 ViewModel 这个词，就会让人想起 MVVM，ViewModel 正是 MVVM 架构里面的一个重要角色。

MVVM 按职责把类分为三种角色，分别是 View，ViewModel，Model。ViewModel 正好处于中间，是连接 View 和 Model 的桥梁。

  • View 只做两件事情，一件是根据 ViewModel 中存储的状态渲染界面，另外一件是将用户操作转发给 ViewModel。用一个公式来表述是这样的：view = render(state) + handle(event)。
  • ViewModel 也只做两件事。一方面提供 observable properties 给 View 观察，一方面提供 functions 给 View 调用，通常会导致 observable properties 的改变，以及带来一些额外状态。observable properties 是指 LiveData、Observable(RxJava) 这种可观察属性。View 正是订阅了这些属性，实现模型驱动视图。functions 是指可以用来响应用户操作的方法或其它对象，ViewModel 不会也不应该自己处理业务，它通过 functions 把业务逻辑的处理委派给 Model。用一个公式来表述是这样的：viewmodel = observable properties + functions。
  • Model 是整个应用的核心。它包含数据以及业务逻辑，网络访问、数据持久化都是它的职责。用一个公式来表述是这样的：model = data + state + business logic。

在 Android 中，View 包含 Activity 和 Fragment，由于 Activity 和 Fragment 可以销毁后重建，因此要求 ViewModel 在这个过程中能够存活下来，并绑定到新的 Activity 或 Fragment。架构组件提供了 ViewModel 来帮我们实现这点。

ViewModel的生命周期跟着传递给ViewModelProvider的LifeCycle走，当生成了ViewModel的实例后，它会一直待在内存中，直到对应的LifeCycle彻底结束。下面是ViewModel与Activity对应的生命周期图：


viewmodel-lifecycle.png

ViewModel将数据从UI中分离出来。并且当Activity或Fragment重构的时候，ViewModel会自动保留之前的数据并给新的Activity或Fragment使用。

public class MyViewModel extends ViewModel {
    private MutableLiveData<List<User>> users;
    public LiveData<List<User>> getUsers() {
        if (users == null) {
            users = new MutableLiveData<List<Users>>();
            loadUsers();
        }
        return users;
    }

    private void loadUsers() {
        // Do an asynchronous operation to fetch users.
    }
}

接着在我们的Activity中就能这样使用了：

public class MyActivity extends AppCompatActivity {
    public void onCreate(Bundle savedInstanceState) {
        // Create a ViewModel the first time the system calls an activity's onCreate() method.
        // Re-created activities receive the same MyViewModel instance created by the first activity.

        MyViewModel model = ViewModelProviders.of(this).get(MyViewModel.class);
        model.getUsers().observe(this, users -> {
            // update UI
        });
    }
}

当 Activity 或 Fragment 真正 finish 的时候，框架会调用 ViewModel 中的 onCleared 方法，在这个方法里面清除不再使用的资源。

如果 ViewModel需要 Application上下文，例如查找系统服务，则可以扩展 AndroidViewModel 该类并在构造函数中接收Application 。

Fragment之间的数据共享
在Activity中包好多个Fragment并且需要相互通信是非常常见的，这时就需要这些Fragment定义一些接口，然后让Activity来进行协调。
上面这个问题可以被ViewModel轻易解决，假设有这么一个Activity，它包含FragmentA和FragmentB，其中A是用户列表，B是用户的详细数据，点击列表上的某个用户，在B中显示相应的数据。如以下示例代码所示：

public class SharedViewModel extends ViewModel {
    private final MutableLiveData<Item> selected = new MutableLiveData<Item>();

    public void select(Item item) {
        selected.setValue(item);
    }

    public LiveData<Item> getSelected() {
        return selected;
    }
}

public class MasterFragment extends Fragment {
    private SharedViewModel model;
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
        itemSelector.setOnClickListener(item -> {
            model.select(item);
        });
    }
}

public class DetailFragment extends Fragment {
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        SharedViewModel model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
        model.getSelected().observe(this, { item ->
           // Update the UI.
        });
    }
}

这里要注意的是两个Fragment都使用了getActivity作为参数来获得ViewModel实例。这表示这两个Fragment获得的ViewModel对象是同一个SharedViewModel。

使用了ViewModel的好处如下：

Activity不需要做任何事情，不需要干涉这两个Fragment之间的通信。
Fragment不需要互相知道，即使一个消失不可见，另一个也能很好的工作。
Fragment有自己的生命周期，它们之间互不干扰，即便你用一个FragmentC替代了B，FragmentA也能正常工作，没有任何问题。

参考：
https://developer.android.com/topic/libraries/architecture/guide.html
https://developer.android.com/topic/libraries/architecture/lifecycle.html
https://developer.android.com/topic/libraries/architecture/livedata.html
https://developer.android.com/topic/libraries/architecture/viewmodel.html
https://listenzz.github.io/android-lifecyle-works-perfectly-with-rxjava.html
http://www.cnblogs.com/zqlxtt/p/6888507.html

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 206,839评论 6赞 482
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 88,543评论 2赞 382
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 153,116评论 0赞 344
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 55,371评论 1赞 279
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 64,384评论 5赞 374
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 49,111评论 1赞 285
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,416评论 3赞 400
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 37,053评论 0赞 259
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 43,558评论 1赞 300
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,007评论 2赞 325
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,117评论 1赞 334
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,756评论 4赞 324
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,324评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,315评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,539评论 1赞 262
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 45,578评论 2赞 355
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,877评论 2赞 345