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。後期方案：全部程序包圖片資源遠程保存，程序包中只保存圖片資源的路徑。