編譯｜燕珊，核子可樂
Meta 現(xiàn)在愛 Kotlin 多于 JAVA。
Facebook 母公司 Meta 正在將其 Android 應(yīng)用的 Java 代碼遷移到 Kotlin。根據(jù) Meta 的官方博客所述，截至今天，其 Android 代碼庫已經(jīng)有超過 1000 萬行 Kotlin 代碼，旗下包括 Facebook、Instagram、Messenger、Portal 和 Quest 在內(nèi)的應(yīng)用都已經(jīng)開始從 Java 轉(zhuǎn)向 Kotlin。
將代碼庫轉(zhuǎn)換為 Kotlin
Kotlin 是一種更年輕的編程語言，也依賴于 Java 虛擬機(jī)。Kotlin 由軟件工具制造商 JetBrains 創(chuàng)建，于 2011 年首次亮相，2016 年發(fā)布 1.0 版本。次年，它被 google 采用為 Android 開發(fā)的一級語言，并由其基金會管理，該基金會由 JetBrains 和 Google 資助。
到 2019 的 Google I/O 大會，Google 正式宣布，Kotlin 編程語言已成為 Android 應(yīng)用開發(fā)人員的首選語言，并在當(dāng)年年底表示前 1000 個 Android 應(yīng)用程序中有近 60% 包含 Kotlin 代碼。
從 Google 自身來看，明面上它說自己選擇 Kotlin 的理由是它更簡潔、更安全、支持結(jié)構(gòu)化并發(fā)，能更輕松地編寫異步代碼，并且可以與 Java 互操作。不過，另一個業(yè)界推測是可能跟那宗與 Oracle 曠日持久的 Java 侵權(quán)案有關(guān)—— Oracle 花了十多年的時間追究 Google 在 Android 中使用 Java API 的侵權(quán)索賠，最終 Oracle 敗訴。
回到 Meta，F(xiàn)acebook 軟件工程師 Omer Strulovich 對選擇 Kotlin 如此解釋道：“Kotlin 通常被認(rèn)為是一種比 Java 更好的語言，在年度 Stack Overflow 開發(fā)人員調(diào)查中，其受歡迎程度高于 Java，”他還指出，由于近年來 Kotlin 已成為 Android 開發(fā)的流行語言，“因此，在努力使我們的開發(fā)工作流程更加高效的過程中，我們在 Meta 的安卓開發(fā)中轉(zhuǎn)向 Kotlin 是非常合理的……”
除了受歡迎之外，Meta 認(rèn)為 Kotlin 擁有的主要優(yōu)勢包括可空性、函數(shù)式編程、代碼更短、以及領(lǐng)域特定語言（DSL）等等。
不過，Strulovich 指出，過渡到 Kotlin 也有一些不可忽視的缺點，比如混合代碼庫可能難以維護(hù)，以及 Kotlin 雖然流行，但與 Java 相比還是有比較大的差距，工具集還不夠成熟。所有 Kotlin 工具都需要考慮 Kotlin 和 Java 的互操作性，這使得它們的實現(xiàn)變得復(fù)雜。
但 Meta 最大的擔(dān)憂還是構(gòu)建時間。“我們從一開始就知道 Kotlin 的構(gòu)建時間會比 Java 的要長。該語言及其生態(tài)系統(tǒng)更加復(fù)雜，Java 在優(yōu)化其編譯器方面領(lǐng)先了 20 年。由于我們擁有多個大型應(yīng)用程序，較長的構(gòu)建時間可能會對我們的開發(fā)人員體驗產(chǎn)生負(fù)面影響。”
為什么不只用 Kotlin 來寫新代碼
Strulovich 沒有透露 Meta 何時開始這種轉(zhuǎn)變。Meta 本來可以選擇只用 Kotlin 編寫新代碼，但它最終還是決定將所有的 Android 應(yīng)用程序都轉(zhuǎn)換過來。
根據(jù) Strulovich 的說法，如果是只使用 Kotlin 來編寫新代碼，繼續(xù)保留大部分現(xiàn)有 Java 代碼的話，工作量明顯更低，但相應(yīng)的也有兩個缺點：首先就是要在 Kotlin 和 Java 代碼之間實現(xiàn)互操作性，就需要引入 Kotlin 中的 platform 類型。Platform 類型會導(dǎo)致運行時中的空指針取消引用，進(jìn)而引發(fā)崩潰，這就破壞了純 Kotlin 代碼提供的靜態(tài)安全優(yōu)勢。在某些復(fù)雜情況下，Kotlin 的空檢查省略可能會漏掉空值，意外引發(fā)空指針異常。例如，如果 Kotlin 代碼調(diào)用由 Java 接口實現(xiàn)的 Kotlin 接口，就會發(fā)生這種情況。其他的問題還包括 Java 無法將類型參數(shù)標(biāo)記為可空（最近才剛剛修復(fù)）；Kotlin 的重載規(guī)則考慮到了可空性，Java 的重載規(guī)則卻沒有考慮到。
第二個缺點是，這種方式要求對 Meta 已經(jīng)開發(fā)的大多數(shù)軟件進(jìn)行代碼修改。如果繼續(xù)把大部分代碼保留為 Java 形式，那開發(fā)人員就沒法充分發(fā)揮 Kotlin 的優(yōu)勢。
Kotlin 遷移大法
如今，Meta 旗下的 Android 版 Facebook、Messenger 和 Instagram 應(yīng)用都擁有超過百萬行 Kotlin 代碼，而且轉(zhuǎn)換率也一路走高?？v觀整個 Android 代碼庫，其中的 Kotlin 代碼量已經(jīng)超過千萬行。
起步階段
事實上，在嘗試為現(xiàn)有應(yīng)用程序引入 Kotlin 時，Meta 遇到了不少麻煩。例如，團(tuán)隊得更新 Redex 才能支持 Java 無法生成的字節(jié)碼模式。另外，其使用的某些內(nèi)部庫要求在編譯期間進(jìn)行字節(jié)碼轉(zhuǎn)換來獲取更好的性能。而在將這些庫納入 Kotlin 編譯過程時，這部分代碼無法正常起效。為此，Meta 針對這些問題構(gòu)建了專門的解決工具。
Meta 還發(fā)現(xiàn)，現(xiàn)有工具之間存在不少沖突。例如，代碼審查和 wiki 工具無法對 Kotlin 語法進(jìn)行高亮顯示。“我們還更新了之前使用的 Pygments 庫，確保其體驗與處理 Java 代碼時一致。我們更新了一些內(nèi)部代碼修改工具，使其能夠支持 Kotlin。我們也構(gòu)建了 Ktfmt，一款基于 google-java-format 編碼理念的確定性 Kotlin 格式化程序。”
遷移加速階段
在工具準(zhǔn)備齊全之后，Meta 現(xiàn)在已經(jīng)能將代碼中的任意部分轉(zhuǎn)換為 Kotlin。但每次遷移都需要大量樣板設(shè)計工作，只能由員工們手動完成。J2K 是一種通用工具，并不會去理解所轉(zhuǎn)換的代碼是在表達(dá)什么。因此，某些特定部分就只能進(jìn)行手動調(diào)整。
最典型的例子就是 Junit 測試規(guī)則的使用。假設(shè)使用 ExpectedException 規(guī)則，來驗證是否拋出了正確的異常：
@Rule public ExpectedException expectedException = ExpectedException.none();
當(dāng) J2K 將這部分代碼轉(zhuǎn)換成 Kotlin 時，得到的就是：
@Rule var expectedException = ExpectedException.none()
這段代碼乍看之下與原先的 Java 代碼等價，但由于 Kotlin 使用了 site 注解，所以其實際上等價于：
@Rule private ExpectedException expectedException = ExpectedException.none();
public ExpectedException getExpectedException() {return expectedException
嘗試運行后，此測試會失敗并返回一個錯誤：“The @Rule expectedException must be public”，這是因為 Junit 發(fā)現(xiàn)了一條帶有 @Rule 注解的私有字段。這是個常見問題，論壇上面也已經(jīng)有成熟答案：要么在字段中添加“@JvmField”；要么在注解中添加注解 use-site，也就是“@get:Rule”：
// 方案一：使用“get”作為注解的use-site@get:Rule var expectedException = ExpectedException.none()
// 方案二：只為沒有g(shù)etter的Java字段生成JVM代碼@JvmField @Rule var expectedException = ExpectedException.none()
由于 J2K 無法（可能也不應(yīng)該）感知 JUnit 的復(fù)雜性，所以沒能正確完成轉(zhuǎn)換。但即使 JUnit 不存在這個問題，J2K 在處理其他小眾框架的時候也肯定會掉類似的坑。
例如，很多 Android Java 代碼會使用 android.text.TextUtils 中的實用方法，例如 isEmpty，來簡化對某些字符串的檢查。但在 Kotlin 中，其實是有內(nèi)置的標(biāo)準(zhǔn)庫方法 String.isNullOrEmpty 的。該方法之所以更好，是因為它能通過契約來告知 Kotlin 編譯器如果它返回 false，則被測試的對象不得再為 null，并將其智能轉(zhuǎn)換為 String。
Java 代碼也有不少類似的輔助方法，也有很多庫都實現(xiàn)了相同的基本方法。這一切都需要替換成標(biāo)準(zhǔn)的 Kotlin 方法，借此簡化代碼并保證編譯器能正確檢測出不可為空的類型。
Strulovich 表示，內(nèi)部發(fā)現(xiàn)了許許多多類似的小小修復(fù)實例。有些難度不大（例如替換 isEmpty），有些則需要研究一番才能搞明白（例如 JUnit 規(guī)則）。還有一些其實屬于 J2K 出的錯，可能導(dǎo)致構(gòu)建錯誤、運行時行為錯亂等問題。
為了解決這些問題，Meta 團(tuán)隊將 J2K 轉(zhuǎn)換流程劃分成三個步驟：
首先，取一個 Java 包并準(zhǔn)備將其轉(zhuǎn)換為 Kotlin。這個步驟主要解決錯誤，并完成相應(yīng)的內(nèi)部工具轉(zhuǎn)換。
第二步就是運行 J2K。團(tuán)隊已經(jīng)能夠以無頭模式運行 Android Studio 并調(diào)用 J2K，由此將整個管道作為腳本來運行。
最后一步，對新的 Kotlin 文件進(jìn)行后處理。具體包括大部分自動重構(gòu)與修復(fù)步驟，例如將 JUnit 規(guī)則標(biāo)記為 @JvmField。在此步驟中，團(tuán)隊還應(yīng)用了自動更新 linter，并在無頭模式下應(yīng)用各種 Android Studio 建議。
“當(dāng)然，自動化并不足以解決所有問題，但至少能幫我們優(yōu)先處理那些最常見的問題。”Strulovich 說。
在 Java 重構(gòu)方面，Meta 使用的是 JavaASTParser 等工具，它能幫助解析某些類型。而在 Kotlin 這邊，團(tuán)隊還沒有找到能夠解析類型的好辦法，所以選擇使用 Kotlin 編譯器 API。
Meta 還發(fā)布了一組自動重構(gòu)方法（https://github.com/fbsamples/kotlin_ast_tools）。雖然不是很多，但希望能幫助更多開發(fā)者利用 Kotlin 編譯器解析器高效完成工作。
下一步
平均而言，Meta 發(fā)現(xiàn)遷移后的代碼行數(shù)減少了 11%。盡管網(wǎng)上各種案例引用的數(shù)字往往要比這高得多，但他們還是對這個數(shù)字感到滿意。
Strulovich 說，Meta 向 Kotlin 的遷移仍在進(jìn)行中并在加速。“Kotlin 仍然缺乏一些我們在使用 Java 時已經(jīng)習(xí)慣了的工具和優(yōu)化，但我們正在努力縮小這些差距。隨著我們?nèi)〉玫倪M(jìn)展和這些工具和庫的成熟，我們也將努力把它們反饋給社區(qū)。”
https://www.theregister.com/2022/10/25/meta_java_kotlin/
https://engineering.fb.com/2022/10/24/android/android-java-kotlin-migration/
