Meta 發(fā)布了一篇博客表示，正在將其 Android 應用的 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?！?/p>

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

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

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

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

如何處理遷移

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

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

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

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

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

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

因此，Meta 方面最終選擇了第二條選項，決定將幾乎所有代碼轉(zhuǎn)換為 Kotlin。而在嘗試為現(xiàn)有應用程序引入 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 格式化程序?！?/p>

準備好所有工具后，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>

審核編輯 ：李倩