在日常開發中，我們經常遇到或者寫出這樣的代碼 ```cs var sTrAngeNamingVariable = "a variable"; #if UNITY_IOS || UNITY_ANDROID || UNITY_EDITOR sTrAngeNamingVariable = "a!value"; #else sTrAngeNamingVariable = "other value"; #endif ``` 宏本身沒有什么問題。但是 MonoDevelop IDE 上，只要寫了宏判斷，后邊的代碼的排版就會出問題。這是第一點。 第二點是，當我們發現 sTrAngeNamingVariable 的命名很不規范的時候，要對此變量進行重命名。一般的 IDE 都會支持變量/類/方法的重命名。 借助 IDE 的重命名功能，代碼會變成如下: ```cs var strangeVariableName = "a variable"; #if UNITY_IOS || UNITY_ANDROID || UNITY_EDITOR strangeVariableName = "a!value"; #else sTrAngeNamingVariable = "other value"; #endif ``` else 代碼塊里的變量重命名沒有成功。當宏判斷散落在各處時，很難發現這種錯誤。直到打包/AssetBundle/切換平臺時，問題才會暴露(筆者也是被坑了很多次T.T)。 從這里得出的結論 : 當進行重構時，宏相關的代碼會對重構造成風險，也不利于維護。在這里筆者設計出了 Platform。首先看下怎么使用: ```cs var strangeVariableName = "a variable"; if (Platform.IsiOS || Platform.IsAndroid || Platform.IsEditor) { sTrAngeNamingVariable = "a!value"; } else { sTrAngeNamingVariable = "other value"; } ``` 代碼很簡單，就是把 宏 換成了 Platform 而已。 這時候我們再進行下重命名。重命名后代碼如下: ```cs if (Platform.IsiOS || Platform.IsAndroid || Platform.IsEditor) { strangeNamingVariable = "a!value"; } else { strangeNamingVariable = "other value"; } ``` 重命名問題解決了。 Platform 的代碼很簡單，貼出簡單看下就可以了。 ```cs 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 的都會簡單封裝下，然后再進行一些小部分的重命名，以熟悉一些代碼的邏輯。 有一些宏判斷比較棘手，比如: ```cs 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 是難免的，追求代碼質量的道路是沒有終點的，讓代碼產生價值才是我們游戲開發者要做的。 今天就到這里。 轉載請注明地址：涼鞋的筆記：[liangxiegame.com](http://liangxiegame.com) ## 更多內容 * QFramework 地址：[https://github.com/liangxiegame/QFramework](https://github.com/liangxiegame/QFramework) * QQ 交流群：[623597263](http://shang.qq.com/wpa/qunwpa?idkey=706b8eef0fff3fe4be9ce27c8702ad7d8cc1bceabe3b7c0430ec9559b3a9ce66) * **Unity 進階小班**： * 主要訓練內容： * 框架搭建訓練（第一年） * 跟著案例學 Shader（第一年） * 副業的孵化（第二年、第三年） * 權益、授課形式等具體詳情請查看[《小班產品手冊》](https://liangxiegame.com/master/intro)：https://liangxiegame.com/master/intro * 關注公眾號：liangxiegame 獲取第一時間更新通知及更多的免費內容。