寫在前面的話，作為一個不熬夜的人，一覺醒來發現 kotlin 成為了 android 的官方語言，可謂是大喜過望。為了趁熱打鐵，我決定提前三天放出原定本周日 release 的文章。希望能及時讓大家了解一下 kotlin。
相信很多開發人員，尤其是 android 開發者都會或多或少聽說過 kotlin，當然如果沒有聽過或者不熟悉也沒有關系。因為本篇文章以及部落格後期的内容會涉及到很多關于 kotlin 的知識分享。
在寫這篇文章前的一個多月，flipboard 中國的 android 項目确定了正式将 kotlin 作為項目開發語言，這就意味着新增的代碼檔案将以 kotlin 代碼格式出現，而且同時舊的 java 代碼也将會陸陸續續翻譯成 kotlin 代碼。在使用 kotlin 的這段時間，被它的簡潔，高效，快捷等等特點震撼，是以有必要寫一篇文章來談一談 kotlin 的特性，如若能取得推廣 kotlin 的效果則倍感欣慰。
kotlin的「履歷」
來自于著名的 ide intellij idea(android studio 基于此開發) 軟體開發公司 jetbrains(位于東歐捷克)
起源來自 jetbrains 的聖彼得堡團隊，名稱取自聖彼得堡附近的一個小島 (kotlin island)
一種基于 jvm 的靜态類型程式設計語言
來自知名的工具開發商 jetbrains，也就決定了 kotlin 的基因中必然包含實用與高效等特征。那我們接下來看一看 kotlin 的特點，當然這也是我改用 kotlin 的重要原因。
文法簡單，不啰嗦
kotlin 支援類型推斷，沒有 java 那樣的啰嗦。
另外用 var 表示變量，val 表示常量更加的簡潔
方法也很簡單，連 function 都縮寫成了 fun，平添了幾分雙關之意。
類的繼承和實作很簡單，使用:即可
kotlin 每個句子都不需要加分号 (;)
空指針安全
空指針（nullpointerexception 或 npe）是我們使用 java 開發程式中最常見的崩潰了。因為在 java 中我們不得不寫很多防禦性的代碼，比如這樣：
在 kotlin 中空指針異常得到了很好的解決。
在類型上的處理，即在類型後面加上?，即表示這個變量或參數以及傳回值可以為 null，否則不允許為變量參數指派為 null 或者傳回 null
對于一個可能是 null 的變量或者參數，在調用對象方法或者屬性之前，需要加上?，否則編譯無法通過。
如下面的代碼就是 kotlin 實作空指針安全的一個例子，而且相對 java 實作而言，簡直是一行代碼搞定的。
關于空指針安全的原理，可以參考這篇文章研究學習kotlin的一些方法。
支援方法擴充
很多時候，framework 提供給我們的 api 往往都時比較原子的，調用時需要我們進行組合處理，因為就會産生了一些 util 類，一個簡單的例子，我們想要更快捷的展示 toast 資訊，在 java 中我們可以這樣做。
但是 kotlin 的實作卻讓人驚奇，我們隻需要重寫擴充方法就可以了，比如這個 longtoast 方法擴充到所有的 context 對象中，如果不去追根溯源，可能無法區分是 framework 提供的還是自行擴充的。
注意：kotlin 的方法擴充并不是真正修改了對應的類檔案，而是在編譯器和 ide 方面做得處理。使我們看起來像是擴充了方法。
lambda, 高階函數，streams api, 函數式程式設計支援
所謂的 lambda 表達式是匿名函數，這使得我們的代碼會更加的簡單。比如下面的代碼就是 lambda 的應用。
所謂的高階函數就是：
可以接受函數作為參數
也可以傳回函數作為結果
舉一個接受函數作為參數的例子。在 android 開發中，我們經常使用 sharedpreference 來存儲資料，如果忘記調用 apply 或者 commit 則資料修改不能應用。利用 kotlin 中的高階函數的功能，我們能更好的解決這個問題：
當然這上面的例子中我們也同時使用了方法擴充這個特性。
kotlin 支援了 streams api 和方法引用，這樣函數式程式設計更加友善。比如下面的代碼就是我們結合 jsoup，來抓取某個 proxy 網站的資料，代碼更加簡單，實作起來也快速。
字元串模闆
無論是 java 還是 android 開發，我們都會用到字元串拼接，比如進行日志輸出等等。在 kotlin 中，字元串模闆是支援的，我們可以很輕松的完成一個字元串數組的組成：
注意：關于字元串拼接可以參考這篇文章java細節：字元串的拼接。
與 java 互動性好
kotlin 和 java 都屬于基于 jvm 的程式設計語言。kotlin 和 java 的互動性很好，可以說是無縫連接配接。這表現在：
kotlin 可以自由的引用 java 的代碼，反之亦然。
kotlin 可以現有的全部的 java 架構和庫
java 檔案可以很輕松的借助 intellij 的插件轉成 kotlin
kotlin 應用廣泛
kotlin 對 android 應用開發支援廣泛，諸多工具，比如 kotterknife(butterknife kotlin 版)，rxkotlin,anko 等等，當然還有已經存在的很多 java 的庫都是可以使用的。
除此之外，kotlin 也可以編譯成 javascript。最近使用 kotlin 寫了一段抓取 proxy 的代碼，實作起來非常快捷。甚至比純 javascript 實作起來要快很多。
關于性能
kotlin 的執行效率和 java 代碼的執行效率理論上一緻的。有時候 kotlin 可能會顯得高一些，比如 kotlin 提供了方法的 inline 設定，可以設定某些高頻方法進行 inline 操作，減少了運作時的進棧出棧和儲存狀态的開銷。
讀到這裡，是不是想要嘗試一下 kotlin 呢，它簡潔的文法，彙集諸多特性，高效率實作等等，已經在國外風生水起，國外的 pintereset, square, flipboard 等公司已經開始應用到生産中。
關于轉向 kotlin
其實，我在做決定之前（當時 kotlin 還沒有被欽定）也曾有過考慮，是不是選擇了 kotlin 就意味着放棄 java 呢，冷靜下來想一想，其實并不是那麼回事，因為 kotlin 與 java 文法太相近，以及在 kotlin 中無時無刻不在和 java 相關的東西打交道，是以這點顧慮不是問題的。
對于個人的項目來轉向 kotlin，通常不是很難的選擇，畢竟 kotlin 是那麼優秀的語言，相信很多人還是願意嘗試并使用這個事半功倍的語言的。
而比較難抉擇的情況是如果如何讓團隊轉用 kotlin，個人認為團隊難以轉用的原因有很多，比如學習成本，曆史包袱等等。但其實根本原因還是思維方式的問題，歪果仁喜歡用工具來提升開發效率，因為人力成本很高。而國内團隊提高效率的辦法通常是增加成員。好在 flipboard 美國團隊自 2015 年（可能更早）就引入了 kotlin，是以中國團隊這邊選用 kotlin 也更加順水推舟。當然更主要的是目前團隊規模不大，成員一緻認可 kotlin 的優點。
關于團隊轉用 kotlin 的方法，一般比較行得通的辦法是自上而下的推行。這就意味着要麼直接的技術負責人比較開明要麼就是需要有人來不斷推介來影響團隊。
做個比較現實的比拟，java 就像是一趟從我的家鄉保定開往北京西的耗時将近 2 個小時甚至更長的普通列車，而 kotlin 則是那趟僅需 40 分鐘就能到達的高鐵。通常的人都會選擇高鐵，因為它節省了時間和提高了體驗。這個時間和體驗對應程式設計中的，我想應該是高效率和高可讀性，可維護性的代碼。
現在好了，有了 google 的支援，kotlin 轉 android 相信在不久的将來就會全面展開。篡改 python 的一句名言「人生苦短，我用 kotlin」，這樣一個高效實用的語言應該會被越來越多的團隊所接受，并應用到開發生産中。當然也希望在國内環境下大放異彩。