浅谈.NET Micro Framework功能优化（.NET Micro Framework）-编程开发-知优网

由于工作原因，这几个月对.NET家族的新成员.NET Micro Framework做了一些研究和实践，对于这个可以直接运行在硬件上的小家伙还是很看好的。这里将为大家讲解.NET Micro Framework性能优化的问题。

.NET Micro Framework的可取舍性，高定履行，和天然生成对硬件高集成度都让它的出路一片光亮。当然，它现在还很年青，就发布的SDK v3.0来看，它还有很长的路要走。

浅谈.NET Micro Framework功能优化（.NET Framework） .NET 性能优化第1张

废话不说，就这几个月我用下来的经历谈谈在针对.NET Micro Framework应用程序的功能优化吧。

1. 尽或许削减办法调用！

办法调用过于频频关于功能的影响十分大，所以一切的优化都是以这个为大前提的。

2. 尽或许防止运用特点，而用公共域来替代。

由于修改器会在编译的时分为每个特点的getter和setter增加拜访办法，根据***条，这是要防止地。
当然也不是说完全防止运用特点了，究竟有的时分特点是很便利且必要的。
比方这个下面这个运用特点的比方：

publicclassTest 
{ 
publicstringName{get;set;} 
}

需要把它改成这样：

publicclassTest 
{ 
publicstringName; 
}

3. 只在结构函数里边初始化变量。

这一条很简单理解，看下面的比方：

publicclassTest 
{ 
privatestringname="TestString"; 
privateDateTimedate=DateTime.Now; 
privateintscore,counter; 
 
publicTest() 
{ 
score=0; 
counter=0; 
} 
}

初始化的作业其实进行了两次，一次是在声明变量的时分，别的一次是在调用结构函数的时分。遵从***条准则，咱们要尽或许削减办法调用，且结构函数的运用概率很高，所以咱们在此需要把初始化的作业悉数会集到结构函数里边来进行。

4. 只在必要的当地调用lock。

关于MF这样一个半实时的体系来说，lock的本钱远远高于咱们的幻想。在.NET里边或许感觉不出来，但到了MF这个小伙子手里感觉就十分显着了，或许这一条咱们现已知道了，就当我老调重弹吧。
看这个比方：

publicclassTest 
{ 
privateArrayListobjs; 
 
publicvoidSomeMethod(objecto) 
{ 
for(inti=0;i<100;i++) 
{ 
if(objs.Contains(o)) 
{ 
lock(objs.SyncRoot) 
{ 
objs.Remove(o); 
} 
} 
} 
} 
}

在一个循环里边增删一个调集，由所以多线程拜访，所以在操作之前加了锁。之所以在循环内部加锁，理由或许是想尽或许的削减lock的拜访次数，只要满意那个if条件的时分才会被调用。
实际上，这个主意错了，无论如何，这儿的lock都会被调用很屡次，这些开支加起来就会对功能形成很大的影响。
把代码改成这样就会好许多：

publicclassTest 
{ 
privateArrayListobjs; 
 
publicvoidSomeMethod(objecto) 
{ 
lock(objs.SyncRoot) 
{ 
for(inti=0;i<100;i++) 
{ 
if(objs.Contains(o)) 
{ 
objs.Remove(o); 
} 
} 
} 
} 
}

5. 确保每个时刻只要一个线程在运转。

用惯了.NET，来到MF国际***个不适应便是它的多线程太慢了，假如一起翻开两个线程作业，那么整个程序的功率都会遭到极大的影响。
拿电子地图软件来做比方，主线程担任更新UI，作业线程担任在后台获得地图块。这样的规划自身无可厚非也是合理的，但***咱们发现功能真实太差了。
后来更改成为当用户在操作UI的时分，作业线程全都暂停，只要检测到用户没有任何操作的时分才进行作业。
要完结这一点，就要求程序在规划的时分就考虑到作业线程的可暂停性。

6. 尽或许少的并且在最小的范围内调用Invalidate()办法。

许多人在重画UI之后都会习惯性的调用顶层元素的Invalidate()办法来更新一切子控件，由于这样是最方便的。可许多时分咱们疏忽了一点，Invalidate()这个办法或许在背面现已被调用过很屡次了。
比方，有的控件会在得到焦点的时分调用这个办法，有的控件会在动身用户事情的时分主动调用这个办法。由于这些都是在背面发生的，咱们或许并不知情，所以在完结咱们自己控件的制造之后通常会调用parent的Invalide来更新整个布局，这样就会在不知不觉之间导致了不必要的重画发生。
要防止这个问题也很简单，一则仔细观察，二则用Refactor！去阅览一下他人的代码。

7. 尽或许少的运用图片资源。

由于MF自身的数据吞吐量很小，假如载入过多图片资源的话，轻则程序运转功率变低，重则呈现内存溢出。所以这儿的准则咱们要参照网页的规划准则，例如一个按钮图片，把它切割成几个小块，运用重复贴图来完结中心部分，而不要直接运用一整张图片。
同样在制造高亮的时分能够经过改动图片通明度或许在图片上面加一层通明矩形来完结。

8. 仅导入必要的字体资源。

这一点和上一条的理由是相同的，都是削减运转期间的数据吞吐量。关于英文来说还好，原本就不大，关于中文来说就很重要了，由于中文字体动辄便是几百k上兆，假如悉数导入的话几乎便是灾祸。
***便是程序用到多少就导入多少，真实没办法，就把生僻字悉数剔出吧。

9. 窗体***用完便是当即封闭。

这一点关于窗体许多的应用程序十分重要！在.NET的国际里，翻开一个主窗体，然后在主窗体里边创立子窗体的做法十分常见。但这或许会成为你的MF程序运转功率***的隐性杀手。
例如主窗体 -> 产品列表 -> 产品详细信息 -> 产品操作窗口 -> 结算窗口
这是一个常见的逻辑线，此刻一共有五个窗口被打看，假如你有时刻测验的话，会发现在翻开结算窗口的时分，整个程序现已气喘吁吁，动弹不得了。

并且，由于MF的半实时性，导致GC在封闭窗口之后不能当即开释资源，假如用户重复翻开封闭这些窗口，内存很快就溢出了。

所以完结一个窗口管理器十分重要，要确保每个时刻只要一个窗口在运转。

10. 削减Timer的运用。

Timer也是功能耗费的大户，我曾见过一个程序里边翻开了数十个Timer，那功能几乎不忍目睹。所以假如或许，确保整个程序仅仅用一个Timer，且只在必要的时分发动它，将会为你的程序减轻许多担负。

【修改引荐】