整體架構
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。后期方案：所有程序包圖片資源遠程保存，程序包中只保存圖片資源的路徑。