温情提示信息：假如对图形界面端控制技术不了解能先查阅 2019 后端年度归纳 / 图形界面端合作开发。除此以外，责任编辑所传授的图形界面端合作开发控制技术并不是选用新奇的 Flutter 控制技术，假如你对穆萨内部 Flutter 控制技术的工程建设非常钟爱，则能查阅穆萨集团内如何展开 Flutter 控制系统化工程建设。
基本原理
首先传授许多图形界面端合作开发的基础概念，这里有些表明并不会横跨概要，其中许多表明会有利于认知先期的架构表明。
Hybrid 混合合作开发
责任编辑所传授的图形界面端合作开发主要就选用了 Hybrid 混和的合作开发商业模式（一种在原生植物应用领域罐子中内嵌 Web 应用领域程序的合作开发商业模式），这种商业模式混和了 Natiive 和 Web 合作开发的缺点。在某些高效能的销售业务场景中（例如 IM 闲聊、音频、现场直播等）能选用 Native 展开合作开发，而在许多功能插值相较频密的销售业务情景克列文能选用 Web 展开合作开发（合作投资成本低）。除此以外， Web 合作开发在虚拟化、动画电影、梅利尼、富文档选曲等方面潜能相较出众。
CEF 罐子
责任编辑所传授的 Hybrid 混和合作开发主要就选用了 CEF（Chromium Embedded Framework） 控制技术，它主要就的特点如下表所示：
能在 Native 原生植物应用领域中内嵌相容 HTML5 的 Google Chromium 应用领域程序能建立轻量的应用领域程序罐子（全称 CEF 罐子），主要就用于横跨采用 Web 控制技术展开合作开发的界面能全力支持虚拟化（Mac、Linux & Windows）合作开发，并且方便订制和结合其他类型的 Native 应用领域会动态跟踪 Google Chromium 的回退，能使 Web 合作开发采用许多相较教捷伊优点选用 C 和 C++ 语言展开合作软件控制系统，能和 Google Chromium 应用领域程序展开结合某一版的 CEF 能全力支持在 Windows XP 控制系统上运行图形界面端应用领域需要注意上述所言的 CEF 罐子能简单认知为在原生植物应用领域环境中内嵌 Google Chromium 应用领域程序。除此以外，图形界面端应用领域能努力做到Perhaps的合作开发商业模式，每一个询问处至少能横跨一个 Web 后端应用领域（全称子应用领域）。多个子应用领域之间假如想展开通讯则能利用 URL 的 query 模块（保密性明确要求低）或者 Native 转接控制技术中的发布订户机制（保密性明确要求高）。
温情提示信息：很多老师对于 Google Chromium 和 Google Chrome 的差别相较蒙蔽，值得 Goolge 一下。
JSBridge & Native API
后端合作开发的环境受制于应用领域程序的沙盒隔绝，操作控制系统中许多涉及到安全问题的控制系统潜能会被限制采用。在图形界面端混和合作开发中难免需要采用 Web 后端去调起某一的控制系统潜能，此时就需要一种转接 Web 和 Native 的控制技术，这种控制技术被称为 Bridge，具体如下表所示图所示：
温情提示信息：图片由同事提供，没有找到具体出处。
能把上图的左侧部分（自绘引擎合作开发架构）简单当作 Native 合作开发，右侧部分（泛 Web 罐子架构）当作 Hybrid 混和合作开发。能发现 Web 后端假如想绕过沙盒限制调起原生植物视图组件和控制系统潜能，需要通过 Native 提供的 Bridge 控制技术。在 CEF 罐子中原生植物应用领域能侵入 JavaScript 语法环境，因此能通过向 JavaScript 环境（例如 window 全局对象）注射 API 的形式展开转接，这里的 API 全称 Native API。
温情提示信息：除了图形界面端混和合作开发模型，移动端也存在类似的混和模型，其中的 Web 后端通常被称作 H5 控制技术。除此以外，转接控制技术是 Web 前端间接通过 Native 去调用控制系统潜能，因此会存在许多性能损耗。
JS API
穆萨的图形界面端除了合作开发自己的应用领域以外，也会提供服务平台供外部的 ISV 展开三方应用领域扩展。此时需要将 Native API 展开潜能开放（会涉及到许多调用的版和鉴权匹配处理），这些开放的 API 全称 JS API，相较 Native API 而言在潜能上会更加抽象，除此以外，也需要努力做到虚拟化、跨应用领域等，具体如下表所示图所示：
温情提示信息：在穆萨内部理论上会对你所能想到的任何控制技术展开收口处理， JS API 也不例外。
HotFix
在原生植物应用领域的图形界面端控制技术中，想要修复线上版的 Bug 或展开新功能插值往往需要伴随着新版的发布。HotFix 是在不发布应用领域版的前提下修复线上 Bug 且能努力做到用户无感知（也能通过提示信息用户手动更新补丁包的方式），大致实现流程如下表所示：
温情提示信息：图片来自大后端时代下的热修复平台工程建设。
在混和合作开发中假如想要修复 Web 后端应用领域的 Bug 会相较简单许多，至少能省略图形界面端重启步骤。同时离线的 Web 后端资源能通过资源下发的形式展开更新，而 CDN 形式的资源则只需要推送捷伊资源版即可（通常做这些事情的时候会展开逐级灰度，确保更捷伊稳定性）。
图形界面端合作开发
在穆萨的一年时间里，对于图形界面端合作开发主要就经历了一下几个阶段：
了解现有的图形界面端架构在已有的架构中合作开发捷伊子应用领域对于图形界面端架构的优化探索设计并实践捷伊图形界面端架构了解图形界面端架构
在前期对图形界面端控制技术展开了简单的科普之后，对于现有的图形界面端架构展开了深入了解，大致如下表所示图所示：
该架构主要就包含了罐子层、通用层和应用领域层三个层级，优点大致如下表所示：
所有的子应用放在同一个仓库中展开合作开发维护Webpack 多入口配置、Webpack 多进程处理以及合作开发态配置新增子应用领域时采用的控制技术栈会受到架构的限制选用 TypeScript 展开销售业务合作开发，鲁棒性好选用 Rxjs （Action 事件流）结合发布订户展开事件处理没有选用 React Router，简单页面的切换选用状态管理的方式展开处理合作开发捷伊子应用领域
刚开始展开客户端子应用领域合作开发时虽然意识到了架构结构的复杂性，但是并没有想到在架构上能做许多优化工作，只是在原有架构的基础上展开了应用领域层的局部优化处理。由于受到了架构的限制，无法选用 React Hook 以及 JavaScript 的许多新优点，代码的设计相对无法努力做到扁平化的结构方式。当时思考了许多子应用领域层面的代码结构层次优化，具体如下表所示图所示：
从图形界面端架构和以上思维导图能看出，这里对原有的应用领域层做了许多简单的变动。原有销售业务层本身的功能没有层级划分，是一种没有层级思维商业模式的合作开发方式。在前期延续旧的子应用领域思维商业模式时发现代码的结构无法适应需求带来的频密变化，因此思考了之后决定选用销售业务层分层的设计商业模式：
布局：可快速响应销售业务需求变化，重组销售业务模块，具备良好的可扩展性罐子：选用高阶函数封装，单纯对销售业务模块展开应用领域数据和行为的分发管控销售业务模块：对销售业务的模块化抽离，模块之间会设计某一的通讯数据这样的层级结构设计带来的好处是需求一旦发生排布变化，只需要在布局层做出相应的调整即可。
MVC 约束工程建设公共的数据层（Model），用于驱动销售业务层（View）更新，而销售业务层中的罐子则担任了控制器（Controller）的作用。除此以外，当销售业务变得极其复杂之后，数据层会变得相较难以维护，这里选用了分类的控制方式：
视图数据：经过数据适配层处理后的渲染视图数据通讯数据：用于销售业务模块之间的联动处理请求状态：用于缓存请求模块、游标 / 分页响应信息以及请求状态标识（默认视图、Loading 以及请求错误等处理）需要注意视图数据会随着销售业务的复杂度增加而增加，当视图数据和视图的关联越来越复杂后容易导致重复渲染问题，此时可通过 immutability-helper 配合 React.PureComponent 或 shouldComponentUpdate 展开处理（更多关于 React 的优化建议可查阅官方文档 Optimizing Performance ）。
温馨提示信息：很多老师书写的代码会强依赖后端接口数据，一旦后端数据失控很容易导致后端页面白屏。为了提升代码的健壮性和可维护性，在数据层中新增后端数据处理的适配层，能努力做到后端数据和后端视图的解耦处理。在适配的过程中能采用 ECMAScript proposal Stage-4 全力支持的 Optional Chaining 语法展开数据处理（假如编译环境不全力支持这种教捷伊语法，则能选用 Lodash 的 get 工具方法）。
图形界面端架构优化探索
在合作开发子应用领域的过程中，逐渐体会到旧客户端架构的许多痛点：
复杂的 Webpack 多入口配置以及冗余的合作开发态配置尽管采用了 parallel-webpack，应用编译速度缓慢，降低了合作开发效率没有 Hot Reload 潜能，降低了合作开发效率无法采用 React 新版的优点，例如 React Hook无法采用 JavaScript & TypeScript 的新版优点，例如 Optional Chaining销售业务层 / 罐子的高阶函数形成的地狱嵌套使得代码臃肿复杂，不利于代码的维护性简单子应用领域的 Rxjs 发布订户以及 Action 流机制不利于代码维护公共服务层以及物料层中的销售业务组件等通用性代码没有努力做到抽离解耦…大致设想了许多架构的局部优化处理：
从上图能看出，在原有架构的基础上新增了 Monorepo 结构，该架构的特点如下表所示：
解耦 Webpack 配置，将多入口配置优化成单入口配置，提升编译效率应用领域层能努力做到部分解耦，能配置许多新环境采用新优点Native API、销售业务组件以及公共服务等通用潜能能展开抽离解耦当时考虑了许多通用潜能的建设，但是子应用领域仍然无法努力做到真正的解耦。除此以外， Monorepo 本身并不能够减少应用领域的认知和维护成本，因此没有选用这套架构体系。该架构的设计思考奠定了解耦子应用领域的思维商业模式。
温情提示信息：Monorepo 的合作开发工具包括 Nx 、 Lerna 等。想要了解关于 Monorepo 的具体实践，能查阅 Vue CLI 3 结合 Lerna 展开 UI 架构设计。
控制技术沉淀
图形界面端架构优化实践
为了彻底努力做到子应用领域的解耦，捷伊子应用领域不在原有应用领域的仓库中展开合作开发和维护，而是选用了集团的工程化脚手架潜能展开独立的合作开发和维护。除此以外，还在脚手架的基础上新增了图形界面端子应用领域的通用模板潜能，可通过 CLI 命令一键快速生成：
大致介绍一下该工程化的潜能工程建设：
集团脚手架：简单认知为 react-scripts，可全力支持应用领域、组件以及小程序等多种合作开发商业模式工程化监控：用于监控并上报脚手架在合作开发采用过程中的编译性能以及本身的其中子应用领域合作开发模板的结构大致如下表所示所示：
这里主要就传授一下通用潜能工程建设：
ErrorBoundary：视图白屏处理（显示兜底的出错视图），并展开白屏的监控上报处理Hook：多端通用的自定义 Hook 潜能Request：多端通用的请求库，能处理缓存和 Loading 优化（某一请求时间内不产生 Loading，请求数据缓存等）Utils：通用的工具函数需要注意这里的子应用领域合作开发模板并没有努力做到动态插件化的潜能，而是相较固定的一个图形界面端合作开发模板。
温情提示信息：这里所言的多端是指小程序、H5、PC 客户端（Windows、Linux、Mac） 等，这是一个常规工程建设命题。
子应用领域解耦之后，图形界面端混和合作开发优化后的架构如下表所示图所示：
优化后的架构特性如下表所示：
新增工程化监控潜能，可快速感知各个子应用领域的合作开发效能Webpack 配置交由工程化脚手架维护提升编译的速度，增加 Hot Reload 潜能采用最捷伊 React 、JavaScript 以及 TypeScript 优点将子应用领域试点优化的多层级合作开发结构改造成扁平化的合作开发结构（去除高阶函数的罐子潜能）请求缓存、Loading 优化、视图的 ErrorBoundary 容错处理等体验提升视图白屏监测潜能真正解耦子应用领域，可努力做到客户端应用领域的订制化除此以外，在旧有架构的基础上新增了构建层。由于架构的优化解耦了各个子应用领域，因此需要将所有子应用领域的构建产物展开合并处理（成为客户端安装包中的 Web 后端离线产物），合并产物所包含的各个子应用领域还需要和客户端展开版映射。因此增加构建层用于处理各个子应用领域的版映射关系以及云构建协同处理，这里选用了 Jenkins、 Node 以及 Shell 展开各个子应用领域的在线构建和产物合并处理。
未来规划
图形界面端架构的优化实践虽然做了许多工作，合作开发效率也得到了极大的提升，但同时也增加了认知和合作开发协同成本。除此以外，在构建层做的太薄，除了构建本身以外还有很多可发挥的空间，这里就客户端未来工程建设做出许多粗略的规划。
文档中心
建立图形界面端合作开发的文档中心，能更好的帮助合作开发者在一无所知的情况下快速了解当前图形界面端控制技术和销售业务背景，文档中心未来大致会分为以下几个内容：
合作开发指南业务表明控制技术规划规范文档销售业务进展其中合作开发指南是重点，大概会包含以下许多内容：
合作开发简介基础概念总体架构项目模板合作开发工具合作开发调试版规范在线构建线上故障构建优化
构建层除了云构建本身以外，还能努力做到子应用领域合作开发规范的收口处理，具体如下表所示图所示：
其中会新增在线检测潜能，主要就包含：
规范：版、工程模板等是否符合合作开发规范架构：相较重要的库版检测资源大小：检测资源构建的大小潜能：检测是否接入监控、销售业务打点以及国际化潜能等代码质量检测：检测 Optional Chaining 等容易导致白屏的语法…流程协同主要就是提升构建的效率，在许多研发流程相关的闭环中能快速展开构建处理。比如在 Gitlab 中提交某一 commit 信息的代码或者 publish 某一分支即可触发构建（这一块和 Github Actions 类似），当然这里的触发层不仅仅涉及 Gitlab，还会涉及到很多穆萨内部的研发协同平台。
研发服务
研发服务是能打通整个研发链路的工具服务平台。例如构建优化架构中最顶层的虚线框就是其中非常重要的一个环节，除此以外也能接入工程化潜能、研发效能数据大盘、销售业务监控数据大盘、流程协同以及 HotFixed 潜能等。
研发服务是未来打通图形界面端（也能包括小程序、H5 等应用领域）整个研发链路的基础服务。在工程化层面能集成类似于 vue ui 的潜能，将现有的子应用领域模板展开灵活的插件化集成，从而能快速适应各个销售业务情景的研发诉求。除此以外，从建立应用领域、需求评审关联、需求变更、分支管理、需求合作开发、云构建、缺陷关联、灰度以及发布等整体的研发链路都能在研发服务平台完成，从而努力做到工程体系、流程协同、构建等一体化。
