在日常開發中，我們經常遇到或者寫出這樣的程式碼

var sTrAngeNamingVariable = "a variable";

#if UNITY_IOS || UNITY_ANDROID || UNITY_EDITOR
        sTrAngeNamingVariable = "a!value";
#else
        sTrAngeNamingVariable = "other value";
#endif

巨集本身沒有什麼問題。但是 MonoDevelop IDE 上，只要寫了巨集判斷，後邊的程式碼的排版就會出問題。這是第一點。

第二點是，當我們發現 sTrAngeNamingVariable 的命名很不規範的時候，要對此變數進行重新命名。一般的 IDE 都會支援變數/類/方法的重新命名。

藉助 IDE 的重新命名功能，程式碼會變成如下:

var strangeVariableName = "a variable";

#if UNITY_IOS || UNITY_ANDROID || UNITY_EDITOR
    strangeVariableName = "a!value";
#else
    sTrAngeNamingVariable = "other value";
#endif

else 程式碼塊裡的變數重新命名沒有成功。當巨集判斷散落在各處時，很難發現這種錯誤。直到打包/AssetBundle/切換平臺時，問題才會暴露(筆者也是被坑了很多次T.T)。

從這裡得出的結論 : 當進行重構時，巨集相關的程式碼會對重構造成風險，也不利於維護。在這裡筆者設計出了 Platform。首先看下怎麼使用:

var strangeVariableName = "a variable";

if (Platform.IsiOS || Platform.IsAndroid || Platform.IsEditor)
{
    sTrAngeNamingVariable = "a!value";
}
else
{
    sTrAngeNamingVariable = "other value";
}

程式碼很簡單，就是把 巨集 換成了 Platform 而已。
這時候我們再進行下重新命名。重新命名後代碼如下:

if (Platform.IsiOS || Platform.IsAndroid
 
 || Platform.IsEditor)
{
    strangeNamingVariable = "a!value";
}
else
{
    strangeNamingVariable = "other value";
}

重新命名問題解決了。
Platform 的程式碼很簡單，貼出簡單看下就可以了。

namespace QFramework
{
    public class Platform
    {
        public static bool IsAndroid
        {
            get
            {
                bool retValue = false;
#if UNITY_ANDROID
                retValue = true;    
#endif
                return retValue;
            }
        }

        public static bool IsEditor
        {
            get
            {
                bool retValue = false;
#if UNITY_EDITOR
                retValue = true;    
#endif
                return retValue;
            }
        }

        public static bool IsiOS
        {
            get
            {
                bool retValue = false;
#if UNITY_IOS
                retValue = true;    
#endif
                return retValue;
            }
        }
    }
}

只是簡單的把巨集封裝了一下。

但是 Platform 不是萬能的，有一些事項還是要注意一下。

• 在有 Platform 的條件語句塊裡，不能使用平臺特有的 API ，如果要使用這種 API 還是建議封裝一下，平臺特有的 API 或者 巨集 最好不要出現在 UI 或者 邏輯層程式碼中。
• Platform.cs 這個類不能打成 dll。
• 其他的大家來補充:)，目前上線了幾個專案，都沒什麼問題。

當筆者在接手一個專案的時候，優先會把所有巨集相關的判斷，能換的全換成 Platform ，不能換的，比如使用了平臺特有 API 的都會簡單封裝下，然後再進行一些小部分的重新命名，以熟悉一些程式碼的邏輯。

有一些巨集判斷比較棘手，比如:

if ("1" == "2" || "2" == "3")
{
    // do sth
#if UNITY_EDITOR
}
else
{
    // do sth   
#else
    // do sth
#endif
}

如果遇到這種程式碼，
首先先揍一頓寫這種程式碼的人吧。哈哈，開玩笑的。
體諒一下吧，也許是版本太急了，誰都不想寫出這樣的程式碼，都有苦衷，都不容易，最起碼是沒有 bug 的。

解決辦法是有的，就是複製一遍程式碼。第一份程式碼刪掉 # if 程式碼塊的程式碼，把巨集換成對應的 Platform API，第二份程式碼刪掉 # else 程式碼塊的程式碼，然後一樣把巨集換成對應的 Platform API。 剩下的就容易解決了。

17 年年底的時候看了 《重構》 這本書，這裡還是推薦大家看一下吧，有點枯燥，但是收穫很多。

Hard Code 是難免的，追求程式碼質量的道路是沒有終點的，讓程式碼產生價值才是我們遊戲開發者要做的。

今天就到這裡。

相關連結:

QFramework&遊戲框架搭建QQ交流群: 623597263

微信公眾號:liangxiegame

如果有幫助到您:

如果覺得本篇教程對您有幫助，不妨通過以下方式贊助筆者一下，鼓勵筆者繼續寫出更多高質量的教程，也讓更多的力量加入 QFramework 。