Meta 發(fā)布了一篇博客表示，正在將其 Android 應(yīng)用的 Java 代碼遷移到 Kotlin，并分享了這一過程中的一些經(jīng)驗。

該公司認為，Kotlin 是一種流行的 Android 開發(fā)語言，與 Java 相比具有一些關(guān)鍵優(yōu)勢?！耙虼耍谖覀兣κ刮覀兊拈_發(fā)工作流程更加高效的過程中，將 Meta 的 Android 開發(fā)轉(zhuǎn)向 Kotlin 是非常合理的。..。..Kotlin 通常被認為是一種比 Java 更好的語言，在年度 Stack Overflow 開發(fā)者調(diào)查中，它的好感度要高于 Java。”

除了受歡迎程度外，Meta 還將最新的 Kotlin 版本與 Java 11（可用于 Android 開發(fā)的最新版本）進行了比較，并得出了 Kotlin 的一些主要優(yōu)勢：可空性、函數(shù)式編程、更短的代碼、以及領(lǐng)域特定語言 （DSL） / 類型安全構(gòu)建器等。

Facebook 軟件工程師 Omer Strulovich 指出，Meta 旗下幾個流行的 Android 應(yīng)用 --Facebook、Instagram、Messenger、Portal 和 Quest 都已經(jīng)開始從 Java 轉(zhuǎn)向 Kotlin。截至目前，F(xiàn)acebook、Messenger 和 Instagram 的 Android 應(yīng)用程序都有超過 100 萬行 Kotlin 代碼，并且轉(zhuǎn)換率正在提高。Meta 的 Android 代碼庫總共已包含有超過 1000 萬行的 Kotlin 代碼。作為此次遷移的一部分，Meta 透露其也正在開源用于操作 Kotlin 代碼的各種示例和實用程序。

不過，采用 Kotlin 也有一些不能忽視的缺點。博客內(nèi)容指出，比如：兩種語言的混合代碼庫需要長時間的處理維護；以及 Kotlin 與 Java 相比，流行度還是存在明顯的差距，這意味著 Kotlin 可用的工具也更少。更糟糕的是所有 Kotlin 工具還都需要考慮 Kotlin 和 Java 的互操作性，這使得它們的實現(xiàn)就變得復(fù)雜。

最大的問題還在于構(gòu)建時間?！拔覀儚囊婚_始就知道 Kotlin 的構(gòu)建時間會比 Java 的要長。該語言及其生態(tài)系統(tǒng)更加復(fù)雜，Java 在優(yōu)化其編譯器方面領(lǐng)先了 20 年。由于我們擁有多個大型應(yīng)用程序，較長的構(gòu)建時間可能會對我們的開發(fā)人員體驗產(chǎn)生負面影響?！?/p>

如何處理遷移

Meta 稱，遷移到 Kotlin 既簡單又非常復(fù)雜。因為 Kotlin 的設(shè)計允許從 Java 進行簡單的轉(zhuǎn)換，并具有經(jīng)過深思熟慮的互操作性。這種設(shè)計使 JetBrains 能夠為開發(fā)人員社區(qū)提供 J2K，即 IntelliJ/Android Studio 中的 Java 到 Kotlin 轉(zhuǎn)換器。但 J2K 不是萬能的，遷移中的有些情況仍然很復(fù)雜。

遷移之前，該公司考慮了兩個選擇：

一個是可以使用 Kotlin 在 Meta 上編寫新代碼，但將大部分現(xiàn)有代碼保留在 Java 中。

還有一個是可以嘗試將幾乎所有內(nèi)部代碼轉(zhuǎn)換為 Kotlin。

第一個選項的優(yōu)勢很明顯，即少得多的工作量；但是這種方法也有兩個明顯的缺點。首先，在 Kotlin 和 Java 代碼之間實現(xiàn)互操作性引入了 Kotlin 中 platform types 的使用。platform types 會導(dǎo)致運行時空指針取消引用，從而導(dǎo)致崩潰，破壞了純 Kotlin 代碼提供的靜態(tài)安全優(yōu)勢。在一些復(fù)雜的情況下，Kotlin 的空檢查省略還可能漏掉空值通過，進而引發(fā)空指針異常。例如，如果 Kotlin 代碼調(diào)用由 Java 接口實現(xiàn)的 Kotlin 接口，就會發(fā)生這種情況。其他問題包括 Java 無法將類型參數(shù)標記為可空性（直到最近才修復(fù)），以及 Kotlin 的重載規(guī)則考慮了可空性，而 Java 的重載規(guī)則卻沒有。

第二個缺點是考慮到 Meta 的大多數(shù)軟件開發(fā)都需要修改現(xiàn)有代碼?！叭绻覀兊拇蟛糠执a都是用 Java 編寫的，我們就無法讓我們的開發(fā)人員充分享受 Kotlin 的樂趣。由于遷移是一個漫長的過程，期望每個工程師在接觸文件之前將文件轉(zhuǎn)換為 Kotlin 既費力又低效?！?/p>

因此，Meta 方面最終選擇了第二條選項，決定將幾乎所有代碼轉(zhuǎn)換為 Kotlin。而在嘗試為現(xiàn)有應(yīng)用程序引入 Kotlin 時，Meta 也遇到了很多麻煩，例如需要更新 Redex 以支持 Java 不生成的字節(jié)碼模式。以及使用的某些內(nèi)部庫依賴于在編譯期間進行字節(jié)碼轉(zhuǎn)換來獲取更好的性能。而將其作為 Kotlin 編譯的一部分運行時，這部分代碼則無法生效。為此，Meta 專門構(gòu)建了解決工具。

此外，他們還發(fā)現(xiàn)在現(xiàn)有工具中存在的一些差異。例如代碼審查或 wiki 中缺少 Kotlin 語法高亮顯示?！拔覀兏铝宋覀冋谑褂玫膸?Pygments，以使體驗與 Java 相媲美。我們更新了一些內(nèi)部代碼修改工具，以便能夠處理 Kotlin。我們還構(gòu)建了 Ktfmt，這是一個基于 google-java-format 的代碼和理念的確定性 Kotlin 格式化程序。”

準備好所有工具后，Meta 就可以正式開始批量轉(zhuǎn)換大量代碼?！半S著我們工具的改進，我們已經(jīng)能夠?qū)⑾喈敶蟮囊徊糠执a轉(zhuǎn)換成 Kotlin。我們的代碼庫中已經(jīng)有超過 1000 萬行 Kotlin 代碼，而且 Meta 的大多數(shù) Android 開發(fā)人員現(xiàn)在都在編寫 Kotlin 代碼”。平均而言，此次遷移使代碼行數(shù)減少了 11%。

Meta 方面表示，其向 Kotlin 的遷移仍在進行中并在加速。“我們已經(jīng)允許 Meta 的任何想要使用 Kotlin 的 Android 開發(fā)人員這樣做，并為他們提供了工具來輕松地將現(xiàn)有代碼遷移到 Kotlin。Kotlin 仍然缺少一些我們在使用 Java 時已經(jīng)習慣的工具和優(yōu)化。但我們正在努力縮小這些差距。隨著我們?nèi)〉眠M展以及這些工具和庫的成熟，我們還將努力將它們反饋給社區(qū)?！?/p>

審核編輯 ：李倩