淺談.NET Micro Framework性能優(yōu)化
.NET Micro Framework的可剪裁性，高定執(zhí)行，和天生對硬件高集成度都讓它的前途一片光明。當然，它現在還很年輕，就發(fā)布的SDK v3.0來看，它還有很長的路要走。
廢話不說，就這幾個月我用下來的經驗談談在針對.NET Micro Framework應用程序的性能優(yōu)化吧。
1. 盡可能減少方法調用！
方法調用過于頻繁對于性能的影響非常大，所以所有的優(yōu)化都是以這個為大前提的。
2. 盡可能避免使用屬性，而用公共域來代替。
因為編輯器會在編譯的時候為每個屬性的getter和setter添加訪問方法，基于***條，這是要避免地。
當然也不是說完全避免使用屬性了，畢竟有的時候屬性是很方便且必要的。
比如這個下面這個使用屬性的例子：
- public class Test
- {
- public string Name { get; set; }
- }
需要把它改成這樣：
- public class Test
- {
- public string Name;
- }
3. 只在構造函數里面初始化變量。
這一條很容易明白，看下面的例子：
- public class Test
- {
- private string name = "Test String";
- private DateTime date = DateTime.Now;
- private int score, counter;
- public Test()
- {
- score = 0;
- counter = 0;
- }
- }
初始化的工作其實進行了兩次，一次是在聲明變量的時候，另外一次是在調用構造函數的時候。遵循***條原則，我們要盡可能減少方法調用，且構造函數的使用概率很高，所以我們在此需要把初始化的工作全部集中到構造函數里面來進行。
4. 只在必要的地方調用lock。
對于MF這樣一個半實時的系統(tǒng)來說，lock的成本遠遠高于我們的想象。在.NET里面可能感覺不出來，但到了MF這個小伙子手里感覺就非常明顯了，也許這一條大家已經知道了，就當我老調重彈吧。
看這個例子：
- public class Test
- {
- private ArrayList objs;
- public void SomeMethod(object o)
- {
- for(int i = 0; i < 100; i++)
- {
- if (objs.Contains(o))
- {
- lock(objs.SyncRoot)
- {
- objs.Remove(o);
- }
- }
- }
- }
- }
在一個循環(huán)里面增刪一個集合，由于是多線程訪問，所以在操作之前加了鎖。之所以在循環(huán)內部加鎖，理由可能是想盡可能的減少lock的訪問次數，只有滿足那個if條件的時候才會被調用。
實際上，這個想法錯了，無論如何，這里的lock都會被調用很多次，這些開銷加起來就會對性能造成很大的影響。
把代碼改成這樣就會好很多：
- public class Test
- {
- private ArrayList objs;
- public void SomeMethod(object o)
- {
- lock(objs.SyncRoot)
- {
- for(int i = 0; i < 100; i++)
- {
- if (objs.Contains(o))
- {
- objs.Remove(o);
- }
- }
- }
- }
- }
5. 保證每個時間只有一個線程在運行。
用慣了.NET，來到MF世界***個不適應就是它的多線程太慢了，如果同時打開兩個線程工作，那么整個程序的效率都會受到極大的影響。
拿電子地圖軟件來做例子，主線程負責更新UI，工作線程負責在后臺取得地圖塊。這樣的設計本身無可厚非也是合理的，但***我們發(fā)現性能實在太差了。
后來更改成為當用戶在操作UI的時候，工作線程全都暫停，只有檢測到用戶沒有任何操作的時候才進行工作。
要實現這一點，就要求程序在設計的時候就考慮到工作線程的可暫停性。
6. 盡可能少的并且在最小的范圍內調用Invalidate()方法。
很多人在重畫UI之后都會習慣性的調用頂層元素的Invalidate()方法來更新所有子控件，因為這樣是最快捷的。可很多時候我們忽略了一點，Invalidate()這個方法可能在背后已經被調用過很多次了。
比如，有的控件會在得到焦點的時候調用這個方法，有的控件會在出發(fā)用戶事件的時候自動調用這個方法。因為這些都是在背后發(fā)生的，我們可能并不知情，所以在完成我們自己控件的繪制之后通常會調用parent的Invalide來更新整個布局，這樣就會在不知不覺之間導致了不必要的重畫產生。
要避免這個問題也很簡單，一則仔細觀察，二則用Refactor！去閱讀一下別人的代碼。
7. 盡可能少的使用圖片資源。
因為MF本身的數據吞吐量很小，如果載入過多圖片資源的話，輕則程序運行效率變低，重則出現內存溢出。所以這里的原則我們要參照網頁的設計原則，例如一個按鈕圖片，把它切割成幾個小塊，利用重復貼圖來完成中間部分，而不要直接使用一整張圖片。
同樣在制作高亮的時候可以通過改變圖片透明度或者在圖片上面加一層透明矩形來實現。
8. 僅導入必要的字體資源。
這一點和上一條的理由是一樣的，都是減少運行期間的數據吞吐量。對于英文來說還好，本來就不大，對于中文來說就很重要了，因為中文字體動輒就是幾百k上兆，如果全部導入的話簡直就是災難。
***就是程序用到多少就導入多少，實在沒辦法，就把生僻字全部剔出吧。
9. 窗體***用完就是立即關閉。
這一點對于窗體很多的應用程序非常重要！在.NET的世界里，打開一個主窗體，然后在主窗體里面創(chuàng)建子窗體的做法非常常見。但這可能會成為你的MF程序運行效率***的隱性殺手。
例如 主窗體 -> 產品列表 -> 產品詳細信息 -> 產品操作窗口 -> 結算窗口
這是一個常見的邏輯線，此時一共有五個窗口被打看，如果你有時間嘗試的話，會發(fā)現在打開結算窗口的時候，整個程序已經氣喘吁吁，動彈不得了。
而且，因為MF的半實時性，導致GC在關閉窗口之后不能立即釋放資源，如果用戶反復打開關閉這些窗口，內存很快就溢出了。
所以實現一個窗口管理器非常重要，要確保每個時間只有一個窗口在運行。
10. 減少Timer的使用。
Timer也是性能消耗的大戶，我曾見過一個程序里面打開了數十個Timer，那性能簡直慘不忍睹。所以如果可能，保證整個程序只是用一個Timer，且只在必要的時候啟動它，將會為你的程序減輕很多負擔。
【編輯推薦】
