Scratch3的结构

总体架构

Scratch3的界面功能划分以下图

Scratch的总体架构以下图所示

scratch-gui: 是基于React的组件库，组成了整个页面。对于界面有定制化的在这个库下进行

scratch-blocks：积木编程模块，建立和生成积木块区域和拖拽效果区域。须要定制化积木块以及积木块相关功能的在这个库下进行　

scratch-vm：虚拟机，管理状态并执行业务逻辑，前端GUI的状态及逻辑部分处理。须要定制化扩展组建在这个库下进行

scratch-l10n：多语言环境，简单描述全部的翻译都在此库

scratch-render：舞台区渲染，在舞台区域出现的基于WebGL的处理器。底层处理svg使用的是scratch-svg-renderer。同类的还有一个scratch-paint，用来处理造型画图。

scratch-storage：做品存储加载

scratch-audio: 声音处理

为何要这么设计

• 从流程上来讲，应该是用户针对每个角色/背景在积木区拖拽出一堆积木程序，而后加上角色/背景的初始化数据，能够转化成固定的表明这个角色/背景动画的结构数据。而后用户点击运行，数据将被一个渲染引擎处理展现到舞台上，造成动画。
  从系统的复杂性来讲，解耦很是由必要，那么按照流程划分，至少有这么几块，基本操做UI层（即scratch-gui,能够包括角色/背景选择，用户的点击按钮等）、单角色/背景积木拼接并转化为结构化数据(即scratch-blocks)、渲染引擎。

• 就渲染来讲，通常分红两个部分：单帧渲染和渲染动画控制
  就如同咱们看视频同样，每个视频都是由不少帧组成的，每一帧的渲染应当是同一个处理，独立出来即scrach-render。在Scratch中回控制帧的播放暂停等操做，须要由一个控制器来管理，即scratch-vm。
  在Scratch的真实场景中，致使scratch-render从新绘制的状况不少，好比修改角色的大小，位置，颜色等等，这些状态的变动管理都归入到scratch-vm中。

• 多语言部分，对于整个系统来讲，各个部分均可能须要，因此独立为一个通用模块比较好

• Scratch代码最终会生成程序代码，须要有地方存储和加载解析。并且这块功能比较独立，因此当都做为一个模块是有必要的。
  程序的存储目前有两种方案。
  一种是将整个程序打包成一个压缩文件，里面包括了程序运行所须要的全部资源和数据结构。这种程序报能够下载下来，即便在离线的状况下，也能够本地载入运行。缺点是程序包可能会过大，并且多个程序可能共用同一个资源（好比一张图片），可是每一个程序包中都必需要有一份，上传下载程序包都很是消耗带宽。
  另外一个方案是全部资源都在服务器端保存，每次存储只需存储数据结构便可，资源所有使用url连接，程序包大大缩小。在程序载入时自动到远程拉取资源。缺点是没法在没有网络的状况下运行（没法保存/下载）。
  Scratch在设计之初是要作纯前端的可视化编程系统，因此内置了全部资源的url。编程后能够下载完整的程序压缩包。不用依靠后台也能玩起来。

• 声音处理模块独立缘由很简单，不是必须功能，并且功能相对独立，内部处理还复杂，独立出来就对了

• 从结构层次来讲，Scratch的结构相对扁平（不考虑服务端）。就功能来看，系统由一个个独立功能功能组成，好比scratch-blocks，该模块实现了积木拼接代码，实现代码转义为结构化数据的功能，彻底能够独立出来做为一个系统。这些一个个独立的功能模块须要一个粘合剂，将他们的数据和状态串起来，这就是scratch-vm。
  scratch-vm中保存着每个角色/背景的初始化状态，保存着每个角色/背景的代码逻辑（积木转义而来），操控代码的渲染逻辑。提供了大量的渲染控制api以及相关事件的钩子函数。
  能够说scratch-vm是整个系统的数据处理中心。

• Stage层是scratch-gui的共享数据层。里面保存着gui层的共享数据。

Stage层

和scratch-vm不一样，scratch-vm管理的是代码编程相关的状态，直白来讲就是管理让用户编辑的代码积木跑起来；而Stage是管理网页自身的数据，好比登陆态数据、页面加载状态、舞台缩放展现、对话框消息数据等等。
这其中有一个比较复杂的状态：页面加载状态

这是因为这个庞大的前端项目要跑起来，须要加载的数据和处理类型比较多。好比加载一个做品，就可能出现经过做品id远程加载，若是没有id要加载默认模板，还能够经过本地上传一个程序包载入；在用户操做过程当中，用户可能手动保存，可是程序自身也会定时保存。
状态的命名仍是比较规范的。若是在这之间增长一写状态(好比，新增一个能够经过homeworkId获取展现默认模板，必然要在FETCHING_NEW_DEFAULT状态之上增长一个状态)，则必需要对以前的状态了如执掌才能修改，不然可能致使遗漏或状态冲突.

加载优化

在实际运行中，这个系统加载的数据仍是很是庞大的，并且如今移动端有独立运行舞台区的需求，而目前只展现舞台区，可是加载了不少无关的模块。须要作加载相关的优化。
分析：

• 系统庞大，代码量比较多，加载数据比较多。可是并非每个模块在页面初始化时用到。
• 脚本公共出口就只有一个，加载的模块同样。应该提供一些独立功能（好比只展现舞台）的入口脚本。
• 目前咱们系统每次保存，是将编程后全部的数据（包括图片）打成了一个完整的压缩包。这块有很大优化空间
• 对代码打包结果模块分析，发现有不少地方用到同一模块，可是每一块都有一份代码拷贝
• 打包后全部代码只有一个js，有26M。每次一个微小的修改都打出新包，没法利用浏览器的缓存。

策略：

• 分模块异步加载，程序初始化不须要用到的模块经过异步懒加载的方式独立出去。减小初次进入的包体积
• 公共模块打包提取。在打包过程当中由不少公共包在不一样的chunk中都有，重复加载了。
• 静态模块/第三方包单独打包，这些模块一般改动比较小，程序改动了，可是没有动到这个部分，这个部分的包就不会从新打。那么能够利用浏览器缓存。
• 运行时模块单独打包，运行时包括连接模块，加载/解析逻辑等。用来定位模块信息的manifest一并包含在里面
• 拆分入口，主要拆分红三个入口：一个PC编程入口，包括了全部的部分；一个专门运行程序包的入口，无关模块都剔除；一个只包含积木编程区的入口，无关的模块剔除
• 减小编程代码程序包大小。简单方案：程序包中的角色/背景图片的压缩，简单图案使用svg。后期方案：全部程序包图片资源远程保存，程序包中只保存图片资源的路径。