最近有興趣了解一下Mono for Andriod，也就是使用.NET平台來開發Andriod程序。Mono for Android API 幾乎映射標准的Andriod API.例如，兩邊API幾乎所有相同的類、方法和字段都相同。主要區別之一，就是Mono for Android使用屬性和委托在Java中不存在。我喜歡緊密相關的兩個api，因為這使它容易地在它們之間來回切換，並使用已存在標准Android API文檔。我能夠成功完成我的項目使用Android，但仍有幾個困難....以下列出了關於Mono for Android的利弊：
優勢：
1. 平台間共享代碼。如果配合使用Mono Touch API與Windows Phone API，您可能重用業務邏輯代碼為iPhone和Windows Phone平台所用。這是可能的，因為一切都可以進行使用單一的編碼，常見的編程語言而不是3種不同的編程語言。請注意，這雖然只適用於業務邏輯代碼；而每個平台的呈現代碼將因為不同平台APIs的有所差異。在我看來重用代碼的能力是使用Mono fo Android的最佳優勢。
2. 使用你已有的.NET技能。如果你在團隊中比較熟悉.net平台而不是Java平台，那么用Mono for Android比較合適。但是，我認為這個優勢已是有所減少的事實，C#和Java是如此相似。有可能在使用Mono Touch，因為這消除了需要學習的Objective- C構成一個學習曲線，所以比有Java更大的優勢。
劣勢：
1. 性能問題。例如垃圾回收，Mono for Android 聲稱支持垃圾回收，但也有需要注意的一些嚴重限制。"GC不完整視圖的進程，可能無法運行在內存不足時，由於GC不知道內存不足。"因為這通常需要手動，每當創建一個activity運行垃圾回收或銷毀，以釋放未使用的內存。否則，可能導致內存不足的異常。 我自己也不止一次碰到了這個問題，不得不使用替代方法來解決問題。
關於內存管理:
許多Mono for Android被分配對象為包裝Java對象做為它們的代表。 這時會發生什么：每次你分配一個包裝過類型相對應Java類型，就創建兩個對象:
1). Java對象在Java堆中
2). Mono代理對象在Mono堆中
Mono for Android不能確保這兩個對象相互引用后長時間存活。那就是，Mono的垃圾回收引用一個對象，Java端的對象將一直活着，反之亦然。這個代理對象的創建mandroid.exe是工具編譯時完成。 然而，GC是懶惰的，按需運行的集合，而不是簡單地對象超出范圍時候。 那么這意味着跨虛擬機的垃圾至少比一般更多，這是不可避免的。所以，為了臨時使用時分配一個大數字對象，顯示釋放那些對象所需的資源是寶貴的。約定的方法使用using關鍵字來new一個object,使用using子句來隱式釋放目標的new object是有必要的。釋放Mono端的包裝的Java-VM收集的對象，從而來防止太多的臨時對象關聯在一起很長時間。
去官方網站了解更多關於Mono for Android的垃圾回收。
2. 第三方JAR Libraries - Mono for Android為Android 4.2版本推出綁定任意JAR文件的支持。JAR綁定項目是一個蠻好的概念，但不幸的是這是不可靠的。對於簡單JAR files可行，但往往不支持在更復雜的Java庫的JAR文件。Xamarin提供一些關於如何排除綁定錯誤jar的文檔，但它並不總是幫助我。在未來版本也許這項功能將改善，但目前其難以使用，缺乏文檔，還有幾個著名的bugs。
3.Bugs-- 有大量的bug在Mono for Android。嗯，也許重要的是太強的一個詞，但肯定的更加穩定的需使用Java相對於Mono for Android。 我遇見的最嚴重的兩個bug有：日期時間。現在返回錯誤的UTC時區時間，並使用SSL與WebClient時會導致異常。
越來越多的趨勢是使用標准的Android和Java API來開發Android應用，而不是使用c#和Mono Android API。這么說是因為，第一，Java有較好的開發社區支持，第二，使用Java可能會導致問題比較少。然而，能夠共享相同的代碼在Android，iPhone，而Windows Phone等平台是吸引人的，所以某些情況下需要權衡。
作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。
該文章也同時發布在我的獨立博客中-Petter Liu Blog。