我們來詳談Unity的transform使用，這里所說的tansform不是類UnityEngine命名空間下的Transform，而是transform.
Transform 是Unity中最常用的類了摊腋。
其類的代碼如下，代碼貼出來太長也不是要說的重點：
我們所說的是常用的還有對象組件自身的transform，他里面包含了位置昏鹃，旋轉(zhuǎn)，縮放參數(shù)诀诊。
在常用組件Compnent的代碼中：
注意這個東西是屬性洞渤，有g(shù)et，沒有set.
當(dāng)然命名空間仍舊為UnityEngine属瓣。
我們先來看看讯柔，這個WrapperlessIcall ，它是unity中一個屬性字段护昧，他有什么用呢魂迄？
WrapperlessIcall 內(nèi)部實現(xiàn)，非公開方法惋耙。
大家來看看如下代碼：
看起來稀松平常极祸，波瀾不驚，但是下面水還是蠻深的怠晴。
使用myTransform替代this.transform遥金。如果你不知道u3d內(nèi)部實現(xiàn)獲取方式你肯定會以為這人腦抽水了，有直接的不用蒜田，還自己保存起來稿械。
this.transform并不是變量，而是一個get/set屬性（property）
他是一個C++寫的代碼冲粤，在Mono中被調(diào)用美莫。調(diào)用是intenal method的調(diào)用，其效率本身不是高梯捕。
比如厢呵，transform 經(jīng)常需要保存在本地，然后在使用傀顾。
n
值得注意的是這個調(diào)用方法略慢襟铭，因為你需要調(diào)用外部的CIL（aka interop），花費了額外的性能短曾。
個人覺得這個是之前的unity版本的東西嫉拐，可能效率和性能沒有做優(yōu)化哩都。
WrapperlessIcall][MethodImpl(MethodImplOptions.InternalCall)]
1
2
就這些屬性來說，有的是直接調(diào)用C++代碼婉徘，有的則是調(diào)用.net的內(nèi)部函數(shù)到Unity中漠嵌。
對于新的版本是不是有的優(yōu)化處理呢，自己做了測試：
先看看現(xiàn)在Compnent的代碼：
效率有手動cache （4ms）>>transform(20ms)>>this.tranform(22ms)>> GetComponent()(54ms)
但是原來的測試結(jié)果為：
1000000 次的Iterations
GetComponent=619ms
Monobehaviour = 60ms
CachedMB = 8ms
Manual Cache = 3ms
看來這其中還是有奧秘的盖呼。
我電腦配置目前還算可以儒鹿，win7 64 位，I7-3770 + 960顯卡+ 16G內(nèi)存塌计。
結(jié)果對比挺身，相對與之前2012年Unity版本侯谁，可能mono做了很大的優(yōu)化锌仅，當(dāng)然我們的電腦可能還是不一樣章钾，沒有辦法直接做對比，也只能猜測而已热芹。
但是結(jié)論還是一樣的：
在以后的使用中贱傀，若大量使用，還是需把transform給手動保存下來吧伊脓。
說明：
代碼做了修改：
原來的代碼中有這些：
我還想努力一把Ｖ晟Α！
讓別人可以直接用纯蛾，但是有不修改原有代碼：
怎么辦呢纤房？
既然大家都要繼承monobehaviour,那我就在他上面想辦法。
但是這個擴展方法炮姨，必須靜態(tài)的，所以沒有辦法做一個靜態(tài)的臨時變量啊碰煌，這個不靠譜啊舒岸。
若寫成上面的代碼效率并沒有太多提高。每次還是需要賦值芦圾。
所以這個路走不通岸昱伞！个少！
來看方法二吧碍脏。
UnityMonoBehaviour 這個是啥呢典尾？哈哈
看using UnityMonoBehaviour = UnityEngine.MonoBehaviour;
我們來看看結(jié)果：
直接使用tranform 和this.tranform花費時間為9ms，比上面的20多ms,那是降低了很多糊探。
但是钾埂，這個是結(jié)論啊，還是沒有手動緩存的效果高啊科平，依舊為4ms褥紫。
放出所有代碼：
https://forum.unity3d.com/threads/cachedmb.130365/
http://blog.sina.com.cn/s/blog_5b6cb9500101fkal.html
http://answers.unity3d.com/questions/700468/where-do-methods-mocked-with-wrapperlessicall-meth.html
