簡介： 最近APP游戲化成為了一個新的風口，把在游戲中一些好玩的、能吸引用戶的娛樂方式或場景應用在應用當中，以達到增加用戶粘性，提升DAU的效果，成本較低。同時在一些需要對用戶有引導性的場景，游戲化還可以使用戶更易于接受并完成引導性任務，并通過激勵的形式鼓勵用戶持續(xù)沉浸在任務當中，形成良性循環(huán)?；谶@個思路，閑魚開發(fā)了互動引擎Candy。

Candy 是閑魚技術團隊設計開發(fā)的一款引擎：

APP嵌入式的、輕量級的、易于開發(fā)、性能穩(wěn)定的互動引擎；繪制系統(tǒng)高度融合Flutter體系，游戲場景和Flutter UI支持無縫混排；動畫系統(tǒng)對主流格式的支持友好且易擴展。

本文講解我們?yōu)槭裁匆鲞@款引擎以及我們是如何設計這款引擎的。

緣起

目前APP內嵌小游戲一般采用H5小游戲的方式，而這個方式存在一些隱患，并不被很多應用商店推薦。因此我們需要尋找一種新的安全的方式來實現(xiàn)APP內嵌小游戲，并且我們希望這個方式開發(fā)友好、性能穩(wěn)定、功能齊全；所以我們遵循這三點去尋找一種新的方式。

思考

我們主要通過下面三種思路來探討APP內嵌小游戲：

采用Native的游戲能力

目前Native開發(fā)游戲生態(tài)并不是特別成熟，而且采用Native開發(fā)，就必須面臨雙端兩套代碼的問題，開發(fā)成本和后續(xù)維護成本都會比較高。

采用游戲引擎，比如Cocos-2dx、Unity等

雖然游戲引擎目前非常成熟，但是游戲引擎一般用于開發(fā)重度游戲，所以引擎大小一般比較大，引入游戲引擎會導致包大小增幅不小。而且游戲引擎比較復雜，所以引擎啟動耗時較多，比較難做到游戲頁面秒開；游戲引擎加載進來后內存消耗都會比較大。游戲引擎和APP間的通信互動相對較為麻煩，目前沒有比較好的混合棧支持。游戲引擎的UI能力較弱，無法勝任復雜的APP UI邏輯，若采用游戲引擎開發(fā)內嵌小游戲，無法融合小游戲頁面內游戲場景和Feeds等UI。

采用Flutter的輕量級互動引擎

Flutter本身是基于Skia這個2D繪制引擎實現(xiàn)的跨端APP解決方案，所以它天然具備2D繪制能力，所以采用Flutter來實現(xiàn)App內嵌小游戲存在可能。目前Flutter存在一些輕量級游戲引擎，比如Flame，這款引擎支持簡單游戲邏輯和動畫能力，同時整個游戲是以一個Widget的形式最終插入到APP中，可以讓小游戲頁面中游戲部分和UI部分完美融合。

綜上考慮，我們決定采用Flutter的輕量級互動引擎。

Flame引擎目前是Flutter生態(tài)中比較不錯的一款小游戲引擎，但是依然存在很多問題：

游戲系統(tǒng)不完善：引擎只有Game和Componet，沒有Scene和GameObject概念，這樣會導致游戲對象嵌套復雜，對多場景不友好。引擎完全采用Canvas來實現(xiàn)，游戲場景中無法實現(xiàn)局部刷新，存在性能隱患。缺少GUI系統(tǒng)，場景內嵌套UI比較難。缺少手勢事件系統(tǒng)。動畫支持格式不主流：骨骼動畫是通過Flare支持的，不支持DragonBones。粒子動畫最近才上，對主流格式支持也不太友好。資源管理存在內存問題，資源加載后一直不會釋放。缺少機型適配能力。

基于這些考慮，我們決定重新設計一款Flutter互動引擎：

對標集團的EVA引擎和業(yè)界的Unity引擎，完善游戲系統(tǒng)。復用Flutter局部刷新。復用Flutter UI作為GUI。復用Flutter手勢管理。實現(xiàn)支持主流格式的骨骼動畫和粒子動畫。復用APP資源庫（圖片庫）。實現(xiàn)全局750適配。

其中2-4點本質上是將互動引擎的繪制系統(tǒng)融合入Flutter的繪制體系中，本文下面按解決上面問題的思路依次介紹我們的引擎設計。

框架設計

首先分析游戲化業(yè)務需要哪些能力，分析我們的業(yè)務場景，得出游戲化業(yè)務需要圖4-1所示的能力：

拆解后，互動引擎需要有游戲系統(tǒng)、繪制系統(tǒng)、生命周期系統(tǒng)、GUI系統(tǒng)、物理系統(tǒng)、動畫系統(tǒng)、資源系統(tǒng)、事件系統(tǒng)（手勢管理）。

根據我們之前的定位，互動游戲繪制融合到Flutter繪制體系中來，基于這個思路，我們可以復用Flutter的UI系統(tǒng)，同時需要融合Flutter和游戲的手勢管理。最終我們得出如圖4-2所示的框架圖：

整個互動引擎架構共分為四部分：

接口層

對外暴露的游戲接口，主要包含創(chuàng)建游戲、創(chuàng)建游戲對象、添加游戲組件等接口，同時還封裝了一些常用游戲對象、常用游戲組件的工廠接口。

游戲系統(tǒng)

游戲世界的管理系統(tǒng)，主要管理Game、Scene、GameObject和Compoent間的組織關系，還控制游戲子系統(tǒng)和繪制系統(tǒng)的啟動與關閉。

游戲子系統(tǒng)

游戲化能力補充，主要包含生命周期系統(tǒng)、物理系統(tǒng)、動畫系統(tǒng)和資源系統(tǒng)，被游戲系統(tǒng)調用。

繪制系統(tǒng)

負責游戲的繪制，本引擎的繪制系統(tǒng)會高度和Flutter繪制邏輯融合，所以兼容了GUI系統(tǒng)和事件系統(tǒng)（手勢管理）。

游戲系統(tǒng)

對標Unity設計，游戲系統(tǒng)有下列四大元素：

Game：游戲類，負責整個游戲的管理，Scene的加載管理以及各子系統(tǒng)管理與調度。Scene：游戲場景類，負責游戲場景中各游戲對象的管理。GameObject：游戲對象類，游戲世界中游戲對象的最小單位，游戲世界中的任何物體都是GameObject。Component：游戲組件類，表示游戲對象的能力屬性，比如SpriteComponent表示精靈組件，表示繪制精靈的能力。

GameObject通過組合Component的形式來讓自己擁有各種能力，不同的組合讓GameObject相互之間不一樣。整個游戲系統(tǒng)的組織關系如圖4-3所示：

生命周期

對標Unity和Flutter特性，我們設計了如表4-1所示的生命周期，共有八個回調，基本可以滿足互動游戲業(yè)務開發(fā)。

渲染系統(tǒng)

基于融合Flutter繪制體系思考，我們就不能全盤用Canvas來做整個游戲的繪制管理，我們需要將游戲對象和Flutter的繪制對象RenderObject結合起來，如圖4-4所示：

圖4-4 渲染映射

首先是Game的對象數和Flutter的三顆樹有效融合，所以每一個GameObject必須對應一個Widget、Element和RenderObject。

融合過程主要需要解決以下問題：

游戲的坐標系與Flutter的布局轉換融合。動態(tài)添加和刪除游戲對象的處理。動態(tài)修改游戲繪制深度的處理。Flutter Inspector對游戲對象的支持。

整個繪制融合相對復雜，需要解決很多BadCase，后續(xù)會另撰文詳述互動引擎繪制融合Flutter繪制體系的過程，本文不再贅述。

GUI系統(tǒng)

由于繪制已經融合到Flutter體系，GameObject都會對應Widget，所以我們可以設計一個特殊的GameObject，支持插入一段Flutter Widget樹，這樣我們就不需要另外實現(xiàn)GUI了，復用Flutter UI作為GUI即可。這個邏輯和繪制融合思路比較一致，將插入的Widget樹作為GUIWidget的孩子即可，在GUIRenderObject中打通layout、paint和hitTest邏輯即可。

這里給一段我們GUI的示例實例代碼，開發(fā)過程相對簡單：

final GUIObject gui = IdleFishGame.createGUI(
  'gui',
  child: GestureDetector(
    child: Container(
      width: 100.0,
      height: 60.0,
      decoration: BoxDecoration(
        color: const Color(0xFFA9CCE3),
        borderRadius: const BorderRadius.all(
          Radius.circular(10.0),
        ),
      ),
      child: const Center(
        child: Text(
          'Flutter UI示例',
          style: TextStyle(
            fontSize: 14.0,
          ),
        ),
      ),
    ),
    behavior: HitTestBehavior.opaque,
    onTap: () {
      print('UI被點擊了');
    },
  ),
  position: Position(100, 100),
);
game.scene.addChild(gui);

事件系統(tǒng)

在繪制融合到Flutter體系的基礎上，我們融合了事件系統(tǒng)，增加了手勢處理組件GestureBoxComponent，如圖4-5所示：

整個融合過程分下列幾步：

GestureBoxComponent將開發(fā)者注冊手勢回調方法注冊到手勢識別器中。GameObject對應的RenderObject復寫hitTest邏輯，按Flutter規(guī)范來處理點擊的hitTest。通過GestureBoxComponent來判斷點擊是否該被消費。GameObject復寫handEvent來將點擊事件傳遞給GestureBoxComponent消費。GestureBoxComponent收到點擊事件后，傳遞給手勢識別器處理。手勢識別器在將點擊傳給手勢競技場開始手勢競技，最終將勝出的手勢返回手勢識別器，最終返回并做出手勢事件響應，當然這一步屬于Flutter邏輯了。

動畫系統(tǒng)

我們目前動畫主要支持骨骼動畫和粒子動畫，骨骼動畫資源目前支持DragonBones，粒子動畫資源目前支持EgretFeather。

資源系統(tǒng)

目前互動引擎的資源系統(tǒng)相對簡單，本文就簡單介紹下。資源系統(tǒng)的設計思路是復用APP的資源系統(tǒng)，確保整個APP只有一份資源庫，減少內存開銷和增大資源復用率。資源系統(tǒng)架構如圖4-6所示，在游戲系統(tǒng)和資源系統(tǒng)中間增加了一層代理，兼容APP資源系統(tǒng)和兜底資源系統(tǒng)。若我們沒有注冊APP的資源系統(tǒng)，系統(tǒng)會自動調用兜底的資源系統(tǒng)。

兜底資源系統(tǒng)目前分兩部分：

兜底圖片庫，復用Flutter的ImageCache，復用Flutter的能力做內存管理。

動畫JSON資源管理，目前只實現(xiàn)了JSON讀取邏輯，由于JSON復用性不高，所以目前并沒有實現(xiàn)緩存管理。

目前資源系統(tǒng)沒有做遠程加載和預加載的能力，這部分在我們的后續(xù)規(guī)劃中，后續(xù)我們再撰文分享具體設計實現(xiàn)。

本文主要講述了Candy互動引擎的設計，而我們在設計實現(xiàn)過程中遇到了很多問題，如發(fā)現(xiàn)了Flutter在繪制過程中存在一定的內存泄露，內存回收不及時等，我們后續(xù)會詳述這些問題的排查與解決，同時還會對Candy引擎的性能與穩(wěn)定性方面做詳細測試分析。