Hello！我們又回到了Kotlin，上篇博客：http://www.lxweimin.com/p/dffe80f4486e 我們最后在findViewById結束，那么這次就由它開始了。
OnClickLisener
上篇博客里面我們寫了一段Code，主要獲取了一個TextView的控件，然后設置文本，字體大小，點擊事件，toast，Intent跳轉界面，現在我們先來設置個 OnClickLisener。
tv_hello_view.onClick {
Toast.makeText(this@HelloActivity, "點擊了我,進行跳轉!", Toast.LENGTH_SHORT).show()
val mIntent = Intent(this@HelloActivity, MainActivity::class.java)
mIntent.putExtra("arr", "123456")
startActivity(mIntent)
}
onClick的內部實現如下：
onClick 是一個擴展方法，傳入的 Lambda 表達式通過 SAM 轉換成了 OnClickListener，一切都是這么的自然。如果你對傳入的 view 感興趣，你當然可以直接用 it 得到當前view。
startActivity
直接看Code，傳遞方ex如下：
接收方：
我從HelloActivity中傳入了兩個參數（key1,key2）到KoTlinActivity中，并通過TextView顯示。這便是一個Kotlin啟動新的Activity并傳遞參數的例子，可能有人會問我這里如果想傳Bundle或者其他對象，應該怎么傳呢，可以取嘗試一下，先不說其他的呢，我們來看下有關internalStartActivity的一段代碼：
可以看到無論是啟動Activity，ActivityForResult,Service都是有相關方法的。
Logcat和toast
通常我們在Java中會自定義一些LogUtils類來打日志，或者直接用android.util.log來輸出日志，往往會在基類或者頂部定義一個TAG,有了Kotlin的這個擴展功能，日子就會好過得多了，它就是Kotlin中的擴展類，它是在現有類的基礎上，添加一些屬性或者方法，當然擴展的這些成員需要導入當前擴展成員所在的包才可以訪問到，我們來看看日志的寫法（在之前的例子中有寫到）。
調用此方法： debug();
至于toast的寫法，也很簡單啦， toast(""),是不是真的很簡單，再也不用去單獨封裝一個toast類了。
Lambdas函數支持
Java 8已經開始可以支持Lambda表達式了，不過對于Kotlin來說也是支持的。通常我們需要執行一段異步的代碼，我們會構造一個Runnable對象，然后交給executor，比如這段java代碼：
只說帥不帥？還有handler.post{}，textView.onClick{ }等等。真的在一定程度上幫我們少了很多代碼。
好了，作為一個Android開發者，我覺得以上幾種是對Android開發發很有用的，即使我們不太會或不太習慣，我覺得可以從最基本的做起，終于還有其他的DSL布局的使用，因為我還是習慣用xml，就不在這里介紹了，有興趣的可參考一下鏈接后半部分，將的很細致：http://mp.weixin.qq.com/s?__biz=MzIzMTYzOTYzNA==&mid=100000193&idx=1&sn=2564acb07db54c72164acc5e6d3297e1&chksm=68a05efc5fd7d7ea309d716056c888e6b9a503b5982b99271758ecec89150c833e5c1a49e136&mpshare=1&scene=23&srcid=0309iHbuVnSyv6qHhC0ebzLI#rd
小結
目前Kotlin 1.0已經release，盡管像0xffffffff識別成Long類型這樣的bug仍然沒有解詳情：
val int: Int = 0xffffffff // error
val anotherInt: Int = 0xffffffff.toInt() // correct
不過，Kotlin的教學資源和社區建設也已經相對成熟，按照官方的說法，Kotlin可以作為生產工具投入開發，詳情可以參考：https://blog.jetbrains.com/kotlin/2016/02/kotlin-1-0-released-pragmatic-language-for-jvm-and-android/
敢于吃螃蟹，多少有些浪漫主義色彩，我們這些程序員多少可以有些浪漫主義特質，不過在生成環境中，穩定高于一切仍然是不二法則。追求新技術，一方面會給團隊帶來開發和維護上的學習成本，另一方面也要承擔未來某些情況下因為對新技術不熟悉而產生未知問題的風險——老板們最怕風險了~~
基于這一點，毫無疑問，Kotlin可以作為小工具、測試用例等的開發工具，這是考慮到這些代碼通常體量較小，維護人數較少較集中，對項目整體的影響也較小；而對于核心代碼，則視情況而定吧。
就我個人而言，長期下去，Kotlin很大可能會成為我的主要語言，短期內則仍然采用溫和的改革方式慢慢將Kotlin滲透進來。
一句話，****Kotlin是用來提升效率的，如果在你的場景中它做不到，甚至成了拖累，請放開它****。
