共计 17600 个字符，预计需要花费 44 分钟才能阅读完成。
这是第 86 篇不掺水的原创，想获取更多原创好文，请搜寻公众号关注咱们吧~ 本文首发于政采云前端博客：【Flutter 技能篇】你不得不会的状态治理 Provider
前言
Provider，Google 官网举荐的一种 Flutter 页面状态治理组件，它的本质其实就是对 InheritedWidget 的包装，使它们更易于应用和重用。对于 InheritedWidget 不做过多介绍，本篇文章次要较全面地介绍 Provider 的相干用法，能在业务场景中有所使用。
本篇文章示例源码：https://github.com/xiaomanzijia/FlutterProvider
用法
Step1: 增加依赖
dependencies:
flutter:
sdk: flutter
# The following adds the Cupertino Icons font to your application.
# Use with the CupertinoIcons class for iOS style icons.
provider: ^4.0.4Step2: 察看构造
执行 flutter pub get 后，能够在工程看到 provider 的 sdk 源码，构造如下：
Step3: 示例简介
本示例将解说 Provider 根底组件的应用，包含但不限于 ChangeNotifier, NotifierProvider, Consumer, Selector, ProxyProvider, FutureProvider, StreamProvider。
Step4: 创立一个 ChangeNotifier
咱们先新建一个 Model1，继承 ChangeNotifier，使之成为咱们的数据提供者之一。
class Model1 extends ChangeNotifier {
int _count = 1;
int get count => _count;
set count(int value) {
_count = value;
notifyListeners();}
}追踪 ChangeProvider 源码，咱们发现它并不属于 Provider，它其实是定义在 Flutter SDK foundation 上面的 change_provider.dart 文件。ChangeNotifier 实现了 Listenable 抽象类，外面保护了一个 ObserverList。
Listenable 类源码：
abstract class Listenable {const Listenable();
factory Listenable.merge(List<Listenable> listenables) = _MergingListenable;
void addListener(VoidCallback listener);
void removeListener(VoidCallback listener);
}能够看出，次要提供了 addListener 和 removeListener 两个办法。
ChangeNotifier 类源码：
class ChangeNotifier implements Listenable {ObserverList<VoidCallback> _listeners = ObserverList<VoidCallback>();
bool _debugAssertNotDisposed() {assert(() {if (_listeners == null) {
throw FlutterError.fromParts(<DiagnosticsNode>[ErrorSummary('A $runtimeType was used after being disposed.'),
ErrorDescription('Once you have called dispose() on a $runtimeType, it can no longer be used.')
]);
}
return true;
}());
return true;
}
@protected
bool get hasListeners {assert(_debugAssertNotDisposed());
return _listeners.isNotEmpty;
}
void addListener(VoidCallback listener) {assert(_debugAssertNotDisposed());
_listeners.add(listener);
}
@override
void removeListener(VoidCallback listener) {assert(_debugAssertNotDisposed());
_listeners.remove(listener);
}
@mustCallSuper
void dispose() {assert(_debugAssertNotDisposed());
_listeners = null;
}
@protected
@visibleForTesting
void notifyListeners() {assert(_debugAssertNotDisposed());
if (_listeners != null) {final List<VoidCallback> localListeners = List<VoidCallback>.from(_listeners);
for (VoidCallback listener in localListeners) {
try {if (_listeners.contains(listener))
listener();} catch (exception, stack) {
FlutterError.reportError(FlutterErrorDetails(
exception: exception,
stack: stack,
library: 'foundation library',
context: ErrorDescription('while dispatching notifications for $runtimeType'),
informationCollector: () sync* {
yield DiagnosticsProperty<ChangeNotifier>(
'The $runtimeType sending notification was',
this,
style: DiagnosticsTreeStyle.errorProperty,
);
},
));
}
}
}
}
}除了实现 addListener 和 removeListener 外，还提供了 dispose 和 notifyListeners 两个办法。Model1 中，当咱们更改 count 值时，就会调用 notifyListeners 办法告诉 UI 更新。
Step5: 创立 ChangeNotifierProvider
示例简介
形式一：通过 ChangeNotifierProvider
return ChangeNotifierProvider(create: (context) {return Model1();
},
child: MaterialApp(
theme: ArchSampleTheme.theme,
home: SingleStatsView(),),
);这里通过 ChangeNotifierProvider 的 create 把 ChangeNotifier（即 Model1）建立联系，作用域的范畴在 child 指定的 MaterialApp，这里咱们将 SingleStatsView 作为首页，SingleStatsView 外面应用了 Model1 作为数据源。须要留神的是，不要把所有状态的作用域都放在 MaterialApp，依据理论业务需要严格控制作用域范畴，全局状态多了会重大影响利用的性能。
class SingleStatsView extends StatelessWidget {
@override
Widget build(BuildContext context) {
return Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: <Widget>[
FlatButton(
color: Colors.blue,
child: Text('Model1 count++'),
onPressed: () {Provider.of<Model1>(context, listen: false).count++;
},
),
Padding(padding: const EdgeInsets.only(bottom: 8.0),
child: Text('Model count 值变动监听',
style: Theme.of(context).textTheme.title),
),
Padding(padding: const EdgeInsets.only(bottom: 8.0),
child: Text('Model1 count:${Provider.of<Model1>(context).count}',
style: Theme.of(context)
.textTheme
.subhead
.copyWith(color: Colors.green)),
),
],
),
);
}
}形式二：通过 ChangeNotifierProvider.value
return ChangeNotifierProvider.value(value: Model1(),
child: MaterialApp(
theme: ArchSampleTheme.theme,
home: SingleStatsView(),));能够看出，和形式一相差无几，形式一用的 create 创立的 ChangeNotifier，这里用的 value 创立。追溯 ChangeNotifierProvider 源码：
class ChangeNotifierProvider<T extends ChangeNotifier> extends ListenableProvider<T> {static void _dispose(BuildContext context, ChangeNotifier notifier) {notifier?.dispose();
}
ChangeNotifierProvider({
Key key,
@required Create<T> create,
bool lazy,
Widget child,
}) : super(
key: key,
create: create,
dispose: _dispose,
lazy: lazy,
child: child,
);
ChangeNotifierProvider.value({
Key key,
@required T value,
Widget child,
}) : super.value(
key: key,
value: value,
child: child,
);
}Step6: 在页面中监听状态变更，其余应用形式
示例
咱们先理解下 ValueListenableBuilder，它能够监听指定值的变动进行 UI 更新，用法如下：
ValueNotifier
1. 新建 ValueNotifier
final ValueNotifier<int> _counter = ValueNotifier<int>(0);在 builder 办法将之指定到 Model1 的 count，这样当 Model1 中的 count 变动时 _counter 也能监听到。
_counter.value = Provider.of<Model1>(context).count;2. 关联 ValueListenableBuilder
ValueListenableBuilder 的 valueListenable 能够绑定一个 ValueNotifier，用于监听 ValueNotifier 的值变动。
ValueListenableBuilder(
valueListenable: _counter,
builder: (context, count, child) => Text('ValueListenableBuilder count:$count'),
),ValueNotifier 源码：
class ValueNotifier<T> extends ChangeNotifier implements ValueListenable<T> {ValueNotifier(this._value);
@override
T get value => _value;
T _value;
set value(T newValue) {if (_value == newValue)
return;
_value = newValue;
notifyListeners();}
@override
String toString() => '${describeIdentity(this)}($value)';
}能够看出，ValueNotifer 也是继承 ChangeNotifier，并实现了 ValueListenable，特别之处是在 set value 的时候调用了 notifyListeners，从而实现了状态变更监听。
MultiProvider
示例简介
一旦业务场景简单，咱们的页面可能须要监听多个 ChangeNotifier 的数据源，这时候 MultiProvider 就派上用场了。该示例在 SingleStatsView 上进行了扩大，这里咱们新建一个 MultiStatsView，监听 Model1 和 Model2 的数据变动。
Model2
class Model2 extends ChangeNotifier {
int _count = 1;
int get count => _count;
set count(int value) {
_count = value;
notifyListeners();}
}MultiStatsView
class MultiStatsView extends StatelessWidget {
@override
Widget build(BuildContext context) {
return Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: <Widget>[
FlatButton(
color: Colors.blue,
child: Text('Model1 count++'),
onPressed: () {Provider.of<Model1>(context, listen: false).count++;
},
),
FlatButton(
color: Colors.blue,
child: Text('Model2 count++'),
onPressed: () {Provider.of<Model2>(context, listen: false).count++;
},
),
Padding(padding: const EdgeInsets.only(bottom: 8.0),
child: Text('Model count 值变动监听',
style: Theme.of(context).textTheme.title),
),
Padding(padding: const EdgeInsets.only(bottom: 8.0),
child: Text('Model1 count:${Provider.of<Model1>(context).count}',
style: Theme.of(context)
.textTheme
.subhead
.copyWith(color: Colors.green)),
),
Padding(padding: const EdgeInsets.only(bottom: 24.0),
child: Text('Model2 count:${Provider.of<Model2>(context).count}',
style: Theme.of(context)
.textTheme
.subhead
.copyWith(color: Colors.red)),
),
],
),
);
}
}应用 MultiProvider 关联 MultiStatsView，能够看出 MultiProvider 提供了 providers 数组，咱们能够把 ChangeNotifierProvider 放进去。
return MultiProvider(
providers: [ChangeNotifierProvider.value(value: Model1()),
ChangeNotifierProvider.value(value: Model2()),
],
child: MaterialApp(
theme: ArchSampleTheme.theme,
localizationsDelegates: [ArchSampleLocalizationsDelegate(),
ProviderLocalizationsDelegate(),],
home: MultiStatsView(),),
);若针对 MultiStatsView 仅提供 Model1 关联的 ChangeNotifierProvider，你会看到如下报错：
══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞═══════════════════════════════════════════════════════════
The following ProviderNotFoundException was thrown building MultiStatsView(dirty, dependencies:
[_LocalizationsScope-[GlobalKey#48c61], _InheritedTheme, _DefaultInheritedProviderScope<Model1>]):
Error: Could not find the correct Provider<Model2> above this MultiStatsView Widget
To fix, please:
* Ensure the Provider<Model2> is an ancestor to this MultiStatsView Widget
* Provide types to Provider<Model2>
* Provide types to Consumer<Model2>
* Provide types to Provider.of<Model2>()
* Ensure the correct `context` is being used.这是因为 Model2 没有注册导致。
ProxyProvider
从 3.0.0 开始，开始提供 ProxyProvider。ProxyProvider 能够将其余 provider 的值聚合为一个新对象，并且将后果传递给Provider。新对象会在其依赖的宿主 provider 更新后被更新。
新建一个 User 类
class User {
var name;
User(this.name);
}咱们把 Model1 通过 ProxyProvider 聚合成 User 对象，而后取 User 对象中的 name 进行渲染。s
ProxyProvider<Model1, User>(update: (context, value, previous) => User("change value ${value.count}"),
builder: (context, child) => Text('ProxyProvider: ${Provider.of<User>(context).name}',
style: Theme.of(context).textTheme.title),
)能够看出，通过 ProxyProvider 形式，咱们间接调用 Provider.of<User>(context) 取值，关联 User 的 Provider 咱们并没有注册，也能无效运行。
FutureProvider
通过名字能够看出，这个 Provider 和异步执行无关，用法相似于 FutureBuilder。这里用FutureProvider 模仿 2 秒后更新 Model1 的初始值。能够在 initialData 指定初始值，create 办法指定具体的异步工作，builder 办法中能够用 Provider.of 取出异步工作执行返回的值进行页面渲染。还能够定义 catchError 捕捉异样，updateShouldNotify比拟新旧值是否 rebuild，新的 create/update 回调函数是懒加载的，也就是说它们在对应的值第一次被读取的时候才被调用，而非 provider 首次被创立时。如果不须要这个个性，能够将 lazy 属性值置为 false。
FutureProvider<Model1>(create: (context) {return Future.delayed(Duration(seconds: 2))
.then((value) => Model1()..count = 11);
},
initialData: Model1(),
builder: (context, child) => Text('FutureProvider ${Provider.of<Model1>(context).count}',
style: Theme.of(context).textTheme.title),
),StreamProvider
通过名字能够看出，StreamProvider也是一个异步执行无关的 Provider，用法相似于 StreamBuilder。这里用 StreamProvider 模仿每隔 1 秒更新 Model1 的初始值。其余参数和 FutureProvider 用法相似。
StreamProvider(create: (context) {return Stream.periodic(Duration(seconds: 1), (data) => Model1()..count = data);
},
initialData: Model1(),
builder: (context, child) => Text('StreamProvider: ${Provider.of<Model1>(context).count}',
style: Theme.of(context).textTheme.title),
),Consumer
具体用法如下，builder 中的参数别离是 Context context，T value, Widget child，value 即 Model1，value 的类型和 Model1 类型统一，builder 办法返回的是 Widget，也就是被 Consumer 包裹的 widget，当监听的 model 值产生扭转，此 widget 会被 Rebuild。
Consumer<Model1>(builder: (context, model, child) {return Text('Model1 count:${model.count}');
},
)Selector
能够看出，Selector 和 Consumer 很类似，惟一不同的是，Selector 能够自定义返回类型，如下 Selector，咱们这里监听 Model1 中的 count 变动，所以这里返回类型定义为 Int 类型。其中 builder 办法中的参数别离是 Context context, T value, Widget child，这里的 value 的类型和 Selector 中定义的返回类型统一。builder 办法返回的是 Widget，也就是被 Selector 包裹的 widget，咱们能够指定监听 ChangeNotifier 中的某个值的变动，从而可触发此 widget Rebuild。
Selector<Model1, int>(builder: (context, count, child) => Text(
"Selector 示例演示: $count",
style: Theme.of(context).textTheme.title,
),
selector: (context, model) => model.count,
),源码：
class Selector<A, S> extends Selector0<S> {
Selector({
Key key,
@required ValueWidgetBuilder<S> builder,
@required S Function(BuildContext, A) selector,
ShouldRebuild<S> shouldRebuild,
Widget child,
}) : assert(selector != null),
super(
key: key,
shouldRebuild: shouldRebuild,
builder: builder,
selector: (context) => selector(context, Provider.of(context)),
child: child,
);
}能够看出 Selector 继承自 Selector0，追踪 Selector0 源码，它通过 buildWithChild 创立 Widget
class _Selector0State<T> extends SingleChildState<Selector0<T>> {
T value;
Widget cache;
Widget oldWidget;
@override
Widget buildWithChild(BuildContext context, Widget child) {final selected = widget.selector(context);
var shouldInvalidateCache = oldWidget != widget ||
(widget._shouldRebuild != null && widget._shouldRebuild.call(value, selected)) ||
(widget._shouldRebuild == null && !const DeepCollectionEquality().equals(value, selected));
if (shouldInvalidateCache) {
value = selected;
oldWidget = widget;
cache = widget.builder(
context,
selected,
child,
);
}
return cache;
}
}这里的 A，S，能够看出 A 是 selector 函数的入参，S 是函数的返回值，这里将 A 通过 Provider.of(context) 转换成了 Provider。比照上述 Selector 的例子，这里的 A 对应 Model1，S 对应 count。这里还有一个 shouldRebuild，看看函数的定义：
typedef ShouldRebuild<T> = bool Function(T previous, T next);通过比拟前一个值和以后值，决定是否从新 rebuild 页面，如果返回 true，则页面会被从新渲染一次，返回 false，页面不会被从新渲染。具体判断逻辑能够参考 _Selector0State 的 buildWithChild 办法。
能够看出，绝对于 Consumer，Selector 放大了数据监听的范畴，并且能够依据本身的业务逻辑自定义是否刷新页面，从而防止了很多不必要的页面刷新，从而进步了性能。
在 Provider SDK 代码构造的 selector.dart 文件里，能够看出还定义了 Selector2、Selector3、Selector4、Selector5、Selector6。这里以 Selector2 做示例解说其用法：
class Selector2<A, B, S> extends Selector0<S> {
Selector2({
Key key,
@required ValueWidgetBuilder<S> builder,
@required S Function(BuildContext, A, B) selector,
ShouldRebuild<S> shouldRebuild,
Widget child,
}) : assert(selector != null),
super(
key: key,
shouldRebuild: shouldRebuild,
builder: builder,
selector: (context) => selector(
context,
Provider.of(context),
Provider.of(context),
),
child: child,
);
}能够看出，Selector2 同样也是继承了 Selector0，不同的是 selector 函数有了两个入参 A 和 B，S 是函数的返回值。也就是说能够通过 Selector2 监听 2 个 Provider，能够从这 2 个 Provider 中自定义 S 的值变动监听。其余 Selector 只是监听的 Provider 更多罢了。如果大于 6 个 Provider 须要监听，就须要自定义 Selector 办法了。
示例中咱们用 Selector2 同时监听 Model1 和 Model2 的变动，对两个 Model 中的 count 进行加和计算。
Selector2<Model1, Model2, int>(selector: (context, model1, model2) {return model1.count + model2.count;},
builder: (context, totalCount, child) {
return Text('Model1 和 Model2 count 共计:$totalCount');
}Selector3, Selector4…，还有 Consumer2，Consumer3…，这里就不做赘述了。
Consumer 和 Selector 性能验证
通过下面的示例，咱们曾经对 Consumer 和 Selector 有所理解。Consumer 能够防止 widget 多余的 rebuild，当 Consumer 中监听的 value 不发生变化，其包裹的 widget 不会 Rebuild。Selector 在 Consumer 根底上提供了更加准确的监听，还反对自定义 rebuild，能够更加灵便地管制 widget rebuild 问题。
上面咱们一起来验证下 Consumer 和 Selector rebuild 的状况。Step3 图示中，咱们定义了两个按钮，一个用于累加 Model1 中的 count，一个用于累加 Model2 中的 count；同时演示了 Selector2 和 Consumer 的用法；定义了 Widget1，Widget2，带 Selector 的 Widget4，用于验证 rebuild 状况。Model1 的 count 值用绿色标识，Model2 的 count 值用红色标识。
本篇文章示例源码：https://github.com/xiaomanzijia/FlutterProvider
Widget1, 在 build 办法中打印“Widget1 build”。
class Widget1 extends StatefulWidget {
@override
State<StatefulWidget> createState() => StateWidget1();
}
class StateWidget1 extends State<Widget1> {
@override
Widget build(BuildContext context) {print('Widget1 build');
return Text('Widget1', style: Theme.of(context).textTheme.subhead);
}
}Widget2, 在 build 办法中打印 “Widget2 build”。
Widget3, 监听了 Model2 count 变动，在 builder 办法中打印“Widget3 build”。
Widget4，在 build 办法中打印 “Widget4 build”，build 办法返回一个 Selector，在 Selector 的 builder 办法中打印“Widget4 Selector build”，Selector 监听 Model1 count 变动。
class Widget4 extends StatefulWidget {
@override
State<StatefulWidget> createState() => StateWidget4();
}
class StateWidget4 extends State<Widget4> {
@override
Widget build(BuildContext context) {print('Widget4 build');
return Selector<Model1, int>(builder: (context, count, child) {print('Widget4 Selector build');
return Text('Widget4 Model1 count:$count', style: Theme.of(context).textTheme.subhead.copyWith(color: Colors.green),);
},
selector: (context, model) => model.count,
);
}
}所有条件具备，咱们运行 StatsView 页面，日志打印如下：
Selector2 build
Model1 Consumer build
Model2 Consumer build
Widget1 build
Widget2 build
Widget3 build
Widget4 build
Widget4 Selector build能够看出，widget 渲染程序是依据页面元素布局程序从上到下开始渲染。
点击 Model1 count++ 按钮，能够看到所有绿色标识的中央，count 已更新。日志打印如下：
Selector2 build
Model1 Consumer build
Model2 Consumer build
Widget1 build
Widget2 build
Widget3 build
Widget4 build
Widget4 Selector build啥！！！怎么和第一次加载页面日志一样，更新 Model1 的 count，不应该只 build 监听 Model1 相干的 widget 吗？咱们改下代码，把 Widget4 作为全局变量，在 initState 的时候初始化。
class StateStatsView extends State<StatsView> {final ValueNotifier<int> _counter = ValueNotifier<int>(0);
var widget4;
@override
void initState() {widget4 = Widget4();
super.initState();}
@override
Widget build(BuildContext context) {_counter.value = Provider.of<Model1>(context).count;
return Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: <Widget>[
..., // 此处省略局部实例源码
Widget1(),
Widget2(),
Widget3(),
widget4,
],
),
);
}
}运行后再次点击 Model1 count++ 按钮，日志打印如下：
Selector2 build
Model1 Consumer build
Model2 Consumer build
Widget1 build
Widget2 build
Widget3 build
Widget4 Selector build能够看到，“Widget4 build”的日志不会再打印，然而“Widget4 Selector build”的日志仍在打印。咱们再改下代码，把 Widget4 中的 selector 作为全局变量，在 initState 的时候初始化。
class Widget4 extends StatefulWidget {
@override
State<StatefulWidget> createState() => StateWidget4();
}
class StateWidget4 extends State<Widget4> {
Selector<Model1, int> selector;
@override
void initState() {selector = buildSelector();
super.initState();}
@override
Widget build(BuildContext context) {print('Widget4 build');
return selector;
}
Selector<Model1, int> buildSelector() {
return Selector<Model1, int>(builder: (context, count, child) {print('Widget4 Selector build');
return Text('Widget4 Model1 count:$count', style: Theme.of(context).textTheme.subhead.copyWith(color: Colors.green),);
},
selector: (context, model) => model.count,
);
}
}运行后再次点击 Model1 count++ 按钮，日志打印如下：
Selector2 build
Model1 Consumer build
Model2 Consumer build
Widget1 build
Widget2 build
Widget3 build能够看到，“Widget4 Selector build”的日志没有打印了，Widget4 中监听的 Model1 中的 count 也失常更新了。
通过后面 3 步的验证，咱们能够得悉 当 ChangeNotifier（这里即 Model1）告诉更新（notifyListener）时，在 Model1 作用域下的 Widget 都会触发 build，Selector，Consumer 本质也就是一个 Widget，当咱们的数据须要 Selector 或 Consumer 包裹时，倡议在 initState 的时候先把 widget 创立好，能够防止不必要的 build。
其余
1.listen
如果咱们把“Model1 count++”按钮点击事件代码改下
FlatButton(
color: Colors.blue,
child: Text('Model1 count++'),
onPressed: () {Provider.of<Model1>(context).count++;
},
),区别在于少了 listen:false，点击按钮你会看到上面的谬误日志：
Tried to listen to a value exposed with provider, from outside of the widget tree.
This is likely caused by an event handler (like a button's onPressed) that called
Provider.of without passing `listen: false`.
To fix, write:
Provider.of<Model1>(context, listen: false);
It is unsupported because may pointlessly rebuild the widget associated to the
event handler, when the widget tree doesn't care about the value.官网正文页对 listen 做了阐明，listen=true，意味着被监听的 ChangeNotifier 中的值发生变化，对应的 widget 就会被 rebuild，listen=false，则不会被 rebuild。在 widget 树外调用 Provider.of 办法，必须加上 listen:false。
2. 扩大
Provider 从 4.1.0 版本开始反对了扩大办法，以后示例基于 4.0.5+1 解说，这里暂不做赘述，具体可看 Changelog。
| before | after |
|---|---|
| Provider.of(context, listen: false) | context.read() |
| Provider.of(context) | context.watch |
其余状态治理组件
| 组件 | 介绍 |
|---|---|
| Provider | 官网举荐，基于 InheritedWidget 实现 |
| ScopedModel | 基于 InheritedWidget 实现，和 Provider 原理和写法都很相似 |
| BLoC | 基于 Stream 实现的，该模式须要对响应式编程（比方 RxDart，RxJava）有肯定的了解。外围概念：输出事件Sink<Event> input，输入事件Stream<Data> output |
| Redux | Web 开发中 React 生态链中 Redux 包的 Flutter 实现，在前端比拟风行，一种单向数据流架构。外围概念：存储对象Store、事件操作Action、解决和散发事件Reducer、组件刷新View |
| Mobx | 原本是一个 JavaScript 的状态治理库，后迁徙到 dart 版本。外围概念：Observables、Actions、Reactions |
这里不对其余组件做赘述，读者有趣味能够钻研一下，理解其余组件的实现原理。
总结
本篇文章次要介绍了官网举荐应用的 Provider 组件，联合源码和平时业务开发过程中遇到的问题，介绍了几种罕用的应用形式，心愿大家能纯熟应用，在业务场景中能灵活运用。
举荐浏览
联合 React 源码，五分钟带你把握优先队列
编写高质量可保护的代码：组件的形象与粒度
招贤纳士
政采云前端团队（ZooTeam），一个年老富裕激情和创造力的前端团队，隶属于政采云产品研发部，Base 在风景如画的杭州。团队现有 40 余个前端小伙伴，平均年龄 27 岁，近 3 成是全栈工程师，妥妥的青年风暴团。成员形成既有来自于阿里、网易的“老”兵，也有浙大、中科大、杭电等校的应届新人。团队在日常的业务对接之外，还在物料体系、工程平台、搭建平台、性能体验、云端利用、数据分析及可视化等方向进行技术摸索和实战，推动并落地了一系列的外部技术产品，继续摸索前端技术体系的新边界。
如果你想扭转始终被事折腾，心愿开始能折腾事；如果你想扭转始终被告诫须要多些想法，却无从破局；如果你想扭转你有能力去做成那个后果，却不须要你；如果你想扭转你想做成的事须要一个团队去撑持，但没你带人的地位；如果你想扭转既定的节奏，将会是“5 年工作工夫 3 年工作教训”；如果你想扭转原本悟性不错，但总是有那一层窗户纸的含糊… 如果你置信置信的力量，置信平凡人能成就不凡事，置信能遇到更好的本人。如果你心愿参加到随着业务腾飞的过程，亲手推动一个有着深刻的业务了解、欠缺的技术体系、技术发明价值、影响力外溢的前端团队的成长历程，我感觉咱们该聊聊。任何工夫，等着你写点什么，发给 ZooTeam@cai-inc.com
