【Bugly 技术干货】Android开发必备知识：为什么说Kotlin值得一试

需要说明的是，这段代码是我从《Kotlin for Android Developer》的示例中摘出来的。有了这个Delegate类，我们就可以完全不需要关心SharedPreference了，下面给出使用的示例代码：

class WhateverActivity : Activity(){
    var aInt: Int by Preference(this, "aInt", 0)
    
    fun whatever(){
        println(aInt)//会从SharedPreference取这个数据
        aInt = 9 //会将这个数据写入SharedPreference
    }
}

于是我们再也不需要重复写那些getSharedPreference，也不用edit、commit，再见那些edit之后忘了commit的日子。有没有觉得非常赞！

扩展类，就是在现有类的基础上，添加一些属性或者方法，当然扩展的这些成员需要导入当前扩展成员所在的包才可以访问到。下面给出一个例子：

data class Coordinate(val x: Double, val y: Double)

val Coordinate.theta: Double
    get() {
        return Math.atan(y/x)
    }

fun Coordinate.R():Double{
    return Math.hypot(x, y)
}

我们已经介绍过data class，Coordinate有两个成员分别是x和y，我们知道通常表示一个二维平面，有这俩够了；然而我们在图形学当中经常会需要求得其极坐标，所以我们扩展了Coordinate，增加了一个属性theta表示角度（反正切的值域为-π/2 ~ π/2，所以这个式子不适用于二三象限，不过这不是重点了），增加了一个R方法来获得点的半径，于是我们在main方法中就可以这么用：

fun main(args: Array) {
    val coord = Coordinate(3.0,4.0)
    println(coord.theta)
    println(coord.R())
}

那么这个扩展有什么限制呢？

在扩展成员当中，只能访问被扩展类在当前作用域内可见的成员，本例中的x和y都是public的（Kotlin默认public，这个我们后面会提到），所以可以在扩展方法和属性中直接访问。

扩展成员与被扩展类的内部成员名称相同时，扩展成员将无法被访问到

好的，基本知识就是这些了，下面我们再给出一个实际的例子。

通常我们在Java中会自定义一些LogUtils类来打日志，或者直接用android.util.log来输出日志，不知道大家是什么感受，我反正每次因为要输入Log.d还要输入个tag简直烦的要死，而且有时候恰好这个类还没有tag这个成员，实践中我们通常会把当前类名作为TAG，但每个类都要做这么个工作，是在是没有什么趣味可言（之前我是用LiveTemplates帮我的，即便如此也没有那种流畅的感觉）。

有了Kotlin的这个扩展功能，日子就会好过得多了，下面我创建的一个打日志的方法：

package com.benny.utils

import android.util.Log

inline fun  T.debug(log: Any){
    Log.d(T::class.simpleName, log.toString())
}

有了这个方法，你可以在任何类的方法体中直接写：

debug(whatever)

然后就会输出以这个类名为TAG的日志。

嗯，这里需要简单介绍Kotlin在泛型中的一个比较重要的增强，这个在Java中无论如何也是做不到的：inline、reified。我们再来回头看一下debug这个方法，我们发现它可以通过泛型参数T来获取到T的具体类型，并且拿到它的类名——当然，如果你愿意，你甚至可以调用它的构造方法来构造一个对象出来——为什么Kotlin可以做到呢？因为这段代码是inline的，最终编译时是要编译到调用它的代码块中，这时候T的类型实际上是确定的，因而Kotlin通过reified这个关键字告诉编译器，T这个参数可不只是个摆设，我要把它当实际类型来用呢。

为了让大家印象深刻，我下面给出类似功能的Java的代码实现：

    public static void debug(Class clazz, Object log){
        Log.d(clazz.getSimpleName(), log.toString());
    }

而你如果说希望在Java中也希望像下面这样拿到这个泛型参数的类型，是不可以的：

public static  void debug(Object log){
    Log.d(T.getSimpleName(), log.toString());//错误，T是泛型参数，无法直接使用
}

就算我们在调用处会写道 debug < Date >("blabla")，但这个Date在编译之后还是会被擦除。

Java 8已经开始可以支持Lambda表达式了，这种东西对于Java这样一个『根红苗正』的面向对象编程语言来说还真是显得不自然，不过对于Kotlin来说，就没那么多顾忌了。

通常我们需要执行一段异步的代码，我们会构造一个Runnable对象，然后交给executor，比如这段java代码：

executor.submit(new Runnable(){
    @Override
    public void run(){
        //todo
    }
});

用Kotlin怎么写呢？

executor.submit({
    //todo
})

一下子省了很多代码。

那么实际当中我们可能更常见到下面的例子，这是一段很常见的Java代码，在Android的UI初始化会见到：

textView.setOnClickListener(new OnClickListener(){
    @Override
    public void onClick(View view){
        //todo
    }
});

handle.post(new Runnable(){
    @Override
    public void run(){
        //todo
    }
});

那么我们用Kotlin怎么写呢？

textView.setOnClickListener{ /*todo*/ }
handler.post{ /*todo*/ }

在Anko这个Android库的帮助下，我们甚至可以继续简化OnClickListener的设置方式：

textView.onClick{ /*todo*/ }

当然，好玩的不止这些，如果结合上一节我们提到的扩展方法，我们就很容易看到Kotlin的标准库提供的类似with和apply这样的方法是怎么工作的了：

public inline fun  with(receiver: T, block: T.() -> R): R = receiver.block()

public inline fun  T.apply(block: T.() -> Unit): T { block(); return this }

我们通常会在某个方法体内创建一个对象并返回它，可我们除了调用它的构造方法之外还需要做一些其他的操作，于是就要创建一个局部变量。。。有了apply这个扩展方法，我们就可以这么写：

fun getStringBuilder: StringBuilder{
    return StringBuilder().apply{
        append("whatever")
    }
}

这样返回的StringBuilder对象实际上是包含"whatever"这个字符串的。

至于说Kotlin对于RxJava的友好性，使得我突然有点儿相信缘分这种东西了：

       Observable.create> {
            it.onStart()
            try {
                it.onNext(dummyObjs)
            } catch(e: Exception) {
                it.onError(e)
            } finally {
                it.onCompleted()
            }
        }.subscribe(object : Subscriber>() {
            override fun onCompleted() {

            }

            override fun onNext(t: ArrayList?) {

            }

            override fun onError(e: Throwable?) {

            }

        })

记得之前在浏览Scala的特性时，看到：

object HelloScala{
  // do something
}

觉得很新鲜，这时候有个朋友不屑的说了句，Scala的模式匹配才真正犀利——Kotlin当中也有这样的特性，我们下面就来看个例子：

val x = 7
when (x) {
  in 1..10 -> print("x is in the range")
  in validNumbers -> print("x is valid")
  !in 10..20 -> print("x is outside the range")
  else -> print("none of the above")
}

咋一看感觉when表达式就是一个增强版的switch——Java 7以前的switch实际上支持的类型非常有限，Java 7当中增加的对String的支持也是基于int类型的——我们可以看到when不再像switch那样只匹配一个数值，它的子式可以是各种返回Boolean的表达式。

when表达式还有一种写法更革命：

when {
  x.isOdd() -> print("x is odd")
  x.isEven() -> print("x is even")
  else -> print("x is funny")
}

只要是返回Boolean的表达式就可以作为when的子式，这样when表达式的灵活性可见一斑。当然，与Scala相比，Kotlin还是要保守一些的，下面给出一个Scala类似的例子，大家感受一下，这实际上也可以体现出Kotlin在增加Java的同时也尽量保持简单的设计哲学（大家都知道，毕竟Scala需要智商o(╯□╰)o）。

object Hello {
  def main(args: Array[String]) {
    easyMatch((1, 3))
    easyMatch(Array(1,3,4))
    easyMatch(Bean(3.0, 4.0))
  }

  def easyMatch(value : Any) = value match {
      case int :Int => {
        println("This is an Int.")
      }
      case (a, b) =>{
        println(s"a tuple with : $a , $b")
      }
      case Bean(x, y)  => {
        println(s"$x, $y")
    }
      case whatever => println(whatever)
    }
}

case class Bean(val x: Double, val y: Double)

运行结果如下：

a tuple with : 1 , 3
[I@2d554825
3.0, 4.0

我曾经做过一段时间的SDK开发，SDK的内部有很多类其实是需要互相有访问权限的，但一旦类及其成员是public的，那么调用方也就可以看到它们了；而protected或者default这样的可见性对于子包却是不可见的。

用了这么久Java，这简直是我唯一强烈感到不满的地方了，甚至于我突然明白了C++的friend是多么的有用。

Kotlin虽然没有提供对于子包可见的修饰符，不过它提供了internal：即模块内可见。换句话说，internal在模块内相当于public，而对于模块外就是private了——于是乎我们如果开发SDK，那么可以减少api层的编写，那些用户不可见的部分直接用internal岂不更好。当然有人会说我们应当有proguard做混淆，我想说的是，proguard自然是要用到的，不过那是SDK这个产品加工的下一个环节了，我们为什么不能在代码级别把这个事情做好呢？

关于Kotlin的默认可见性究竟是哪个还有人做出过讨论，有兴趣的可以参考这里：Kotlin’s default visibility should be internal。

其实我们对DSL肯定不会陌生，gradle的脚本就是基于groovy的DSL，而Kotlin的函数特性显然也是可以支持DSL的。比如，我们最终要生成下面的xml数据：

我们可以构建下面的类：

class Project {
    var version: String? = null
        get() =
        if (field == null) ""
        else {
            " version="${field}""
        }

    lateinit private var component: Component

    fun component(op: Component.() -> Unit) {
        component = Component().apply {
            op()
        }
    }

    override fun toString(): String {
        return "${component}"
    }


}

fun project(op: Project.() -> Unit): Project {
    return Project().apply {
        op()
    }
}

class Component {
    var name: String? = null
        get() =
        if (field == null) ""
        else {
            " name="${field}""
        }


    lateinit private var file: File

    fun file(op: File.() -> Unit) {
        file = File().apply {
            op()
        }
    }

    override fun toString(): String {
        return "${file}"
    }
}

class File {
    var url: String? = null
        get() =
        if (field == null) ""
        else {
            " url="${field}""
        }

    var charset: String? = null
        get() =
        if (field == null) ""
        else {
            " charset="${field}""
        }

    override fun toString(): String {
        return ""
    }
}

fun main(args: Array) {
    val xml = project {
        version = "4"
        component {
            name = "Encoding"
            file {
                url = "PROJECT"
                charset = "UTF-8"
            }
        }
    }

    println(xml)
}

我们看到在main方法当中，我们用kotlin定义的dsl写出了一个Project对象，它有这与xml描述的一致的结构和含义，如果你愿意，可以构造相应的方法来输出这样的xml，运行之后的结果：

当然，这个例子做的足够的简陋，如果你有兴趣也可以抽象出"Element"，并为之添加"Attributes"，实际上这也不是很难。

写了很多代码，却发现它们干不了多少事情，终究还是会苦恼的。比如我一直比较痛苦的一件事儿就是：

Button button = (Button) findViewById(R.id.btn);

如果我需要很多个按钮和图片，那么我们要写一大片这样的findViewById。。妈呀。。。这活我干不了啦。。

不过用Kotlin的Android扩展插件，我们就可以这样：

先上布局文件：

main.xml

在Activity中：

package com.benny

……
import kotlinx.android.synthetic.main.load_activity.*
import org.jetbrains.anko.onClick
import org.jetbrains.anko.startActivity
import org.jetbrains.anko.toast
……

class LoadActivity : Activity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.main)

        start.onClick {
            toast("开始")
            startActivity()
        }
        textView.text = "你好"
              
    }
}

注意到：

import kotlinx.android.synthetic.main.load_activity.*

导入这一句之后，我们就可以直接在代码中使用start、textView，他们分别对应于main.xml中的id为start的按钮和id为textView的TextView。

于是你就发现你再也不用findViewById了，多么愉快的一件事！！！当然，你还会发现Toast的调用也变得简单了，那其实就是一个扩展方法toast()；而startActivity呢，其实就是一个inline加reified的应用——这我们前面都提到过了。

还有一个恶心的东西就是UI线程和非UI线程的切换问题。也许你会用handler不断的post，不过说真的，用Handler的时候难道你不颤抖么，那可是一个很容易内存泄露的魔鬼呀~哈哈，好吧其实我不是说这个，主要是用handler写出来的代码 实在 太 丑 了 ！！

原来在java当中，我们这么写：

handler.post(new Runnable(){
    @Override
    public void run(){
        //todo    
    }
});

MainActivity.this.runOnUiThread(
    public void run(){
        //todo
    }
});

而在Kotlin当中呢，我们只需要这么写：

async() {
    //do something asynchronously
    uiThread {
        //do something on UI thread
    }
}

自己感受一下吧。

下面我们再来提一个有意思的东西，我们从做Android开发一开始就要编写xml，印象中这个对于我来说真的是一件痛苦的事情，因为它的工作机制并不如代码那样直接（以至于我现在很多时候居然喜欢用Java代码直接写布局）——当然，最主要的问题并不是这个，而是解析xml需要耗费CPU。Kotlin有办法可以解决这个问题，那就是DSL了。下面给出一个例子：

linearLayout {
    button("Login") {
        textSize = 26f
    }.lparams(width = wrapContent) {
        horizontalMargin = dip(5)
        topMargin = dip(10)
    }
}

一个LinearLayout包含了一个Button，这段代码你可以直接写到你的代码中灵活复用，就像这样：

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContentView(linearLayout {
            button("This is a button") {
                onClick {
                    toast("clicked!")
                }
            }.lparams {
                width = matchParent
                verticalMargin = dip(5)
            }
        })
    }

这样做的好处真是不少：

比起xml的繁琐来，这真是要清爽很多

布局本身也是代码，可以灵活复用

再也不用findViewById了，难道你不觉得在这个上面浪费的生命已经足够多吗

事件监听很方便的嵌到布局当中

DSL方式的布局没有运行时的解析的负担，你的逻辑代码怎么运行它就怎么运行

Anko还增加了更多好玩的特性，有兴趣的可以参考：Anko@Github

我曾经尝试用Scala写了个Android的HelloWorld，一切都配置好以后，仅仅引入了Scala常见的几个库，加上support-v4以及appcompat这样常见的库，结果还是报错了。是的，65K。。。而且用Scala开发Android的话，基于gradle的构建会让整个app的build过程异常漫长，有时候你会觉得自己悟出了广义相对论的奥义，哦不，你一定是晕了，时间并没有变慢。

相比之下，Kotlin的标准库只有7000个方法，比support-v4还要小，这正反映了Kotlin的设计理念：100% interoperable with Java。其实我们之前就提到，Java有的Kotlin就直接拿来用，而Scala的标准库要有5W多个方法，想想就还是想想算了。

目前Kotlin 1.0已经release，尽管像0xffffffff识别成Long类型这样的bug仍然没有解详情：

val int: Int = 0xffffffff // error
val anotherInt: Int = 0xffffffff.toInt() // correct

不过，Kotlin的教学资源和社区建设也已经相对成熟，按照官方的说法，Kotlin可以作为生产工具投入开发，详情可以参考：Kotlin 1.0 Released: Pragmatic Language for JVM and Android。

敢于吃螃蟹，多少有些浪漫主义色彩，我们这些程序员多少可以有些浪漫主义特质，不过在生成环境中，稳定高于一切仍然是不二法则。追求新技术，一方面会给团队带来开发和维护上的学习成本，另一方面也要承担未来某些情况下因为对新技术不熟悉而产生未知问题的风险——老板们最怕风险了~~

基于这一点，毫无疑问，Kotlin可以作为小工具、测试用例等的开发工具，这是考虑到这些代码通常体量较小，维护人数较少较集中，对项目整体的影响也较小；而对于核心代码，则视情况而定吧。

就我个人而言，长期下去，Kotlin很大可能会成为我的主要语言，短期内则仍然采用温和的改革方式慢慢将Kotlin渗透进来。

一句话，Kotlin是用来提升效率的，如果在你的场景中它做不到，甚至成了拖累，请放开它。

如果你觉得内容意犹未尽，如果你想了解更多相关信息，请扫描以下二维码，关注我们的公众账号，可以获取更多技术类干货，还有精彩活动与你分享~

腾讯Bugly，专业的App Crash监测平台。监测信息实时上报，让开发同学可以第一时间了解到App的质量情况，为移动开发节省大量人力与精力，提升移动产品质量。目前腾讯内部所有的移动端产品均在使用，现已免费对外开放。