重构原因

技术栈原因

• RN不足之处
  • 开发体验差，android模拟器卡，真机会因为各种原因无法调试运行
  • 开源组件质量良莠不齐，经常break change，我们几次尝试升大版本都失败
  • 理论性能上限低，组件最终调用的是native的，安卓系统分布非常碎片化，大量的platform判断逻辑，兼容适配的成本高，表现很难统一。和Native通信只能是异步模型，导致如RecycleView这种高性能列表组件无法使用。动画实现也不理想。
• Flutter理论优势
  • Flutter继承了RN衣钵，但更进一步。它自己实现了UI引擎，从而真的可以是write once，run anywhere，是的，除了iOS，android，它还能写前端页面，Google未来融合Chromebook和Android的Fuchsia系统是运行Flutter app的。
  • Dev友好，开发是Jit模式，毫秒级hot reload，release是Aot，针对ABI优化编译成机器码，性能好
  • Flutter引擎没有历史包袱，直接面向最新的Vulkan和Metal封装，渲染效率更高。升级没有依赖，引擎维护者也可以做更彻底的优化。

业务原因

• 公司业务战略调整，ME暂时没有高优先级的业务需求。正所谓天晴时修房顶，这时候重构项目是科学的。
• 可以还技术债，也可以提高小伙伴的专业技能，为后面可能到来的业务挑战做好准备。

重构目标

• 软件指标（帧数，内存，CPU）
  • 帧数平均有10%提升
  • 运行内存有10%下降
  • 运行CPU有10%下降
• 业务指标（人天效能，稳定度）
  • 人天效能（对比RN）有50%以上提升
  • 核心模块高于50%的单元测试覆盖率
  • 上线前人均Bug数不大于5，上线后Crash率小于0.05%

重构结果

业务表现

• 计划履行率
  • 开发前有比较详细的任务分工，功能细化到人天，95%的story都能按期完成，开发过程可计划，可调控。
  • 开发计划表：https://shimo.im/sheet/gsWNVfO3BpMN9bGS/yWUJN
• 人均效能
  • RN的人天总数是3*（2018/8/23-2017/11/15）=843人天，
  • Flutter是6（2018/11/30-2018/9/8）=498人天，提升大概是843/498 -1 = *69.2%**
• 单元测试
  • 我们还实现了50%以上的单元测试覆盖率，此处会有截图（11/27前完成）

目的

1. 认识Flutter Redux局限性
2. 引入Middleware必要性
3. 全方位集成UT

Flutter Redux初代实现局限性

UT不好覆盖

1. 页面

初代实现一个页面的结构是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class XXXScreen extends StatefulWidget {
  @override
  _XXXScreenState createState() => _XXXScreenState();
}

class _XXXScreenState extends State<XXXScreen> {
  @override
  Widget build(BuildContext context) {
    return StoreConnector<AppState, _XXXViewModel>(
        converter: (store) => _XXXViewModel.fromStore(store),
        builder: (BuildContext context, _XXXViewModel vm) =>
            Container());
  }
}

会有两个问题：UI视图和Redux数据通用逻辑耦和在一起，无发通过mock数据来对UI进行UT；大家习惯套路代码，上来就是一个stful，不会想是不是stless更科学点（事实上初代实现80%的Screen是Statefull的，重构后90%都能写成Stateless，提升了页面刷新效率）。

2. API call

我们的API就是一个静态方法：

Flutter Theme

主题（Theme）在软件开发里属于高级追求，Mac OS经过多年演化后终于在macOS Mojave中加入深色主题，可以让你做起事来更专注。

作用

• 取悦用户，白菜萝卜给用户更多个性化选择
• 提升效率，比如深色主题让人更专注，演示模式让内容更突出

组成

主题（Theme）一般是由color，BG image，fontSize，font等资源组成

Android/iOS

android应用资源都在资源路径src/res下，style相关改动可以通过activity的setTheme来切换，图片换肤一般会将资源打成一个不带launcher icon的Apk，用Resource实例去加载特定资源；而iOS相应的配置信息都预先写在plist文件里，通过一个ThemeManager实例来控制应用使用哪套资源配置。

Flutter

MaterialApp组件接受一个theme参数，通过改变theme的数据，组件会实时重新渲染

目的

1. Redux是什么
2. Redux在Flutter里的作用
3. Flutter里如何使用Redux

效果

Flutter App本质上是一个单页面应用，需要我们自己维护State，Model，Route。随着业务的增加，这些工作会变得很复杂，也不可预测，复现一个bug会很困难，跨组件传递数据也很难。Redux思想继承于Flux，通过合理的约定让业务分层解耦，数据的变动可以预测，可以重现。Redux有三个原则：

1.单一的数据来源（App统一的Store）

2.状态State是只读的（数据不能直接修改，只能用过约定的Action触发，Reduce修改）

3.数据改动须是纯函数（这些纯函数叫Reducer，定义了如何修改Store，由Action触发）

原理

Redux（3.0.0）是作者用Dart把JS 的redux库实现了，它定义了Store，Action，Reduce，Middleware以及它们之间的行为关系。

flutter_redux（0.5.2）作为工具类桥接Redux和Flutter，它提供了StoreProvider，StoreBuilder，StoreConnector这些组件，使我们在flutter中使用redux变的很简便。

Flutter Bottom Navigation Bar

底部导航是常见的APP布局方式，实际上我自己常用的app都是底部导航的。Android和iOS都有官方组件可供使用。Flutter也有，使用时有踩坑，这里记录一下。

一般用法

普通实现:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

BottomNavigationBar botttomNavBar = BottomNavigationBar(
  items: [
    BottomNavigationBarItem(icon: Icon(Icons.code), title: Text('code')),
    BottomNavigationBarItem(icon: Icon(Icons.add), title: Text('add')),
    BottomNavigationBarItem(icon: Icon(Icons.print), title: Text('print'))
  ],
  currentIndex: _currentIndex,
  type: BottomNavigationBarType.fixed,
  onTap: (int index) {
    setState(() {
      _currentIndex = index;
    });
  },
);

问：看起来很简单，至于分析这么多吗？

答：emmmm，这实现优点是设计标准规范，官方组件也简单稳定可靠。但前提是设计师接受这种设定（即使是fixed，选中图标和文字也会有放大缩小动画），至少中国主流的APP，navigation item都是fixed而且没有动画，官方组件并不提供这种选择。

有点问题

既然设计师有要求那不能怂，分析是因为内部的_BottomNavigationTile作祟，那自己实现navigationItem控制是否选中，并且不传currentIndex给BottomNavigationBar，应该可以吧

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

Widget _buildBottomNavigationBar() {
  return BottomNavigationBar(
    type: BottomNavigationBarType.fixed,
    items: [
      _buildItem(icon: Icons.code, tabItem: TabItem.code),
      _buildItem(icon: Icons.add, tabItem: TabItem.add),
      _buildItem(icon: Icons.print, tabItem: TabItem.print),
    ],
    onTap: _onSelectTab,
  );
}

// 用定制化的icon和tabItem构建BottomNavigationBarItem
BottomNavigationBarItem _buildItem({IconData icon, TabItem tabItem}) {
  String text = tabItemName(tabItem);
  return BottomNavigationBarItem(
    icon: Icon(
      icon,
      color: _colorTabMatching(item: tabItem),
    ),
    title: Text(
      text,
      style: TextStyle(
        color: _colorTabMatching(item: tabItem),
      ),
    ),
  );
}

// 切换item的颜色，选中用primaryColor，其他都是grey 
Color _colorTabMatching({TabItem item}) {
  return currentItem == item ? Theme.of(context).primaryColor : Colors.grey;
}

万事开头难，先把环境搞起来

配置镜像

flutter还在墙外，为了我们墙内人们能顺畅使用，官方提供了一个临时镜像：

在命令行只能更新当前会话的PATH变量，写在.bash_profile(bash) .zshrc(zsh) 可以永久修改此变量

1
2

export PUB_HOSTED_URL=https://pub.flutter-io.cn
export FLUTTER_STORAGE_BASE_URL=https://storage.flutter-io.cn

获取Flutter SDK

• 去flutter官网下载其最新的安装包，推荐下载Beta的，不过下好了也可以切分支，下载地址

• 解压文件到开发目录

1
2

cd ~/development
unzip ~/Downloads/flutter_macos_v0.5.1-beta.zip

• 配置环境变量

打开或创建HOME/.bash_profile(bash)，加入这行：

工作

17年奋战在一线，参与并推进了这些事儿的进程：

• 商家APP惠管家上线运行
• 小管家，管理惠管家版本，基于vue.js
• 对接了拉卡拉的惠管家上线
• 惠收银开发上线，基于mvp，kotlin
• 小伙伴扩充到6人，技术栈包括android，iOS，RN

生活

两人形影不离生活在一起，有欢笑，也会有摩擦，需要的是多一份理解，和让步

4月清明回我老家，去摘了树莓，漫田野酸甜可口的树莓，大家开心的采摘，仿佛回到了童年。

5月最开心的事儿是借自己生日之由勒索女票一个三星s8+手机，手感，屏幕和拍照都堪称完美。

8月开始看车，试了320，女票坐后排说头晕，旁边的梅赛德斯，没敢进去；揣着a3的预算看a4l觉得好大，好气派，里面的多媒体好高级，口水流一地，一见倾心。打算加点预算咬牙上a4l乞丐版。但Led大灯，真皮座椅，自动空调都是我无法割舍的啊。。。好好好，加5万上次低配，套路我是服奥迪！

十一回女票家，开着小车车带我爸妈去他家，父母正式见了面，住了几天，走完定金流程，多亏她家人情通达，我爸妈应付到位，还是蛮顺利的。

11月公司集体去泰国旅游，这次人多了，但感觉并没有超越上一次，比如吃的，住的，还好大家都安全来回。

开发流程约定

大部分参考百姓的开发流程，感谢。

基本流程

主要分支有两个，master 和 dev，master 一般只能由 dev 往里面合并。dev 接收各种BUG修复和新功能。

所有人 fork 一份 upstream（zaihui/server），然后在自己的 fork（yourname/server）上开发，开发完毕后通过 Pull Request 向 upstream 的 **dev** 分支提交代码。

禁止直接 clone upstream 作为工作环境。

如果需要合作的话，直接把某人的 fork 加为 remote 就可以了，然后在他的分支上 pull 和 push。

好处

• 在自己的分支上可以随便 push -f ，branch 名字即使简单也不会和别人冲突。
• 主代码仓库可以实现更好的权限控制。
• 通过设置，可以强制其他人输入 LGTM 才允许合并，强制 Code Review。

  坏处

• 略显麻烦？

好习惯

Hot fix

会讲述我们为什么这个时间点需要引入热修复，市面上多种解决方案我们选择哪种，为何？

引入契机

• 敏捷开发需要有一种方式能快速修复问题，灰度验证，和上线部署
• 商家端应用，我们提供定制化的硬件，前期是通过全量强制更新上线新功能和修复问题
• 拉卡拉Pos，惠管家自动更新不能工作
• 去拉卡拉自带应用商店里更新流程会特别复杂，无法保证新版本安装率

期望目标

• 能方便的使用热更新快速修复Bug，上线一些小版本功能
• 能灰度发布测试布丁，和不同功能，AB Test验证产品
• 定义热更新和自动更新的适用范围

方案对比

• Amigo和Robust原理类似，都是受Instant Run启发，采用hack ClassLoader的方案，优点是可以即时生效，缺点是兼容性不佳，从完成度上看Amigo优于Robust。
• Tinker原理是生成差分Dex，与现在的dex合并，并替换现在的dex。优点是可以做到粒度很小的全面修复，兼容性极好，缺点是合dex耗费的时间会比价长，也会占用额外的rom空间，必须重启应用才能生效。相比Amigo它少了四大组件的修复，但认同Tinker的做法，热修复的作用应该是在修复上面而不是添加新的模块，这有些违背职能单一化，加上社区的接受和认可度，Tinker优胜Amigo。
• Sophix是Andfix的商业版，可以看成是Andfix+Tinker，基于native hook的Andfix可以带来快速修复bug，立即生效的好处。无法添加新类和方法的缺点可以通过合并生成新Dex的方式解决，加上接入门槛非常低和可靠的补丁托管平台，结合我们现阶段的需求，最终选择Sophix。

操作手法

三星S8

软件：

• 自带应用就看设置，s8的设置归类科学，显示清新，顶部有快速搜索也非常实用。

• 相机，计算器的UI交互也非常简单易用

• 安全文件夹，其实就是一个安全级别很高的应用分身功能

• 游戏中心，可以设置这个文件夹里的应用运行时的性能通知免打扰

• 电话，信息交互自然，本地化也做的很好，能自动标注常见的号码

• S助手很好用，在杭州呆的两天里，吃喝玩乐都用它解决了，感觉这个总入口的流量好大

• Bixby除了几次误按进去，暂时没发现有啥应用场景

• 锁屏解锁，动态壁纸，搭配面部解锁，体验细腻迅速，丝滑自然

  缺点：指纹解锁非常难用，摆放的位置是脑残。用的时候总是担心会按到镜头，很难下意识解锁，只能翻过来眼睛看着手指才能解锁，如果放在摄像头下面会好用很多，只是视觉上不那么好看了。

硬件：

• 高通835玩王者农药和崩坏3，没有比这更顺的机子了，机身始终温热
• 电池3500非常耐用，自带的快充，1个半小时就能充满，机身始终温热
• 买的s8+，握持感优于7plus，点亮屏幕，就美感来说这两完全不是一个维度的东西
• 摄像头，后置对焦快准白平衡自然像素高，前置毫无下限的磨皮美颜，讨好机主
• 前后完全对称的双面玻璃，带来温润如玉的手感，和不着边际的视野
• 曲面屏在s8上应该是大成，自然不炫技，大弧度的4个R角很有灵性和美感
• 外放音量一般，质感不错

总结：

工作相关，三星历代安卓旗舰都有关注，或欣赏或吐槽。绿的出油，文字锯齿的s1，鹅软石的s3，后来买了s5，彻底路转黑，Rom别家一般500M它得1.5G，是塞了多少垃圾进去，刷机还特别麻烦。刷完安全模式就不工作，软件UI奇丑，交互复杂。GPS定位总是会悄悄起进程，导致一天至少2冲。最后因为屏接触不良，服役1年就被弃。一个月前看到S8的信息，被这块屏折服，决定再试一次三星，大不了退货嘛。但真是出乎意料的好用啊！！！

适用对象：

出于各种原因不喜IOS，但内心追求独特，又不把性价比放第一位TX