19

从0开始设计Flutter独立APP | 第一篇: 数据库与状态管理

 3 years ago
source link: https://segmentfault.com/a/1190000022962365
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

鉴于Flutter高性能渲染和跨平台的优势,闪点清单在移动端APP上,使用了完整的Flutter框架来开发。既然是完整APP,架构搭建完全不受历史Native APP的影响,没有历史包袱的沉淀,设计也能更灵活和健壮。

Az2Unui.png!web

首先列举部分闪点清单的业务特性(较为通用的业务特性):

  1. 本地有较大数据量的清单数据,离线可用,未登录可用;登录后需要服务器数据同步
  2. 状态变更场景多,前端状态逻辑较为复杂,跨页面、跨组件状态更新频繁

这几个业务点,设计到的技术选型有:本地数据库、前端状态管理,对很多业务来说,这几点都是比较核心的东西,也是我们今天重点要讲的内容。

数据库选型

数据库选型,首先要定的,就是选择数据库类型:关系型数据库、非关系型数据库还是Key/Value存储。

对于关系型数据库,可选的有比如:SQLite、Core Data、GreenDao等;对于非关系型数据库,可选有Realm、UnQLite等;对于Key/Value存储,有比如Redis、Berkeley DB、Level DB等。

由于业务形态具有复杂的查询场景,所以首先排除了Key/Value存储;然后鉴于业务迭代频繁,数据结构变动较大,所以完全的关系型数据库使用成本会较高,版本更新时在数据兼容和数据清洗方面要做较多的工作;所以我们采用了NoSQL数据库,或者支持JSON类型的关系型数据库。

Flutter目前在NoSQL上的可选项并不多,Realm、UnQLite等均未支持(当然可以通过Flutter FFI来封装给Dart用,但成本过高);Flutter的sqflite插件可以较好地支持SQLite,但由于SQLite在3.9以后才支持JSON数据,考虑到Android版本( Android各版本使用的SQLite版本文档 )兼容问题,我们并没有采用sqflite;我们最终采用的数据库是 Sembast ,一个还比较小众,但性能和API建设都还不错的NoSQL数据库。

nIRBVj.png!web

Sembast介绍

Sembast API很简洁,但能支持较复杂的数据库操作。

在数据查询上,能够通过简单的逻辑API,通过聚合构造出复杂的逻辑查询语句;数据排序实现也比较完整,支持多字段排序(但不支持bool类型排序);对事务操作也有支持;支持整型自增key。

Sembast部分API预览

var store = intMapStoreFactory.store('animals');

// 事务处理
await db.transaction((txn) async {
  await store.add(txn, {'name': 'fish'});
  await store.add(txn, {'name': 'cat'});
  await store.add(txn, {'name': 'dog'});
});

// 数据查询
var finder = Finder(
    filter: Filter.greaterThan('name', 'cat'),
    sortOrders: [SortOrder('name')]);
var records = await store.find(db, finder: finder);

expect(records.length, 2);
expect(records[0]['name'], 'dog');
expect(records[1]['name'], 'fish');

但由于对小众数据库前途的担忧考虑,我们设计了便于迁移的数据架构,对数据操作层做了一层抽象,后期如果迁移数据库,业务层可以完全不需要改动。

状态管理选型

状态管理,在如今的前端技术中,是非常重要的一环,好的状态管理框架,可以让业务更好得解耦、简化组件数据通讯成本、大幅提升开发体验。我们在状态管理选型上花了较多的时间来对比各种方案,比如: providerblocreduxscoped_modelmobx 、甚至业界网红团队的 fish-redux 。我们最终采用的是mobx,关于各个方案的对比,一篇文章讲不完,我们最终选择mobx,更多是因为它的API更友好。

Mobx采用注解的方式来定义状态,并封装了一个Widget用于Widget的数据更新,学习、使用成本较低。

3eUzaey.png!web

注解定义

Mobx的注解使用方式,与Web中的Vue非常类似如:

  1. 使用@observable来注解一个属性,表示其需要被监听,Mobx会自动为其添加getter和setter
  2. 使用@computed来注解一个计算属性
  3. 使用@action来注解一个修改store的方法,类似于Vuex里的mutations

示例代码:

import 'package:mobx/mobx.dart';

part 'counter.g.dart';

class Counter = CounterBase with _$Counter;

abstract class CounterBase with Store {
  @observable
  int value = 0;

  @computed
  int get allowCount {
    return value*2;
  }

  @action
  void increment() {
    value++;
  }
}

使用Mobx必须的一个步骤,就是前置编译步骤。我们编写Mobx的状态脚本,需要在前置编译环节,编译成dart可读的脚本,为此我们需要执行 flutter pub run build_runner build 生成 .g.dart 为后缀的文件(其实就是将注解转义为getter和setter)。

UI更新方式

UI更新方式

需要使用Mobx的Widget,使用Observer包装一层,这样其就可以相应Mobx的状态变化,如:

Observer(
  builder: (context) => Text('昵称: ${userStore.user.username}'),
)

前置编译脚本

Dart在编译时和运行时均无法支持注解,所以Mobx使用了前置编译脚本解析注解动态生成Dart代码的方式(Dart官方支持)。Mobx注解方式使用前,需要为项目添加 build_runnermobx_codegen 依赖。 build_runner 为Dart官方提供,用于在构建项目之前执行特定任务,任务配置于依赖库的 build.yaml 脚本中; mobx_codegen 依赖于该 build_runner 将注解生成可执行的Dart代码(如添加getter和setter方法)。

结尾

状态管理和数据库,是前端项目基础框架的重要环节,设计好了可以很好地提升开发体验和效率,降低后续开发维护成本。

讲到这里,还并没有完成基础框架的搭建,后面我们会讲解更多的Flutter架构设计内容,比如:国际化、通知、分享、UI设计等等。

持续分享 闪点清单 在Flutter上的开发经验。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK