需要說明的是，這段代碼是我從《Kotlin for Android Developer》的示例中摘出來的。有了這個(gè)Delegate類，我們就可以完全不需要關(guān)心SharedPreference了，下面給出使用的示例代碼：

class WhateverActivity : Activity(){
    var aInt: Int by Preference(this, "aInt", 0)
    
    fun whatever(){
        println(aInt)//會(huì)從SharedPreference取這個(gè)數(shù)據(jù)
        aInt = 9 //會(huì)將這個(gè)數(shù)據(jù)寫入SharedPreference
    }
}

于是我們?cè)僖膊恍枰貜?fù)寫那些getSharedPreference，也不用edit、commit，再見那些edit之后忘了commit的日子。有沒有覺得非常贊！

擴(kuò)展類，就是在現(xiàn)有類的基礎(chǔ)上，添加一些屬性或者方法，當(dāng)然擴(kuò)展的這些成員需要導(dǎo)入當(dāng)前擴(kuò)展成員所在的包才可以訪問到。下面給出一個(gè)例子：

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)
}

我們已經(jīng)介紹過data class，Coordinate有兩個(gè)成員分別是x和y，我們知道通常表示一個(gè)二維平面，有這倆夠了；然而我們?cè)趫D形學(xué)當(dāng)中經(jīng)常會(huì)需要求得其極坐標(biāo)，所以我們擴(kuò)展了Coordinate，增加了一個(gè)屬性theta表示角度（反正切的值域?yàn)?π/2 ~ π/2，所以這個(gè)式子不適用于二三象限，不過這不是重點(diǎn)了），增加了一個(gè)R方法來獲得點(diǎn)的半徑，于是我們?cè)趍ain方法中就可以這么用：

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

那么這個(gè)擴(kuò)展有什么限制呢？

在擴(kuò)展成員當(dāng)中，只能訪問被擴(kuò)展類在當(dāng)前作用域內(nèi)可見的成員，本例中的x和y都是public的（Kotlin默認(rèn)public，這個(gè)我們后面會(huì)提到），所以可以在擴(kuò)展方法和屬性中直接訪問。

擴(kuò)展成員與被擴(kuò)展類的內(nèi)部成員名稱相同時(shí)，擴(kuò)展成員將無法被訪問到

好的，基本知識(shí)就是這些了，下面我們?cè)俳o出一個(gè)實(shí)際的例子。

通常我們?cè)贘ava中會(huì)自定義一些LogUtils類來打日志，或者直接用android.util.log來輸出日志，不知道大家是什么感受，我反正每次因?yàn)橐斎隠og.d還要輸入個(gè)tag簡(jiǎn)直煩的要死，而且有時(shí)候恰好這個(gè)類還沒有tag這個(gè)成員，實(shí)踐中我們通常會(huì)把當(dāng)前類名作為TAG，但每個(gè)類都要做這么個(gè)工作，是在是沒有什么趣味可言（之前我是用LiveTemplates幫我的，即便如此也沒有那種流暢的感覺）。

有了Kotlin的這個(gè)擴(kuò)展功能，日子就會(huì)好過得多了，下面我創(chuàng)建的一個(gè)打日志的方法：

package com.benny.utils

import android.util.Log

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

有了這個(gè)方法，你可以在任何類的方法體中直接寫：

debug(whatever)

然后就會(huì)輸出以這個(gè)類名為TAG的日志。

嗯，這里需要簡(jiǎn)單介紹Kotlin在泛型中的一個(gè)比較重要的增強(qiáng)，這個(gè)在Java中無論如何也是做不到的：inline、reified。我們?cè)賮砘仡^看一下debug這個(gè)方法，我們發(fā)現(xiàn)它可以通過泛型參數(shù)T來獲取到T的具體類型，并且拿到它的類名——當(dāng)然，如果你愿意，你甚至可以調(diào)用它的構(gòu)造方法來構(gòu)造一個(gè)對(duì)象出來——為什么Kotlin可以做到呢？因?yàn)檫@段代碼是inline的，最終編譯時(shí)是要編譯到調(diào)用它的代碼塊中，這時(shí)候T的類型實(shí)際上是確定的，因而Kotlin通過reified這個(gè)關(guān)鍵字告訴編譯器，T這個(gè)參數(shù)可不只是個(gè)擺設(shè)，我要把它當(dāng)實(shí)際類型來用呢。

為了讓大家印象深刻，我下面給出類似功能的Java的代碼實(shí)現(xiàn)：

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

而你如果說希望在Java中也希望像下面這樣拿到這個(gè)泛型參數(shù)的類型，是不可以的：

public static  void debug(Object log){
    Log.d(T.getSimpleName(), log.toString());//錯(cuò)誤，T是泛型參數(shù)，無法直接使用
}

就算我們?cè)谡{(diào)用處會(huì)寫道 debug < Date >("blabla")，但這個(gè)Date在編譯之后還是會(huì)被擦除。

Java 8已經(jīng)開始可以支持Lambda表達(dá)式了，這種東西對(duì)于Java這樣一個(gè)『根紅苗正』的面向?qū)ο缶幊陶Z言來說還真是顯得不自然，不過對(duì)于Kotlin來說，就沒那么多顧忌了。

通常我們需要執(zhí)行一段異步的代碼，我們會(huì)構(gòu)造一個(gè)Runnable對(duì)象，然后交給executor，比如這段java代碼：

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

用Kotlin怎么寫呢？

executor.submit({
    //todo
})

一下子省了很多代碼。

那么實(shí)際當(dāng)中我們可能更常見到下面的例子，這是一段很常見的Java代碼，在Android的UI初始化會(huì)見到：

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這個(gè)Android庫(kù)的幫助下，我們甚至可以繼續(xù)簡(jiǎn)化OnClickListener的設(shè)置方式：

textView.onClick{ /*todo*/ }

當(dāng)然，好玩的不止這些，如果結(jié)合上一節(jié)我們提到的擴(kuò)展方法，我們就很容易看到Kotlin的標(biāo)準(zhǔn)庫(kù)提供的類似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 }

我們通常會(huì)在某個(gè)方法體內(nèi)創(chuàng)建一個(gè)對(duì)象并返回它，可我們除了調(diào)用它的構(gòu)造方法之外還需要做一些其他的操作，于是就要?jiǎng)?chuàng)建一個(gè)局部變量。。。有了apply這個(gè)擴(kuò)展方法，我們就可以這么寫：

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

這樣返回的StringBuilder對(duì)象實(shí)際上是包含"whatever"這個(gè)字符串的。

至于說Kotlin對(duì)于RxJava的友好性，使得我突然有點(diǎn)兒相信緣分這種東西了：

       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的特性時(shí)，看到：

object HelloScala{
  // do something
}

覺得很新鮮，這時(shí)候有個(gè)朋友不屑的說了句，Scala的模式匹配才真正犀利——Kotlin當(dāng)中也有這樣的特性，我們下面就來看個(gè)例子：

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表達(dá)式就是一個(gè)增強(qiáng)版的switch——Java 7以前的switch實(shí)際上支持的類型非常有限，Java 7當(dāng)中增加的對(duì)String的支持也是基于int類型的——我們可以看到when不再像switch那樣只匹配一個(gè)數(shù)值，它的子式可以是各種返回Boolean的表達(dá)式。

when表達(dá)式還有一種寫法更革命：

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

只要是返回Boolean的表達(dá)式就可以作為when的子式，這樣when表達(dá)式的靈活性可見一斑。當(dāng)然，與Scala相比，Kotlin還是要保守一些的，下面給出一個(gè)Scala類似的例子，大家感受一下，這實(shí)際上也可以體現(xiàn)出Kotlin在增加Java的同時(shí)也盡量保持簡(jiǎn)單的設(shè)計(jì)哲學(xué)（大家都知道，畢竟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)

運(yùn)行結(jié)果如下：

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

我曾經(jīng)做過一段時(shí)間的SDK開發(fā)，SDK的內(nèi)部有很多類其實(shí)是需要互相有訪問權(quán)限的，但一旦類及其成員是public的，那么調(diào)用方也就可以看到它們了；而protected或者default這樣的可見性對(duì)于子包卻是不可見的。

用了這么久Java，這簡(jiǎn)直是我唯一強(qiáng)烈感到不滿的地方了，甚至于我突然明白了C++的friend是多么的有用。

Kotlin雖然沒有提供對(duì)于子包可見的修飾符，不過它提供了internal：即模塊內(nèi)可見。換句話說，internal在模塊內(nèi)相當(dāng)于public，而對(duì)于模塊外就是private了——于是乎我們?nèi)绻_發(fā)SDK，那么可以減少api層的編寫，那些用戶不可見的部分直接用internal豈不更好。當(dāng)然有人會(huì)說我們應(yīng)當(dāng)有proguard做混淆，我想說的是，proguard自然是要用到的，不過那是SDK這個(gè)產(chǎn)品加工的下一個(gè)環(huán)節(jié)了，我們?yōu)槭裁床荒茉诖a級(jí)別把這個(gè)事情做好呢？

關(guān)于Kotlin的默認(rèn)可見性究竟是哪個(gè)還有人做出過討論，有興趣的可以參考這里：Kotlin’s default visibility should be internal。

其實(shí)我們對(duì)DSL肯定不會(huì)陌生，gradle的腳本就是基于groovy的DSL，而Kotlin的函數(shù)特性顯然也是可以支持DSL的。比如，我們最終要生成下面的xml數(shù)據(jù)：

我們可以構(gòu)建下面的類：

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方法當(dāng)中，我們用kotlin定義的dsl寫出了一個(gè)Project對(duì)象，它有這與xml描述的一致的結(jié)構(gòu)和含義，如果你愿意，可以構(gòu)造相應(yīng)的方法來輸出這樣的xml，運(yùn)行之后的結(jié)果：

當(dāng)然，這個(gè)例子做的足夠的簡(jiǎn)陋，如果你有興趣也可以抽象出"Element"，并為之添加"Attributes"，實(shí)際上這也不是很難。

寫了很多代碼，卻發(fā)現(xiàn)它們干不了多少事情，終究還是會(huì)苦惱的。比如我一直比較痛苦的一件事兒就是：

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

如果我需要很多個(gè)按鈕和圖片，那么我們要寫一大片這樣的findViewById。。媽呀。。。這活我干不了啦。。

不過用Kotlin的Android擴(kuò)展插件，我們就可以這樣：

先上布局文件：

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.*

導(dǎo)入這一句之后，我們就可以直接在代碼中使用start、textView，他們分別對(duì)應(yīng)于main.xml中的id為start的按鈕和id為textView的TextView。

于是你就發(fā)現(xiàn)你再也不用findViewById了，多么愉快的一件事?。?！當(dāng)然，你還會(huì)發(fā)現(xiàn)Toast的調(diào)用也變得簡(jiǎn)單了，那其實(shí)就是一個(gè)擴(kuò)展方法toast()；而startActivity呢，其實(shí)就是一個(gè)inline加reified的應(yīng)用——這我們前面都提到過了。

還有一個(gè)惡心的東西就是UI線程和非UI線程的切換問題。也許你會(huì)用handler不斷的post，不過說真的，用Handler的時(shí)候難道你不顫抖么，那可是一個(gè)很容易內(nèi)存泄露的魔鬼呀~哈哈，好吧其實(shí)我不是說這個(gè)，主要是用handler寫出來的代碼 實(shí)在 太 丑 了 ??！

原來在java當(dāng)中，我們這么寫：

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

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

而在Kotlin當(dāng)中呢，我們只需要這么寫：

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

自己感受一下吧。

下面我們?cè)賮硖嵋粋€(gè)有意思的東西，我們從做Android開發(fā)一開始就要編寫xml，印象中這個(gè)對(duì)于我來說真的是一件痛苦的事情，因?yàn)樗墓ぷ鳈C(jī)制并不如代碼那樣直接（以至于我現(xiàn)在很多時(shí)候居然喜歡用Java代碼直接寫布局）——當(dāng)然，最主要的問題并不是這個(gè)，而是解析xml需要耗費(fèi)CPU。Kotlin有辦法可以解決這個(gè)問題，那就是DSL了。下面給出一個(gè)例子：

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

一個(gè)LinearLayout包含了一個(gè)Button，這段代碼你可以直接寫到你的代碼中靈活復(fù)用，就像這樣：

    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的繁瑣來，這真是要清爽很多

布局本身也是代碼，可以靈活復(fù)用

再也不用findViewById了，難道你不覺得在這個(gè)上面浪費(fèi)的生命已經(jīng)足夠多嗎

事件監(jiān)聽很方便的嵌到布局當(dāng)中

DSL方式的布局沒有運(yùn)行時(shí)的解析的負(fù)擔(dān)，你的邏輯代碼怎么運(yùn)行它就怎么運(yùn)行

Anko還增加了更多好玩的特性，有興趣的可以參考：Anko@Github

我曾經(jīng)嘗試用Scala寫了個(gè)Android的HelloWorld，一切都配置好以后，僅僅引入了Scala常見的幾個(gè)庫(kù)，加上support-v4以及appcompat這樣常見的庫(kù)，結(jié)果還是報(bào)錯(cuò)了。是的，65K。。。而且用Scala開發(fā)Android的話，基于gradle的構(gòu)建會(huì)讓整個(gè)app的build過程異常漫長(zhǎng)，有時(shí)候你會(huì)覺得自己悟出了廣義相對(duì)論的奧義，哦不，你一定是暈了，時(shí)間并沒有變慢。

相比之下，Kotlin的標(biāo)準(zhǔn)庫(kù)只有7000個(gè)方法，比support-v4還要小，這正反映了Kotlin的設(shè)計(jì)理念：100% interoperable with Java。其實(shí)我們之前就提到，Java有的Kotlin就直接拿來用，而Scala的標(biāo)準(zhǔn)庫(kù)要有5W多個(gè)方法，想想就還是想想算了。

目前Kotlin 1.0已經(jīng)release，盡管像0xffffffff識(shí)別成Long類型這樣的bug仍然沒有解詳情：

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

不過，Kotlin的教學(xué)資源和社區(qū)建設(shè)也已經(jīng)相對(duì)成熟，按照官方的說法，Kotlin可以作為生產(chǎn)工具投入開發(fā)，詳情可以參考：Kotlin 1.0 Released: Pragmatic Language for JVM and Android。

敢于吃螃蟹，多少有些浪漫主義色彩，我們這些程序員多少可以有些浪漫主義特質(zhì)，不過在生成環(huán)境中，穩(wěn)定高于一切仍然是不二法則。追求新技術(shù)，一方面會(huì)給團(tuán)隊(duì)帶來開發(fā)和維護(hù)上的學(xué)習(xí)成本，另一方面也要承擔(dān)未來某些情況下因?yàn)閷?duì)新技術(shù)不熟悉而產(chǎn)生未知問題的風(fēng)險(xiǎn)——老板們最怕風(fēng)險(xiǎn)了~~

基于這一點(diǎn)，毫無疑問，Kotlin可以作為小工具、測(cè)試用例等的開發(fā)工具，這是考慮到這些代碼通常體量較小，維護(hù)人數(shù)較少較集中，對(duì)項(xiàng)目整體的影響也較小；而對(duì)于核心代碼，則視情況而定吧。

就我個(gè)人而言，長(zhǎng)期下去，Kotlin很大可能會(huì)成為我的主要語言，短期內(nèi)則仍然采用溫和的改革方式慢慢將Kotlin滲透進(jìn)來。

一句話，Kotlin是用來提升效率的，如果在你的場(chǎng)景中它做不到，甚至成了拖累，請(qǐng)放開它。

如果你覺得內(nèi)容意猶未盡，如果你想了解更多相關(guān)信息，請(qǐng)掃描以下二維碼，關(guān)注我們的公眾賬號(hào)，可以獲取更多技術(shù)類干貨，還有精彩活動(dòng)與你分享~

騰訊Bugly，專業(yè)的App Crash監(jiān)測(cè)平臺(tái)。監(jiān)測(cè)信息實(shí)時(shí)上報(bào)，讓開發(fā)同學(xué)可以第一時(shí)間了解到App的質(zhì)量情況，為移動(dòng)開發(fā)節(jié)省大量人力與精力，提升移動(dòng)產(chǎn)品質(zhì)量。目前騰訊內(nèi)部所有的移動(dòng)端產(chǎn)品均在使用，現(xiàn)已免費(fèi)對(duì)外開放。