Hello！我们又回到了Kotlin，上篇博客：http://www.jianshu.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是用来提升效率的，如果在你的场景中它做不到，甚至成了拖累，请放开它****。
