接下來的時間主要都會花在實作上，可能不太會有時間記錄。像是今天，真正能開始撰寫時也只剩下不到一小時。在這樣短的時間來記錄一下Remote Config的使用好了。

在Unity搭配Firebase的專案裡，有二個現成的Remote Config可以使用，一個是Unity提供的，而另一個則是Firebase提供的。然而，在前後端都有可能會使用到Remote Config的情況下，用Unity Remote Config比較方便，Firebse最主要還是只能用在手機和Web的平台。不過在後端有各式各樣的資料讀取替換的方式，如Database等，用或不用Remote Config好像差異不大。但就算是考量到前端的環境中，Unity Remote Config仍是有比Firebase Remote Config較好的使用方式。

Unity Remote Config可以有多層次的分類，好比說要依據開發環境或是Release環境來進行資料的引用，則可以在一開始時就分類好，並於適當的環境裡進行切換。Firebase Remote Config就需要自行在命名key時放入Prefix，到時再依照不同的環境組合key後使用。

實際在Unity裡的Code很單純

public struct UserAttributes
{
}

public struct AppAttributes
{
}

ConfigManager.FetchCompleted += ApplyRemoteSettings;
ConfigManager.SetEnvironmentID(remoteConfigEnvironmentId);
ConfigManager.FetchConfigs<UserAttributes, AppAttributes>(
    new UserAttributes(), new AppAttributes());

switch (configResponse.requestOrigin)
{
    case ConfigOrigin.Default:
        break;
    case ConfigOrigin.Cached:
        break;
    case ConfigOrigin.Remote:
        _gameServerIp = ConfigManager.appConfig.GetString("game-server-ip");
        break;
}

在使用上的Code就是這樣，沒有太複雜的設定。主要就是註冊FetchCompleted並於接收的地方確認

• Default
• Cached
• Remote

如果是Remote則資料是從網路上拿下來的，要不然就是本地端的暫存。

且用Unity Remote Config還有一個方便處是可直接在Unity Editor的UI裡進行key, value的更新和變更。變更後可以直接反應到Dashboard裡的值。

除此之外，Unity也有提供API，可以利用API的方式進行值的變更，可以從API文件裡看到所有的用法，但這個API的認證機制很奇怪，要先利用自己的Unity Account帳密去換token後再回來使用。若是以個人操作來看，這不是太大的問題，但要放到CI時，這就有點麻煩。這也是為什麼這一陣子也開始在研究Vault的原因之一。