在最近的GR8Conf Europe 2014期間，SpringSource/Pivotal的Groovy高級(jí)軟件工程師 Cédric Champeau已經(jīng)在Andriod上完成一次Groovy代碼的現(xiàn)場(chǎng)pull請(qǐng)求的合并。

Groovy開(kāi)發(fā)人員為了在Android上運(yùn)行Groovy已經(jīng)等待好幾年了。因?yàn)楦鞣N困難，它的實(shí)現(xiàn)被推遲了，這包括Andriod Dalvik虛擬機(jī)的不同字節(jié)碼和Groovy代碼的動(dòng)態(tài)特性等。官方對(duì)Android的支持可能在Groovy2.4版本。InfoQ采訪了 Champeau，了解了更多的這方面的內(nèi)容以及未來(lái)Groovy在Andriod系統(tǒng)中的發(fā)展。

[[114134]]

Question：讓Groovy在Android上工作，最困難的部分是什么？

實(shí)際上有多個(gè)問(wèn)題，它們結(jié)合在一起使得這個(gè)工作變得有些困難。***個(gè)問(wèn)題是Groovy是一個(gè)在運(yùn)行時(shí)生成類的動(dòng)態(tài)語(yǔ)言。問(wèn)題是那些類是使用標(biāo)準(zhǔn) 的JVM格式生成的，而Android使用了自己的類格式（Dalvik VM）。Dalvik VM并不意味著運(yùn)行時(shí)創(chuàng)建類，這樣就變得很困難，因?yàn)槊總€(gè)使用標(biāo)準(zhǔn)JVM字節(jié)碼的文件都需要通過(guò)'dex'工具加載處理。甚至你能夠在設(shè)備上做到這些，運(yùn) 行時(shí)加載類仍然是痛苦的。例如，在jar文件中寫(xiě)一個(gè)類，然后加載這個(gè)jar。***，我們決定這不是Groovy運(yùn)行在Android上的主要關(guān)注點(diǎn)，我 們應(yīng)該更關(guān)注用Groovy寫(xiě)一個(gè)完整的應(yīng)用，不涉及運(yùn)行時(shí)創(chuàng)建類。這意味著有一些限制，但是這對(duì)許多用戶來(lái)說(shuō)是不可見(jiàn)的。***，如果你在Android 上靜態(tài)編譯Groovy時(shí)，使用了@compileStatic，性能以及內(nèi)存消耗相當(dāng)于或者同Android原生應(yīng)用相同。

第二個(gè)問(wèn)題實(shí)際上是和系統(tǒng)構(gòu)建相關(guān)。新的Andriod構(gòu)建系統(tǒng)使用了Gradle和一個(gè)自定義的插件,"android"，它繞過(guò)了正常 的"java"和"groovy"插件提供類似于應(yīng)用程序變種的功能。這需要一些工作來(lái)弄清楚我們?nèi)绻迦胨鼇?lái)添加對(duì)Groovy的支持。令人欣慰的是自 從公布以后，Groovy的Gradle插件和Android已經(jīng)發(fā)布，使得事情變得更容易了。***但并非最不重要的一點(diǎn)，我通過(guò)編寫(xiě)對(duì)Groovy的支 持了解了Android。這是一件好事情，因?yàn)槲铱梢钥吹皆谀男┑胤绞褂肎roovy會(huì)讓你受益，但是實(shí)際上這花費(fèi)我更多的時(shí)間比適配Groovy本身！

Question：將來(lái)會(huì)考慮將這項(xiàng)工作擴(kuò)展到iOS或者至少是Windows Phone來(lái)作為一中跨平臺(tái)解決方案嗎？

我肯定非常希望能在iOS上面看到Groovy的身影，但是我沒(méi)有硬件設(shè)備去測(cè)試;)即使最近發(fā)布的Swift語(yǔ)言看起來(lái)與Groovy非常接近并且遠(yuǎn)遠(yuǎn) 比Object-C吸引人，人們?nèi)匀豢梢园阉鳛镚roovy的一種替代。但是，我們還要考慮這樣一個(gè)問(wèn)題：Swift是由供應(yīng)商封鎖的閉源軟件。相比之 下，Groovy則是完全開(kāi)源的，如果你能在iOS和Android平臺(tái)下用Groovy進(jìn)行編碼，舉個(gè)例子來(lái)說(shuō)，人們可能需要做的僅僅是重寫(xiě)他們應(yīng)用的 UI部分就可以使他們的應(yīng)用更適應(yīng)大部分的手機(jī)開(kāi)發(fā)。至于Windows Phone，我完全不知道這是否可行。實(shí)際上對(duì)于這個(gè)平臺(tái)，我了解甚少。

Question：當(dāng)前有哪些不足之處? 還有哪些是不能運(yùn)行的?

 直到最近，僅僅@CompileStatic類能運(yùn)行在Android上。但是現(xiàn)在也可以運(yùn)行動(dòng)態(tài)代碼了，因此幾乎所有的東西都能運(yùn)行了，包括 構(gòu)建器。應(yīng)當(dāng)知道，使用動(dòng)態(tài)代碼應(yīng)限于應(yīng)用程序的非CPU密集型部分，因?yàn)樗婕暗椒瓷洹＿@就是說(shuō)，當(dāng)前的限制是不能運(yùn)行時(shí)實(shí)時(shí)構(gòu)建類，因此一些特定的結(jié) 構(gòu)比如映射到類或者實(shí)時(shí)運(yùn)行特征將不工作。欣慰的是有辦法解決這些問(wèn)題。***，在方法描述符的數(shù)量上仍然有問(wèn)題。Andriod缺省的方法總量的限制是 65536，這相當(dāng)?shù)牡停跓o(wú)優(yōu)化的情況下，Groovy將消耗8k(例如，ProGuard)。因此這意味著比通常的java應(yīng)用程序更快的到達(dá)限制， 即使有方法可以解決這件事情（例如用multidex選項(xiàng)）。

Question：對(duì)將來(lái)Groovy/Android的發(fā)展有何規(guī)劃？

CC： 官方對(duì)Android的支持會(huì)有***個(gè)測(cè)試版的Groovy2.4。目前，你已經(jīng)可以將其應(yīng)用于自己的應(yīng)用程序，并且實(shí)際上在***個(gè)示例應(yīng)用程序中，這已 經(jīng)包含在產(chǎn)品中。([2]）但是它僅是基于Groovy的一個(gè)快照版本。但我真的很想看看新的庫(kù)或框架編寫(xiě)的Groovy是如何便利Android應(yīng)用程 序的開(kāi)發(fā)。Android非常啰嗦，Groovy則可以使編碼更容易。為此，我們很多社區(qū)的開(kāi)發(fā)人員已經(jīng)寫(xiě)了大量的像這樣的為Java開(kāi)發(fā)的庫(kù)，所以 Groovy的普及和發(fā)展只是時(shí)間問(wèn)題。我相信一旦用戶在Android上面體驗(yàn)到了Groovy，他們不太可能切換回Java;)

[1] https://github.com/melix/groovy-android-gradle-plugin

[2] https://play.google.com/store/apps/details?id=me.champeau.gr8confagenda.app