一位Android资深工程师对移动端架构的思考( 四 ) _Android

俗话说他山之石可以攻玉，我们对架构的思考也是如此，不能仅限于自己的一亩三分地，也要学习下友军的套路。
这类一般都是响应式视图的系统，MVVM就是个响应式，所以其实都是有联系的。
进化 5.0 Flutter/ReatNative

Flutter
是google用以帮助开发者在Ios和Android两个平台开发高质量原生应用的全新移动UI框架，也是据说要把Android替换掉的一个恐怖存在（目前现在还是个弱鸡）
React Native
让开发者使用 JAVAScript 和 React 编写应用，利用相同的核心代码就可以创建 Web，iOS 和 Android 平台的原生应用。React Native 的宗旨是，学习一次，高效编写跨平台原生应用。
ReatNative

JS 开发者可以用类似DOM编程模型就可以开发原生APP，画UI只需要画到virtual DOM 中，不需要特别关心具体的平台, RN 会把应用的JS代码编译成一个js文件，RN的整体框架目标就是为了解释运行这个js 脚本文件，通过bridge 传递到native，然后根据数据属性设置各个对应的真实native的View 。

文章插图

RN官方给的框架是Flux

文章插图

action 封装请求
dispatcher 注册处理器、分发请求
store 是处理器，处理业务逻辑，保存数据
view 根据store提供的数据进行展现;接受用户的输入并发出action请求。

解耦很细，做一个功能会涉及很多地方，所以人们对于这个官方架构进行简化
Reflux：

文章插图

这个三层框架就大大简化了flux的复杂交互。
不管是面向对象还是面向状态，其实本质上是一致的。三层框架能够很好处理视图，数据，事件，逻辑的问题。
我们也可以参考另外一种架构
Redux：

文章插图

我们可以看出其实也是分为三层，组件，Store，Action 。组件绑定这Action和state，store reducer都是页面单例，易于管理。action为请求dto对象，是请求类型，请求数据的载体，reducer是处理请求的方法。不允许有状态，必须是纯方法。必须严格遵守输入输出，中间不允许有异步调用。不允许对state直接进行修改，要想修改必须返回新对象。
这就是面向状态编程
react的组件只关注数据的最终状态，数据是怎么产生的并不关心。这个是RN的核心思想。

优点

1、提升产品迭代速度，APP迭代周期变短
2、减少研发成本（可不，ios和android都可以下岗了）
3、提升开发测试效率（不用双端两套代码分开测试了）

缺点

1、原生有些功能实现不了或者说很复杂
2、需要掌握IOS和Android的知识，个人学习成本高
3、需要兼容IOS和Android（很苦逼）
Flutter今年谷歌推出了Flutter的Beta版本，离正式的出生越来越近了。我们来看看这个新同学吧。
Flutter主要解决了移动开发中的两个重要问题，一是原生应用程序的性能与平台的集成;二是提供多平台、可移植的UI工具包支持高效应用开发。
和RN的跨平台思想不同
RN是将一种设计理念延伸到两个平台，而Flutter则实现了一套代码，部署多个平台。解决了RN开发需要IOS和Android基础的窘迫和成本。
在Flutter中，每个应用程序都是Widget，这点和其他的应用框架不一样，Flutter的对象模型是统一的，也就是控件。
Flutter 基本上就是一个 V（View），响应式视图，它可以是无状态或有状态的 widget，就连 AppCompatActivity 也是一个 widget 。是不是很过分？简单到粗暴。采用widget 和 state分离，比如我们在原生里大量重复代码来管理 Activity 的生命周期。但是在 Flutter 中，这是不需要的，从设计的角度就解决了这个问题。就像LifeCycles也是这种思想，解决了生命周期的问题。
对于这种面向状态编程的思想，架构和RN是类似，同时我们也期待Google的官方架构指导的出现，会不会有更多的惊喜呢？