⑴ android啟動執行多個runtime
深入理解Android Runtime
申國駿
2022-08-08 12:31·字數:2599·閱讀:2340
image.png
上圖是Android整體的架構，Android Runtime之於Android而言相當於心臟之於人體，是Android程序載入和運行的環境。這篇文章主要針對Android Runtime部分進行展開，探討Android Runtime的發展以及目前現狀，並介紹應用Profile-Guided Optimization(PGO)技術對應用啟動速度進行優化的可行性。轉載請註明來源「申國駿」
App運行時演進
JVM
Android原生代碼使用Java或者Kotlin編寫，這些代碼會通過javac或者kotlinc編譯成.class文件，在Android之前，這些.class文件會被輸入到JVM中執行。JVM可以簡單分為三個子系統，分別是Class Loader、Runtime Data Area以及Execution Engine。其中Class Loader主要負責載入類、校驗位元組碼、符號引用鏈接及對靜態變數和靜態方法分配內存並初始化。Runtime Data負責存儲數據，分為方法區、堆區、棧區、程序計數器以及本地方法棧。Execution Engine負責二進制代碼的執行以及垃圾回收。
image.png
Execution Engine中，會採用Interpreter或者JIT執行。其中Interpreter表示在運行的過程中對二進制代碼進行解釋，每次執行相同的二進制代碼都進行解釋比較浪費資源，因此對於熱區的二進制代碼會進行JIT即時編譯，對二進制代碼編譯成機器碼，這樣相同的二進制代碼執行時，就不用再次進行解釋。
image.png
DVM(Android 2.1/2.2)
JVM是stack-based的運行環境，在移動設備中對性能和存儲空間要求較高，因此Android使用了register-based的Dalvik VM。從JVM轉換到DVM我們需要將.class文件轉換為.dex文件，從.class轉換到.dex的過程需要經過 desugar -> proguard -> dex compiler三個過程，這三個過程後來逐步變成 proguard -> D8(Desugar) 直到演變到今天只需要一步R8(D8(Desugar))。
image.png
我們主要關注Android中Runtime Engine與JVM的區別。在Android早期的版本裡面，只存在Interpreter解釋器，到了Android2.2版本將JIT引入，這個版本Dalvik與JVM的Runtime Engine區別不大。
image.png
ART-AOT(Android 4.4/5.0)
為了加快應用的啟動速度和體驗，到了Android4.4，Google提供了一個新的運行時環境ART(Android Runtime)，到了Android5.0，ART替換Dalvik成為唯一的運行時環境。
image.png
ART運行時環境中，採用了AOT(Ahead-of-time)編譯方式，即在應用安裝的時候就將.dex提前編譯成機器碼，經過AOT編譯之後.dex文件會生成.oat文件。這樣在應用啟動執行的時候，因為不需要進行解釋編譯，大大加快了啟動速度。
image.png
然而AOT帶來了以下兩個問題：
應用安裝時間大幅增加，由於在安裝的過程中同時需要編譯成機器碼，應用安裝時間會比較長，特別在系統升級的時候，需要對所有應用進行重新編譯，出現了經典的升級等待噩夢。
image.png
應用佔用過多的存儲空間，由於所有應用都被編譯成.oat機器碼，應用所佔的存儲空間大大增加，使得本來並不充裕的存儲空間變得雪上加霜。
進一步思考對應用全量進行編譯可能是沒有必要的，因為用戶可能只會用到一個應用的部分常用功能，並且全量編譯之後更大的機器碼載入會佔用IO資源。
ART-PGO(Android 7.0)
從Android7.0開始，Google重新引入了JIT的編譯方式，不再對應用進行全量編譯，結合AOT、JIT、Interpreter三者的優勢提出了PGO(Profile-guided optimization)的編譯方式。
在應用執行的過程中，先使用Interpreter直接解釋，當某些二進制代碼被調用次數較多時，會生成一個Profile文件記錄這些方法存儲起來，當二進制代碼被頻繁調用時，則直接進行JIT即時編譯並緩存起來。
當應用處於空閑（屏幕關閉且充電）的狀態時，編譯守護進程會根據Profile文件進行AOT編譯。
當應用重新打開時，進行過JIT和AOT編譯的代碼可以直接執行。
這樣就可以在應用安裝速度以及應用打開速度之間取得平衡。
image.png
image.png
JIT 工作流程：
image.png
ART-Cloud Profile(Android 9.0)
不過這里還是有一個問題，就是當用戶第一次安裝應用的時候並沒有進行任何的AOT優化，通常會經過用戶多次的使用才能使得啟動速度得到優化。
image.png
考慮到一個應用通常會有一些用戶經常使用執行的代碼（例如啟動部分以及用戶常用功能）並且大多數時候會有先行版本用於收集Profile數據，因此Google考慮將用戶生成的Profile文件上傳到Google Play中，並在應用安裝時同時帶上這個Profile文件，在安裝的過程中，會根據這個Profile對應用進行部分的AOT編譯。這樣當用戶安裝完第一次打開的時候，就能達到較快的啟動速度。
image.png
image.png
Profile in cloude 需要系統應用市場支持，在國內市場使用Google Play的佔比非常低，因此cloud profile的優化在國內幾乎是沒有作用的，不過Profile的機制提供了一個可以做啟動優化的思路。早在2019年，支付寶就在秒開技術的回應的裡面提到過profile-based compile的技術，參考：如何看待今日頭條自媒體發布謠言稱「支付寶幾乎秒開是因為採用華為方舟編譯器」？，這也是我們一直研究Profile技術的原因。困擾著我們的一直有兩個問題，第一個問題是如何生成Profile文件，第二個問題是怎麼使用生成的Profile文件。對於第一個問題的解決相對還是有思路的，因為app運行就會生成profile文件，因此我們手動運行幾次app就能在文件系統中收集到這個文件，不過如何以一種較為自動化的手段收集仍然是個問題。第二個問題我們知道Profile文件最終生成的位置，因此我們可以把生成的文件放到相應的系統目錄，不過大多數手機和應用都沒有許可權直接放置這個文件。因此Profile優化技術一直都沒有落地，直到Baseline Proflie讓我們看到了希望。
Baseline Profile
Baseline Profile是一套生成和使用Profile文件的工具，在2022年一月份開始進入視野，隨後在Google I/O 2022隨著Jetpack新變化得到廣泛關注。其背景是Google Map加快了發版速度，Cloud Profle還沒完全收集好就上新版，導致Cloud Proflie失效。還有一個背景是Jetpack Compose 不是系統代碼，因此沒有完全編譯成機器碼，而且Jetpack Compose庫比較大，因此在Profile生成之前使用了Jetpack Compose的應用啟動會產生性能問題。最後Google為了解決這些問題，創造了收集Profile的BaselineProfileRule Macrobenchmark以及使用Profile的ProfileInstaller。
使用Baseline Profile的機制可以在Android7及以上的手機上得到應用的啟動加速，因為從上述知道Android7就已經開始有PGO(Profile-guided optimization)的編譯方式。生成的Profile文件會打包到apk裡面，並且會結合Google Play的Cloud Profile來引導AOT編譯。雖然在國內基本上用不了Cloud Profile，不過Baseline Profile是可以獨立於Google Play單獨使用的。
image.png
在使用了Baseline Proflie之後，有道詞典的啟動速度從線上統計上看，冷啟動時間有15%的提升。
這篇文章主要介紹了Android Runtime的演進以及對於應用啟動的影響，下一篇文章我會詳細介紹關於Profile&dex文件優化、Baseline Profile工具庫原理，以及在實際操作上如何使用的問題，敬請大家期待一下！
⑵ Swift VS Kotlin
Swift和Kotlin作為更加"現代化"的語言，毫無疑問提升了開發原生app的效率，二者旨在與Objective-C和Java互操作，方便"舊"應用的開發進行更新，如果你要從零開始編寫一個全新的應用，不要猶豫，選擇使用它們，盡情享受它們帶來的樂趣。這兩個語言有著許多相似之處，讓我們來"欣賞"一下吧：
Kotlin有一個稱為數據類的東西，該類在編譯時將獲得諸如hashCode()，toString()和()等方法。可以這樣定義：
Swift沒有數據類或任何等效類。
Swift具有元組功能，並且可以為元組設定類型別名；
Kotlin具有Pair和Triple工具類，用物散於呈現2元和3元組對象，並且可以通過data class模擬自定義元組。
Swift Struct和Class之間的區別在於，結構體是值類型，而類是引用類型。可將元組視為隱式定義的Struct：
Kotlin沒有Struct類型。但是，我們可以通過函數創建一個新引用：
我們可以使用Kotlin數據類和Swift結構體來保存數據。即使一個是引用類型，另一個是值類型。
Swift和Kotlin都有枚舉。但是聲明和匹配方式有很大的區別：
Kotlint通過密封類可以實現枚舉。Kotlin的Sealed Class和Swift的Enum之間的唯一區別是，密封類是引用類型，而Swift的Enum是值類型：
Swift還具有隱式解包功能，它定義了一個可選內容，但告罩寬氏訴編譯器可以展開該內容，因為後面它將會被值。Kotlin也可以通過lateinit關鍵字執行相同的操作。需要注意的是，作為開發人員，應盡可能避免使用隱式解包方式。
協議和介面有相同的功能，只是使用了不同的術語。它們定義了一個類在實現介面時必須遵循的一組函數/變數。Kotlin允許在介面的定義中使用泛型，而Swift則可以通過定義關聯類型associatedtype來實現。
高階函數本質上是接受閉包或函數作為參數並返回新值或另一個函數的函數。使用高階函數，我們可以對值（例如數組）進行轉換，過濾巧衡和迭代。
參考：
⑶ 如何學習Kotlin編程語言
為什麼說 Kotlin 是優秀的
本文不會像一碰頌般介紹語言的文章那樣，一開頭就羅列出語言那些酷炫的特性，我們稍後再來探討這些內容。
首先我將介紹一些其它的信息，因為2013 年一項研究顯示，當開發者評估一種編程語言時生態系統要比語言特性更重要。這符合我個人的經驗，下面就讓我開始介紹吧：
Kotlin 被編譯成 JVM 位元組碼或者 JavaScript 代碼。Java 開發者將會是對它最感興趣的人，不過對於使用垃圾收集運行時語言畝信的開發者而言它也具有一定的吸引力，比如 Scala、Go、Python、Ruby 和 JavaScript 等語言。
Kotlin 來自業界，而不是學術界。它解決了開發者現今面臨的實際問題。例如它的類型系統可以幫助你避免空指針異常。
切換到 Kotlin 無需成本！它是開源的但這不是重點，重點是它提供了一個高質量的一鍵從 Java 轉換到 Kotlin 的工具，並且十分關注 Java 二進制文件的兼容性。你可以將現有 Java 項目的一次性轉換成 Kotlin 項目，而該項目仍將可以正常編譯，即使這是一個包含上百萬行代碼的復雜程序。
顯然你可以從上文得知，Kotlin 程序能夠使用所有現存的 Java 框架和庫，甚至那些依賴註解處理的高級框架。它們之間的交互是無縫的，不需要包裝或者適配層。Kotlin 可以整合 Maven，Gradle 以及其它構建系統。
它十分平易近人，語法精煉直觀，僅僅是閱讀語言參考文檔幾個小時就能學會使用。Kotlin 看起來十分像 Scala 但是更加簡潔並且兼顧了可讀性。
它不遵循特定的編程哲學，例如極度的函數式編程或者面向對象編程風格。
它不會增加運行時的開銷。Kotlin 的標准庫十分小巧緊湊：專注於擴展 Java 標准庫，編譯階段的大量內聯操作意味像 map/filter/rece 等管道結構函數將被編譯成類似於命令式語言的代碼。
Anko 與 Kovenant 等框架的出現意味著在 Android 開發者中 Kotlin 開始變得流行起來。如果你正在從事 Android 相關的工作，相信你笑耐鄭很快就會獲得好的工作。你可以閱讀這份 Square 公司開發者 JakeWharton 的報告，了解用 Kotlin 進行 Android 開發的體驗。
Kotlin 允許你繼續使用你的工作效率提升工具。IntelliJ 的 IDE 對 Kotlin 的支持十分完善：你可以對代碼進行重構、搜索、導航以及使用自動完成，而且 IDE 充分支持調試、單元測試、性能分析等等功能。
除了 Android，我認為 Kotlin 還非常適用於企業中 Java 的應用場景。如果你的工作是整天埋頭於大公司的代碼庫中，那麼當 Kotlin 1.0 版本正式發布時你應該盡快去了解一下：
由知名公司為它提供強大的商業支持。 JetBrains 這家公司 有一個高度稱職的大團隊致力於該項目，有穩定的商業模式甚至在自己的部分旗艦產品中使用 Kotlin，這表明短期內 Kotlin 不會被放棄。
使用 Kotlin 風險較低：可以由一兩個感興趣的團隊成員在項目中小范圍的試驗 Kotlin，這並不會擾亂你的項目，因為 Kotlin 的類對外提供的 Java API 看起來就與普通的 Java 代碼一樣。
因為 Kotlin 十分注重語法的可讀性，代碼審查不會成為問題，對 Kotlin 不熟悉的團隊成員仍然能夠完成該工作。
Kotlin 基於 Java 6，所以假如你難以在項目中升級使用新版本的 JVM，你可以使用 Kotlin。
今年早些時候我向 Swiss Re 這家瑞士再保險公司的團隊（他們使用 Java 和 .NET）展示了 Kotlin。首先我定義了一個簡單的 Java 類包含一些欄位以及 toString、equals、hashCode 等方法，大概有 50 行代碼。然後我將它轉換成 Kotlin 代碼（大部分是自動完成的），結果僅剩 1 行代碼，接著我還演示了其它節省時間的特性。他們看過後對 Kotlin 充滿了熱情並且認為 Kotlin 是它們項目中 C# 語言的一個潛在競爭對手。
我認為 Kotlin 正中企業 Java 開發者的紅心，所以盡管 Kotlin 是免費的，JetBrains 還是能夠通過它增加商業版本 IDE 的銷售來賺大錢。這將激勵他們根據用戶的意願持續改進它。
與此相比，對於那些由不相關產品資助的語言開發者來說，當用戶需求與之前的設計理念沖突時，他們很少會因此作出調整。
特性
Kotlin 作為一門新的編程語言能夠脫穎而出，是因為它關注生態系統：JetBrains 懂得生產力的高低更多的取決於生態系統而不是便捷的語法。
盡快如此，Kotlin 還是有許多有用的特性能讓你編碼的過程變得愉快：
我們已經提過 null 安全（可選），它能夠讓編譯器系統的標記潛在的空指針引用。與一些語言不同的是它不涉及 option 類，因此是零開銷的，並且還有其它語言特性確保它不會造成不便。
精煉的語法：無處不在的類型推斷、簡單的函數只需要一行、簡單的結構以及 JavaBeans 也只需要一行就能聲明、真正的屬性——可以在背後自動生成 getFoo/setFoo 方法用於與 Java 進行交互、函數可以獨立存在於類之外。
異常均為非檢查型。（譯者註：感興趣的可以閱讀一下Java 理論與實踐: 關於異常的爭論）
使用 data class 關鍵字創建數據類會自動生成通用方法，例如 equals、hashCode、toString 以及 和 componentN（同時聲明多個變數時會調用該方法）。這將幫助你在不使用構建器的情況下便捷的獲得不變類（immutable classes）。
但如果你需要構造復雜的結構體，藉助類型安全的構建器這個特性可以簡潔的實現。如果你使用 Google Protocol Buffers 來存儲結構化數據， 通過 KBuilders 這個庫也能很輕易做到。
支持函數式編程以及零開銷的 lambda 表達式，能夠在 Java 的集合中做 Map、Filter、Folder 等處理。Kotlin 的類型系統能夠自動識別可變或者不可變的集合。
擴展函數特性能夠讓你在不改動源碼的情況下為類添加方法。乍眼一看以為是為了避免寫出像 FooUtils 這種風格工具類的語法糖，不過隨著使用的加深，你會認識到它不僅能幫你更加容易的通過自動完成使用方法，還能協助你集成現有的 Java API 以及藉助其它 Kotlin 特性構建功能強大的擴展。
支持運算符重載，但是不會像 Scala 或者 Perl 那樣出現難以理解的代碼。運算符被映射成相應名字的方法，通過重寫這些方法改變運算符的行為（包括函數調用），但是不能定義新的運算符。這使得程序能夠兼顧功能與可讀性。
Kotlin 沒有宏或者其它的方式來重定義語言，但是通過這些精心設計的特性能夠使第三方庫自由的對它進行擴展，官方對集合類進行的擴展也只是小試牛刀而已，請看以下例子。
想使用 fibers、actors 和 Go 風格的 channels？一個名為 Quasar 的庫已經為你實現了。
使用 Markdown 替代 HTML 來編寫 API 文檔，這樣編寫 JavaDocs 可比以前舒適多了。（譯者註：JetBrains 提供了相應的文檔生成器 Dokka）
更好用的泛型。如果你沒有完全掌握泛型參數中 super 以及 extends 的含義，別擔心，這不是你的錯。Java 的泛型的確令人費解，Kotlin 解決了這個問題。
委託是一個大家都知道的設計模式，Kotlin 原生支持它。
== 運算符的行為符合預期（譯者註：簡單來說 a == b 相當於 a.equals(b)；新增了 === 運算符，用來判斷運算符兩邊是否指向同一個對象）
想快速便捷的進行非同步編程嗎？當然！
字元串插值「可以使用這樣的寫法在字元創中直接引用變數 {this.example}」
函數中的參數可以指定默認值、使用可變長度以及通過參數名傳參。
還有許多的調整與優化。假如 Java 中有某些讓你覺得困擾的問題，我相信 Kotlin 一定已經把它處理好了。
現在就來試用一下！
跟很多現代編程語言一樣，Kotlin 可以通過網頁瀏覽器來進行體驗。不過跟其他語言不一樣的是，Kotlin 的實驗網站提供了一個成熟的 IDE，包括響應很快的自動完成，實時的後台編譯，甚至還有在線的靜態分析！
在線試用一下吧
好了，讓我們繼續接下來的內容
目前存在哪些問題？
生活中沒有什麼是完美的，包括 Kotlin。以下是我嘗試這門語言時遇到的一些問題。
最大的問題是不夠成熟，因為 Kotlin 目前還處於 Beta 階段，這意味著：
每更新一個版本，語法、ABI 以及標准庫就變一次。好消息是這些變化通常比較微小，可以藉助 IntelliJ IDE 來自動升級你的代碼，所以這個過程並不會太麻煩。
Java-to-Kotlin 的轉換工具（J2K）還沒有完成。它偶爾會大規模的破壞和默默地擦除 Java 8 中的 Lambdas（修改：2015 年 10 月：M13 版本的轉換工具已經可以正確地處理 Java 8 的特性了）。由它轉換而成的代碼並不總是最好的寫法，但是 JetBrains 為這個工具付出了大量努力，它已經是我用過的語言轉換工具中最好的了。所以我並不太擔心這個問題，這個轉換器正在迅速的改進中，變得越來越成熟。
你會遇到編譯器錯誤。盡管我的程序並不大，但還是會發生無法編譯的情況，甚至錯誤的編譯結果。診斷這些問題並不難，但終歸還是影響了開發的體驗。
你會遇到 IDE 內部錯誤。當這個錯誤發生時，IntelliJ IDE 會彈出一個懸浮窗口，附帶向 JetBrains 報告的選項。大部分錯誤無需理會，不過依然會使人厭煩。
偶爾會出現無法載入提示文檔的錯誤（修改：M14 版本發布後，這個問題已被修復）
目前 JetBrains 正致力於完善發布 1.0 版本而不是添加新的功能，期待這些問題能夠得到修復。
第二個我遇到的比較大的問題是，有時與 Java 的交互會受到局限。
一個典型的 Bug 是 Java 的類型系統無法防止你改變 Map 中 Key 的類型。按理來說，這樣操作應該導致編譯器報錯，例如使用類型錯誤的 Key 刪除元素。有些 JDK 中的集合使用了泛型，它們某些重要方法的泛型參數是 Obejct，所以編譯器不會提示。當在 IntelliJ IDE 中編寫 Java 代碼時會有靜態分析的警告，但是目前 Kotlin 環境還沒有這個功能。因為 Kotlin 使用的是 Java 的集合框架沒有自己實現，所以這導致了一些類型安全方面的問題，我已經遇到好幾次了。
（修改：1.0 Beta 版本中這個問題已經解決了，Java 中集合框架的類型安全缺陷在 Kotlin 已經不復存在。喲呵！）
另一個例子是，當調用或使用 Java 代碼時 Kotlin 的 Null 安全特性無法發揮作用（可以藉助註解彌補）。作為 Kotlin 的初學者，剛開始你可能會寫許多調用 Java 庫的代碼，但是因為以上的問題它們並沒有你想像中那麼好用。這種情況的改善只能等待 Kotlin 使用人數的增長。JetBrains 一直在嘗試使 Null 安全特性能體現在 Java 交互中，這種想法是好的，但有時考慮並太周全。（修改: 從 M13 版本開始，在 Java 代碼中將自動以 @NotNull @Nullable 等註解實現 Kotlin 的 Null 安全特性）
雖然有以上的問題存在，但同時也使得我們能更流暢的使用 Java API，我覺得這種權衡是值得的，只是在開發中要注意。
其它需要考慮的問題:
Kotlin 的社區還比較小。雖然目前沒有多少 Kotlin 的庫可以使用，但是憑借優秀的 Java 交互能力，Kotlin 可以使用現有成熟的 Java 庫。
如果你喜歡看書來學習，那麼你需要等到今年晚些時候才能看到 Kotlin 開發者寫的書（譯者註：Kotlin in Action）
純粹的函數編程風格開發者可能會覺得類型系統中缺乏一些 Scala 或 Haskell 擁有的高級功能。如果你對類型系統一些功能比較看重，那麼 Kotlin 可能不適合你。
Kotlin 還能編譯成 Javascript 代碼，但是比較少用，所以可能會遇到更多的問題，這是我從論壇中得到的印象。（修改: 目前 Kotlin 的開發重心在於完成 1.0 版本並使其穩定運行在 JVM 中，Javascript 方面的問題將會在 1.0 發布後著手解決）
沒有標準的編程風格指南，目前 Kotlin 提供了多種語法可供選擇。不同人寫出來的 Kotlin 代碼很可能完全不一樣。這與 Go 嚴格的風格形成了鮮明的對比。（修改: Kotlin 1.0 版本開始，一些靈活的語法已經被移除了，例如現在重載運算符以及定義中綴函數時必須分別使用 operator 和 infix 關鍵字進行標記）
Kotlin 的編譯速度稍稍慢於 Java，以及 IntelliJ IDE 的智能提示反應有點緩慢，不算嚴重而且比 Scala 快多了。（修改：Kotlin 1.0 開始編譯速度有了明顯提升）
Kotlin 有一個 Eclipse 插件，但是很明顯沒有 IntelliJ 的好用。
Kotlin 在某些方面比 Java 要嚴格。它不會自動將 Int 轉換為 Long 類型，需要開發者顯示的轉換。這是因為 Kotlin 關注正確性和試圖解決《Java Puzzlers》一書中提出的問題。JetBrains 聲稱他們已經搞定一半了。
Kotlin 基於 Java 6，因此會受到它的局限。Kotlin 與 C# 在很多領域都很相似甚至比 C# 做得更好，但是它缺少一些功能，例如 Java 平台尚未支持的某些數據類型。
為什麼應該開始考慮使用 JVM
最近一段時間我遇到了很多使用動態腳本語言（JavaScript 或者 Go —— 譯者註：Go 應該是靜態編譯型語言）的創業公司。
我在 Bitcoin Space 工作的時候，使用動態語言是非常痛苦的事情。在這些語言里沒有安全性的類型，這已經導致了巨大的貨幣損失。Go 比較少出錯，但是在基礎層面上給人的體驗依然很差，比如說缺少好的調試工具，快速 GC 機制，穩健的管理器以及可靠的分析工具。
過去 15 年或者更長時間里，Java 變得越來越健壯，越來越冗長，甚至有過度設計的跡象，這些變化很大程度上源於它的聲譽。企業級 Java 類的名字 就是例證。在很長一段時間里我沒有考慮 JVM，我確信這種環境並不適合我。
最終我因為 Android 被迫回到 Java，發現 Java 的開發環境已經改變了。雖然 XML 仍然不合時宜的頻繁出現在各種場合，但是一些基礎功能十分完善，令人印象深刻。 IntelliJ 是比 Eclipse 更快並且更智能的 IDE。Maven 一出現就得到了迅速的發展，擁有許多原本我想要其它構建 / 依賴系統增加的功能。較新的 Web 框架像 Ninja 和 Play 從類似 Ruby on Rails 的框架中學到了輕量簡潔。有大量的庫可供使用。硬體性能變得更高以及 JVM 變得更有效率，等等轉變。
沒有真正改變的是語言本身，Java 代碼寫起來依然是令人不快的冗長。
現在有了 Kotlin，完全無需承受離開 Java 現有的生態系統的疼苦。你可以編寫更富有表現力的代碼，但是卻比腳本語言更簡潔，同時擁有更好的性能和更少的錯誤。
如果你喜歡 JavaScript，可以嘗試 Kotlin 的 JS 後端，或者在 Nashorn JS 引擎里運行你現有的代碼。
最後，如果你喜歡 Go 語言是因為它可以編譯獨立運行的程序，那麼試試 javapackager 工具。Kotlin 在本地為每個平台創建了捆綁包，這意味著在 linux 上不需要 JRE 的依賴就可以獨立自主的獲取 DEBs（linux 的安裝包）或者壓縮包。當然，它拆包之後不是單個文件而是單個目錄，從部署的角度來看並不難操作。
簡而言之：如果你之前因為看 Java 不順眼而忽略了 JVM 的生態系統，那麼你應該借著 Kotlin 這門新語言進入這個世界瞧瞧。
⑷ Kotlin——數組
Kotlin為數組增加了一個Array類。為元素是基本類型的數組增加了XxxArray類(其中Xxx可以是Byte、Short、Int等基本類型)
Kotlin自己提供了一套集合體系，Kotlin的集合體系拋棄了Java集合體系中的Queue集合，Kotlin集合體系中增加了可變集合和不可變集合。
Kotlin的數組使用Array<T>來代表，Kotlin的數組就是一個Array類的實例，因此Kotlin數組是引用類型
訪問數組是通過在數組的索引後跟一鄭中個[]來實現，方括弧中的值是數組元素的索引值。kotlin中的[]運算值其實是get(index)、set(index,value)方法，使用[]訪問數組元素，調用的其實就是get(index)方法，使用[]為數組元素賦值，調用的其實就是set(index,value)方法
上面的兩種方式本質是一樣的，在經過編譯器編譯優化後，會轉換成根據數組的內存地址來訪問數組元素，性能不會有任何損失
所有的數組都有 size 屬性，通過這個屬性可以訪問到數組的長度。
for-in 循環可以自動遍判亂歷數組的每個元素
對數組使用for-in循環會被編譯成使用基於索引的循環，並不會創建迭代器。因此具有良好的性能
kotlin數組提供了一個indices屬性，這個屬性可返回數組的索引區間
這種通過索引區間遍歷的實現具有更好的性能，kotlin將會在底層掘叢檔將其編譯成根據內存地址來訪問元素，不需要額外創建區間對象
Kotlin還為數組提供了一個lastIndex屬性，該屬性用於返回數組最後一個元素的索引，size-1
如果需要同時訪問數組的索引和元素，可以使用數組的 withIndex() ，該方法返回一個Iterable對象，該對象的所有元素都是IndexedValue.
⑸ Kotlin & 'onConfigurationChanged' overrides nothing
編譯項目報錯：
但是這個方法是根據 AndroidStudio 自動補全功能，直接自動補全的
原因還是 Java 轉 Kotlin 的類型轉化導致知陪的，由於Kotlin 版本兼容問題，平台類型轉為可空類型時出錯。
去掉 可空類型符號 ？ 就好了。
同輪猛升理，遇臘老到類似問題，可以去掉或者添加 可空類型符號 ？ ，看問題能否解決。
⑹ kotlin—lazy及其原理
lazy是屬性委託的一種，是有kotlin標准庫實現。它是屬性懶載入的一種實現方式，在對屬性使用時才對屬性進行初始化，並且支持對屬性初始化的操作時進行加鎖，使屬性的初始化在多線程環境下線程安全。lazy默認是線程安全的。
lazy既然是屬性委託的一種，那麼其語法也遵循屬性委託的語法：
對應的lazy 的語法為：
由於lazy為函數，其最後一個參數是函數，那麼可以使用lamda的語法代替最後一個函數參數：
通過2中的語法，我們知道lazy是kotlin標准庫中的重載函數，我們先從標准庫lazy的函數的分析其原理：
lazy函數默認情況下是同步安全鎖模式，其可以指定線程同步模式、線程公有模式、非線程安全模式，也在同步模式時指定使用的鎖對象，lazy函數會創建懶載入類的實現類，通過懶載入類的實現類實現不同模式的懶載入。
我們依次分析SynchronizedLazyImpl、SafePublicationLazyImpl、UnsafeLazyImpl這三種模式是怎麼實現懶載入的：
SynchronizedLazyImpl是同步模式的懶載入，它是lazy的默認實現，其在多線程環境下進行初始化是線程安全的，我們看看其源碼實現：
同步模式的懶載入SynchronizedLazyImpl的實現原理其實是使用兩個屬性，一個是公有屬性value—對外代表屬性的值，一個是私有屬性_value——是真正的值。value的get內部對_value進行初始化，如仔納果_value已納局初始化則直接返回，如果沒有初始化過則加鎖並調用初始化函數把返回值賦值給_value。
SafePublicationLazyImpl是多線程環境下的公共線程安全模式，我們從其源碼分析其原理:
公共線程安全模式SafePublicationLazyImpl與同步模式SynchronizedLazyImpl的區別在於，SafePublicationLazyImpl使用自旋鎖進行初始化操作，而SynchronizedLazyImpl是要同步鎖的方式進行初始化操作，其他與SynchronizedLazyImpl的實現一樣。
SafePublicationLazyImpl是非線程安全的懶載入實現模式，在單線程下進行初始化是沒啥問題，但是多線程下是進行初始化是不安全的，我們從其源碼分析其原理：
SafePublicationLazyImpl與前面的兩種模式的實現方式不一樣就是初始化時沒有加任何鎖，其它是一樣的。
上面分析了使用lazy函數之後返回了不同的懶載入實現類及各懶載入實現類的原理，所以lazy的語句最終語句念茄沒的是：
val propertyName by [SynchronizedLazyImpl | SafePublicationLazyImpl | UnsafeLazyImpl]
但具體是怎麼個懶載入實現類的value的get方法呢？——下面我們舉例，然後通過編譯後的位元組碼分析器實現原理:
舉例：
編譯後的位元組碼文件:
通過對生成的位元組碼的分析，lazy的原理：
注意lazy實現了懶載入，達到在使用時才進行初始化的目的，但是也為此增加了一個懶載入類，如果一個類的初始化操作不耗時卻使用lazy進行懶載入是不明智的，lazy的適合場景是類的初始化操作比較耗時占資源。
⑺ Kotlin的延遲初始化
Kotlin中有兩種延遲首虛初始化的方式。一種 lateinit var ，一種 by lazy
在AS中Tools—>Kotlin—>show Kotlin Bytecode—>Decompile反編譯Kotlin位元組碼得到
可以看到：我們在引用變數的時候會進行判斷，如果為空（也就是未初始化），就會拋出異常。
by是屬性委託關鍵字
注釋：使用指定的初始化函數[initializer]來創建一個[Lazy]類型的對象，默認的線程模型是[LazyThreadSafetyMode.SYNCHRONIZED]。默認返回了SynchronizedLazyImpl對象：
我們反編譯Kotlin位元組碼得到
可以看到，生成了一者磨燃個getter方法，return一個(String)var1.getValue()，也就是獲取str會通過getValue。而SynchronizedLazyImpl實現了Lazy的value方法， 調用getValue方法返回_value， _value默認值是UNINITIALIZED_VALUE，表示為初始化，就會調用傳入的initializer進行初始化，並把值賦給 _value，以後每次調用直接返回。
lateinit var和游猛by lazy都可以推遲初始化，lateinit var只是在編譯期忽略對屬性未初始化進行檢查，何時初始化還需開發者自行決定。而by lazy在被第一次調用的時候能自動初始化，做到了真正的延遲初始化的行為。
⑻ 編程時選用的程序設計語言，對軟體的開發與維護的影響
【CSDN 編者按】「如果我們把人類文明想像成汽車的話，那麼軟體開發行業就相當於汽車的引擎，編程語言就像引擎的燃料。」作為一名開發者，需跟隨技術潮流的發展來學習新技術。2020年，你有計劃新學一門編程語言嗎？
本文作者從一名架構師的角度，詳細分析了7種現代編程語言的優點與功能，你對哪門語言最感興趣呢？
作者 | Md Kamaruzzaman，軟體架構師
譯者 | 彎月，責編 | 伍杏玲
封圖| CSDN 下載於視覺中國
出品 | CSDN（ID：CSDNnews）
以下為譯文：
如果我們把人類文明想像成汽車的話，那麼軟體開發行業就相當於汽車的引擎，而編程語言就像引擎的燃料。作為一名開發者，今年你應該學習哪種編程語言呢？
學習一種新的編程語言無疑是時間、精力和智力上的巨大投資， 但是學習一種新的編程語言可以提升你的軟體開發技術力，促進你的職業發展。
在這里，我將獻上一份現代編程語言的列表，這些語言不僅有助於提高你的生產力，而且還可以促進你的職業發展，並讓你成長為更優秀的開發人員。這份列表還涵蓋了非常廣泛的領域：系統編程、應用程序開發、Web開發、科學計算等。
什麼是現代編程語言？
「現代編程語言」這個說法本身就很含糊。許多人認為Python和JavaScript等語言是現代編程語言，還認為Java是一種古老的編程語言。實際上，這幾種語言大約在同一時間出現：1995年。
大多數主流編程語言是上個世紀開發的：七十年代（如C）、八十年代（如C ++）、九十年代（如Java、Python、JavaScript）。這些語言在設計上並沒有考慮現代軟體開發生態系統：多核CPU、GPU、快速的互聯網、移動設備、容器和雲等。盡管許多語言中的許多功能都已進行一些改進，如並發等，而且在不斷調整自己以適應時代，但它們依然保留了向後兼容性，無法拋棄那些過時的舊功能。
在這方面，Python就做得很好（某種意義上也未必是好事），Python 2和Python 3兩者之間有明確的分界線。很多語言常常會為解決同一個問題提供十餘種的方法，同時又沒有顧及到開發人員的感受。根據StackOverflow的開發人員調查，大多數舊時的主流編程語言在「最可怕的語言」排名都名列前茅：
如果非要在新舊編程語言之間劃個界限的話，那麼應該是2007年6月29日，也就是第晌扮埋一台iPhone發行的時候。在這之後，編程語言界發生了很大變化。因此，在本文的列表中，我只考慮2007年以後的編程語言。
為什麼要學習新語言？
首先，現代編程語言充分利用現代計算機硬體（多核CPU、GPU、TPU）、移動設備、大量數據、高速互聯網、容器和雲的優勢。大多數現代編程語言會關注開發人員的體驗，比如：
簡潔明了的代碼（減少樣板代碼）
內置的並發支持
空指針安全
類型推斷
簡潔的功能集
降低學習難度
融合所有編程範例的最佳功能
通過所有權和借用概念提供內存安全和並發安全。
內存安全和並發安全在編譯時確保，即如果程序代碼可以宴螞編譯，那麼內存既安全又沒有數據競爭。這是Rust最吸引人的功能。
它還提供了Haskell中元編程的表現力。憑借不可變的數據結構和功能編程功能，Rust提供了功能並發和數據並發。
Rust的速度非常快，純Rust的性能甚至優於純C。
在沒有運行時的情況下，Rust可以完全控制現代硬體（TPU、GPU、多核CPU）。
Rust具有LLVM支持。因此，Rust提供一流的與WebAssembly的互操作性，而且Web代碼也非常快。
系統編程
Serverless 計算
商業應用
C
C++
Go
Swift
Go具有一流的並發支持。Go不通過線程和鎖提供「共享內存」並發性，因為編程難度太大。相反，它提供了基於CSP的消息傳遞並發性（基於Tony Hoare的論文）。Go使用「 Goroutine」（輕量級綠色線程）和「 Channel」進行消息傳遞。
Go最大的殺手級功能是：簡單，它是最簡單的系統編程語言。新手軟體開發人員只需幾天就可以編寫高效的代碼，就像Python一樣。有些大規模的雲原生項目（如Kubernetes、Docker）都是用Go編寫的。
Go還內置了垃圾收集器，這意味著開發人員無需擔心C/C++中的內存管理問題。
Google投入了大量資金打造Go。因此Go擁有大量的工具支持。新手Go開發人員擁有大量的工具生態系統。
一般，開發人員80%的時間都花在了維護現有代碼上，用於編寫新代碼的時間只佔20%。由於其簡單性，Go在語言維護方面表現出色。如今，Go在業務應用程序中大量使用。
系統編程
Serverless 計算
商業應用
雲原生開發
C
C++
Rust
Python
Java
Kotlin的主要賣點在於其語言設計。我總是將Kotlin視為JVM上的Go/Python，因為它簡潔明了的代碼。因此，Kotlin的生產力很高。
與許多其他現代語言一樣，Kotlin提供了Null指針、安全性、類型推斷等功能。
由於Kotlin也運行在JVM中，因此現有Java庫龐大的生態系統都可供使用。
Kotlin是一流的Android應用開發語言，並且已經超過Java，成為開發Android應用的首選。
Kotlin得到了JetBrains和Open Source的支持，因此具有出色的工具支持。
Kotlin有兩個有趣的項目：Kotlin Native（將Kotlin編譯為原生代碼）和kotlin.js（Kotlin到JavaScript）。如果成功，則可以在JVM外部使用Kotlin。
Kotlin還提供了一種簡單的方式來編寫DSL（域特定語言）。
企業應用程序
主要競爭對手：
TypeScript
JavaScript是一門優秀的編程語言，在2015年之前，JavaScript有很多缺點。著名的軟體工程師Douglas Crockford寫了一本書名為《JavaScript: The Good Parts》，暗示了JavaScript有很糟的部分。無模塊化，還有「回調地獄」，因此開發人員都不喜歡維護特別大的JavaScript項目。
Google甚至還開發了一個平台，可將Java代碼反編譯為JavaScript代碼（GWT）。許多公司和個人都曾嘗試開發更好的JavaScript，例如CoffeeScript、Flow、ClojureScript。最終，微軟的TypeScript取得了成功。
微軟的一隊工程師在著名的Anders Hejlsberg的帶領下，創建了JavaScript的靜態類型、模塊化超集——TypeScript。
TypeScript可以編譯為JavaScript。於2014年首次發布後，TypeScript很快引起了社區的關注。Google當時還計劃開發JavaScript的靜態類型超集。Google對TypeScript青睞有加，以至於他們沒有開發新的語言，而是選擇與微軟合作改進TypeScript。
Google選擇TypeScript作為其SPA框架Angular 2+的主要編程語言。此外，流行的SPA框架React也提供對TypeScript的支持。另一個流行的JavaScript框架Vue.js也宣布將使用TypeScript開發新的Vue.js 3：
另外，node.js的創建者Ryan Dahl已決定使用TypeScript來開發安全的Node.js替代品Deno。
主要特徵：
流行度：
開發人員喜歡TypeScript的優雅語言設計。在StackOverFlow最受歡迎的語言類別的調查中，TypeScript與Python並列第二名：
根據GitHub的排名，TypeScript是增長最快的編程語言之一，排名第五：
從GitHub的貢獻度來看，TypeScript排名第七，打進了前十：
Google的趨勢表明，在過去的幾年中，TypeScript的熱度越來越高：
主要用途：
主要競爭對手：
Swift
當初喬布斯拒絕在iOS中支持Java（和JVM），他認為Java不再是主流編程語言。如今我們發現喬布斯當初的估計是錯的，雖然iOS仍然不支持Java。蘋果選擇了Objective-C作為iOS中的首選編程語言。Objective-C是一門很難掌握的語言，它不支持現代編程語言所要求的高生產力。
後來，蘋果的Chris Lattner和其他人開發了一種多範例、通用的、編譯編程語言——Swift，來替代Objective-C。Swift的第一個穩定版本於2014年發布。Swift還支持LLVM編譯器工具鏈（也由Chris Lattner開發）。Swift與Objective-C代碼庫具有出色的互操作性，並且已確立為iOS應用開發中的主要編程語言。
主要特徵：
流行度：
開發人員對Swift的喜愛不亞於許多其他現代編程語言。根據StackOverflow的調查，Swift在最受歡迎的編程語言中排名第六：
2019年，在TIOBE的編程語言排名中，Swift的排名上升到了第10名。鑒於這種編程語言只有5年的歷史，可以說是成績斐然：
Google的趨勢表明，在過去的幾年中，Swift的熱度出現了激增：
主要用途：
主要競爭對手：
Dart
Dart是Google出品的第二大編程語言。Google是Web和Android領域的巨頭，因此Google在Web和應用領域開發自己的編程語言也不足為奇。在丹麥軟體工程師Lars Bak（領導Chrome的 JavaScript V8引擎開發）的帶領下，Google於2013年發布了Dart。
Dart是一種通用編程語言，支持「強類型」和「面向對象」編程。Dart也可以轉編譯為JavaScript，凡是JavaScript可以運行的任何地方（例如Web、移動、伺服器）幾乎都可以運行 Dart。
主要特徵：
流行度：
根據GitHub Octoverse數據顯示，Dart是2019年增長最快的編程語言，去年它的流行度增長了五倍：
根據TIOBE指數顯示，Dart排名第23，僅用了4年時間就超過了很多其他的現代編程語言：
根據StackOverflow的調查，Dart在最受歡迎的編程語言中排名第12：
受Flutter的影響，Google的趨勢表明，在過去的兩年中，Dart的熱度急劇上升：
主要用途：
主要競爭對手：
Julia
本文提及的大多數編程語言都是由大型公司開發的，但Julia是個例外。科技計算領域通常都會使用動態語言，例如Python、Matlab。雖然這些語言提供易於使用的語法，但不適用於大規模的科技計算。他們需要使用C/C ++庫執行CPU密集型任務，因此這就產生了著名的「兩種語言」的問題，因為他們需要粘合代碼來綁定兩種語言。由於編寫的代碼需要在兩種語言之間來回切換，因此總是會損失部分性能。
為了解決這個問題，麻省理工學院的一隊研究人員計劃從頭開始創建一種新的語言，這種語言既可以利用現代硬體的優勢，而且還結合其他語言的優勢。於是，Julia誕生了。
Julia是一種動態的高級編程語言，提供一流的並發、並行和分布式計算支持。Julia的第一個穩定版本於2018年發布，並很快受到社區和行業的關注。Julia可用於科學計算、人工智慧和許多其他領域，而且還可以解決「兩種語言」的問題。
主要特徵：
流行度：
Julia在許多領域主要與Python競爭。由於Python是最流行的編程語言之一，因此Julia想晉升主流還需要幾年的時間。
雖然Julia非常新（只有一歲），但仍在TIOBE指數中排到第43名：
Google趨勢顯示，在過去的一年中，Julia的熱度在穩步增長：
但是考慮到Julia的功能集，以及NSF、DARPA、NASA、因特爾等公司的推動，相信Julia取得突破的進展只是時間的問題。
主要用途：
主要競爭對手：
原文鏈接：https://towardsdatascience.com/top-7-modern-programming-language-to-learn-now-156863bd1eec
本文為 CSDN 翻譯，轉載請註明來源出處。
【End】
Python
Matlab
科學計算
高性能計算
數據科學
可視化
與Rust一樣，Julia的主要特徵在於語言的設計。這種語言在不犧牲性能的情況下，將高性能和科學計算中現有編程語言的一些功能結合在一起。就目前的情況來看，Julia出色地完成了這項任務。
Julia是一種動態編程語言，支持類型系統但類型不是必須的。因此，Julia這種編程語言很容易學習，生產力很高。
Julia的核心是多調度編程範例。
Julia內部支持並發、並行和分布式計算。
Julia為I/O密集型任務提供非同步I/O。
Julia的運行速度非常快，可用於需要數百萬個線程的科學計算。
JavaScript
TypeScript
應用開發
UI開發
與Go一樣，Dart也非常注重開發人員的工作效率。由於Dart簡潔的語法，以及高效的生產力，受到開發人員的喜愛。
Dart還提供「強類型」和「面向對象」編程。
Dart是少數同時支持JIT編譯（運行時編譯）和AOT編譯（創建時編譯）的編程語言之一。因此，Dart可以針對JavaScript運行時（V8引擎），並且Dart可以編譯為快速的原生代碼（AOT編譯）。
跨平台原生應用程序開發平台Flutter選擇了Dart作為開發iOS和Android應用的編程語言。從那以後，Dart的流行度越來越高。
與Goog的Go編程語言一樣，Dart也具有出色的工具支持和龐大的Flutter生態系統。Flutter的日益普及也會推動Dart的採用率升高。
Objective-C
Rust
Go
iOS應用開發
系統編程
客戶端開發（通過WebAssembly）
Swift的殺手級功能之一是其語言設計。語言本身很簡單，語法簡潔，比Objective-C更高效。
Swift還提供了現代程序語言的功能：null安全。此外，它還提供了語法糖來避免「厄運金字塔」。
作為一種編譯語言，Swift和C++一樣快。
Swift支持LLVM編譯器工具鏈。因此，我們可以在伺服器端編程，甚至瀏覽器編程（使用WebAssembly）中使用Swift。
Swift提供了自動引用計數（ARC）支持，可抑制內存管理的不善。
JavaScript
Dart
Web UI開發
伺服器端開發
與Go或Kotlin同樣，TypeScript的主要特徵也是語言設計。TypeScript憑借其簡潔明快的代碼，成為了目前最優雅的編程語言之一。就開發人員的生產力而言，它與JVM或Go/Python上的Kotlin並駕齊驅。TypeScript是生產力最高的JavaScript超集。
TypeScript是JavaScript的強類型超集，特別適合大型項目，而且可以稱為「可擴展的JavaScript」。
單頁應用程序框架的「三巨頭」（Angular、React、Vue.js）為TypeScript提供了出色的支持。在Angular中，TypeScript是首選的編程語言。在React和Vue.js中，TypeScript越來越受歡迎。
最大的兩家技術巨頭：微軟和Google正在合作開發由活躍的開源社區支持的TypeScript。因此，TypeScript擁有最好的工具支持。
由於TypeScript是JavaScript的超集，因此凡是可以運行JavaScript的任何地方都可以運行TypeScript，包括瀏覽器、伺服器、移動設備、物聯網設備和雲。
Java
Scala
Python
Go
本文列表的許多編程語言都帶有革命性地變化，並將永久地改變軟體行業缺扒。一些已成為主流編程語言，還有一些則有望取得突破。因此選擇這些語言作為第二種編程語言是明智的做法。
Rust
一直以來，系統編程語言環境主要由靠近硬體的語言（如C、C ++等）主導。盡管它們可以完全控製程序和硬體，但是它們缺乏內存安全性。即使它們支持並發，使用C/C ++編寫並發程序也很困難，因為沒有並發安全性。還有一些流行的編程語言是解釋性語言，例如Java、Python、Haskell。這些語言具備安全性，但需要龐大的運行時或虛擬機。由於它們的運行時間長，因此Java等語言不適合於系統編程。
許多人曾嘗試將C/C ++的功能與Java、Haskell的安全性相結合。然而，Rust才是第一個成功實現了這一點的編程語言。
Graydon Hoare在業余項目中開發出了Rust，他的靈感來自研究編程語言Cyclone。Rust是開源的，由Mozilla與許多其他公司和社區一起領導這門語言的開發。Rust於2015年首次發布，並很快引起了社區的關注。
主要特徵：
流行度：
自2015年首次亮相以來，Rust已被開發人員廣泛接受，並在StackOverflow開發人員調查中連續四年（2016、2017、2018、2019）被評選為最受歡迎的語言：
根據GitHub Octoverse的調查，Rust是運行速度第二快的語言，僅次於Dart：
此外，根據編程語言流行度排名網站PyPl的數據，Rust排名第18位，並呈上升趨勢：
對比Rust提供的功能集，我們就會明白為什麼微軟、亞馬遜、Google等科技巨頭相繼宣布投資Rust作為一種長期的系統編程語言。
根據Google統計的趨勢，在過去的5年中，Rust的熱度每年都在增加。
主要用途：
主要競爭對手：
Go
在本世紀初，Google面臨兩個擴展問題：開發擴展和應用程序擴展。開發擴展問題指的是他們不能僅通過投入開發人員的方式來添加更多功能。應用程序擴展問題則指他們無法開發出一款能夠擴展到Google級別的計算機集群的應用程序。
所以在2007年左右，Google創建了一種新的編程語言，用於解決這兩個擴展問題。兩位才華橫溢的Google軟體工程師Rob Pike（UTF-8）和Ken Thompson（UNIX OS）創建了一種新語言。
2012年，Google正式發布了第一版的Go編程語言。Go是一種系統編程語言，但與Rust不同，它還具有Runtime和垃圾收集器（幾兆位元組）。但是與Java或Python不同，這個Runtime包含了生成的代碼。最後，Go生成了一個本地的二進制代碼，可以在沒有附加依賴項或運行時的情況下在計算機中運行。
主要特徵：
流行度：
Go一問世就受到了軟體開發社區熱烈的歡迎。2009年-2018年，Go一直在TIOBE編程語言排行榜上徘徊。Go的成功為Rust等新一代編程語言鋪平了道路。
如今，Go已是主流編程語言。最近，Go團隊宣布了有關「Go 2」的消息，這門編程語言的發展會更加穩固。
幾乎在所有的流行編程語言排行榜中，Go的排名都很高，已超過許多現有的語言。自2019年12月以來，在TIOBE指數排名中，Go名列第15位：
根據StackOverFlow的調查，十大最受喜愛的編程語言中，Go也位列其中：
此外，根據GitHub的數據，Go也是十大發展最迅速的語言之一：
Google趨勢顯示，在過去的5年中，Go的熱度每年都在增加。
主要用途：
主要競爭對手：
Kotlin
Java 是企業軟體開發領域無可爭議的王者。近年來，Java受到了一些負面評論：過於冗長，大量樣板代碼，容易出現意外的復雜性。但是，關於Java虛擬機（JVM）的爭論卻很少。JVM是軟體工程的傑作，經過了時間的考驗，提供了硬核的runtime。
多年來，Scala等JVM語言一直在努力克服Java的缺點，想成為更好的Java，但他們都失敗了。最終，這場提升Java的探索以Kotlin的誕生結束。Jet Brains（流行的IDE IntelliJ背後的公司）開發了Kotlin，它可以在JVM上運行，克服了Java的很多缺點，提供許多現代功能。
與Scala不同的是，Kotlin比Java更簡單，還可在JVM中提供與Go或Python開發人員同等的生產力。
Google宣布Kotlin是一流的Android應用開發語言，因此Kotlin在社區中的接受度得到了大幅提高。自2017年以來，同樣受歡迎的Java Enterprise框架Spring也開始支持Kotlin。我曾嘗試結合Kotlin與Reactive Spring使用，體驗非常棒。
主要特徵：
流行度：
自2015年首次發布以來，Kotlin的知名度不斷飆升。根據Stack Overflow，Kotlin是2019年第四大最受歡迎的編程語言：
Kotlin還是增長最快的編程語言之一，排名第四：
在流行編程語言排名網站PyPl的排名中，Kotlin名列第十二名，並具有較高的上升趨勢：
自從Google宣布Kotlin是一流的Android應用開發語言以來，Kotlin的流行趨勢出現了大幅上漲，如下所示：
主要用途：
⑼ SpringBoot到Kotlin血淚史
如果原先有 @Bean(name="xxx") 直接用方法名即可（我原先的 name 和方法名不一樣洞段就很尷尬）
hashedCredentialsMatcher 中的內容可以直接 new ，所以不需要注入
如果SpringBoot的版本從 1.5.x 變成了 2.0.x ， shiroDialect 或者 shiroFilter 可能會報如下錯誤
把 thymeleaf-extras-shiro 的版本號改成 2.0.0 即可（原先是 1.2.1 ）
在 SpringBoot 版本中，在 Realm 中注入 Service 時，為了啟用緩存，需要在前面加上 @Lazy 註解，如下
在 Kotlin 版本中我不知道發了啥瘋就把它去掉了（可能是看到前面類型是 lateinit var ，自以為是的覺得可以代替 @Lazy ），然後改成了改成如下形式
拷貝完整個叢滾項目之後，測試功能的時候，發現緩存沒了……然後就開始瘋狂DEBUG，從版本問題，到 jar 包沖突問題，經歷了很漫長的一段時間後，我定位到了 ShiroConfiguration ，只要把 shiro aop 註解關閉就可以開啟緩存了
WHAT？？
瘋狂谷納鄭譽歌一個小時無果（因為一直以為是 Kotlin 不兼容啥的，或者是 shiro 在 boot2.x 之後需要修改相應的配置）
然後又瘋狂DEBUG，把 Kotlin 版和 springboot 版進行對比，最後。定位到了 @Lazy （還好只是改成了注釋，沒把它給直接刪了）
果然。加了 @Lazy ，整個天都亮了
最後順便提一句 Realm 認證超級管理員的問題，可以直接在 Realm 中加上超級管理員的特別認證，就不用去方法級別上區分這個許可權可以超級管理和XX管理員都可用了
⑽ Kotlin介紹系列（三）高級用法之DataClass
經常會需要創建一些類除了保存數據不幹其他事情，比如我們臘凳野解析網路請求下輪喊來的數據。Kotlin就提供了一個非常方便的class—— data class
我們知道在Kotlin中，聲明類的同時可以方便的直接聲明構造方法等參數，鑒於data class只是存放數據，那麼只一個構造方法足矣，所以連類的body也就不需要了。是不是很清爽？
編譯器會根據我們在構造函數里聲明的屬性自動導出下列成員：
經常會遇到我們只需要替換一個對象的個別屬性，而其他屬性保留的情況。這就是data class中生成的函數的作用了。
本文已開始的例子類，它的生成的默認函數是下面粗和這樣的：
fun (name: String = this.name, age: Int = this.age) = User(name, age)
這就運訓我們這樣寫：
data class的生成的component方法給我們的結構化聲明及使用提供了可能
Kotlin介紹系列（三）高級用法之object
Kotlin介紹系列（三）高級用法之Delegation