當大規模采用一門新語言時，有許多不同的因素需要考慮，因為事情可能會發生巨大的變化。對于許多人來說，選擇一門語言可以說是取決于個人偏好，但在 LinkedIn，我們有一個基礎團隊，負責評估這些基本技術決策的影響。最近，我們經歷了評估 Android 開發語言的過程。從移動基礎設施團隊的角度來看，我想與你分享一下，我們在評估語言時所采取的步驟，以及為什么我們最終選擇了 Kotlin 語言。

[[275193]]

方法

大規模采用移動語言有許多不同的因素需要考慮。這樣一個決定會對開發人員的生產力、招聘、培訓成本以及最終產品產生巨大的影響。例如，你可能會提高開發人員的生產力，并能夠交付更多的功能，但是必須付出應用程序大小增加的代價，這最終會影響用戶的下載。為了更好地理解采用特定語言的投資和回報，我們認為，公正的技術分析是我們做出決定的基礎。一旦做出了客觀的評估，我們就可以制定一個最適合整個公司移動開發的路線圖。

技術分析

在 Linkedin，Android 開發跨越了不同形式和規模的團隊——從開發大型應用程序的大型團隊，到開發多個中小型應用程序的小型團隊，再到只專注于構建工具和基礎設施的團隊。為了盡可能全面地執行評估，我們成立了一個委員會，由每個應用程序團隊的高級開發人員、基礎設施團隊和構建工具團隊的代表組成。在 LinkedIn 的 Android 開發背景下，這些是我們研究的領域。

語言特性

當谷歌宣布將 Kotlin 作為 Android 開發的官方支持編程語言時，我們都非常激動。Kotlin 作為一門語言，具有許多 Java 世界中沒有的新特性，比如空值安全(null-safety)、擴展、數據類、協程等等。雖然我們享受了這些新特性帶來的所有好處，但是 Kotlin 還在設計時刪除了某些 Java 特性，比如直接原始類型、靜態成員、檢查異常等等。在我們的分析中，我們深入了解了語言設計決策背后的想法，并研究了反編譯代碼來理解每個特性。這有助于我們將來制定指導方針，并對我們發布的代碼充滿信心。

兼容性

在 LinkedIn 的規模下，如果我們決定遷移到一種新的語言，遷移將是一個很長的過程，尤其是對于包含數百萬行代碼的代碼庫。正如理解每種語言的特性很重要一樣，考慮互操作性也同樣重要。幸運的是，Kotlin 和 Android Studio 之間的集成經常提供建議并幫助你重構代碼。然而，歸根結底，它們是兩種不同的語言，讓它正常工作只是一個開始。在此過程中，你肯定希望構建一些增強功能。例如，我們遇到的一些問題是為靜態成員添加 JVM 注解，并確保 Java API 把單一抽象方法(SAM)轉換 參數放在最后，這樣 Kotlin 編譯器就可以使用拖尾 lambda 語法 。

擴展性

構建時間是移動工程師最優先考慮的問題之一。使用 Kotlin，我們預計構建時間會增加。LinkedIn 的移動開發從數千行代碼到數百萬行代碼不等;因此，構建時間的增加可能有很大差異。這可能不會立即引起注意，但隨著時間的推移，我們會密切關注轉向 Kotlin 所導致的時間增加，尤其是 LinkedIn 的規模下。為了測試構建時間的長短，我們使用Android Studio Poet 創建了包含不同模塊數量、不同 Kotlin 和 Java 代碼行的 Android 項目作為模擬，同時保持類似的項目大小和依賴關系圖。我們使用Gradle Profiler 測量了清除構建和增量構建，以了解構建時間花在哪里。

考慮到該項目的規模，它有可能影響從開發到生產的許多不同方面。運行時性能是該分析的另一個關鍵領域。我們在 Kotlin 和 Java 中實現了幾種算法作為測試工具，并在物理設備上運行它們。為了使實驗更加真實，我們還在這些測試中啟用了ProGuard 。研究結果與“Kotlin 和 Java 在 Android 運行時上的性能評估 ”結果一致。有趣的是，Kotlin 中的大部分開銷來自空安值全特性，該特性使方法的每個調用都具有非可選參數，都不能被編譯器映射到基本類型。這就導致了對 Intrinsics.checkParameterIsNotNull 的調用，它要為我們實驗中的大部分開銷負責。

應用程序的大小是由許多因素造成的。按照谷歌的說法 ，初始的 Kotlin 標準庫導入將使應用程序的大小增加大約 1MB，隨著時間的推移，更多的 Java 代碼被轉換成 Kotlin，由于 Kotlin 字節碼方法的增加，應用程序將變得更大。幸運的是，ProGuard 能夠從 Kotlin 生成的代碼中去除并大大減少未使用的方法。我們創建了示例應用程序，并將它們從 Java 轉換為純 Kotlin，以了解方法數量和應用程序大小的開銷。

語言升級

移動開發的前景在不斷變化，了解升級過程非常重要。在過去，我們看到語言升級伴隨著不兼容的更改、構建失敗和許多意外錯誤，這些錯誤最終迫使我們鎖定主干，甚至執行語言升級。JetBrains 承諾為 Kotlin 提供兩種形式的向后兼容性：

新編譯器仍將可以使用舊二進制文件(但是舊編譯器可能無法識別新二進制文件，比如 javac 1.6，它無法讀取由 javac 1.8 編譯的類)。

舊二進制文件將可以在運行時繼續和新二進制文件一起工作，而新代碼可能需要新依賴項。

在源代碼兼容性方面，Kotlin 遵循 API 棄用警告的模式，一旦升級到新的編譯器版本，該警告就會逐漸變為錯誤。在過去，我們看到升級通常會給社區足夠的時間來適應這些更改。例如，KT-21515 中的語言行為變化被標記為警告，并在接下來的 1.2.x 補丁版本中得以保留，直到 Kotlin 1.3。然而，值得注意的是，JetBrains 并沒有聲明將在主要版本更改中提供哪種類型的兼容性。

開發者生態系統

Kotlin 能夠輕而易舉地與 Android Studio 搭配使用并不奇怪，因為 JetBrains 是這兩款產品背后的主要貢獻者。大多數(如果不是全部的話)Android Studio 工具都可以無縫地與 Kotlin 一起工作，包括調試器、內存分析器、Android 分析器等等。值得一提的 Kotlin 特性包括 Kotlin 自動轉換和 Kotlin 反編譯器。后者讓你深入了解 Kotlin 代碼的底層工作機制。

LinkedIn 使用 Gradle 作為 Android 和 Java 產品的實際構建系統。借助 Kotlin- Android Gradle 插件，Kotlin 在 Gradle 中可以順暢地工作。Gradle 企業版提供遠程緩存解決方案。Kotlin 1.2.21 允許 Kotlin 項目使用構建緩存。具體來說，對于 Gradle 構建緩存，它還需要使用 Kotlin Gradle Plugin 1.2.20 和 Gradle 4.3 或更高版本。總的來說，由于采用 Kotlin 而引起的構建工具的變化很少。然而，我們的分析主要集中在 Gradle 上，可能不適用于其他構建系統，比如 Buck。

正如我們關注開發人員的生產力一樣，質量也是我們要考慮的另一個重要因素。編寫測試對于確保代碼質量至關重要。我們花了一些時間來理解測試生態系統的局限性及其與其他語言的兼容性。這不僅包括測試框架，還包括代碼覆蓋率分析、CI 管道，最重要的是，在開始編寫 Kotlin 測試之前，在不違背測試標準的情況下所要采取的步驟。該分析還包括 Android 中的主要靜態分析工具Android Lint ，它現在使用UAST 支持 Java 和 Kotlin 分析及樣式檢查工具。

行業分析

自從 Kotlin 于 2017 年在谷歌 I/O 大會上宣布成為 Android 開發的一等語言以來，越來越多的工程師開始接受 Kotlin。Stack Overflow 2018 調查顯示，Kotlin 是第二受歡迎的編程語言。Kotlin 還被認為是未來語言中增長最快的語言，與 Swift、Go、Haskell 和 Rust 并列第一。據谷歌報道，2017 年，當 Kotlin 被宣布為 Android 開發的第一語言時，Google Play 中 9% 的應用程序已經在使用 Kotlin。一年后，即 2018 年 5 月，谷歌宣布這一數字已增至 35%，同比增長近 6 倍。

我們分析了Google Play 商店中的前 300 個免費應用程序 ，并根據它們的 DEX 文件大小進行了篩選，以了解有多少應用程序在大規模使用 Kotlin。雖然這個數字包含了所有第三方庫的代碼，但它能很好地反映應用程序代碼的大小。作為一個初步步驟，我們排除了 APK 中沒有專門 Kotlin 文件夾的應用程序，該文件夾將包含 Kotlin 運行時使用的一些 Kotlin 內置文件。由于代碼的混淆，計算 Kotlin 在代碼中的百分比非常棘手。但是，我們使用apktool 將所有 DEX 文件轉換為 SMALI 代碼，并發現了兩個不同的線索，它們標識了用 Kotlin 編寫的類。對于沒有從.source 屬性中刪除原始文件名的應用程序，我們可以提取擴展名 *.kt。對于其他應用程序，我們尋找 kotlin.Metadata 類。總的來說，我們能夠建立一個圖表來顯示應用程序及其類的數量、代碼大小和 Kotlin 百分比。這讓我們了解到社區有多成熟，以及我們可以從合作伙伴那里得到多少支持。

起初，大多數庫所有者認為，在自己的代碼中使用 Kotlin 實現細節是不成熟的，不應該強加給用戶。隨著 Kotlin 社區變得越來越活躍，這種觀點已經開始轉變。Square 是許多最受歡迎的 Android 開源庫的所有者，它宣布他們的核心Okio 庫已經用Kotlin 重寫 ，并且他們將在未來的所有版本中使用Kotlin。其他一些庫項目已經選擇遵循谷歌針對Android KTX 提供的示例，并發布了一個用 Java 編寫的基本庫，在其中單獨的構件中添加了特定于 Kotlin 的擴展點。例如，FasterXML 的 Jackson 項目添加了一個用于序列化和反序列化 Kotlin 類的Kotlin 模塊 ，以及 Mockito，該項目正在研究添加一個針對 Kotlin 優化過的 mock 語法 。

全方位考察

除了上面列出的要點，我們還花時間研究了與 LinkedIn 內部工具系統的集成，包括崩潰報告、審查流程和 CI 管道。我們不斷與社區和其他公司的開發人員進行溝通，包括谷歌和 JetBrains，不僅要了解他們的方向，還要確保我們的決定與未來的 Android 開發保持一致。人才始終是我們首先要考慮的因素之一;因此，與招聘和培訓有關的成本也是我們分析的重要部分。

總的來說，我們從社區聽到了各種好處和證詞。綜合分析，我們能夠建立一個路線圖，使 LinkedIn 進入下一個使用 Kotlin 的 Android 開發時代，并且相信，我們可以最小化技術風險，已經了解了對招聘和培訓的影響，能夠保持技術標準，并不斷為我們的會員提供價值。