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

Candy 是閑魚技術(shù)團(tuán)隊(duì)設(shè)計(jì)開發(fā)的一款引擎：

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

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

緣起

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

思考

我們主要通過(guò)下面三種思路來(lái)探討APP內(nèi)嵌小游戲：

采用Native的游戲能力

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

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

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

采用Flutter的輕量級(jí)互動(dòng)引擎

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

綜上考慮，我們決定采用Flutter的輕量級(jí)互動(dòng)引擎。

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

游戲系統(tǒng)不完善：引擎只有Game和Componet，沒(méi)有Scene和GameObject概念，這樣會(huì)導(dǎo)致游戲?qū)ο笄短讖?fù)雜，對(duì)多場(chǎng)景不友好。引擎完全采用Canvas來(lái)實(shí)現(xiàn)，游戲場(chǎng)景中無(wú)法實(shí)現(xiàn)局部刷新，存在性能隱患。缺少GUI系統(tǒng)，場(chǎng)景內(nèi)嵌套UI比較難。缺少手勢(shì)事件系統(tǒng)。動(dòng)畫支持格式不主流：骨骼動(dòng)畫是通過(guò)Flare支持的，不支持DragonBones。粒子動(dòng)畫最近才上，對(duì)主流格式支持也不太友好。資源管理存在內(nèi)存問(wèn)題，資源加載后一直不會(huì)釋放。缺少機(jī)型適配能力。

基于這些考慮，我們決定重新設(shè)計(jì)一款Flutter互動(dòng)引擎：

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

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

框架設(shè)計(jì)

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

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

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

整個(gè)互動(dòng)引擎架構(gòu)共分為四部分：

接口層

對(duì)外暴露的游戲接口，主要包含創(chuàng)建游戲、創(chuàng)建游戲?qū)ο蟆⑻砑佑螒蚪M件等接口，同時(shí)還封裝了一些常用游戲?qū)ο?、常用游戲組件的工廠接口。

游戲系統(tǒng)

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

游戲子系統(tǒng)

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

繪制系統(tǒng)

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

游戲系統(tǒng)

對(duì)標(biāo)Unity設(shè)計(jì)，游戲系統(tǒng)有下列四大元素：

Game：游戲類，負(fù)責(zé)整個(gè)游戲的管理，Scene的加載管理以及各子系統(tǒng)管理與調(diào)度。Scene：游戲場(chǎng)景類，負(fù)責(zé)游戲場(chǎng)景中各游戲?qū)ο蟮墓芾怼ameObject：游戲?qū)ο箢?，游戲世界中游戲?qū)ο蟮淖钚挝唬螒蚴澜缰械娜魏挝矬w都是GameObject。Component：游戲組件類，表示游戲?qū)ο蟮哪芰傩裕热鏢priteComponent表示精靈組件，表示繪制精靈的能力。

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

生命周期

對(duì)標(biāo)Unity和Flutter特性，我們?cè)O(shè)計(jì)了如表4-1所示的生命周期，共有八個(gè)回調(diào)，基本可以滿足互動(dòng)游戲業(yè)務(wù)開發(fā)。

渲染系統(tǒng)

基于融合Flutter繪制體系思考，我們就不能全盤用Canvas來(lái)做整個(gè)游戲的繪制管理，我們需要將游戲?qū)ο蠛虵lutter的繪制對(duì)象RenderObject結(jié)合起來(lái)，如圖4-4所示：

圖4-4 渲染映射

首先是Game的對(duì)象數(shù)和Flutter的三顆樹有效融合，所以每一個(gè)GameObject必須對(duì)應(yīng)一個(gè)Widget、Element和RenderObject。

融合過(guò)程主要需要解決以下問(wèn)題：

游戲的坐標(biāo)系與Flutter的布局轉(zhuǎn)換融合。動(dòng)態(tài)添加和刪除游戲?qū)ο蟮奶幚?。?dòng)態(tài)修改游戲繪制深度的處理。Flutter Inspector對(duì)游戲?qū)ο蟮闹С帧?/p>

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

GUI系統(tǒng)

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

這里給一段我們GUI的示例實(shí)例代碼，開發(fā)過(guò)程相對(duì)簡(jiǎn)單：

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被點(diǎn)擊了');
    },
  ),
  position: Position(100, 100),
);
game.scene.addChild(gui);

事件系統(tǒng)

在繪制融合到Flutter體系的基礎(chǔ)上，我們?nèi)诤狭耸录到y(tǒng)，增加了手勢(shì)處理組件GestureBoxComponent，如圖4-5所示：

整個(gè)融合過(guò)程分下列幾步：

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

動(dòng)畫系統(tǒng)

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

資源系統(tǒng)

目前互動(dòng)引擎的資源系統(tǒng)相對(duì)簡(jiǎn)單，本文就簡(jiǎn)單介紹下。資源系統(tǒng)的設(shè)計(jì)思路是復(fù)用APP的資源系統(tǒng)，確保整個(gè)APP只有一份資源庫(kù)，減少內(nèi)存開銷和增大資源復(fù)用率。資源系統(tǒng)架構(gòu)如圖4-6所示，在游戲系統(tǒng)和資源系統(tǒng)中間增加了一層代理，兼容APP資源系統(tǒng)和兜底資源系統(tǒng)。若我們沒(méi)有注冊(cè)APP的資源系統(tǒng)，系統(tǒng)會(huì)自動(dòng)調(diào)用兜底的資源系統(tǒng)。

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

兜底圖片庫(kù)，復(fù)用Flutter的ImageCache，復(fù)用Flutter的能力做內(nèi)存管理。

動(dòng)畫JSON資源管理，目前只實(shí)現(xiàn)了JSON讀取邏輯，由于JSON復(fù)用性不高，所以目前并沒(méi)有實(shí)現(xiàn)緩存管理。

目前資源系統(tǒng)沒(méi)有做遠(yuǎn)程加載和預(yù)加載的能力，這部分在我們的后續(xù)規(guī)劃中，后續(xù)我們?cè)僮姆窒砭唧w設(shè)計(jì)實(shí)現(xiàn)。

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