...

...

...

...

...

近期学到一个词：Digital Twin(数字孪生)，简单来讲就是在计算机世界给现实世界的物体（飞船/城市）、系统（电力/交通）建立数字化镜像，让数字世界和物理世界更好地交互，数字大屏也可以算这种技术一种应用场景。这个概念由 Dr.Michael Grieves 于 2002 年提出，随着 IOT、AI、图形技术、工业 4.0 的飞速发展，应用前景越来越广阔。Google 一下 就会发现：NASA、GE、Microsoft、SAP、IBM 等巨头早已布局和应用这项技术，它还是 Gartner Top 10 Strategic Technology Trends for 2019 中的一项。

 这种新形态无疑将为我们打开一片新天地。Gartner 这份报告中还有两项技术和前端紧密相关： * Immersive technologies：Augmented Reality(AR)、Virtual Reality(VR)、Mixed Reality(MR) 等 * Smart Spaces：智慧城市、智能汽车、智能商店等

看到未来有三项战略性技术居然和前端有关，着实让人兴奋不已。不过莫急，既然是战略，也就意味着三五年内未必能开花结果。再仔细分析会发现：当下的前端技术远不足以胜任这些领域，不由得让人心忧。远方的风景很美，但要成功抵达就需要早做准备。站在 201X 的末尾、互联网下半场的开始，不妨先结合 Gartner 这份报告一起分析下：下一个 10 年前端技术的变革在哪里、有哪些值得大力投入的方向？

回顾过去

“以史为鉴，可以知兴替”，如果历史是一组波，它过去的相位所形成的轨迹已足以预见未来。回顾 Web 技术的发展历程，可以清晰地看到三类促使变革发生的关键因子： * 引擎：有四大引擎显得尤为重要： * V8** **：不仅提升了 JS 的执行效率，助力 ES 规范落地，而且催生了 Node.js  * 浏览器引擎：以 Webkit、Blink、Chromium 为典型代表，浏览器的高速发展为 Web 的繁荣奠定了基础 * Node.js** **：大大拓展了前端的生存空间，以至于“Any application that can be written in JavaScript, will eventually be written in JavaScript.” * Hybrid 容器：让被 App 统治的移动互联网时代也给 Web 开发留下了一席之地，小程序是典型代表 * 开发套件：语法、框架、工具、类库在社区的推动下一直在蓬勃发展，优秀的开源项目灿若星河，前端生态也成为技术圈中最活跃的。虽然以 React 为核心的主流技术栈上手成本还比较高，也做不到让开发人员只关心业务逻辑，但不可否认应用开发正在变简单。有些类型的应用甚至做到了无需 Coding 通过专门的可视化搭建平台就可以完成，比如：门户网站、营销活动、问卷调查等。 * 分工模式：前后端分离、BFF(Backend For Frontend)、全栈、全端、大前端等分工模式的创新不仅提高了前端和其它工种的协作效率，也让前端有机会承担应用研发。由“前端 + 设计”组合形成的“体验技术部”也成为很多业务的标配，部分前端团队甚至发展为应用研发团队并且拥有了自研产品。前端的影响圈已经从应用开发延展到了用户体验甚至产品设计，以人机交互为本的 体验科技 也开始崭露头角。

这些变革因子的背后是两条主线： * 让现有研发工作做得更好：开发套件是主要推手，一些分工模式（比如：前后端分离）的创新也归属这条线 * 开辟新战场：引擎是主要推手，一些分工模式（比如：全栈）的创新也归属这条线上

这些变革之所以会发生，是因为有一个刚需：客户端软件的生产力水平满足不了飞速增长的互联网应用诉求，而前端技术恰好能提升应用研发的生产力水平。虽然移动互联网的崛起曾一度让前端缺少发力之处，但寄生于超级 App 上的 Hybrid 容器又让前端焕发了生机，小程序更是将之推向了和 PC 时代同样重要的地位。应用虽然琳琅满目，但其形态演化也是有迹可循的，要讲清楚得专门写一篇文档，这里不过多展开，简单介绍几个我认为最重要的： * UGC 内容的主流载体在变：文本 -> 图片 -> 短视频/直播，用户创作内容的成本越来越低了 * 终端的主流交互方式在变：PC(键盘/鼠标) -> 手机/PAD(触屏/摄像头/语音)，交互越来越自然、简单了 * 信息获取的主流方式在变：主动获取 -> 被动推送 -> 智能推荐，异步 -> 实时，信息已触手可得

这一个刚需、两条主线、三类因子也是我们预判未来的重要依据。

立足当下

在当下可实践的新技术中，前端相关的有：AI、Serverless/FaaS、Blockchain、IOT、AR/VR/MR、智能硬件、可视化应用开发。不可否认，它们都是能在一些领域带来颠覆性革命的技术，但是否会给前端带来变革呢？让我们详细分析一下： * AI：核心是云，而且 AI 应用的典型特点是“重引擎轻 UI”，所以前端不在主赛道，只能在应用开发中使用它。目前市面上的 AI 应用，多数是大数据技术的延伸，离 Intelligence 还太远。作为人类技术的巅峰之作，AI 应该在人类最难解决的问题上发挥价值，比如：语言文字、医疗、科研、教育、环境等。个人看好机器翻译，打破语言界限将会是人类文明一次划时代的变革。作为前端，我们也应该去关注这些基础领域，并学习和掌握 AI 技术。 * Serverless/FaaS： 核心是云，前端能做的是基于这种技术优化 Node.js 在服务端的 Runtime 和运维方式，把服务端复杂的技术细节屏蔽掉，让 Node.js 开辟出来的服务端战场可以延续，让端上所需的数据能以简洁、低成本的方式存储和获取。当然，也可以基于它优化现有的工具体系，让开发越来越简单。 * Blockchain：核心还是云，和前端最相关的是 Decentralized Application(DApp)、IPFS(the InterPlanetary File System)。但 DApp 是一种新的应用形态，IPFS 改变的是网络协议。这两者还处于非常早起的阶段，发展形势还不明朗，最好是静观其变，在合适的时候基于它们开发应用。 * IOT：核心是端，但关键技术是硬件及嵌入式系统，和前端交集较少，发挥空间很有限。除了在之上开发应用外，能看到的还有两个潜在方向：把 Node.js、浏览器内核移植到 IOT 设备，打造一个可运行前端代码的 Runtime；部分设备需要展示数据，可以基于图形技术打造专属渲染引擎。 * AR/VR/MR：核心是硬件及交互方式的变化，前端能参与到类库及应用开发中。但受设备所限，目前还不是应用的主流，需要结合业务特点寻找切入点。 * 智能硬件：机器人则是这项技术的终极形态。**其核心在 AI 、自动化控制及硬件上，给前端带来的更多是应用形态和交互方式的升级。 * 可视化应用开发：不写/少写代码就完成开发，这是前端的一个夙愿，不可能完全达成，但在特定场景下是可以做到的。MFC、Dreamweaver、Flash、Microsoft 是该领域的先驱，Wix、Webflow、Bubble、Node-RED、FrameX、PowerApps 是当下值得关注的。其本质上仍是通过更好的开发套件提升应用生产效率，其最大竞品是成品 SaaS，毕竟拿来就用比搭建更简单，这就如同当需要一台电脑时多数人会选择买成品而不是买配件组装。

综上来看，这些新技术的关键路径和核心技术多数都不在前端，但我们能以使用者的身份参与进去，结合业务特点进行实践，让现有研发工作做得更好，让应用的交互体验更好。不过，还是有两个前端强相关的技术有望带来变革： * **IOT 上的 App Runtime **：其背后就是一个引擎，能让前端应用运行在越来越多的新型终端上 * 可视化应用开发：有望把部分功能和应用的开发成本降到最小

一窥未来

应用形态日新月异，新技术风起云涌，未来扑朔迷离...作为前端，我们究竟该往那些方向进行技术储备呢？要找到有指导意义的技术路线图，除了前文这些分析外，还得回到前端的本质中去探寻变革背后那些不变的东西，只有它们才能让我们以不变应万变，把技术转换为生产力。

前端技术发展变化虽然很快，但从程序的视角来看，有两个东西一直未变： * 终端的形态和交互方式一直在变，其本质未变： * 渲染数据：把数字世界的数据转换成可被人感知的声音或图像，图形技术、音频技术、排版技术是核心 * 采集数据：把物理世界的数据、人脑中的知识转换到数字世界，传感器技术、编辑器技术是核心 * 应用的类别和交互方式在变，但应用研发始终可以分解为四大部分： * 云：提供应用运行所需的数据，托管资源及可执行代码 * 端：依托某个 App Runtime 提供 UI 给最终用户 * 专项技术：业务是技术之本，脱离了业务，前端将是无根之萍，而每个业务都有其专业属性和专项技术 * App Development Engine：也即“开发套件”，在普通工程师完全自主可控的范围内提升生产力

结合以上分析以及语雀所属业务的特点，整理了下边这幅前端技术大图以抛转引玉：

App Development Engine

当下的 Web 应用开发真的让人揪心，学习曲线非常陡峭、新概念层出不穷、技术更新换代太快...应用复杂度并不比十年前高多少，但要学习和掌握的东西是之前的很多倍。身处产品研发这个战场的前线，我们的装备一点都不精良，大把精力耗在作战无关的地方。生产力虽然在提升，但完全赶不上业务增长速度，App Developement Engine 这个提升生产力的关键因子在当下显得尤为重要。

这个领域是创新最活跃的地方，从过去的发展历程中能看到一些演进脉络： * 从 Engine 的角度看，演进的背后有两种理念： * Coding Less：通过强大的 SDK、框架和工具让工程师更好地 Coding，专注在实现业务上 * No Coding：通过可视化 IDE 达成不写代码，通过拖拽、编写配置文件就能完成应用开发 * 从开发者角度看，对 Engine 有三个期待： * Productivity：必须能提升生产力，让工程师可以高效地写出健壮、易维护的代码 * Simple & Stupid：KISS 原则 的核心，让开发变简单不仅能提升效率，还能让更多人成为前端工程师 * Business More：研发资源非常宝贵，让工程师专注在业务上是提升效能的关键

未来的演化也会遵循这些脉络，Coding Less、No Coding 各有其应用场景，需要结合业务特点选择侧重点进行投入。但有一点我觉得是必然的：要开发优质应用，还得靠 Coding，不过写的代码会越来越少。No Coding 过于完美，应用场景有限，再加上有成品 SaaS 作为更好的替代品，我更倾向于用 Coding Less 模式去实现业务主线，把一些机械性、重复性、一次性的开发工作通过 No Coding 模式搞定。不过 No Coding 的一个分支 Visual Programming 非常值得关注，它在编程教育领域应用前景非常好，Scratch 、Blockly 是典型代表，而编程教育不仅蕴藏着巨大的商机，而且还会给我们带来源源不断的生力军。

语雀专项技术

语雀致力于打通「知识」和「大脑」之间的双向通道，背后是两大关键技术： * 编辑器：知识从大脑到数字世界的关键，语雀当下的文本编辑器、目录编辑器还很初级 * 知识可视化：知识被人脑感知和理解的关键，给知识最佳的呈现形态有助于知识的理解和传播

“数据可视化”和“数字孪生”在当下和语雀的关联并不大，但在未来一定会和语雀紧密相关： * 数据不仅是科学研究的基础，其背后本身就蕴藏着知识，数据可视化可以让这些知识更好地呈现给人们 * 数字孪生和知识结合蛮有想象空间的，比如：数字博物馆、虚拟天文馆、仿真生态系统

App Runtime

为什么 App Rutime 会是变革的生力军呢？因为历史告诉我们：引擎的革新是开辟新战场的核心驱动力，而 App Rutime 的核心恰好就是引擎及其之上的 SDK。在很长一段时间里，前端技术得益并受限于浏览器引擎，广大前端工程师只能在 App Development Engine 层发力。但时至今日，终端、应用形态的多样性越来越强，移动互联网已经打破浏览器一统天下的局面，不难看出浏览器技术的进化速度已不能满足越来越多的新型终端和应用形态了。

可以大胆地预测在这个领域必然会有一场变革，变革有可能由浏览器进化产生，也有可能是一些新的引擎。已经能看到一些苗头了： * Office 以惊人的速度和 UI 一致性覆盖了所有终端，猜测其背后有一套跨端 UI 方案 * 超级 App 打破了浏览器一统天下格局，小程序已是新的 Runtime * Flutter 在探索的就是一个新的跨端 UI 开发方式 * Fuchsia 则是 Google 在探索的一个更大的局，从 OS 层面推动变革

更关键的是：这场变革是前端工程师有机会参与进去的，因为引擎的核心技术——图形技术已经在数据可视化、H5 Game 的推动下成为不少团队能熟练使用的技术。而应用类型的多样性也会给一些垂直市场的 App Runtime 留下生存空间，这块已经有一些成功案例，比如：游戏领域的 Cocos 引擎 和 白鹭引擎、桌面软件开发领域的 Electron，未来应该还会有更多。

领域服务

“领域服务”对前端来说可能比较陌生，它的背后是大名鼎鼎的 领域驱动设计（DDD:Domain-Driven Design），是应用在云端部分的高度抽象，是系统中的稳定部分，这也正是前端总是改版而服务端接口却可以不变的原因。服务端研发有这样一条演化主线：解决编程语言层面的问题 -> 解决开发框架 & 类库问题 -> 专注于解决业务问题，Java -> Spring -> DDD & Sofaware Architecure 就是典型案例。服务端之所以抗变能力这么强，正式由于把主要精力放在了领域模型抽象和系统架构设计上。

为何领域服务在当下对前端也这么重要，因为： * 领域模型和领域服务是对业务的抽象，也是理解业务的直观体现，好的领域模型能大大降低前端开发成本 * 领域设计的相关思想、理念可以借鉴到前端中，给前端带来解决问题的新思路 * 前端处于研发的十字路口，信息面最广，极有潜力协调产品、设计、服务端等工种共同梳理领域模型和业务链路

关于 DDD，可以从这三种非常容易理解和掌握的经典架构入门： * Hexagonal Architecture(Ports and Adapters) * CQRS - Command Query Responsibility Segregation  * The Clean Architecture 

全功能型团队

前端是工程师中离用户最近的群体，很多前端心中都有一个产品梦，这个产品可能是一个技术产品也可能是一个用户产品。很长一段时间内，我们疲于生存，只能忙里偷闲折腾个小工具或者参加下 Hackathon。但随着技术的演进，不少团队已经具备了全栈能力，并承担了 App Development Engine 中的一些平台的自主研发，让这个梦近了一些。但要完整实现，光有全栈能力是远远不够的，还需要一个包含技术、产品、设计、运营的全功能团队才能达成，这种团队不仅能提升协作效率、保证交付质量，还有可能催生出商业化产品。很多公司都在往大中台 + 小前台的方向发展，而支撑小前台的恰恰就是全功能型团队。所以在时机成熟时可以组建全功能型团队，逐步承接业务中人机交互部分的研发工作，让“用户体验”能落到实处。

砥砺前行

前端技术的未来，没有标准大图，这份图蕴含在每个业务中，更需要脚踏实地把未来亲手打造出来，业界趋势、新技术、新产品形态都是可以借力的因素。如果你已经有一个愿意与之一起奋斗和成长的业务，就可以结合业务定期推演适合它不同发展阶段的技术大图。如果还没有，也不用急，打好技术基础，做好手上的每个项目，结合业务在 Appliaction Development Engine 领域探索和实践，逐步寻找真正想做的业务、想服务的用户。

软件研发是一项理论和实践并重的技术，实践尤为重要，因为最终我们是要写出健壮运行的代码给用户用的。不管未来如何，在持续学习和实践中强化对编程、技术、业务的理解才是根本。除了学习和实践与业务最相关的技术外，建议按自己的专长和兴趣把重点放在这些领域： * 领域驱动设计：强化领域建模和系统设计能力，力争懂业务、成为领域专家 * 软件架构设计和软件设计哲学：它们会为系统、框架、类库注入灵魂，让代码有生命力 * 图形技术：在应用、引擎两层都有广阔的场景，最关键的是图形应用在未来的占比一定会越来越高 * AI ：不必深入到底层，但需要掌握其使用，不妨先从 TensorFlow 开始

编程是一种修行，应用修行的产物，也是我们与世界交流的方式。
未来在哪里并不重要，重要的是以空杯心态持续学习和实践，用心写下每行代码。

欢迎来语雀沉淀你的专业知识，让你对编程、技术、产品的理解和思考可以被更多人看见。 语雀会努力提供最好的服务，让你安静地创作、愉快地分享。

---

ref:
Digital Twin – The Machines’ Mind 
Origins of the Digital Twin Concept 
Top 10 Strategic Technology Trends for 2019
Gartner发布 2019 年十大战略性技术趋势
什么是Digital Twin 
Dapp.com - Learn Everything About Decentralized Apps 
The General Theory of Decentralized Applications, Dapps
IPFS is the Distributed Web
You Do Not Need Blockchain: Eight Popular Use Cases And Why They Do Not Work 
Cloud Programming Simplified: A Berkeley View on Serverless Computing
Knowledge Visualization 
Google Fuchsia release date, news and rumors
The Kiss Principle 
Basics of the Unix Philosophy
Principles Wiki 
Demystifying the Hexagon 
Software Architecture Design 
前端开发漫游指南 
体验科技与好的社会

...

刚刚，阿里宣布开源Flutter应用框架Fish Redux！

作者：闲鱼技术-吉丰
3月5日，闲鱼宣布在GitHub上开源Fish Redux，Fish Redux是一个基于 Redux 数据管理的组装式 flutter 应用框架， 特别适用于构建中大型的复杂应用，它最显著的特征是 函数式的编程模型、可预测的状态管理、可插拔的组件体系、最佳的性能表现。下文中，我们将详细介绍Fish Redux的特点和使用过程，以下内容来自InfoQ独家对闲鱼Flutter团队的采访和Fish Redux的开源文档。

开源背景

在闲鱼接入Flutter之初，由于我们的落地的方案希望是从最复杂的几个主链路进行尝试来验证flutter完备性的，而我们的详情整体来讲业务比较复杂，主要体现在两个方面：

• 页面需要集中状态管理，也就是说页面的不同组件共享一个数据来源，数据来源变化需要通知页面所有组件。
• 页面的UI展现形式比较多（如普通详情、闲鱼币详情、社区详情、拍卖详情等），工作量大，所以UI组件需要尽可能复用，也就是说需要比较好的进行组件化切分。

在我们尝试使用市面上已有的框架（google提供的redux以及bloc）的时候发现，没有任何一个框架可以既解决集中状态管理，又能解决UI的组件化的，因为本身这两个问题有一定的矛盾性（集中vs分治）。因此我们希望有一套框架能解决我们的问题，fish redux应运而生。

fish redux本身是经过比较多次的迭代的，目前大家看到的版本经过了3次比较大的迭代，实际上也是经过了团队比较多的讨论和思考。

第一个版本是基于社区内的flutter_redux进行的改造，核心是提供了UI代码的组件化，当然问题也非常明显，针对复杂的详情和发布业务，往往业务逻辑很多，无法做到逻辑代码的组件化。

第二个版本针对第一个版本的问题，做出了比较重大的修改，解决了UI代码和逻辑代码的分治问题，但同时，按照redux的标准，打破了redux的原则，对于精益求精的闲鱼团队来讲，不能接受；

因此，在第三个版本进行重构时，我们确立了整体的架构原则与分层要求，一方面按照reduxjs的代码进行了flutter侧的redux实现，将redux的原则完整保留下来。另一方面针对组件化的问题，提供了redux之上的component的封装，并创新的通过这一层的架构设计提供了业务代码分治的能力。

至此，我们完成了fish redux的基本设计，但在后续的应用中，发现了业务组装以后的代码性能问题，针对该问题，我们再次提供了对应的adapter能力，保障了在长列表场景下的big cell问题。目前，fish redux已经在线上稳定运行超过3个月以上，未来，期待fish redux给社区带来更多的输入。

Fish Redux技术解析

分层架构图

架构图：主体自底而上，分两层，每一层用来解决不通层面的问题和矛盾，下面依次来展开。

Redux

Redux 是来自前端社区的一个数据管理框架，对 Native开发同学来说可能会有一点陌生，我们做一个简单的介绍。

Redux 是做什么的？

Redux 是一个用来做[可预测][集中式][易调试][灵活性]的数据管理的框架。所有对数据的增删改查等操作都由 Redux 来集中负责。

Redux 是怎么设计和实现的？

Redux 是一个函数式的数据管理的框架。传统 OOP 做数据管理，往往是定义一些 Bean，每一个 Bean 对外暴露一些 Public-API 用来操作内部数据（充血模型）。

函数式的做法是更上一个抽象的纬度，对数据的定义是一些 Struct（贫血模型），而操作数据的方法都统一到具有相同函数签名 (T, Action) => T 的 Reducer 中。

FP:Struct（贫血模型） + Reducer = OOP:Bean（充血模型）

同时 Redux 加上了 FP 中常用的 Middleware（AOP） 模式和 Subscribe 机制，给框架带了极高的灵活性和扩展性。

贫血模型、充血模型请参考：

https://en.wikipedia.org/wiki/PlainoldJava_object

Redux 的缺点

Redux 核心仅仅关心数据管理，不关心具体什么场景来使用它，这是它的优点同时也是它的缺点。

在我们实际使用 Redux 中面临两个具体问题：

• Redux 的集中和 Component 的分治之间的矛盾；
• Redux 的 Reducer 需要一层层手动组装，带来的繁琐性和易错性。

Fish Redux 的改良

Fish Redux 通过 Redux 做集中化的可观察的数据管理。然不仅于此，对于传统 Redux 在使用层面上的缺点，在面向端侧 flutter 页面纬度开发的场景中，我们通过更好更高的抽象，做了改良。

一个组件需要定义一个数据（Struct）和一个 Reducer。同时组件之间存在着父依赖子的关系。通过这层依赖关系，
我们解决了【集中】和【分治】之间的矛盾，同时对 Reducer 的手动层层 Combine 变成由框架自动完成，大大简化了使用 Redux 的困难。
我们得到了理想的集中的效果和分治的代码。

对社区标准的 follow

State、Action、Reducer、Store、Middleware 以上概念和社区的 ReduxJS 是完全一致的。我们将原汁原味地保留所有的 Redux 的优势。

如果想对 Redux 有更近一步的理解，请参考：https://github.com/reduxjs/redux

Component

组件是对局部的展示和功能的封装。 基于 Redux 的原则，我们对功能细分为修改数据的功能(Reducer)和非修改数据的功能(副作用 Effect)。

于是我们得到了，View、 Effect、Reducer 三部分，称之为组件的三要素，分别负责了组件的展示、非修改数据的行为、修改数据的行为。

这是一种面向当下，也面向未来的拆分。在面向当下的 Redux 看来，是数据管理和其他。在面向未来的 UI-Automation 看来是 UI 表达和其他。

UI 的表达对程序员而言即将进入黑盒时代，研发工程师们会把更多的精力放在非修改数据的行为、修改数据的行为上。

组件是对视图的分治，也是对数据的分治。通过逐层分治，我们将复杂的页面和数据切分为相互独立的小模块。这将利于团队内的协作开发。

关于 View

View 仅仅是一个函数签名: (T,Dispatch,ViewService) => Widget
它主要包含三方面的信息

• 视图是完全由数据驱动。
• 视图产生的事件／回调，通过 Dispatch 发出“意图”，不做具体的实现。
• 需要用到的组件依赖等，通过 ViewService 标准化调用。比如一个典型的符合 View 签名的函数。

关于 Effect

Effect 是对非修改数据行为的标准定义，它是一个函数签名: (Context, Action) => Object
它主要包含四方面的信息

• 接收来自 View 的“意图”，也包括对应的生命周期的回调，然后做出具体的执行。
• 它的处理可能是一个异步函数，数据可能在过程中被修改，所以我们不崇尚持有数据，而通过上下文来获取最新数据。
• 它不修改数据， 如果修要，应该发一个 Action 到 Reducer 里去处理。
• 它的返回值仅限于 bool or Future， 对应支持同步函数和协程的处理流程。

比如良好的协程的支持：

关于 Reducer

Reducer 是一个完全符合 Redux 规范的函数签名:(T,Action) => T
一些符合签名的 Reducer：

同时我们以显式配置的方式来完成大组件所依赖的小组件、适配器的注册，这份依赖配置称之为 Dependencies。

所以有这样的公式 Component = View + Effect(可选) + Reducer(可选) + Dependencies(可选)。

一个典型的组装：

通过 Component 的抽象，我们得到了完整的分治，多纬度的复用，更好的解耦。

Adapter

Adapter 也是对局部的展示和功能的封装。它为 ListView 高性能场景而生，它是 Component 实现上的一种变化。

它的目标是解决 Component 模型在 flutter-ListView 的场景下的 3 个问题：

1）将一个"Big-Cell"放在 Component 里，无法享受 ListView 代码的性能优化；

2）Component 无法区分 appear|disappear 和 init|dispose ；

3）Effect 的生命周期和 View 的耦合，在 ListView 的场景下不符合直观的预期。

概括的讲，我们想要一个逻辑上的 ScrollView，性能上的 ListView ，这样的一种局部展示和功能封装的抽象。做出这样独立一层的抽象是我们看实际的效果，我们对页面不使用框架Component，使用框架 Component+Adapter 的性能基线对比。

• Reducer is long-lived, Effect is medium-lived, View is short-lived.

我们通过不断的测试做对比，以某 Android机为例：

• 使用框架前 我们的详情页面的 FPS，基线在 52FPS；
• 使用框架， 仅使用 Component 抽象下，FPS 下降到 40， 遭遇“Big-Cell”的陷阱；
• 使用框架，同时使用 Adapter 抽象后，FPS 提升到 53，回到基线以上，有小幅度的提升。

Directory

推荐的目录结构会是这样

sample_page -- action.dart -- page.dart -- view.dart -- effect.dart -- reducer.dart -- state.dart components sample_component -- action.dart -- component.dart -- view.dart -- effect.dart -- reducer.dart -- state.dart

上层负责组装，下层负责实现,   同时会有一个插件提供， 便于我们快速填写。

以闲鱼的详情场景为例的组装：

组件和组件之间，组件和容器之间都完全的独立。

Communication Mechanism

• 组件|适配器内通信
• 组件|适配器间内通信

简单的描述：采用的是带有一段优先处理的广播， self-first-broadcast。

发出的 Action，自己优先处理，否则广播给其他组件和 Redux 处理。最终我们通过一个简单而直观的 dispatch 完成了组件内，组件间（父到子，子到父，兄弟间等）的所有的通信诉求。

Refresh Mechanism

数据刷新

• 局部数据修改，自动层层触发上层数据的浅拷贝，对上层业务代码是透明的。
• 层层的数据的拷贝：
  • 一方面是对 Redux 数据修改的严格的 follow。
  • 另一方面也是对数据驱动展示的严格的 follow。

视图刷新

扁平化通知到所有组件，组件通过 shouldUpdate 确定自己是否需要刷新。

Fish Redux的优点

数据的集中管理

通过 Redux 做集中化的可观察的数据管理。我们将原汁原味地保留所有的 Redux 的优势，同时在 Reducer 的合并上，变成由框架代理自动完成，大大简化了使用 Redux 的繁琐度。

组件的分治管理

组件既是对视图的分治，也是对数据的分治。通过逐层分治，我们将复杂的页面和数据切分为相互独立的小模块。这将利于团队内的协作开发。

View、Reducer、Effect 隔离

将组件拆分成三个无状态的互不依赖的函数。因为是无状态的函数，它更易于编写、调试、测试、维护。同时它带来了更多的组合、复用和创新的可能。

声明式配置组装

组件、适配器通过自由的声明式配置组装来完成。包括它的 View、Reducer、Effect 以及它所依赖的子项。

良好的扩展性

核心框架保持自己的核心的三层关注点，不做核心关注点以外的事情，同时对上层保持了灵活的扩展性。

• 框架甚至没有任何的一行的打印的代码，但我们可通过标准的 Middleware 来观察到数据的流动，组件的变化。
• 在框架的核心三层外，也可以通过 dart 的语言特性 为 Component 或者 Adapter 添加 mixin，来灵活的组合式地增强他们的上层使用上的定制和能力。
• 框架和其他中间件的打通，诸如自动曝光、高可用等，各中间件和框架之间都是透明的，由上层自由组装。

精小、简单、完备

• 它非常小，仅仅包含 1000 多行代码；
• 它使用简单，完成几个小的函数，完成组装，即可运行；
• 它是完备的。

关于未来

开源之后，闲鱼打算通过以下方式来维护Fish Redux：

• 通过后续的一系列的对外宣传，吸引更多的开发者加入或者使用。目前Flutter生态里，应用框架还是空白，有机会成为事实标准；
• 配合后续的一系列的闲鱼Flutter移动中间件矩阵做开源；
• 进一步提供，一系列的配套的开发辅助调试工具，提升上层Flutter开发效率和体验。

Fish Redux 目前已在阿里巴巴闲鱼技术团队内多场景，深入应用。最后 Talk is cheap, Show me the code，我们今天正式在GitHub上开源，更多内容，请到GitHub了解。

GitHub地址：https://github.com/alibaba/fish-redux

...

...

...

...