"Analysis of the principle of Xamain cross-platform mechanism"

The original: "Analysis of the principle of Xamain cross-platform mechanism"

"Recommended, recommended after 100, will send patch address"

Xamarin project from shouting slogans to now, for several years, there is no fire in the mainland, the reason is no more than three, 1. Authorized Fegui 2.3. The original ecological Java development of Android more and more, labor costs reduced.

The above mentioned 3, are related to the money, not the technical side, looks like the title of this article seriously inconsistent. But, carefully, if this product circle can not open, and then cattle technology, it is in vain. Because technology is constantly advancing,

Performance issues, technical issues, implementation issues, and so on can all be resolved over time, but Xamarin doesn't seem to be planning to lower prices. Increasingly stable. The Dead Bastard ... So, we need to crack, we need to crack, we need to crack (important things say 3 times), but the hack is not easy, this platform software, almost I have seen the CLI language most difficult to crack east, because there are too many nails, shaving clean. (I've tried to crack it and found it takes too much time, and it's not stable). But, uh, however persuasive outsmart. Find patches, to Google ..... Now it is clear to tell you that the latest version of Xamarin has cracked patches. Let's go to Google.

The above is a digression, I hope this ecology can continue to grow in this piece of soil. We begin to enter our title, don't say I am the title party. Oh.

Let's talk about Xamarin's Android development mechanism, iOS, itself is compiled under the Mac, is the AOT, not the JIT ... The AOT mechanism itself transforms the code into a native code application. JIT is the intermediate code that runs based on the virtual machine language. Both Java and. Net are JIT .... Have virtual machines that are similar to running. JAVA->JVM ..... C#->clr->jit->native Code ...

First, this cross-platform approach is based on a long-ago Mono project, on the Mono project, its own Baidu brain supplement. Mono is a cross-platform implementation of micro-emulsion. Net. Based on the implementation of C language, the CLR can run under different platform systems. Of course, the Linux system is targeted. The birth of Mono allows. NET to run under Linux.

OK, above is just the beginning, let's look at Android again. This project is a product of a droid company acquired by Google. is to use the Open source Linux system, do two times development. The essence remains the Linux kernel.

Google's acquisition of the project has increased its investment in the project. This project was finally able to run on mobile devices. (Capital + technology = progress)

Look at the structure of the Android project:

• Applications application layer (written by Java and run on DALVK virtual machines)
• Framework application frame layer (written by Java)
• Libraries and Android runtime various libraries and Android runtime environment
• Linux Kernel OS Layer

From the top of the application layer, such as SMS phone video QQ and other applications to the first support library, are implemented in Java.

Then down is some of the library LIB layer for the hardware function packaging, mostly open source Linux application Library, with this layer of Android virtual machine Dalvik.

Finally, the kernel of Linux, the role of the system's kernel is that the operating system interacts with the hardware. (Of course, the hardware needs the corresponding driver to be recognized by the system)

The above is an overview of Android's structure and operation. When you open it, you invoke the interaction from the application Layer-"framework Layer-" virtual machine to the kernel.

How does the----------------------------------xamarin work? ----------------------------------

As we said above, the Mono project, implementing the. NET language running under Linux, Android is a Linux project, so long as there is mono in Android,. NET can run in Android!!!

As a result, some people who have developed from Mono have gone over to Xamarin. Xamarin is based on this.

So how did Xamarin pack the Android app run? Look at the following figure:

What is this?

Oh, old uncle's shadow.

Well, I was learned by foreigners ....

And then, no words ........ .....

Yes, this xamarin is actually a shadow puppet (High-tech puppet)!!!!!!!!!!!!!!!!!!!!!

(written here, not only for the Chinese people sad, their own things are discarded as garbage, foreign people can always find something from it ...) For example: explosives Sinan Compass and so on, we ourselves abandoned ourselves, our eyes only the money in the mind room ..... Come up with some ideals, my guys!!! ）

Say it is a high-tech shadow puppet, not unfounded. Let's look at the structure explained by the official:

Original:

The idea is that the Xamarin Android project is based on the Mono runtime, the Android native app is based on the Android runtime, which is the Dalvik virtual machine ... When running the Android app created by Xamarin,

An instance of the corresponding wrapped object will also be allocated on the corresponding Android virtual machine. The MCW represents a binding to the native Android Lib, ACW is based on the call map API and returns the response to mono.

How to bind, and how to feedback it? See what the official said ...

Below:

Address: http://developer.xamarin.com/guides/android/under_the_hood/architecture/

English is not good students, you open the Web site to find translation tools it.

Probably mean: MCW's binding mechanism and ACW's core is JNI .

What the hell is JNI? Popular Science: JNI is the abbreviation for Java Native Interface, which provides a number of APIs that enable the communication of Java and other languages (primarily c&c++).

Well, since the interactive ingress JNI is provided, our code will be able to interact with the Android Java project after monodroid processing.

So is the C # language processed and transformed into a JNI application? Yes. Look at the picture:

After reading, you should know that it compiles the C # code file into a map based on the native file of Java. Note: not directly translated into Java code! is the call to register.

The Java file produced does not provide a run implementation, but rather provides a matching mapping at the Android runtime!!!!!!!!!!!!!!!

The actual execution code is still in the Classes.dex file. But not our C # compiled business code OH ~ ~ ~ The business code will say in a minute (this file is a binary file that can be executed by an Android virtual machine, regardless of the language).

Java native Development compresses the business code into this file. This file is also used by the Android virtual machine to perform the corresponding application, can find the entrance, the starting point. However, the business code for the Mono project is not in this, remember that it is a shadow puppet. This is Shadow puppet. The real operator, behind the scenes murderer, in the background!!!

The Magic:

This is also true of the APK package that is generated by Xamarin.

The Lib directory provides the Lib libraries required by the runtime, such as the Mono runtime.

Note that the following two files, is the shadow play of the rod, mapping tool.

The real code of execution in the????

In Lib or in assemblies!!

Why or what? Because the enterprise version of Xamarin supports the use of NDK to package applications into native applications!!!

Some people tangle with that Calsses.dex file, as an entry point, that Android applications are not nonlinear coupled module applications? Yes, however, this nonlinearity is for the system, or the inside of the block, rather than the description between the system and the program application. The application is plugged into the system, and the self-description file Androidmanifest.xml provides an entry description for the program.

And Calsses.dex by the Android virtual machine Dalvik execution, will give the program to assign the corresponding program run domain,

(Excerpt from: Ascendas (Jesse)) The difference between a dalvk virtual machine and a Java operating environment

1. Dalvik mainly includes the completion of object lifecycle management, stack management, thread management, security and exception management, as well as garbage collection and other important functions.
2. Dalvik is responsible for process isolation and thread management, and each Android application will have a standalone Dalvik virtual machine instance at the bottom, and its code can be executed under the virtual machine interpretation.
3. Unlike Java virtual machines running Java bytecode, the Dalvik virtual machine is running its own proprietary file format
4. The Dex file format reduces the overall file size and improves the class lookup speed of I/O operations.
5. is to further improve performance during operation and further optimize the Dex file.
6. All Android apps have threads that correspond to one Linux thread, so virtual machines can rely more on the operating system's thread scheduling and management mechanisms.
7. There is a special virtual machine process zygote, which is an incubator of virtual machine instances. It will be generated when the system starts, it will complete the initialization of the virtual machine, library loading, prefabricated class library and initialization operations. If the system needs a new instance of the virtual machine, it will quickly replicate itself and provide the system with the fastest data. For some read-only system libraries, all virtual machine instances share a memory area with zygote.

Attention to 2nd and 7th helps us understand the working mechanism of xamarin.android

Well, here you know, that Classes.dex is for zygote to provide the incubator application ....... Zygote (fertilized eggs). Very image. Applied like a fertilized egg, through which he warmed out a chick application)

ko!!!!!!! In this way, you basically know how this thing works .... Yes, remember, Shadow!!!!!!!!!!!!!!!.

-----------------------------Garbage Collection----------------------------------------

On this topic, in fact, there is no need to discuss excessively, because it is shadow puppet, then certainly the interaction between the two sides is certainly not as good as the original, if you tangled this, then please learn Java to go.

Then is the hardware problem, from 09 to now, memory AH CPU and so on mobile terminal for several generations. From single-core to dual-core to four-core to eight-core .... The hardware upgrade is simply to kill.

Spend months optimizing projects, possibly the next generation of hardware directly defying previous project performance issues ... (Of course, you can't pay attention to performance.) In some game video and other hardware rendering requirements are high, you can reflect the performance of the deadly!! ）

Well, there's no need for you to look down here. The following is a Xamarin-based memory management.

Because it is shadow puppet, both sides actually hold each other's information. Play Shadow puppet According to the information of the shadow puppet, the next step how to operate, shadow puppet received the command, will display the corresponding action on the screen ...

Excerpt: http://www.cnblogs.com/wintersun/archive/2013/02/28/2937270.html

1. Performance issues. such as garbage collection, Mono for Android claims to support garbage collection, but there are some serious limitations that need to be noted. "GC does not complete the view of the process and may not run when it is insufficient, because the GC does not know that there is not enough memory. "Because this usually requires manual, whenever an activity is created to run garbage collection or destruction to free unused memory. Otherwise, an out-of-memory exception may be caused. I have encountered this problem more than once and have to use an alternative approach to solve the problem.

About Memory Management:
Many mono for Android are assigned objects for wrapping Java objects as their representatives. What happens: Every time you assign a wrapper type that corresponds to a Java type, you create two objects:
1). Java objects in the Java heap
2). Mono proxy object in mono heap
Mono for Android does not ensure that these two objects are referenced to each other for a long time to survive. That is, Mono's garbage collection refers to an object, and the Java-side object will remain alive and vice versa. The creation of this proxy object is mandroid.exe when the tool is compiled. However, the GC is lazy, run on demand collections, and not simply object out of scope. So this means that garbage across virtual machines is at least more than normal, which is unavoidable. Therefore, to allocate a large number object for temporary use, it is valuable to display the resources required to release those objects. The agreed method uses the Using keyword to new an object, and it is necessary to use the using clause to implicitly release the target's new object. Releases the JAVA-VM of the mono-side wrapper to collect objects, thereby preventing too many temporary objects from being associated together for a long time.

Go to the official website to learn more about mono for Android garbage collection.

In fact, Mono has been optimized for the garbage collection mechanism.

The Monotouch for iOS currently supports the generational garbage collector (generational garbage collector) SGen. Until recently, SGen was only an experimental part of the full version of Mono. Along with the garbage collector, there is a memory profiler prepared for iOS, which can be accessed from the MonoDevelop integrated development environment.

The generational garbage collector SGen replaces the traditional Boehm garbage collector in mono. Although SGen is expected to have better performance, its pessimistic scanning still poses some obstacles. It is expected that future SGen will switch to an accurate stack marking system, which should significantly reduce the amount of memory fragmentation generated.

The iOS parser supports two modes, the default mode is heap analysis mode, in which memory snapshots can be collected on demand or triggers, which can be set to a certain number of garbage collector cycles or time-based intervals. In addition, the parser includes some standard tools, such as comparing snapshots and locating object locations in memory.

The performance analysis supports statistical sampling, as well as an accurate but low-speed entry/exit event record. Statistical sampling captures application snapshots and evaluates their speed based on how often each method is captured by the collector. Literally, an entry/exit event record is a log that is logged each time the function starts or finishes. While it provides a complete record of time spent, it can incur significant performance overhead. This pattern also captures the stack traces associated with object allocation.

MonoDevelop 2.8.5 and Monotouch 5.1.1 all require the use of the tool. For individual projects, the debug, parse, and sgen garbage collector options must be activated.

The Sgen project has been advancing ...

About the mechanism, see the official article yourself. Too long, not translated.

http://www.mono-project.com/docs/advanced/garbage-collector/sgen/

https://developer.xamarin.com/guides/android/advanced_topics/garbage_collection/

The yard is a little bit of information, understand it.

From: http://www.cnblogs.com/shanyou/archive/2012/12/09/2810468.html

Mono 3 is now the default GC is the SGen garbage collector, a few performance and scalability improvements in the garbage collector to make better use of multicore processor hardware. SGen has been ported to Windows and MIPS.

Mono was the first to use Boehm-demers-wiser conservative garbage Collector, which was the default garbage collector before Mono 3.0. The main problem with the Boehm garbage collector is the inability to accurately read registers and stack frames. Because it is not possible to determine whether a given value is a pointer or a scalar, it always assumes that the given value is a pointer and marks the associated object as alive. Not only does this mistake cause large chunks of memory to be unallocated, but it also makes it extremely difficult to compress the available space.

Later, Mono had its own simple generational GC, the generational garbage collector SGen, instead of the traditional Boehm garbage collector in mono. Document address: Http://www.mono-project.com/Compacting_GC, which uses an accurate generational (generational) garbage collector, similar to the. NET version of the CLR. The SGen garbage collector uses two generations instead of three in. NET, but uses a separate heap for large objects like. Net.

1. Divided into two generations, before using conservative GC. The description of its document is visible. is a relatively backward implementation, no generational,. NET CLR is three generations of
2. Large object special handling, default greater than 64KB as a large object. NET is larger than 20KB, and is assigned to a special large object heap. Objects in the heap can be finalized and freed like other small objects.
3. Small objects use GET_INTERNAL_MEM/FREE_INTERNAL_MEM for memory allocation processing, large objects using OS Malloc/free
4. Major collection when used in Mark/sweep
5. The collection is "Stop the World" when
6. Conservatively scanned objects
7. The older generation is pointing to the next generation in the following two scenarios, so they are tracked:

• In program execution, a field is assigned a value
• This object points to an object in a new generation during replication (generation move)

The Mono 3.2 further enhances the SGen GC, especially for the following scenarios-

• Popular object payload, the old generation objects are very welcome to some fixed new objects that cause a collection of many memories to be created. To avoid this, the popular object will be used as an eternal object until the next master collection.
• Large-scale thread stack load, in which case a large number of large stack threads need to be scanned reasonably. This usually puts a lot of pressure into the planning phase, because it creates a very large fixed queue. To avoid this, SGen now uses hash filtering on fixed queues, which greatly reduces their average size, and it secures the main blocks rather than individual objects.

Mono 3.0 adds asynchronous support, improved SGen garbage collector, and other features

Building cross-platform applications with XWT

New Mono GC

Sgen–concurrent Mark

Sgen–concurrency and evacuation

Flame Graphs for Instruments

How SGen Rocks

Sgen–the Write Barrier

SGen and DTrace

Sgen–finalization and Weak References

Sgen–the Major Collectors

SGen

"Analysis of the principle of Xamain cross-platform mechanism"