详解Android中实现Redux方法

Redux 是一个用于应用程序状态管理的开源JavaScript库,其核心是通过可管理和控制的状态来描述一个系统。这意味着其思想其实是可以应用于任何类型应用的开发的,包括移动应用。

Redux 架构基于一个严格的单向数据流,应用中的所有数据都是通过组件在一个方向上流动。Redux 希望确保应用的视图是根据确定的状态来呈现的。意思就是,在任何时间点,你应用的状态总是确定、有效的,并且可以转换到另一个可预测和有效的状态。而 UI 将根据所处的状态来进行呈现。

关于 Redux 在网上已经有很多相关的资料,这里就只介绍下 Redux 核心的三个组件:

1. Store:保存应用的状态并提供一些帮助方法来存取状态,分发状态以及注册监听。

2. Actions:简单说 Actions 就是事件,包含要传递给 store 的信息,表明我们希望怎样改变应用的状态。比如,定义如下的一个 action:

data class AddTodoAction(val text: String)

由 store 来进行分发:

store.dispatch(AddTodoAction("Write blog post"))

3. Reducers:进行状态的转变。类似这样:

fun reduce(oldState: AppState, action: Action) : AppState {
  return when (action) {
    is AddToDoAction -> {
      oldState.copy(todo = ...)
    }
    else -> oldState
  }
}

介绍完核心组件,下面来看一下它们是怎么组合到一起的:

Redux 的流程很简单,你的应用根据当前状态呈现 UI,用户的交互触发 action,并交给 reducer 来更新状态。

最近,作者在一个还挺大的项目上试了下 Redux 架构,所以这里就分享下从中总结的一些经验。

1. 应用里最好不要有多个 store

针对不同模块有不同的 store 似乎是个不错的主意,但从上面的图可以看到每个 store 和其数据流是一个闭环系统,这就使得不同 store 之间的状态难以同步。这样你就通常需要在一个状态的变更响应中去进行另一个 store 的 action 分发,而这很容易造成无限循环。

另一个原因是多 store 的架构是非常僵化的,难以灵活的改动。

更好的做法是维护一个包含多个子状态的全局应用状态,由一个 store 来表示:

data class AppState(val LoginState,
          val HomeScreenState,
          val GridState )

2. 保持应用的状态层级尽可能少

因为 Redux 中 state 是不可变的,因此深层次嵌套的 state 会产生很多的样板代码,并且难以更新。比如,考虑下面的一组数据模型

data class State(val sections: List<Section>)
open class Section(val articles: List<Article>)
class Home(articles: List<Article>) : Section(articles)
class Discover(articles: List<Article>) : Section(articles)
class Article

实例化和更新状态对象:

val state = State(sections = listOf(
         Home(listOf(article1, article2)),
         Discover(listOf(article1, article2))))

即使是用了 Kotlin 的 copy 机制,更新深层嵌套的属性(比如上面的 Article)也是非常单调乏味的:

val newHome = Home(listOf(newArticle, state.sections[0].articles[1]))
state.copy(sections = listOf(newHome, state.sections[1]))

3. Reducers 只是纯函数

Reduce 的作用只是处理 action 并返回新的 state 到 store 的,需要保证相同的输入总会得到一样的输出。Reduce 自身不应该有状态和执行任何额外工作,而只是做状态转换。

class Reducer {
  fun reduce(state: State, action: Action) : State {
    ...
  }
}

如果你需要响应某个 action,并执行一些操作,那应该考虑使用 Middleware。

4. 只用 Kotlin

Redux 很大部分受到 Flux 的启发,而关于 Flux 最常见的抱怨就是需要写一大堆的样板代码。而所选择的语言很大程度会决定你管理样板代码的便利性。

Kotlin 中类似 data class,when 语句之类的特性,能让你的代码清晰很多。例如,在 Reducer 中匹配 action 时,可以选择用 instanceof 方法实现。

if (action instanceof AddTodoAction) {
  return reduceAddTodoAction(oldState, action);
} else if (action instanceof RemoveTodoAction) {
  return reduceRemoveTodoAction(oldState, action);
} else if (...) {
  ...
}
return oldState;

当 action 很多时,这种写法就很痛苦了。如果用 Kotlin 就是这样的:

return when (action) {
  is AddTodoAction -> reduceAddTodoAction(oldState, action)
  is RemoveTodoAction -> reduceRemoveTodoAction(oldState, action)
  else -> oldState
}

结论

虽然,Redux 主要是被用于 Web 应用开发,但其思想我们还是可以学习并引入到 Android 中。但 Redux 也不是「银弹」,事实上也没有什么架构是,其在 Android 上的应用还很新,但我们还是很希望能看到它的逐渐成熟。

(0)

相关推荐

  • 详解Android中实现Redux方法

    Redux 是一个用于应用程序状态管理的开源JavaScript库,其核心是通过可管理和控制的状态来描述一个系统.这意味着其思想其实是可以应用于任何类型应用的开发的,包括移动应用. Redux 架构基于一个严格的单向数据流,应用中的所有数据都是通过组件在一个方向上流动.Redux 希望确保应用的视图是根据确定的状态来呈现的.意思就是,在任何时间点,你应用的状态总是确定.有效的,并且可以转换到另一个可预测和有效的状态.而 UI 将根据所处的状态来进行呈现. 关于 Redux 在网上已经有很多相关的

  • 详解Android中Intent对象与Intent Filter过滤匹配过程

    如果对Intent不是特别了解,可以参见博文<详解Android中Intent的使用方法>,该文对本文要使用的action.category以及data都进行了详细介绍.如果想了解在开发中常见Intent的使用,可以参见<Android中Intent习惯用法>. 本文内容有点长,希望大家可以耐心读完. 本文在描述组件在manifest中注册的Intent Filter过滤器时,统一用intent-filter表示. 一.概述 我们知道,Intent是分两种的:显式Intent和隐式

  • 详解 Android中Libgdx使用ShapeRenderer自定义Actor解决无法接收到Touch事件的问题

    详解 Android中Libgdx使用ShapeRenderer自定义Actor解决无法接收到Touch事件的问题 今天在项目中实现了一个效果,主要是画一个圆.为了后续使用方便,将这个圆封装在一个自定义Actor(CircleActot)中,后续想显示一个圆的时候,只要创建一个CircleActor中即可. 部分代码如下所示: package com.ef.smallstar.unitmap.widget; import android.content.res.Resources; import

  • 详解Android中图片的三级缓存及实例

    详解Android中图片的三级缓存及实例 为什么要使用三级缓存 如今的 Android App 经常会需要网络交互,通过网络获取图片是再正常不过的事了 假如每次启动的时候都从网络拉取图片的话,势必会消耗很多流量.在当前的状况下,对于非wifi用户来说,流量还是很贵的,一个很耗流量的应用,其用户数量级肯定要受到影响 特别是,当我们想要重复浏览一些图片时,如果每一次浏览都需要通过网络获取,流量的浪费可想而知 所以提出三级缓存策略,通过网络.本地.内存三级缓存图片,来减少不必要的网络交互,避免浪费流量

  • 详解Android中的Service

    Service简介: Service是被设计用来在后台执行一些需要长时间运行的操作. Android由于允许Service在后台运行,甚至在结束Activity后,因此相对来说,Service相比Activity拥有更高的优先级. 创建Service: 要创建一个最基本的Service,需要完成以下工作:1)创建一个Java类,并让其继承Service 2)重写onCreate()和onBind()方法 其中,onCreate()方法是当该Service被创建时执行的方法,onBind()是该S

  • 详解Android中Handler的内部实现原理

    本文主要是对Handler和消息循环的实现原理进行源码分析,如果不熟悉Handler可以参见博文<详解Android中Handler的使用方法>,里面对Android为何以引入Handler机制以及如何使用Handler做了讲解. 概括来说,Handler是Android中引入的一种让开发者参与处理线程中消息循环的机制.我们在使用Handler的时候与Message打交道最多,Message是Hanlder机制向开发人员暴露出来的相关类,可以通过Message类完成大部分操作Handler的功

  • 详解Android 中AsyncTask 的使用

    详解Android 中AsyncTask 的使用 1.首先我们来看看AsyncTask 的介绍:   Handler 和 AsyncTask 都是android 中用来实现异步任务处理的方式:其中: Handler 实例向 UI 线程发送消息,完成界面更新, 优点:对整个过程控制的比较精细:         缺点:代码相对臃肿,多个任务同时执行时,不易对线程进行精确的控制: AsyncTask :比Handler 更轻量级一些,适用于简单的异步处理: 优点:简单 | 快捷 | 过程可控:    

  • 详解Android中获取软键盘状态和软键盘高度

    详解Android中获取软键盘状态和软键盘高度 应用场景 在Android应用中有时会需要获取软键盘的状态(即软键盘是显示还是隐藏)和软键盘的高度.这里列举了一些可能的应用场景. 场景一 当软键盘显示时,按下返回键应当是收起软键盘,而不是回退到上一个界面,但部分机型在返回键处理上有bug,按下返回键后,虽然软键盘会自动收起,但不会消费返回事件,导致Activity还会收到这次返回事件,执行回退操作,这时就需要判断,如果软键盘刚刚由显示变为隐藏状态,就不执行回退操作. 场景二 当软键盘弹出后,会将

  • 详解Android中fragment和viewpager的那点事儿

    在之前的博文<Android 中使用 ViewPager实现屏幕页面切换和页面轮播效果>和<详解Android中Fragment的两种创建方式>以及<Android中fragment与activity之间的交互(两种实现方式)>中我们介绍了ViewPager以及Fragment各自的使用场景以及不同的实现方式. 那如果将他们两结合起来,会不会擦出点火花呢,答案是肯定的.之前在介绍ViewPager时,我们实现了多个ImageView的切换,并配合更新导航原点的状态.那我

  • 详解Android中PopupWindow在7.0后适配的解决

    本文介绍了详解Android中PopupWindow在7.0后适配的解决,分享给大家,具体如下: 这里主要记录一次踩坑的经历. 需求:如上图左侧效果,想在按钮的下方弹一个PopupWindow.嗯,很简单一个效果,然当适配7.0后发现这个PopupWindow显示异常,然后网上找到了下面这种方案. 7.0适配方案(但7.1又复现了) // 将popupWindow显示在anchor下方 public void showAsDropDown(PopupWindow popupWindow, Vie

随机推荐