-

This is the translated version of my 2020 Unity 和 git post with some minor updates and all the Chinese reference links removed. Sorry I am not a fluent English speaker. Please leave a comment if something seems wrong/out-dated. Thank you.

+

This is the translated version of my 2020 Unity 和 git post with some minor updates and all the Chinese reference links removed. Sorry I am not a fluent English speaker. Please leave a comment if something seems wrong/out-dated. Thank you.

I’ve been using Git to version control Unity projects for a while now. Recently, my company open-sourced our Unity builder mimiron-lite, along with a new set of Git configuration files that are now being used as Git configuration standard of my company . I would like to share some insights regarding the thought process behind these configuration files and the experiences of using Git.

If you prefer a TL;DR, you can directly download the Git configuration files. The latest configuration now includes an updated .gitignore for Wwise, available at: https://github.com/FrankNine/RepoConfig.
This repo was forked from: https://github.com/rayark/repo-config.
diff --git a/posts/unity-mobile-optimization-prologue/index.html b/posts/unity-mobile-optimization-prologue/index.html index 837936a..6c9eba1 100644 --- a/posts/unity-mobile-optimization-prologue/index.html +++ b/posts/unity-mobile-optimization-prologue/index.html @@ -156,7 +156,7 @@

一分證據說一分話 (

C/P 值高的先做 (Go after the low-hanging fruit)

絕大多數時候浪費的效能都是在很好解決的東西上面，當你想要繼續往上推就可能會越來越難做，效益也越來越差。當然要判斷哪邊 C/P 值高還是要靠 Profiler ，所以還是再說一次 Profiler 很重要。

不一定要最佳化「所有」東西

-

程式的執行效率只是程式品質眾多面向的其中一個，有的時候別的東西的價值可能會比效率重要。Unity 社群裡面常常在爭執的 foreach 問題就是一個很好的例子，有些人會覺得那 24 bytes 的 GC Allocation 實在是不能忍，要除惡務盡把所有 foreach 都改成 for 。但是我覺得我會比較看重可讀性而不去把它改成 for ，這當然沒有一定標準，只是想提醒一下執行效率不是程式的一切、可讀性、可維護性等等也是很重要的。最佳化可能會犧牲它們，犧牲它們之前想想這個交易划不划算。

+

程式的執行效率只是程式品質眾多面向的其中一個，有的時候別的東西的價值可能會比效率重要。Unity 社群裡面常常在爭執的 foreach 問題就是一個很好的例子，有些人會覺得那 24 bytes 的 GC Allocation 實在是不能忍，要除惡務盡把所有 foreach 都改成 for 。但是我覺得我會比較看重可讀性而不去把它改成 for ，這當然沒有一定標準，只是想提醒一下執行效率不是程式的一切、可讀性、可維護性等等也是很重要的。最佳化可能會犧牲它們，犧牲它們之前想想這個交易划不划算。

除了哪種最佳化要不要做之外，也可以考慮哪邊要做哪邊不做。通常 Gameplay 是最需要效率的標準比較高，在時間不夠的情況下當然是先優化 Gameplay 。反過來選單之類的就不那麼需要效能，犧牲一點效率讓讓選單部分的程式保有更多的可讀、可維護性也許是比較好的策略。

確定最佳化的目標

在最佳化開始之前最好先確定你的目標，像是在哪種規格上要跑到多少 FPS 。達到目標之後的最佳化其實就沒有甚麼意義了，如果不會 Frame drop ，跑再快使用者的感受到的都差不多。可以定像是記憶體不能接近 256MB (實體記憶體 512 MB 的機器單一 App 能用的記憶體大概一半)，或是 OpenGL ES2 (放棄 ETC2 壓縮格式)。如果對規格沒有想法，可以想說自己的遊戲大概幾年前的主力手機應該要能玩，像如果抓四年前，那就是看 Galaxy S3 跟 iPhone 5 的規格。如果你曾經上架過遊戲，Google 跟 Apple 的後台都有使用者用的機器分布，參考這項資料照顧一下既有玩家也是很重要的。

diff --git a/posts/unity-on-ios9/index.html b/posts/unity-on-ios9/index.html index 0535e3e..5218c11 100644 --- a/posts/unity-on-ios9/index.html +++ b/posts/unity-on-ios9/index.html @@ -146,7 +146,7 @@

App Transport Security

https://developers.facebook.com/docs/ios/ios9

我本來以為 Prime31 的作者會在新版本裡面加入修改 info.plist 的選項，不過他老兄很霸氣的說應該是 Facebook 的責任要自己把連線修成 HTTPS ，所以現在還是得自己加：

http://support.prime31.com/22777/social-networking-plugin-on-ios-9?show=22777#q22777

-

以我之前的 Xcode Postprocessing 教學 的當作基底，可以用完全一樣的 PlistDocument 操作把這些設定加到 info.plist 。Code 大概像是：

+

以我之前的 Xcode Postprocessing 教學 的當作基底，可以用完全一樣的 PlistDocument 操作把這些設定加到 info.plist 。Code 大概像是：

 1
diff --git a/posts/unity-profiling-tools/index.html b/posts/unity-profiling-tools/index.html
index d901240..275d1b5 100644
--- a/posts/unity-profiling-tools/index.html
+++ b/posts/unity-profiling-tools/index.html
@@ -187,7 +187,7 @@ 
共用控制 UI

 adb forward tcp:34999 localabstract:Unity-<你的遊戲 bundle ID>
-

另一個方法是上一篇有提到的改用 TCPIP 模式。

+