Co Xamarin.iOS robi z zarządzaniem pamięcią, gdy kompiluje C# do natywnego kodu?

Question

Co Xamarin.iOS robi na temat zarządzania pamięcią? W zwykłym IL mamy Garbage Collector, który zajmuje się obiektami nieużywanymi i programatorami reliefowymi od wywoływania delete. Jak to działa, gdy Xamarin kompiluje kod do natywnego? Kto czyści obiekty, które nie są już używane?

To pytanie odpowiedzi Jak działa kompilacji, ale nie wyjaśnia rolę zarządzania pamięcią: How MonoTouch works?

Answer 1

answer you seek został podany na pytania, które powiązane.

Podsumowując, proces tłumaczenia IL-to-native jest wykonywany z wyprzedzeniem, ale inne elementy środowiska wykonawczego Mono są nadal wymagane. Kompilacja JIT jest tylko jednym z zadań wykonywanych przez środowisko wykonawcze, a ten konkretny element jest niezgodny z ograniczeniami pamięci iOS (nie można również wykonywać zapisywalnych stron pamięci, co jest wymagane, aby funkcja JIT działała). To jest AFAIK, jedyny powód, dla którego kompilacja z wyprzedzeniem (AOT) jest w ogóle wymagana.

Śmieciuch Mono rzeczywiście działa na iOS, jest po prostu wbudowany w plik binarny tworzony przez kompilator Monotouch. Wytworzony plik binarny zawiera Twój skompilowany kod AOT, a także skompilowane wersje AOT bibliotek, z których korzystasz, i odchudzoną wersję środowiska wykonawczego Mono.