关于Mobile系统内存不足而崩溃的总结.docx

1、关于Mobile系统内存不足而崩溃的总结关于Mobile系统内存不足而崩溃的调研与总结by Skyfrog 2011/9/15异常代码：0xc0000005异常地址：0x78801950读取：0x00000040/ Exception: OutOfMemoryException1. Mobile开发语言强烈推荐C+；C#虽然简单上手快，不过实在太慢了，ARM11才做考虑，ARM9不推荐使用.等到项目做大的时候，才发现运行速度慢想再换工具，那就非常麻烦了. （Choosing a Programming Language for Windows Mobile DevelopmentVisual

2、C+The advantages of using Visual C+ are execution speed, application size and flexibility. Applications written in C+ run very quickly and consume minimal resources: fast-action games are good examples of programs that benefit from C+. Furthermore, the ability to access low-level system components m

3、eans that using C+ is the only way to create a Today or Home screen plug-in.Visual C+ applications can interact with the Windows Mobile powered device by calling the Win32 APIs (Application Program Interface functions). These APIs are functions that perform particular actions, such as playing a soun

4、d or drawing a button on the screen. There are thousands of these APIs (Windows Mobile supports a subset of the complete desktop Windows set of Win32 APIs), and they are documented in the section entitled Windows Mobile Features (Native). When browsing this section, pay particular attention to the f

5、act that some APIs are available only in Windows Embedded CE - a platform that is related to, but separate from, Windows Mobile. A table in the top right of each topic will clarify which API is supported by which platform.If you have experience developing for Windows using Visual C+, you will not fi

6、nd the transition to Windows Mobile particularly jarring. You should read the sections covering installing and using the tools, and then the topic Making use of Device-Specific FeaturesM which will highlight the unique abilities of Windows Mobile powered devices.If you are new to both programming an

7、d Windows Mobile, it may be a good idea to begin with Visual C#, and then transition to Visual C+.Visual C# and Visual BasicVisual C# and Visual Basic .NET are managed development languages. Not only are they relatively easy to learn, but they support the .NET Compact Framework - a library of classe

8、s that perform a lot of frequently used programming tasks, to greatly simplify application development.The development tools for C# and Visual Basic .NET include a fully what-you-see-is-what-you-get user interface designer. You can drag and drop buttons and other controls directly onto your applicat

9、ions window (called a form in managed programming), and then double-click to access the underlying code. This approach makes creating an applications user interface extremely fast and easy.Extra classes covering everything from data structures to intercepting text messages are available to you as pa

10、rt of the Compact Framework library. You can read more about the framework in the section entitled the .NET Compact Framework Reference.To make use of Windows Mobile specific features, a set of extra classes are provided. These provide access to the devices features, for example, the list of Contact

11、s, or built-in camera. The documentation for these classes is in the section entitled Windows Mobile Features (Managed).The Compact Framework is a subset of the .NET Framework, so some functionality may require a slight reworking of your code.Visual C# is a great way to learn programming. (2. 内存资源释放

12、(NETCF: Memory leak. now what? 20 Feb 2008 7:12 PM Subtitles:- OutOfMemoryException (OOM)- SqlCeException: Not enough memory to complete this operation- .Im a Support Engineer at Microsoft CSS (Customer Service and Support), and I pretty often handle requests related to NETCF applications crashing w

13、ith OOM messages, or under a heavy memory pressure and therefore performing bad. I collected some hints and techniques ISV Application Developers may use to prevent or troubleshoot it, so that I can point next developers to them by using a link and not copyingpasting every time the same initial mail

14、. :-) which frankly btw addresses half of the requests related to leaks. Happy reading!GENERIC SUGGESTIONSIts quite difficult to get a comprehensive set of actions in order to debug a memory leak, as its dependent on the specific scenario youre running. So, some of the following suggestion could be

15、useful in your case, some others couldnt. Accordingly to Three Common Causes of Memory Leaks in Managed Applications the 3 most common causes are:1. unmanaged resources not correctly cleaned up 2. drawing resources not correctly .Dispose-d 3. still referenced managed objects Regarding (1), if youre

16、developing custom controls then remember to implement Finalize & Dispose, as recommended by Implementing Finalize and Dispose to Clean Up Unmanaged Resources. Regarding (2), consider the following subtle things you should know: drawing NETCF classes such as Font, Image, Bitmap, Pen, Brush, etc are t

17、iny wrappers around the native resources, which are handled in Windows CE by the GWES (Graphics, Windowing and Event Subsystem). This simply means that in NETCF applications, when you instantiate such classes you must invoke .Dispose on the object, otherwise a leak will be produced. This is the same

18、 for MODAL forms (myForm.ShowDialog) as I pointed above: call .Dispose() from the method showing the dialog.Note that, because of a bug addressed in v3.5, calling Dispose() on an ImageList object causes a memory leak. Therefore, if youre using an ImageList, do not call Dispose() on it, unless youre

19、application is targeting 3.5. In any case you must clear the list if youve finished with it: frm.ImageList1.Images.Clear();/ NOT NEEDED frm.ImageList1.Images0.Dispose();/ NOT NEEDED frm.ImageList1.Images.Dispose();/ DO NOT frm.ImageList1.Dispose();/ because it leaks in NETCF v2 addressed in v3.5The

20、same applies to Toolbars, because they have a .ImageList property. When you close the form and free up the images, dont call .Dispose on the .ImageList property of the toolbar, but simply frm.ToolBar1.ImageList.Images.Clear()Regarding (3), you can leverage on some monitoring-tools (below) and you sh

21、ould be aware of some caveats, some of which are described in How to: Improve Performance (.NET Framework Developers Guide). So for example: Since String objects are immutable in .NET, every time you modify the value of a String internally a new String object is created. Use StringBuilder instead of

22、 concatenating (“+”) String objects, because otherwise too much garbage will be created and the GC will kick too often, thus affecting the whole performances of the application. Avoid NEW statements in loops Limit the number of open SqlCeCommand objects and dispose of them when finished . TAKE SOME

23、TIME to read through that article.Still about (3), remember that if you add an event handler to a control that has been dynamically created, before disposing the control you need to explicitly remove that eventhandler - otherwise a reference will be hold for that control and it wont be effectively g

24、arbage-collected.GC is very expensive, as it needs to freeze all applications threads to run.NETCF AND VIRTUAL MEMORY:If youve never looked at how the memory looks like on Windows CE-based platforms, you may start from this 2-part blog post:Slaying the Virtual Memory Monster DumpMem explained - 1st

25、part Slaying the Virtual Memory Monster DumpMem explained - 2nd partI wont enter on the details described in that blog, so let me write down some probably useful notes:1- The DLLs related to the NETCF loaded in the applications address space (aka process slot) are only the ones for the CLR (netcfagl

26、* and mscoree*, in case theyre not XIP DLLs already in ROM, thus meaning theyre loaded at slot 1): all the other managed assemblies are loaded into the Large Memory Area (1GB2GB in the virtual address space). Therefore, the only impact managed modules have in the applications address space is the JI

27、Ted code. This is why unloading assembly, even if it was possible, doesnt give any benefit. This is documented by Device Memory Management (.NET Framework Developers Guide) and by Mike Zintels blog (he was the Program Manager for NETCF Product Group) .Net Compact Framework Advanced Memory Management

28、2- The code+stack+heap can be allocated ABOVE the “DLL Load Point”: this is NOT a problem. They can oversee that line and can even fill blank spaces between separate loaded DLLs. An OOM may happen if:* a NEW library is loaded (i.e. a library that wasnt loaded by any other process so far, thus meanin

29、g that the DLL wont find any available space downwards)* theres no more room for loading code+stack+heap even in the blank spaces among the loaded DLLs (virtual memory is completely full, considering also fragmentation)3- COSTs: only mscoree*_0.dll and netcfagl*_0.dll are loaded into a managed appli

30、cations virtual memory address space (in case theyre not XIP DLLs already in ROM), and this is the only fixed cost of a managed application (roughly 750KB). Dynamic costs might be:* CLR Data structures: 250KB* JIT Heap: 500KB (remember about “Code Pitching”, i.e. the ability to throw away the JIT-ed

31、 code in case of scarce memory)* for each thread: a minimum of 64KB-stack (and a NON-multithreaded managed application has 2 or 3 threads)* GC Heap: 2MB, even if a Garbage Collection takes place every 1MB of managed objects allocated (moreover, note that when allocating an object, a VirtualAlloc is invoked for at least a 64KB-segment* there are other heaps (AppDomain, Process, Short-Term), in any case what RPM calls “Total size of objects” is the total of all of them.Apart from the cost associated to “pure” managed