Bin’s Blog

LeakCanary 2 初始化方式分析——ContentProvider 妙用

2020-06-10T00:00:00+00:00

LeakCanary 2 是一次重大的版本升级。与旧版本相比，依赖与配置 LeakCanary 库的方式变得更加简单，只需要在 app 模块的 build.gradle 文件中添加：

dependencies {
  debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.3'
}

官方文档也特别突出了这一点：

That’s it, there is no code change needed!

本篇文章结合 LeakCanary v2.3 源码，分析其“无代码侵入”初始化库的实现方式，以及在自己的库中使用这一特性的注意事项。

使用 `ContentProvider` 初始化库

我们可以在 leakcanary-object-watcher-android 模块的 AndroidManifest.xml 文件中发现注册了一个 provider：

<provider
    android:name="leakcanary.internal.AppWatcherInstaller$MainProcess"
    android:authorities="${applicationId}.leakcanary-installer"
    android:exported="false"/>

其源码如下：

/**
 * Content providers are loaded before the application class is created. [AppWatcherInstaller] is
 * used to install [leakcanary.AppWatcher] on application start.
 */
internal sealed class AppWatcherInstaller : ContentProvider() {

  /**
   * [MainProcess] automatically sets up the LeakCanary code that runs in the main app process.
   */
  internal class MainProcess : AppWatcherInstaller()

  /**
   * When using the `leakcanary-android-process` artifact instead of `leakcanary-android`,
   * [LeakCanaryProcess] automatically sets up the LeakCanary code
   */
  internal class LeakCanaryProcess : AppWatcherInstaller() {
    override fun onCreate(): Boolean {
      super.onCreate()
      AppWatcher.config = AppWatcher.config.copy(enabled = false)
      return true
    }
  }

  override fun onCreate(): Boolean {
    val application = context!!.applicationContext as Application
    InternalAppWatcher.install(application)
    return true
  }

  override fun query(
    uri: Uri,
    strings: Array<String>?,
    s: String?,
    strings1: Array<String>?,
    s1: String?
  ): Cursor? {
    return null
  }

  override fun getType(uri: Uri): String? {
    return null
  }

  override fun insert(
    uri: Uri,
    contentValues: ContentValues?
  ): Uri? {
    return null
  }

  override fun delete(
    uri: Uri,
    s: String?,
    strings: Array<String>?
  ): Int {
    return 0
  }

  override fun update(
    uri: Uri,
    contentValues: ContentValues?,
    s: String?,
    strings: Array<String>?
  ): Int {
    return 0
  }
}

MainProcess 是 AppWatcherInstaller 的一个内部类，继承了 AppWatcherInstaller，用于在主进程注册。AppWatcherInstaller 中还有一个 LeakCanaryProcess 内部类，同样继承了 AppWatcherInstaller，用于在 :leakcanary 进程注册。

AppWatcherInstaller 是一个 ContentProvider，却并没有任何 CRUD 操作，只在 onCreate() 中获取应用 Application 并在第 26 行执行了 LeakCanary 的初始化操作 InternalAppWatcher.install(application)。这相当于 LeakCanary 旧版本中需要我们手动调用的 LeakCanary.install(Application) 方法。

如果打 log 可以发现，ContentProvider 的 onCreate 方法要早于 Application 的 onCreate 方法执行。相关方法的调用顺序是：

Application.attachBaseContext
ContentProvider.onCreate
Application.onCreate

因此在 ContentProvider 的 onCreate 中初始化库是可行的。LeakCanary 2 利用了这一特性完成了初始化，同时避免了代码侵入。

不得不说，这并不是 ContentProvider 的“正确”打开方式，不过用起来，真香！

初始化依赖问题

上面的分析已经有很多文章做过了，不过在实践过程中发现一个小问题。

我自己需要一个 base 库，上层 app 依赖这个 base 库。像 LeakCanary 这样的基础工具库可以放在 base 库中，不需要让每个使用库的 app 分别依赖。而我的 base 库也希望像 LeakCanary 2 一样，使用 ContentProvider 做初始化，于是乎我添加了一个 BaseInstaller：

/**
 * 用于获取应用 [Application] 并初始化库.
 */
internal class BaseInstaller : ContentProvider() {
    override fun onCreate(): Boolean {
        // 自定义配置 LeakCanary.
        initLeakCanary()
        // 其他初始化操作.
        // ...
        return true
    }

    private fun initLeakCanary() {
        // 不显示 LeakCanary 启动器图标.
        LeakCanary.showLeakDisplayActivityLauncherIcon(false)
    }

    // ...
}

在我自己的 BaseInstaller 中我对 LeakCanary 做了一些额外的自定义配置工作。

运行起来应用却崩溃了，异常信息是：

Caused by: kotlin.UninitializedPropertyAccessException: lateinit property application has not been initialized
   at leakcanary.internal.InternalLeakCanary.setEnabledBlocking(InternalLeakCanary.kt:330)
   at leakcanary.LeakCanary.showLeakDisplayActivityLauncherIcon(LeakCanary.kt:337)

根据异常栈大概能猜到原因了，在 BaseInstaller 中配置 LeakCanary 时，LeakCanary 还没有完成初始化。

在 InternalLeakCanary 中可以看到，application 是一个 lateinit 字段，在 invoke(Application) 方法中第一次赋值，InternalLeakCanary 实现了 (Application) -> Unit 接口，在 InternalAppWatcher 的 install(Application) 方法中调用。

internal object InternalLeakCanary : (Application) -> Unit, OnObjectRetainedListener {
  // ...

  lateinit var application: Application

  // ...

  override fun invoke(application: Application) {
    this.application = application
    // ...
  }

  // ...

  fun setEnabledBlocking(
    componentClassName: String,
    enabled: Boolean
  ) {
    val component = ComponentName(application, componentClassName)
    // ...
  }

  // ...
}

之所以抛“未初始化”异常是因为，我们的 base 库同样通过注册一个 ContentProvider 的方式实现初始化，而 base 库依赖了 LeakCanary，相当于在 app 的 AndroidManifest.xml 中注册了两个 ContentProvider。根据依赖关系，base 库中的自定义 ContentProvider 会优先于 LeakCanary 中的初始化，因此在 BaseInstaller 中配置 LeakCanary 的时机过早。

如何解决这一问题？provider 在 AndroidManifest.xml 中注册时提供一条属性 android:initOrder，可以用来指定初始化顺序。

我们可以先查看一下所有已注册的 ContentProvider 以及它们的 initOrder：

context.packageManager
    .getPackageInfo(context.packageName, PackageManager.GET_PROVIDERS)
    .providers
    .forEach {
        log("${it.name}: ${it.initOrder}")
    }

输出：

D: *.BaseInstaller: 0
D: leakcanary.internal.LeakCanaryFileProvider: 0
D: leakcanary.internal.AppWatcherInstaller$MainProcess: 0

可以看到，第一条是 base 库的 BaseInstaller，之后有 LeakCanary 的 FileProvider 以及我们上面分析的 AppWatcherInstaller$MainProcess。默认情况下 provider 的 android:initOrder 属性值为 0，数值越大越早执行初始化，因此为了保证 LeakCanary 优先初始化完成，我们只要为 BaseInstaller 指定一个小于 0 的数：

<provider
    android:name=".BaseInstaller"
    android:authorities="..."
    android:exported="false"
    android:initOrder="-1"/>

如果依赖了更多的使用 ContentProvider 的库并且存在初始化顺序问题，只需要保证被依赖的 provider 的 android:initOrder 大于调用者的值就可以了。

小结

ContentProvider 的初始化早于 Application 的 onCreate 且可以由系统自行注册调用，LeakCanary 2 使用了这一特性用来执行初始化操作。
在使用自定义 ContentProvider 初始化其他第三方库时需要注意依赖关系，使用 android:initOrder 属性可以改变初始化顺序。

Kotlin 高阶函数和 lambda 表达式

2018-03-07T00:00:00+00:00

button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        System.out.println("clicked");
    }
});

以上这段代码在 Java 8 中可以这么写：

button.setOnClickListener(v -> System.out.println("clicked"));

在 Kotlin 中可以这么写：

button.setOnClickListener { println("clicked") }

如何理解这段代码，一步一步来简化。

1. 匿名内部类

要创建一个继承自某类型的匿名类的对象，写法如下（这段代码相当于 Java 8 之前的匿名内部类写法）：

button.setOnClickListener(object : View.OnClickListener {
    override fun onClick(v: View?) {
        println("clicked")
    }
})

2. 使用 lambda 表达式

约定如下：

lambda 表达式总是括在花括号中；
其参数（如果有的话）在 -> 之前声明；
函数体（如果存在的话）在 -> 后面。

button.setOnClickListener({ v: View? -> println("clicked") })

3. 省略参数类型

（参数类型可以省略）

省略类型，形式参数 v 没有使用时可以简写为 _：

button.setOnClickListener({ _ -> println("clicked") })

4. 省略参数

如果函数字面值只有一个参数，那么它的声明可以省略（连同 ->），其名称是 it：

button.setOnClickListener({ println("clicked") })

5. 将花括号移出圆括号

在 Kotlin 中有一个约定，如果函数的最后一个参数是一个函数，并且你传递一个 lambda 表达式作为相应的参数，你可以在圆括号之外指定它。如果 lambda 是该调用的唯一参数，则调用中的圆括号可以完全省略：

button.setOnClickListener { println("clicked") }

一个 lambda 表达式或匿名函数是一个“函数字面值”，即一个未声明的函数，但立即做为表达式传递。接受一个函数作为参数的函数是一个函数。对于接受另一个函数作为参数的函数，我们必须为该参数指定函数类型。

setOnClickListener 的函数类型为

比如：

fun captureScreenshot(view: View, viewToBitmap: (View) -> Bitmap) {
    val header = createHeader()
    val content = viewToBitmap(view)
    val footer = createFooter()
    saveBitmap(header, content, footer)
}

其中 (View) -> Bitmap 就是参数 viewToBitmap 的函数类型，它接受一个 View 返回一个 Bitmap，相当于：

什么是 lambda？简单的说就是匿名函数，它是一个“函数字面值”，即一个未声明的函数，但立即做为表达式传递。比如：

val sum = { x: Int, y: Int -> x + y }

// 使用时：
val result = sum(1, 2)
// 或者:
val result = sum.invoke(1, 2)

它相当于：

fun sum(x: Int, y: Int): Int {
    return x + y
}

// 使用时：
val result = sum(1, 2)
// 或者：
val result = ::sum.invoke(1, 2)

标签

Lambda 表达式的完整语法形式，即函数类型的字面值如下：

Kotlin 操作符重载

2018-01-31T00:00:00+00:00

在 Kotlin 中，我们可以用 约定的操作符，代替 调用代码中以特定的命名定义的函数，来实现 与之对应的操作。例如在类中定义了一个名为 plus 的特殊方法，就可以使用加法运算符 + 代替 plus() 的方法调用。由于你无法修改已有的接口定义，因此一般可以通过 扩展函数 来为现有的类增添新的 约定方法，从而使得 操作符重载 这一语法糖适应任何现有的 Java 类。

算术运算符

我们就从最简单直接的例子 + 这一类算术运算符开始。

data class Point(val x: Int, val y: Int) {
    operator fun plus(other: Point) = Point(x + other.x, y + other.y)
    operator fun plus(value: Int) = "toString: ${Point(x + value, y + value)}"
}

fun main(args: Array<String>) {
    val p1 = Point(1, 2)
    val p2 = Point(3, 4)
    println(p1 + p2)
    println(p1 + 3)
}

/*
Point(x=4, y=6)
toString: Point(x=4, y=5)
*/

operator 修饰符是必须的，否则 plus 只是一个普通方法，不能通过 + 调用。
操作符是有优先级的，比较 * 优先级高于 +，不论这个操作符应用于什么对象，这种优先级都是固定存在的。
plus 方法的参数类型是任意的，因此可以方法重载，但是 参数数量只能是 1 ，因为 + 是一个二元操作符。plus 方法的返回值类型也是任意的。
如果出现多个方法签名相同的 operator 扩展方法，根据 import 决定使用哪个一，例如：

// 第一个文件：
package package0

operator fun Point.times(value: Int) = Point(x * value, y * value)

// 第二个文件：
package package1

operator fun Point.times(value: Int) = Unit // Do nothing.

// 使用第一个扩展操作符：
import package0.times

val newPoint = Point(1, 2) * 3

Kotlin 为一些基本类型预定义了一些操作符方法，我们平时常写的基本数据计算也可以翻译成调用这些操作符方法，比如 (2 + 3) * 4 可以翻译成 2.plus(3).times(4)，2 + 3 * 4 可以翻译成 2.plus(3.times(4))。根据扩展函数的语法，扩展函数无法覆盖与类已有的方法签名相同的方法，因此，不必担心随随便便给 Int 自定义一个 plus 扩展方法就能让 1 + 1 变得不等于 2。

同时，所有操作符都针对基本类型做了优化，比如 1 + 2 * 3、4 < 5，不会为它们引入函数调用的开销。

所有可重载的算术运算符有：

表达式	翻译为
a + b	a.plus(b)
a - b	a.minus(b)
a * b	a.times(b)
a / b	a.div(b)
a % b	a.rem(b)、 ~~a.mod(b)~~ （在 Kotlin 1.1 中被弃用）
a..b	a.rangeTo(b)

它们的优先级与普通的数字类型运算符优先级相同。其中 rangeTo 会在下面说明。

广义赋值操作符

表达式	翻译为
a += b	a.plusAssign(b)
a -= b	a.minusAssign(b)
a *= b	a.timesAssign(b)
a /= b	a.divAssign(b)
a %= b	a.remAssign(b)、 ~~a.modAssign(b)~~ （在 Kotlin 1.1 中被弃用）

对于以上广义赋值操作符：

如果对应的二元算术运算符函数也可用，则报错。plus 对应 plusAssign。minus、times 等也类似。
返回值类型必须为 Unit。
如果执行 a += b 时 plusAssign 不存在，会尝试生成 a = a + b，其中的 a + b 使用的就是 plus 操作符方法，相当于调用 a = a.plus(b)。并且此时会 要求 a + b 的 plus 方法的返回值类型必须与 a 类型一致（如果单独使用 a + b 不做此要求）。

data class Size(var width: Int = 0, var height: Int = 0) {
    operator fun plus(other: Size): Size {
        return Size(width + other.width, height + other.height)
    }

    operator fun plusAssign(other: Size) {
        width += other.width
        height += other.height
    }
}

fun main(args: Array<String>) {
//    var s1 = Size(1, 2) // 如果这么写，执行 += 时会报错.
    val s1 = Size(1, 2)
    val s2 = Size(3, 4)
    s1 += s2
}

我们使用这个例子来理解：为什么使用 var 定义的 s1 会导致 += 报错呢？因为理论上，执行 += 时，既可以调用 s1 = s1 + s2，也就是 s1 = s1.plus(s2)，又可以调用 s1.plusAssign(s2)，都符合操作符重载约定，这样就会产生歧义，而如果使用 val 定义 s1，则只可能执行 s1.plusAssign(s2)，因为 s1 不可被重新赋值，因此 s1 = s1 + s2 这样的语法是出错的，永远不能能调用，那么调用 s1 += s2 就不会产生歧义了。

既然编译器会帮我把 a += b 解释成 a = a + b，那是不是意味着我只需要 plus 永远不需要 plusAssign 了呢？比较好的实践方式是：

+ (plus) 始终返回一个新的对象
+= (plusAssign) 用于内容可变的类型，修改自身的内容。

Kotlin 标准库中就是这么实现的：

fun main(args: Array<String>) {
    val list = arrayListOf(1, 2)
    list += 3              // 添加元素到自身集合, 没有新的对象被创建, 调用的是 add 方法.
    val newList = list + 4 // 创建一个新的 ArrayList, 添加自身元素和新元素并返回新的 ArrayList.
}

in

表达式	翻译为
a in b	b.contains(a)
a !in b	!b.contains(a)

println("hello" in arrayListOf("hello", ", ", "world"))

/*
true
*/

在 for 循环中使用 in 操作符会执行迭代操作，for(x in list) { /* 遍历 */ } 将被转换成 list.iterator() 的调用，然后在上面重复调用hasNext 和 next 方法。

rangeTo

rangeTo 用于创建一个区间。例如 1..10 也就是 1.rangeTo(10) 代表了从 1 到 10 这 10 个数字，Int.rangeTo 方法返回一个 IntRange 对象，IntRange 类定义如下：

/**
 * A range of values of type `Int`.
 */
public class IntRange(start: Int, endInclusive: Int) : IntProgression(start, endInclusive, 1), ClosedRange<Int> {
    override val start: Int get() = first
    override val endInclusive: Int get() = last

    override fun contains(value: Int): Boolean = first <= value && value <= last

    override fun isEmpty(): Boolean = first > last

    override fun equals(other: Any?): Boolean =
        other is IntRange && (isEmpty() && other.isEmpty() ||
        first == other.first && last == other.last)

    override fun hashCode(): Int =
        if (isEmpty()) -1 else (31 * first + last)

    override fun toString(): String = "$first..$last"

    companion object {
        /** An empty range of values of type Int. */
        public val EMPTY: IntRange = IntRange(1, 0)
    }
}

它的基类 IntProgression 实现了 Iterable 接口，因此 1..10 可以用来迭代：

for (index in 1..10) {
    // 遍历 1 到 10, 包括 1 和 10.
}

IntRange 还实现了接口 ClosedRange ，可以用来判断某元素是否属于该区间。

Kotlin 为 Comparable 定义了扩展函数 rangeTo：

/**
 * Creates a range from this [Comparable] value to the specified [that] value.
 *
 * This value needs to be smaller than [that] value, otherwise the returned range will be empty.
 * @sample samples.ranges.Ranges.rangeFromComparable
 */
public operator fun <T: Comparable<T>> T.rangeTo(that: T): ClosedRange<T> = ComparableRange(this, that)

因此所有的 Comparable 对象都可以使用 .. 区间操作符，例如：

fun main(args: Array<String>) {
    val c1 = Calendar.getInstance() // 代表今天.
    val c2 = Calendar.getInstance() 
    c2.add(Calendar.DATE, 10)       // 代表 10 天后.
    val c3 = Calendar.getInstance()
    c3.add(Calendar.DATE, 3)        // 代表 3 天后.
    val c4 = Calendar.getInstance()
    c4.add(Calendar.DATE, 13)       // 代表 13 天后.
    
    // 判断某日期是否在某两个日期范围内.
    println(c3 in c1..c2)
    println(c4 in c1..c2)
}

/*
true
false
*/

一元前缀操作符

表达式	翻译为
+a	a.unaryPlus()
-a	a.unaryMinus()
!a	a.not()

data class Point(val x: Int, val y: Int)

operator fun Point.unaryMinus() = Point(-x, -y)

val point = Point(10, 20)
println(-point)

/*
Point(x=-10, y=-20)
*/

递增与递减

表达式	翻译为
a++	a.inc()
a–	a.dec()

编译器自动支持与普通数字类型的前缀、后缀自增运算符相同的语义。例如后缀运算会先返回变量的值，然后才执行 ++ 操作。

索引访问操作符

表达式	翻译为
a[i]	a.get(i)
a[i, j]	a.get(i, j)
a[i_1, ……, i_n]	a.get(i_1, ……, i_n)
a[i] = b	a.set(i, b)
a[i, j] = b	a.set(i, j, b)
a[i_1, ……, i_n] = b	a.set(i_1, ……, i_n, b)

@Suppress("IMPLICIT_CAST_TO_ANY", "UNCHECKED_CAST")
operator fun <T> SharedPreferences.get(key: String, defValue: T) = when (defValue) {
    is String -> getString(key, defValue)
    is Int -> getInt(key, defValue)
    is Long -> getLong(key, defValue)
    is Float -> getFloat(key, defValue)
    is Boolean -> getBoolean(key, defValue)
    else -> throw RuntimeException()
} as T

@SuppressLint("CommitPrefEdits")
operator fun <T> SharedPreferences.set(key: String, value: T) = with(edit()) {
    when (value) {
        is String -> putString(key, value)
        is Int -> putInt(key, value)
        is Long -> putLong(key, value)
        is Float -> putFloat(key, value)
        is Boolean -> putBoolean(key, value)
        else -> throw RuntimeException()
    }.apply()
}

fun main(args: Array<String>) {
    val version = sp["key_version", 47] // 读 sp.
    sp["key_version"] = 48 // 写 sp.
}

调用操作符

表达式	翻译为
a()	a.invoke()
a(i)	a.invoke(i)
a(i, j)	a.invoke(i, j)
a(i_1, ……, i_n)	a.invoke(i_1, ……, i_n)

相等与不等操作符

表达式	翻译为
a == b	a?.equals(b) ?: (b === null)
a != b	!(a?.equals(b) ?: (b === null))

这在 Any 中被定义。Java 的 a.equals(b) 相当于 Koltin 的 a == b，Java 的 a == b 相当于 Kotlin 的 a === b（同一性检查）。要自定义 == 操作符其实就是覆写 equals 方法。Kotlin 中 === 不可被重载。

比较操作符

表达式	翻译为
a > b	a.compareTo(b) > 0
a < b	a.compareTo(b) < 0
a >= b	a.compareTo(b) >= 0
a <= b	a.compareTo(b) <= 0

要求 compareTo 返回值类型必须为 Int ，这与 Comparable 接口保持一致。

data class Movie(val name: String, val score: Int, val date: Date, val other: Any = Any()) : Comparable<Movie> {
    override fun compareTo(other: Movie): Int {
        return compareValuesBy(this, other, Movie::score, Movie::date, Movie::name) // 如果将 Movie::other 也用作比较会报错, 因为 other 不是 Comparable 类型的。
    }
}

fun main(args: Array<String>) {
    val df = SimpleDateFormat("yyyy-MM-dd", Locale.getDefault())
    val movie0 = Movie("马戏之王", 8, df.parse("2018-01-31"))
    val movie1 = Movie("神秘巨星", 7, df.parse("2018-01-01"))
    val movie2 = Movie("移动迷宫", 7, df.parse("2018-01-02"))
    
    println(movie0 < movie1)
    println(movie1 < movie2)
}

/*
false
true
*/

其中的 compareValuesBy 方法如下：

/**
 * Compares two values using the specified functions [selectors] to calculate the result of the comparison.
 * The functions are called sequentially, receive the given values [a] and [b] and return [Comparable]
 * objects. As soon as the [Comparable] instances returned by a function for [a] and [b] values do not
 * compare as equal, the result of that comparison is returned.
 *
 * @sample samples.comparisons.Comparisons.compareValuesByWithSelectors
 */
public fun <T> compareValuesBy(a: T, b: T, vararg selectors: (T) -> Comparable<*>?): Int {
    require(selectors.size > 0)
    return compareValuesByImpl(a, b, selectors)
}

private fun <T> compareValuesByImpl(a: T, b: T, selectors: Array<out (T)->Comparable<*>?>): Int {
    for (fn in selectors) {
        val v1 = fn(a)
        val v2 = fn(b)
        val diff = compareValues(v1, v2)
        if (diff != 0) return diff
    }
    return 0
}

我们定义一个 Movie 类，它实现了 Comparable 接口，在比较时，希望按照 评分 、 上映日期 、 电影名称 的优先级顺序排序。可以简单的使用比较操作符对 Movie 对象进行“大小比较”。

操作符函数与 Java

Java 中调用 Kotlin 中的操作符方法，就跟调用普通方法一样，你不能期望在 Java 中写 new Point(1, 2) + new Point(3, 4) 这样的语法，只能乖乖调用 new Point(1, 2).plus(new Point(3, 4))。
反之，Kotlin 中调用 Java 代码却可以同 Kotlin 中自定义操作符方法一样方便。只要一个类提供了满足操作符方法签名的方法，哪怕它只是一个普通方法，不需要加 operator 修饰符（Java 中也没有这个修饰符），就可以在 Kotlin 中以操作符的方式调用。例如：arrayList[0] 相当于 Java 中 arrayList.get(0)，尽管这个 get 方法是 Java 中定义的。又比如所有实现了 Comparable 的类实例都可以使用比较操作符 >、< 等进行比较。
Java 中的位运算符在 Kotlin 中是没有的 ，它们只能使用普通方法加中缀表达式使用，只能用于 Int 和 Long，对应关系如下：

Java 中	Kotlin 中
« 有符号左移	shl(bits)
» 有符号右移	shr(bits)
»> 无符号右移	ushr(bits)
& 与	and(bits)
\| 或	or(bits)
^ 异或	xor(bits)
! 非	inv()

操作符重载与属性委托、中缀调用

我们在使用委托属性时也用过 operator 修饰符：

class Delegate {
    operator fun getValue(thisRef: Any?, property: KProperty<*>): String {
        //...
    }
 
    operator fun setValue(thisRef: Any?, property: KProperty<*>, value: String) {
        //...
    }
}

符合这样方法签名的 getValue 、 setValue 也是操作符函数，用于委托属性的 getter 和 setter。

可以看出，操作符重载并不是一定要用如 * 、 + 、 < 这样的符号来表示的，比如之前的 in 操作符，这里的 getter 、 setter。

除了以上这些标准的可被重载的操作符外，我们也可以通过中缀函数的调用来模拟自定义中缀操作符，实现形如 a in list 这样的语法。

Kotlin 函数

2017-12-13T00:00:00+00:00

函数默认参数和命名参数

默认参数扩展函数调用方式。

fun setPadding(
        left: Int = this.left,
        top: Int = this.top,
        right: Int = this.right,
        bottom: Int = this.bottom) {}

setPadding()                                         // 全部使用默认值.
setPadding(1)                                        // 设置 left.
setPadding(1, 2, 3, 4)                               // 设置全部.
setPadding(top = 2)                                  // 设置 top.
//setPadding(left = 1, 2, 3, 4)                      // 编译错误.
setPadding(1, 2, bottom = 4, right = 3)              // 默认参数顺序可以改变.
setPadding(left = 1, top = 2, right = 3, bottom = 4) // 命名参数, 增加可读性.

默认参数可以使用之前的参数作为默认值。

fun setMargin(
        left: Int = 0,
        top: Int = 0,
        right: Int = left,
        bottom: Int = top) {}

setMargin()                    // 0, 0, 0, 0
setMargin(1)                   // 1, 0, 1, 0
setMargin(1, 2)                // 1, 2, 1, 2
setMargin(right = 3)           // 0, 0, 3, 0
setMargin(top = 2, bottom = 4) // 0, 2, 0, 4

默认参数减少方法重载。

class CustomView(context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = 0, defStyleRes: Int = 0)

默认参数在无默认参数之前。

fun circle(x: Float = 0, y: Float = 0, radius: Float) {}

circle(radius = 1f) // 如果要 x, y 使用默认参数, 必须通过命名参数指定 radius.

Lambda 表达式作为最后一个参数。

fun post(delayMillis: Long = 0L, runnable: () -> Unit) {}

post {
    // Do something.
}
post(1000L) {
    // 1 秒后 do something.
}
post(runnable = {
    // 如果在括号内传递 lambda 表达式参数, 想要使用 delayMillis 默认参数, 仍然必须使用命名参数.
})

可变数量参数

与 Java 的 … 可变参数类似。

fun sum(vararg numbers: Float): Float {
    var sum = 0f
    numbers.forEach { sum += it }
    return sum
}

sum(1f, 2f, 3f, 4f)

可变数量参数作为参数传递。

fun average(vararg numbers: Float): Float {
//    return sum(numbers) / numbers.size // 编译错误：Type mismatch. Required: Float. Found: FloatArray.
    return sum(*numbers) / numbers.size
}

val floatArray = floatArrayOf(3f, 4f, 5f)
average(1f, 2f, *floatArray, 6f)

扩展函数

能够扩展一个类的新功能而无需继承该类或使用像装饰者这样的任何类型的设计模式。

fun Date.toCalendar(): Calendar {
    val calendar = Calendar.getInstance()
    calendar.time = this
    return calendar
}

val calendar = date.toCalendar()

扩展函数不会覆盖成员函数。

// Warning: Extension is shadowed by a member: public open fun toString(): String
fun Date.toString(): String {
    return "我就不告诉你时间"
}

date.toString() // 还是会输出时间的.

但是方法重载是可以的。

fun Date.toString(pattern: String): String {
    val dateFormat = SimpleDateFormat(pattern, Locale.getDefault())
    return dateFormat.format(this)
}

date.toString("yyyy-MM-dd") // 2017-12-13

可空接受者。 ``` kotlin fun String?.isEmpty(): Boolean { // return this == null || this.isEmpty() // 这么写会出现一个小递归。。。 return this == null || this.length == 0 }

fun foo(str: String?) { str.isEmpty() }

* 中缀表示法进一步简化.

``` kotlin
infix fun Int.pow(e: Int): Int {
    return Math.pow(this.toDouble(), e.toDouble()).toInt()
}

2.pow(5) // 不加 infix 调用.
2 pow 5 // 加 infix 简化调用. 32

局部函数

fun processor(type: Char) {
    // 需要被复用且仅被 processor 方法复用.
    fun coreOperation() {
        println("Core operation.")
    }

    when (type) {
        'A' -> {
            println("Pre A")
            coreOperation()
            println("Post A")
        }
        'B' -> {
            println("Pre B")
            coreOperation()
            println("Post B")
        }
    }
}

方法赋予属性

val action = fun() {
    println("property")
}

val action2 = fun() {
    println("property 2")
}

fun action2() {
    println("function")
}

action()         // property
action2.invoke() // property 2
action2()        // function

传递成员 function 参数

fun printAsterisk() {
    println("****************************************************************")
}
fun printPound() {
    println("################################################################")
}
fun printHyphe() {
    println("----------------------------------------------------------------")
}

fun log(message: String, printSeparatorAction: () -> Unit) {
    printSeparatorAction()
    println(message)
    printSeparatorAction()
}

log("hello", ::printAsterisk)

Kotlin 日常踩坑

2017-12-07T00:00:00+00:00

踩到一个 Koltin 加 Android api 27 的坑。

Support library 升级到 27.x.x 之后，发现项目一堆报错：

它说我的 onCreateView 方法覆写了 nothing。Are You Kidding me?

对比了一下两个版本的 support library，发现了问题。

27.x.x 版本：

@Nullable
public View onCreateView(@NonNull LayoutInflater inflater, @Nullable ViewGroup container,
        @Nullable Bundle savedInstanceState) {
    return null;
}

26.x.x 版本

@Nullable
public View onCreateView(LayoutInflater inflater, @Nullable ViewGroup container,
        @Nullable Bundle savedInstanceState) {
    return null;
}

就是这个 LayoutInflater 前的 @NonNull 注解导致的，在 kotlin 中，任何类型都分 nullable 和 non-null 两种，并且不能隐式转换，在 kotlin 调用 java 代码时如果 java 代码没有使用注解声明一个变量是否可为空，例如 String str，kotlin 会将这个变量标记为 String! 类型，表示我也不知道这个变量是否可为空，使用时需要自行处理，当 java 代码中使用了 @NonNull 和 @Nullable 注解标注了一个变量的类型，那么 kotlin 就明确地知道了它要么是 String 不可为空，要么是 String? 可为空。String 和 String? 可以理解为两个不相同的类型，因此上面的方法覆写就会报错，认为方法签名不相同，不能使用 override 关键字。

同理，在 fragment 中：

@Nullable
public Context getContext() {
    return mHost == null ? null : mHost.getContext();
}

因此在调用 context 的方法时必须 context!!.getString() 而不能 context.getString()。

WTTTTTTTF!

即便在我明确认定 context 不为空的情况下，仍然需要加 !! 使用。于是我想了一个办法：

override fun getContext() = super.getContext()!!

fun getNullableContext() = super.getContext()

这样我就可以在明确知道 context 不为空的地方直接调用 context.getString() 啦，需要判断是否为空的地方调用 getNullableContext()。

然而问题并没有结束，因为有些地方我需要使用 getActivity() 而不只是 getContext()，可是：

@Nullable
final public FragmentActivity getActivity() {
    return mHost == null ? null : (FragmentActivity) mHost.getActivity();
}

注意到那个“万恶”的 final 了吗？

WTTTTTTTTTTTTTTF!

只能在每个使用 getActivity() 并确定它不为空的地方手动加 !! 了。。。暂时没有想到更好的解决办法。

最后说两句：

第一，新的变动并不是为了给写代码添加麻烦而加上的，要明确 fragment 中的 getContext()、getActivity() 在一些情况下就是有可能为空的，不要简单地在所有地方加上 !! 就算完事，该判断的地方还是得判断的。
第二，虽然 27 版本的升级带来了这样的兼容问题，但整体而言，对于是否可为空类型在 java 和 kotlin 之间的调用语法更加完善了。兼容适配的过程很痛苦，但是 —— 忍着！ - -#

Android Instance State

2017-11-28T00:00:00+00:00

今天我们来聊聊 onRestoreInstanceState 和 onSaveInstanceState 这两个非生命周期却为大家所熟知的方法。

我们从简书 app 的一个功能说起。

浏览过一个文章页面后，如果应用在后台被杀死，再次打开 app 时，会从首页自动跳转到上次浏览的页面以及浏览的位置。

而如果是正常的返回退出应用，再次打开 app 时不会进行自动跳转。

简书自动恢复页面功能简单实现

话不多说先上代码：

// ItemActivity.

public static final String KEY_ITEM = "item";
public static final String KEY_SCROLL_Y = "scroll_y";

@Override
protected void onCreate(Bundle savedInstanceState) {
    // ...

    setTitle(getIntent().getStringExtra(KEY_ITEM));

    if (savedInstanceState == null && mSp.contains(KEY_SCROLL_Y)) {
        final int scrollY = mSp.getInt(KEY_SCROLL_Y, 0);
        mScrollView.postDelayed(new Runnable() {
            @Override
            public void run() {
                mScrollView.smoothScrollTo(0, scrollY);
            }
        }, 500L);
    }
}

@Override
protected void onResume() {
    super.onResume();

    mSp.edit().remove(KEY_ITEM).apply();
    mSp.edit().remove(KEY_SCROLL_Y).apply();
}

@Override
protected void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);

    mSp.edit().putString(KEY_ITEM, getIntent().getStringExtra(KEY_ITEM)).apply();
    mSp.edit().putInt(KEY_SCROLL_Y, mScrollView.getScrollY()).apply();
}

// MainActivity.

@Override
protected void onCreate(Bundle savedInstanceState) {
    // ...

    mListView.setAdapter(new ArrayAdapter<>(this, android.R.layout.simple_list_item_1, LIST_VIEW_ITEMS));
    mListView.setOnItemClickListener(this);

    if (savedInstanceState == null && mSp.contains(ItemActivity.KEY_ITEM)) {
        final String item = mSp.getString(ItemActivity.KEY_ITEM, "0");
        mListView.postDelayed(new Runnable() {
            @Override
            public void run() {
                int position = Integer.parseInt(item);
                onItemClick(null, null, position, 0L);
            }
        }, 500L);
    }
}

@Override
public void onItemClick(AdapterView<?> parent, View view, int position, long id) {
    startActivity(new Intent(this, ItemActivity.class)
            .putExtra(ItemActivity.KEY_ITEM, LIST_VIEW_ITEMS[position]));
}

效果如下：

当然这只是一种可以达到效果的实现方式，在 ItemActivity 的 onSaveInstanceState 中使用 SharedPreferences 保存当前 Item 页面和 ScrollView 滚动的位置，在 onResume 中清除这两个值。因为正常按返回键退出 app，下次启动时不会自动打开上次浏览的页面。这就涉及到 onSaveInstanceState 的触发时机了。

`onRestoreInstanceState` 和 `onSaveInstanceState` 的触发时机

对于 onSaveInstanceState，在以下场景会触发回调：

Home 键
熄屏
打开另一个 Activity
屏幕旋转（不止是屏幕旋转，任何未在 Manifest 中配置 configChanges 的 config 在改变时都会触发，只是屏幕旋转最常见也最容易观测）

总而言之，onSaveInstanceState 会在 非用户主动关闭 Activity 而又有可能导致 Activity 被回收而销毁 的时机调用，屏幕旋转是会立即销毁并立即重建 activity，如果是用户主动按 back 退出 Activity，这个方法不会被调用。

对于 onRestoreInstanceState，它不是和 onSaveInstanceState 配对调用的。onSaveInstanceState 被调用并不一定意味着 onRestoreInstanceState 在之后也会被调用，它只在 onSaveInstanceState 被调用且 Activity 的确被销毁的情况下，下次恢复 activity 时调用。例如：按 home 键触发 onSaveInstanceState，然后立即回到 activity，activity 还没有被销毁，是不会调用 onRestoreInstanceState 的。

也就是说：

onSaveInstanceState：如果你不是主动要退出，但目前的某个操作导致你处于可能被系统回收的状态，你可以在这里保存你当前的状态
onRestoreInstanceState：如果你之前保存过状态，且你真的被系统回收了，你可以在这里恢复你保存的状态

onRestoreInstanceState 在 application 进程被杀死的情况下，例如，在应用信息中强制停止 app，或在 recent 界面中清除 app，则不会在下次启动时被调用。

另外，onCreate 生命周期方法中也提供参数 savedInstanceState。与 onRestoreInstanceState 不同的是：onCreate 中的 savedInstanceState 是可能为 null 的，onRestoreInstanceState 中的一定不为 null，只在有状态需要被恢复时，才会调用 onRestoreInstanceState。

回到上面的问题，在 onSaveInstanceState 中保存 SharedPreferences 是因为这符合“我的数据可能丢失”的情况，只是这里使用了持久化存储以便在即使应用被杀死的情况下也能恢复数据。在 onResume 中删除数据是因为我又回到了正常状态，如果这时候按 back 退出，这是用户的主动操作，我不需要在下一次启动是恢复数据了。之后在 onCreate 中判断是否存在已保存的数据，如果存在就恢复。判断的时候多加了一个 savedInstanceState == null 是因为这是针对应用被杀死后还能恢复的需求的，如果仍然存在可以恢复的数据，应该使用 savedInstanceState 进行数据恢复而不应该读取 SharedPreferences 进行数据恢复。

View 的 instance state.

等等，这个场景好像和 onRestoreInstanceState 没什么关系啊，我们上面写的 demo，都没有用到 onRestoreInstanceState，而且，我们目前测试的主要是持久化的部分，并没有测试真正的当 activity 被系统回收时的情况。

那么我们该怎么测试系统回收 activity 的情况呢。。。毕竟现在手机内存都大，哪那么容易测得到这种情况。

两种办法：

自己写的 demo 不固定屏幕方向，测试屏幕旋转时候的情况，它一定会调用 onSaveInstanceState 和 onRestoreInstanceState
如果我不在 demo 中测试，想自己在线上项目中测试，而这个 app 又不允许屏幕旋转，那么：

在 开发者选项 中开启“不保留活动”，这个“活动”就是 Activity 的翻译 = =。。。还不如不翻。

它会在 activity 被放置到后台时就销毁（回收）。那么我们只要按下 home 键就立刻模拟了系统内存不够而回收 activity 的场景。再次回到 activity 时，onSaveInstanceState 就会被调用。

开启后我们测试下我们的 demo。

发现之前滚动的位置被恢复了，并没有回到 ScrollView 顶部。然而，我们并没有覆写 onRestoreInstanceState 在里面恢复 ScrollView 的位置，甚至没有在 onSaveInstanceState 中保存什么值啊？

View 也有自己的 onRestoreInstanceState 和 onSaveInstanceState，我们可以看一下 ScrollView 源码：

@Override
protected void onRestoreInstanceState(Parcelable state) {
    if (mContext.getApplicationInfo().targetSdkVersion <= Build.VERSION_CODES.JELLY_BEAN_MR2) {
        // Some old apps reused IDs in ways they shouldn't have.
        // Don't break them, but they don't get scroll state restoration.
        super.onRestoreInstanceState(state);
        return;
    }
    SavedState ss = (SavedState) state;
    super.onRestoreInstanceState(ss.getSuperState());
    mSavedState = ss;
    requestLayout();
}

@Override
protected Parcelable onSaveInstanceState() {
    if (mContext.getApplicationInfo().targetSdkVersion <= Build.VERSION_CODES.JELLY_BEAN_MR2) {
        // Some old apps reused IDs in ways they shouldn't have.
        // Don't break them, but they don't get scroll state restoration.
        return super.onSaveInstanceState();
    }
    Parcelable superState = super.onSaveInstanceState();
    SavedState ss = new SavedState(superState);
    ss.scrollPosition = mScrollY; // 保存滚动位置
    return ss;
}

ScrollView 自己处理的滚动位置的保存与恢复。

然后 Activity 是怎么保存和恢复 View 的状态的呢？我们可以追溯到 Activity 的 onSaveInstanceState（onRestoreInstanceState 与它是基本类似的逻辑，一个是保存，一个是恢复，所以我们接下来就只看保存的部分）：

protected void onSaveInstanceState(Bundle outState) {
    outState.putBundle(WINDOW_HIERARCHY_TAG, mWindow.saveHierarchyState()); // 这里

    outState.putInt(LAST_AUTOFILL_ID, mLastAutofillId);
    Parcelable p = mFragments.saveAllState();
    if (p != null) {
        outState.putParcelable(FRAGMENTS_TAG, p);
    }
    if (mAutoFillResetNeeded) {
        outState.putBoolean(AUTOFILL_RESET_NEEDED, true);
        getAutofillManager().onSaveInstanceState(outState);
    }
    getApplication().dispatchActivitySaveInstanceState(this, outState);
}

它往 Bundle 中存入了 mWindow.saveHierarchyState()，这个 mWindow 就是 PhoneWindow，所以我们接着找 PhoneWindow：

@Override
public Bundle saveHierarchyState() {
    Bundle outState = new Bundle();
    if (mContentParent == null) {
        return outState;
    }

    SparseArray<Parcelable> states = new SparseArray<Parcelable>();
    mContentParent.saveHierarchyState(states); // 这里
    outState.putSparseParcelableArray(VIEWS_TAG, states);

    // Save the focused view ID.
    final View focusedView = mContentParent.findFocus();
    if (focusedView != null && focusedView.getId() != View.NO_ID) {
        outState.putInt(FOCUSED_ID_TAG, focusedView.getId());
    }

    // save the panels
    SparseArray<Parcelable> panelStates = new SparseArray<Parcelable>();
    savePanelState(panelStates);
    if (panelStates.size() > 0) {
        outState.putSparseParcelableArray(PANELS_TAG, panelStates);
    }

    if (mDecorContentParent != null) {
        SparseArray<Parcelable> actionBarStates = new SparseArray<Parcelable>();
        mDecorContentParent.saveToolbarHierarchyState(actionBarStates);
        outState.putSparseParcelableArray(ACTION_BAR_TAG, actionBarStates);
    }

    return outState;
}

这个 mContentParent 是 Window 的 DecorView 上 id 为 com.android.internal.R.id.content 的一个 ViewGroup，在设置了某些 flag 或主题的情况下，它有可能是 DecorView 自身。简而言之，它是我们 setContentView 时内容添加到的 ViewGroup，平时我们往 Activity 填充一个 fragment 时可以这么写：

fragmentManager.beginTransaction().add(android.R.id.content, fragment).commit();

就往 Activity 的 contentView 上添加一个 fragment，省去了为 Activity setContentView 添加只有一个 FrameLayout 的布局的麻烦。

对的这个 mContentParent 就是这个 android.R.id.content 的 View，Activity 的 content 区域的所有 View 都以它为父 ViewGroup。

这个 mContentParent 调用了 saveHierarchyState(states)：

public void saveHierarchyState(SparseArray<Parcelable> container) {
    dispatchSaveInstanceState(container);
}

protected void dispatchSaveInstanceState(SparseArray<Parcelable> container) {
    if (mID != NO_ID && (mViewFlags & SAVE_DISABLED_MASK) == 0) {
        mPrivateFlags &= ~PFLAG_SAVE_STATE_CALLED;
        Parcelable state = onSaveInstanceState(); // 这里
        if ((mPrivateFlags & PFLAG_SAVE_STATE_CALLED) == 0) {
            throw new IllegalStateException(
                    "Derived class did not call super.onSaveInstanceState()");
        }
        if (state != null) {
            // Log.i("View", "Freezing #" + Integer.toHexString(mID)
            // + ": " + state);
            container.put(mID, state);
        }
    }
}

绕了一大圈子，总算回到 onSaveInstanceState 了，这还没完，这是 View 的 dispatchSaveInstanceState，对于 ViewGroup：

@Override
protected void dispatchSaveInstanceState(SparseArray<Parcelable> container) {
    super.dispatchSaveInstanceState(container);
    final int count = mChildrenCount;
    final View[] children = mChildren;
    for (int i = 0; i < count; i++) {
        View c = children[i];
        if ((c.mViewFlags & PARENT_SAVE_DISABLED_MASK) != PARENT_SAVE_DISABLED) {
            c.dispatchSaveInstanceState(container);
        }
    }
}

如果还是不太清楚，我们从头屡一遍：

因可能发生 Activity 回收而调用 Activity 的 onSaveInstanceState
Activity 的 onSaveInstanceState 中调用 PhoneWindow 的 saveHierarchyState()
PhoneWindow 的 saveHierarchyState() 中调用 mContentParent，也就是 Window 的 contentView 的父 ViewGroup，的 saveHierarchyState(states)
mContentParent 的 saveHierarchyState(states) 会调用 dispatchSaveInstanceState(container)
mContentParent 是一个 ViewGroup，它的 dispatchSaveInstanceState(container) 会先保存自己的状态，然后调用每一个子 View 的 dispatchSaveInstanceState(container)
对于一个 View 的 dispatchSaveInstanceState(container) 中会调用 onSaveInstanceState()
ScrollView 的 onSaveInstanceState() 中保存了滚动位置信息

这个图展示了 View 部分的 instance state 调用顺序：

因此，我们啥也不写，ScrollView 也能正确地保存和恢复自己的状态。

注意一点：想要一个 View 的状态被自动保存和恢复，必须设置 setSaveEnabled(true)（默认情况下这个 flag 就是 true 的，所以这个用来阻止一个 view 自动保存状态时使用），还必须为这个 View 设置 id，通常是在 xml 中 android:id="@+id/..." 的形式。如果没有设置 id，View 将不会自动处理状态的保存与恢复。原因可以查看上面的 View 的 dispatchSaveInstanceState 代码，一开始就进行了判断：

protected void dispatchSaveInstanceState(SparseArray<Parcelable> container) {
    if (mID != NO_ID && (mViewFlags & SAVE_DISABLED_MASK) == 0) {
        // ...
        Parcelable state = onSaveInstanceState();
        // ...
        if (state != null) {
            // Log.i("View", "Freezing #" + Integer.toHexString(mID)
            // + ": " + state);
            container.put(mID, state);
        }
    }
}

这里首先就判断了 id 不为空且不允许添加 SAVE_DISABLED_MASK flag.

View 的 id 是作为这个用于存储状态的 SparseArray<Parcelable> 的 key 使用的，如果没有设置 id，所有未设置 id 的 View 的 key 都使用 -1 显然是不可能的。

自定义 View 的状态的保存与恢复.

其实对于 Activity 的 onRestoreInstanceState 和 onSaveInstanceState 理解和使用起来还是比较简单的，无非是往传入的 savedInstanceState 和 outState 这两个 Bundle 对象中读写可序列化的对象或基本数据类型变量。

但我们为什么需要自定义 View 处理 onRestoreInstanceState 和 onSaveInstanceState 呢？

在用途上，Activity 和 Fragment 应该保存的是与业务相关的状态。如果所有 View 的状态都交由 Activity 和 Fragment 处理，显然是不可行的，因此就需要 View 自身管理自身的状态，正确的保存和恢复。

它和 Activity 的区别还在于方法签名的不同导致的用法上的区别：

Activity 的：void onRestoreInstanceState(Bundle savedInstanceState) 和 void onSaveInstanceState(Bundle outState) View 的：void onRestoreInstanceState(Parcelable state) 和 Parcelable onSaveInstanceState() 以及 Fragment 的：void onViewStateRestored(Bundle savedInstanceState) 和 onSaveInstanceState(Bundle outState)，fragment 与 activity 的差别只在方法名上，使用起来和 activity 是一样的。

Activity 的参数 Bundle 是一个非抽象类，且都是通过参数传入，使用时只需要调用 Bundle 已有的一堆方法。 View 的参数 Parcelable 是一个接口，没有多少可调用的方法，且 onSaveInstanceState() 时需要返回一个 Parcelable。

所以它使用起来是这样的：

// 需要被保存的自定义状态.
private String mCustomState;

@Override
protected void onRestoreInstanceState(Parcelable state) {
    // 强转 state 为 SavedState 类型，这是安全的，因为保存状态时提供的也是这个类型。
    SavedState ss = (SavedState) state;
    // 恢复 super 状态。
    super.onRestoreInstanceState(ss.getSuperState());
    // 恢复当前自定义的状态。
    mCustomState = ss.customState;
}

@Override
protected Parcelable onSaveInstanceState() {
    // 保存 super 状态。
    Parcelable superState = super.onSaveInstanceState();
    // 创建自定义的 SavedState 并传入 super 的状态和当前自定义的状态。
    SavedState ss = new SavedState(superState, mCustomState);
    // 返回 SavedState。
    return ss;
}

/**
* 自定义状态保存类。
*/
private static class SavedState extends BaseSavedState {
    public final String customState;

    /**
    * 由 Parcelable 使用。
    */
    public SavedState(Parcel source) {
        super(source);
        customState = source.readString();
    }

    /**
    * @param superState Super 的状态。
    * @param customState 自定义的状态。
    */
    public SavedState(Parcelable superState, String customState) {
        super(superState);
        this.customState = customState;
    }

    @Override
    public void writeToParcel(Parcel out, int flags) {
        super.writeToParcel(out, flags);
        out.writeString(customState);
    }

    public static final Parcelable.Creator<SavedState> CREATOR
            = new Parcelable.Creator<SavedState>() {
        public SavedState createFromParcel(Parcel in) {
            return new SavedState(in);
        }

        public SavedState[] newArray(int size) {
            return new SavedState[size];
        }
    };
}

上面我们说，一个 View 必须设置 id 才能被保存和恢复状态，如果同一个 ViewGroup 下的两个 View id 相同呢？

这怎么可能呢？在 layout 文件中，两个 View id 相同会直接报错的。但是，如果使用了 <include> 标签，同时 include 了两个 layout 文件，它们中存在相同的 id，或者干脆我 include 同一个 layout 文件两次，那么这个问题就出现了。虽然这样的情况很少见，甚至 android 自带的 ViewGroup 都没有处理这种情况，但是我们还是要说一下。

如果引用了两个不同的 layout 文件，它们中存在相同的 id，比较简单的方式是，直接修改 id 保证同一个 Activity 内的所有子 View id 都不相同。这需要项目自己做规范。

如果引用了同一个 layout 文件多次，那么这种时候，修改 id 的方式就不可行了，当然，你还是可以复制出来一份 layout，然后修改，啊这不是我想说的。。

有一种解决办法是自定义你所需要的 ViewGroup，修改其中保存子 View 状态的相关方法，然后 layout 文件中使用自定义 ViewGroup。

@Override
protected void dispatchRestoreInstanceState(SparseArray<Parcelable> container) {
    // 阻止 ViewGroup 恢复子 View 的状态，只让 ViewGroup 恢复自己的状态。
    dispatchThawSelfOnly(container);
}

@Override
protected void dispatchSaveInstanceState(SparseArray<Parcelable> container) {
    // 阻止 ViewGroup 保存子 View 的状态，只让 ViewGroup 保存自己的状态。
    dispatchFreezeSelfOnly(container);
}

@Override
protected void onRestoreInstanceState(Parcelable state) {
    SavedState ss = (SavedState) state;
    super.onRestoreInstanceState(ss.getSuperState());
    // 从自己创建的 SparseArray 恢复子 View 的状态，保证了子 View 的状态也在单独的 SparseArray 中。
    for (int i = 0; i < getChildCount(); i++) {
        getChildAt(i).restoreHierarchyState(ss.childrenStates);
    }
}

@Override
protected Parcelable onSaveInstanceState() {
    Parcelable superState = super.onSaveInstanceState();
    SavedState ss = new SavedState(superState);
    // 保存到自己创建的 SparseArray 中。
    for (int i = 0; i < getChildCount(); i++) {
        getChildAt(i).saveHierarchyState(ss.childrenStates);
    }
    return ss;
}

private static class SavedState extends BaseSavedState {
    final SparseArray<Parcelable> childrenStates;

    public SavedState(Parcel source) {
        this(source, null);
    }

    public SavedState(Parcel source, ClassLoader loader) {
        super(source);
        childrenStates = source.readSparseArray(loader);
    }

    public SavedState(Parcelable superState) {
        super(superState);
        childrenStates = new SparseArray<>();
    }

    public static final ClassLoaderCreator<SavedState> CREATOR
            = new ClassLoaderCreator<SavedState>() {
        @Override
        public SavedState createFromParcel(Parcel source) {
            return createFromParcel(source, null);
        }

        @Override
        public SavedState createFromParcel(Parcel source, ClassLoader loader) {
            return new SavedState(source, loader);
        }

        public SavedState[] newArray(int size) {
            return new SavedState[size];
        }
    };
}

其中 dispatchThawSelfOnly(container) 和 dispatchFreezeSelfOnly(container) 的实现如下：

protected void dispatchThawSelfOnly(SparseArray<Parcelable> container) {
    super.dispatchRestoreInstanceState(container);
}

protected void dispatchFreezeSelfOnly(SparseArray<Parcelable> container) {
    super.dispatchSaveInstanceState(container);
}

dispatchRestoreInstanceState 和 dispatchSaveInstanceState 的默认实现如下：

@Override
protected void dispatchRestoreInstanceState(SparseArray<Parcelable> container) {
    super.dispatchRestoreInstanceState(container);
    final int count = mChildrenCount;
    final View[] children = mChildren;
    for (int i = 0; i < count; i++) {
        View c = children[i];
        if ((c.mViewFlags & PARENT_SAVE_DISABLED_MASK) != PARENT_SAVE_DISABLED) {
            c.dispatchRestoreInstanceState(container);
        }
    }
}

@Override
protected void dispatchSaveInstanceState(SparseArray<Parcelable> container) {
    super.dispatchSaveInstanceState(container);
    final int count = mChildrenCount;
    final View[] children = mChildren;
    for (int i = 0; i < count; i++) {
        View c = children[i];
        if ((c.mViewFlags & PARENT_SAVE_DISABLED_MASK) != PARENT_SAVE_DISABLED) {
            c.dispatchSaveInstanceState(container);
        }
    }
}

这两个方法就是放弃 ViewGroup 本来那些保存和恢复子 View 的操作，只简单地调用 ViewGroup 作为 View 自身应该保存和恢复的操作。

还记得 PhoneWindow 中的代码吗：

@Override
public Bundle saveHierarchyState() {
    // ...

    SparseArray<Parcelable> states = new SparseArray<Parcelable>();
    mContentParent.saveHierarchyState(states);

    // ...
}

从根 ViewGroup 开始遍历，所有的 View 的状态都被添加到这个名为 states 的 SparseArray，key 为 view id，value 为状态。这就是整个 layout 下的需要保存状态的 view 需要有 id 且 id 不能重复的原因。而在自定义的 ViewGroup 中，原先应该 put 进公共 states 中的子 View 的状态，被 put 进了自己创建的 childrenStates 这个 SparseArray 中，然后整个 ViewGroup 包括其子 View 的状态被 put 进公共的 states 中，只要 ViewGroup 的 id 不重复，其子 View 的 id 是可以与其他 ViewGroup 中子 View 的 id 相同的。而一个布局 include 两次同一个 layout 文件，它们也需要不同的 id，这就没有问题了。

这是默认情况下 ViewGroup 的实现：

这是自己管理子 View 状态的 ViewGroup 的实现：

系统提供的各个 ViewGroup 默认不会有这样的实现，是为了提高性能，这样的需求，只在必要时使用就好了。

persistentState

从 API 21 开始，Activity 中添加了几个方法：

/**
  * @param persistentState if the activity is being re-initialized after
  *     previously being shut down or powered off then this Bundle contains the data it most
  *     recently supplied to outPersistentState in {@link #onSaveInstanceState}.
  *     <b><i>Note: Otherwise it is null.</i></b>
  */
@Override
public void onCreate(Bundle savedInstanceState, PersistableBundle persistentState) {}

@Override
public void onRestoreInstanceState(Bundle savedInstanceState, PersistableBundle persistentState) {}

@Override
public void onSaveInstanceState(Bundle outState, PersistableBundle outPersistentState) {}

从 api 文档上看，在 Manifest 中配置 android:persistableMode="persistAcrossReboots" 后，这几个方法的 PersistableBundle 是用来在手机重启后仍能恢复状态使用的。

然而在我不成熟的小测试中，它们并没有什么卵用，且不同版本的设备上出现的问题也不相同。

不过即便是它们的确起到了卵用，对于实际的开发而言也仍然没太大实际作用，如果真的希望更长久的保存 app 中的状态数据，应该考虑持久化存储，onRestoreInstanceState 和 onSaveInstanceState 也只是用来暂存的，它不能保证数据不丢失（比如强制停止 app），真正重要的数据是不应该使用 instance state 的。

应用场景

大家有没有发现，平时开发，似乎都不怎么注意到 instance state 的处理，不论是自定义 View，还是在 Activity 或 Fragment 中，都较少关注这几个方法参数。

首先，Android 提供的原生控件，已经很好地帮我们实现的大部分情况下需要的 instance state 的保存与恢复。使用的大部分都是原生控件，不需要额外的处理。

其次，Android 设备内存越来越大，大部分情况下不需要考虑 app 因系统内存紧张而被回收的情况，即使被回收，重新初始化所有数据就好，没有多少恢复状态的必要。并且，受各种因素影响，多数 app 基本 ui 模型都是底部 4 到 5 个 tab，这样的应用 ui 结构在横屏的显示效果是不太好的，也没有太大必要的，因此，大部分应用的屏幕方向都固定写死了。没有回收和屏幕旋转，平时我们很难注意到对状态的处理，因为它不是能很直观地看的出来的东西。

因此就现有的应用结构，完全不处理 onRestoreInstanceState 和 onSaveInstanceState 也能应付大部分情况。

当开发者选项中的“不保留活动”开启后，模拟系统回收 Activity 的场景，其实大部分 app 都有多多少少的适配问题。

因此为了更好的用户体验，以及可能的部分页面横竖屏切换的需要（其实一个应用能支持横竖屏切换也是用户体验的一部分），理解掌握 instance state 还是有必要的。

Kotlin 对 Android APK 包大小的影响

2017-11-07T00:00:00+00:00

使用两个空项目测试以 Java 和 Kotlin 作为开发语言生成的 APK 包的大小。

两个项目都没有任何 res 资源文件（ AndroidManifest 文件中全部使用默认值），都只有一个空的 MainActivity 文件，没有任何逻辑代码。Kotlin 项目中添加了 kotlin-android 和 kotlin-android-extensions 插件，引用了 org.jetbrains.kotlin:kotlin-stdlib-jre8:$kotlin_version 库。Java 项目中不引用任何库。build.gradle 文件中使用 minifyEnabled true 控制代码压缩，使用 useProguard false 控制代码混淆，分别打 Release 包，测试结果如下（大小分别为 .apk 文件大小和 .dex 文件大小）：

	Java	Kotlin
不压缩不混淆	5K (1K)	360K (1.5M)
压缩不混淆	5K (484B)	20K (5K)
压缩混淆	5K (432B)	18K (436B)

应该可以理解为，Kotlin 语言的引入对 APK 包大小的影响，最大为 360K 左右，即 Kotlin 依赖库中的所有文件在项目中都用到了。一般情况下，使用 Kotlin 开发只会增加 APK 包 100~200K 的大小。其他的可能的影响就是 Kotlin 的语法糖对应的 Java 代码的复杂程度了。

比如下面这个例子 （以下测试代码都是在不压缩不混淆的配置下反编译的）：

import kotlinx.android.synthetic.main.activity_main.helloButton

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

        setContentView(R.layout.activity_main)

        helloButton.text = "Hello"
        helloButton.setOnClickListener { Toast.makeText(this, "World", Toast.LENGTH_SHORT).show() }
    }
}

这个扩展插件 Kotlin Android Extensions 简化了 findViewById 的使用。

反编译后得到的 Java 代码：

public final class MainActivity
  extends Activity
{
  private HashMap _$_findViewCache;
  
  public MainActivity() {}
  
  public void _$_clearFindViewByIdCache()
  {
    if (_$_findViewCache != null) {
      _$_findViewCache.clear();
    }
  }
  
  public View _$_findCachedViewById(int paramInt)
  {
    if (_$_findViewCache == null) {
      _$_findViewCache = new HashMap();
    }
    View localView = (View)_$_findViewCache.get(Integer.valueOf(paramInt));
    if (localView == null)
    {
      localView = findViewById(paramInt);
      _$_findViewCache.put(Integer.valueOf(paramInt), localView);
    }
    return localView;
  }
  
  protected void onCreate(@Nullable Bundle paramBundle)
  {
    super.onCreate(paramBundle);
    setContentView(2130837504);
    ((Button)_$_findCachedViewById(R.id.helloButton)).setText((CharSequence)"Hello");
    ((Button)_$_findCachedViewById(R.id.helloButton)).setOnClickListener((View.OnClickListener)new View.OnClickListener()
    {
      public final void onClick(View paramAnonymousView)
      {
        Toast.makeText((Context)this$0, (CharSequence)"World", 0).show();
      }
    });
  }
}

可以看出 Kotlin Android Extensions 为每一个 Activity 生成了一个名为 _$_findViewCache 的 HashMap 用于缓存 View id，每次通过 kotlinx.android.synthetic.*.*.* 获取 View 其实都是从 Cache 中获取。

优点是书写方便。
缺点是其实真正执行的代码反而变多了，并且灵活性下降。
性能上，由于使用了缓存，所以基本上无差。

Kotlin 标识符

2017-11-07T00:00:00+00:00

简单地聊一聊 Kotlin 标识符。

Java 允许而 Kotlin 不允许的

_、__、___ 等只由下划线组成的标识符在 Kotlin 中是不允许的。但是复合在其他字符中使用是可以的。下划线在 Kotlin 中的使用有几个场景：

Lambda 表达式中简写参数。

// 第一个参数是 View, 第二个参数是 MotionEvent. 但他们在函数中都不需要 (没引用), 所以可以使用 _.
view.setOnTouchListener { _, _ -> 
    // Do nothing.

    true // 这个是返回值, 在 Lambda 表达式中不需要也不能够写 return.
}

提高数字常量可读性。

val num = 1_000_000
val hex = 0xFF_EC_DE_5E
val bytes = 0b11010010_01101001_10010100_10010010

// PS: Kotlin 不支持八进制数字, Java 中 0 开头的数字是八进制数字.

数据类和解构声明中省略不需要的属性声明。

data class Person(var name: String, var age: Int)

val person = Person("Pichai", 45)
val (name, _) = person
println(name) // Pichai

$ 这个字符在 Kotlin 中不能用在标识符中，它在 Kotlin 中在字符串模版中使用。例如 "My name is $name!"。
Kotlin 中的关键字或修饰符（而 Java 中不是关键字的），例如 in、when，在 Kotlin 中使用 `in`, `when`。其实 Kotlin 中所有标识符都可以在前后添加 ` 来使用，就是为了在任何 Koltin 本身不允许作为标识符的情况下做兼容，比如 `_` 相当于 Java 中的 _。当使用的标识符在当前语境下不产生歧义时，关键字或修饰符也可以作为标识符，比如 data 在 Kotlin 中是可以用来定义数据类（data class）的修饰符，但是 var data = 0 这么写是允许的。

Kotlin 允许而 Java 不允许的

毕竟 Java 是老大，Kotlin 要向 Java 兼容而不是反过来，所以当 Kotlin 中可用而 Java 中不允许的标识符出现时（例如 Java 中的关键字在 Kotlin 中不是关键字的），那么 Kotlin 就要自己通过添加前缀修饰符的方式在字节码层面做兼容了。

中文标识符

这在 Kotlin 和 Java 中都允许但 = =。。。 永远别用！！

Kotlin 的 Getter 和 Setter

2017-11-06T00:00:00+00:00

关于 Kotlin 的 getter 和 setter 的基础语法就不详细介绍了。但是就是这么一个简单的概念，却有很多容易让人忽略细节。如果不理解 Kotlin 的语法在编译到字节码后是什么样的，你可能无法真正用好 getter 和 setter，先来个例子：

private val foo = calcValue("foo")
private val bar get() = calcValue("bar")

private fun calcValue(name: String): Int {
    println("Calculating $name")
    return 3
}

是的唯一的不同是添加了 get()，这两个属性在访问时的行为却不一致了。

属性 foo 只有第一次使用时会调用 calcValue()，属性 bar 每一次使用是都会调用 calcValue()。可以通过反编译后的 Java 代码明确看出区别：

private final int foo = calcValue("foo");

private final int calcValue(String paramString)
{
String str = "Calculating " + paramString;
System.out.println(str);
return 3;
}

private final int getBar()
{
return calcValue("bar");
}

一个简单的访问权限修饰符也能导致其对应的 Java 代码的较大的差别：

private val foo = 3
val bar = 3

反编译后：

private final int bar = 3;
private final int foo = 3;

public final int getBar()
{
return bar;
}

在 Kotlin 中，类中没有字段这一概念，所有形如 Java 中 field 的变量在 Kotlin 中都叫属性，它和字段的区别是所有的属性都有对应的 getter 和 setter，val 属性没有 setter，private 属性在编译成可能省略 getter 和 setter。这体现在，Kotlin 代码中的所谓 “字段” 在 Java 文件中使用时是无法直接调用的，必须通过 getXxx() 和 setXxx(value) 调用 Kotlin 中名为 xxx 的属性。还体现在，Kotlin 代码中如果已经存在名为 xxx 的属性，就不允许再创建名为 getXxx() 或 setXxx(value) 的方法。

因此，在 Kotlin 中的一个 有初始化值 的属性对应了 Java 中的一个 private 字段加上其相应的 getter 和 setter。这个字段一定是 private 的，属性的修饰符体现在对应的 getter 和 setter 上。

var 和 val 的唯一区别在于 var 既有 getter 又有 setter，val 只有 getter 没有 setter。

val 与 Java 中的 final 不完全相同。只有一种情况它们完全相同，就是像 private val foo = 3 这样，以 private 修饰，赋予初始值，并且不提供自定义 getter，不被委托的属性，这个属性完全等同于 Java 中的 private final int foo = 3;。

再回顾上面第一个例子，我们把代码简化一下，关注这个 get()：

val foo = 3

val bar
    get() = 3

private final int foo = 3;

public final int getBar()
{
return 3;
}

public final int getFoo()
{
return foo;
}

注意到，被 private 修饰的 Kotlin 属性在编译成字节码后省略了 getter 和 setter，因为 private 属性的非自定义 getter 和 setter 的存在是没有意义的，省略 getter 和 setter 是为了节省调用方法的开销。就如在 Java 中，如果你的 getter 和 setter 只是简单的赋值和返回，那么调用 getXxx() 和 setXxx(value) 和直接使用字段有什么差别呢？我个人认为 Java 中无意义的 getter 和 setter 是非常糟糕的实践，我们每个人在初学 Java 时都被告知，类里的字段不应该是 public 的，最好要被 private 修饰，然后提供对应的 getXxx() 和 setXxx(value)，所以每一个 Java 初学者都习惯了这种写法，却不知道为什么！！？？为了封装？封装什么？不还是通过 getXxx() 原样暴露出去了吗？

渐渐地我们发现，Java 中的 getter 和 setter 不是没有意义的，只是经常被滥用了。只有当一个字段的 getter 和 setter 在意义上 需要被自定义，它才有存在的必要，对于一个纯 Model，赋值取值时不做校验且需要对外暴露的字段，或者在意义上就是共享的字段，强行封装一层 getter 和 setter 只会导致冗余没有任何意义。

Java 中与字段分离的 getter 和 setter 有两个缺点，第一书写相对麻烦，这个不多说了，第二：

private int x;
private int y;

public int getX() {
    return x;
}

public int getY() {
    return y;
}

public void setX(int x) {
    if (this.x == x) {
        return;
    }

    this.x = x;
    onPositionChanged();
}

public void setY(int y) {
    if (this.y == y) {
        return;
    }

    this.y = y;
    onPositionChanged();
}
    
public void setPosition(int x, int y) {
    if (this.x == x && this.y == y) {
        return;
    }
    
    this.x = x;
    this.y = y;
    onPositionChanged();
}

protected void onPositionChanged() {
}

OK 我很有可能在类内部忘记调用 setX(x) 而直接使用 x = 100，那么 onPositionChanged 回调不就被我遗漏了吗？这时候有两种说辞：

- 我可能就是不需要 onPositionChanged 回调啊！- 那在业务复杂的时候你自己不会混乱什么时候调用 x 什么时候调用 getX() 吗？它们俩为什么意义不同呢？如果真的有这个必要，不应该以更明确的方式写出来吗？
- 那我每次都调用 setX(x) 呗！- 既然如此，为啥非得以这样的麻烦语法去写它？IDE 提供的 Getter and Setter Generator 就已经说明了——“这是个语言设计缺陷，这么麻烦的操作让我用外部工具帮你批量完成它吧！”

Kotlin 的 getter 和 setter 是与属性绑定的：

var foo
    get() = ...
    protected set(value) = ...

val bar
    get() { return ... }

如果没有权限修饰符修饰 getter 和 setter，那么默认为属性的修饰符，getter 和 setter 的修饰符不能大于属性的修饰符，比如被 protected 修饰的属性的 getter 和 setter 不能被 public 修饰。
不能同时存在两个形如 foo 和 Foo 的字段，因为他们在 Java 中的 getter 和 setter 调用方法签名冲突。
如果 Kotlin 中的属性使用了 Java 的关键字（但非 Kotlin 的关键字，比如 default、new），那么 Kotlin 会为对应的 Java 字段添加一个前缀，比如 jdField_，在 Kotlin 中的 default 字段反编译后得到 Java 中的 jdField_default，但是其 getter 还是 getDefault()，如果在 Kotlin 中再添加一个名为 jdField_default 的字段，编译运行都不会出问题，但是反编译出来的 Java 文件中出现了两个重名的字段，不确定是不是我使用的反编译工具的问题。。。不过这个问题要想做兼容并不困难，具体就不再深究。代码如下：

var default: Int = 0
var jdField_default: Int = 0
var new: Int = 0

private int jdField_default;
private int jdField_default;
private int jdField_new;

public final int getDefault()
{
return jdField_default;
}

public final int getJdField_default()
{
return jdField_default;
}

public final int getNew()
{
return jdField_new;
}

public final void setDefault(int paramInt)
{
jdField_default = paramInt;
}

public final void setJdField_default(int paramInt)
{
jdField_default = paramInt;
}

public final void setNew(int paramInt)
{
jdField_new = paramInt;
}

如果你确定你已经理解了 Kotlin 属性，来看最后这个例子：

var a = 3
// var a: Int = 3
// 省略可推断类型.

var b = 3
    // Warning: Redundant setter.
    get() = field
    // Warning: Redundant setter.
    set(value) {
        field = value
    }

// 编译错误: Property must be initialized or be abstract.
// var c: Int

// 编译错误: Property must be initialized.
// var d
//     get() = 3

val e
    get() = 3

var f
    get() = 3
    // Warning: Redundant setter.
    set(value) {}

属性 a 和属性 b 在字节码层面 完全一致，属性 b 中的 getter 和 setter 写与不写完全没差。
对比属性 d 和属性 e，为什么 d 编译错误呢，因为我们上面说过属性 b 的 setter 完全可以省略，意味着属性 a 的 setter 其实就长属性 b 的 setter 那样，只是被省略了，那对于这样一个默认的 setter，如果属性 e 不初始化，setter 中的 field 字段从何而来？field 是一个代表了当前属性的 幕后字段 ，它的作用域只限于当前 setter（getter 中也有一个 field），由于 Kotlin 中的类属性不像 Java 中的类字段，Kotlin 中的类属性是不提供默认初始化的，必须手动指定其默认值，因此属性 e 必须被初始化，setter 中的 field 被访问时才有值。而对于 val 属性 e，没有 setter，虽然 getter 中也可以存在 field 幕后字段，但是这里直接返回 3 没有用到 field，所以属性 e 这么写是没有问题的。
对比属性 d 和属性 f，多了个 setter，覆盖了默认的 field = value 的 setter，那么 field 也就没有引用了，f 的初始化也就可以省略了。
属性 f 的写法与直接写两个名为 getF() 和 setF(value) 的方法在字节码完全没区别。
像属性 a、属性 b 这种带初始化值的属性，在 Java 字节码会创建对应的字段，而像属性 e、属性 f 这样不带初始化值的属性，就不会有对应的字段被生成，原因很简单，它们不需要幕后字段 field，这个幕后字段其实就是对应到 Java 中的类字段，在 Kotlin 中，这样的幕后字段是用来存储属性真正的值的，除了 getter 和 setter 外部访问不到。如果 getter 和 setter 都不需要，那它就会被省略。
最后需要注意的一点：属性 b 的 setter 所带的 warning，和属性 f 的 setter 所带的 warning，虽然都提示 Redundant setter.，但它们意义不同。前者是说，“你不写这个 setter 我也会默认帮你做一样的事情 field = value”，后者是说，“你写了一个啥事情都没做一条语句都没有的空方法”，后者的 setter 也会被 IDE 提示“可删除”，但是如果删除了，逻辑是不同的。

以上这些分析，可以很容易从下面反编译出的 Java 代码得到验证：

private int a = 3;
private int b = 3;

public final int getA()
{
return a;
}

public final int getB()
{
return b;
}

public final int getE()
{
return 3;
}

public final int getF()
{
return 3;
}

public final void setA(int paramInt)
{
a = paramInt;
}

public final void setB(int paramInt)
{
b = paramInt;
}

public final void setF(int paramInt) {}

总结

Kotlin 中的类属性对映 Java 中的类字段加上其对应的 getter 和 setter。
属性的访问权限修饰符作用于其 getter 和 setter，getter 和 setter 的权限不能大于属性的权限，对应的 Java 字段始终为 private 权限。
val 属性没有 setter，形如 private val a = 0 的属性与 Java 中的 private final 字段完全相同。
幕后字段 field，用来在 getter 和 setter 中访问当前属性，相当于 Java 中的 private 字段。
一定条件下属性可以不赋予初始化值，对应在 Java 中不会生成字段，只会生成 getter 和 setter。

好了，现在随便写一个 Kotlin 属性，脑中马上就能反映出来对应的 Java 代码了吧！

Kotlin 委托属性

2017-10-23T00:00:00+00:00

简单的说，委托属性就是将一个属性的操作委托给一个委托类的实例处理，多个属性可以委托给同一个委托类。

跟没说一样。。

委托类

先看一个简单的例子。

class Delegate {
    operator fun getValue(thisRef: Any?, property: KProperty<*>): String {
        return "${property.name}: $thisRef"
    }

    operator fun setValue(thisRef: Any?, property: KProperty<*>, value: String) {
        println("value=$value")
    }
}

class Test {
    var s: String by Delegate()
}

val test = Test()
println(test.s) // s: Test@4eec7777
test.s = "hello" // value=hello

委托类类名任意。
如果被 val 属性委托，必须提供 getValue 方法，如果被 var 属性委托，必须提供 getValue 和 setValue 方法。委托类中的其他属性和方法任意。
getValue，setValue 的方法签名，参考对应接口：kotlin.properties.ReadOnlyProperty 和 kotlin.properties.ReadWriteProperty。

`thisRef` 参数

官方对 thisRef 参数的要求：

thisRef —— 必须与 属性所有者 类型（对于扩展属性——指被扩展的类型）相同或者是它的超类型

class DelegateTest {
    private var s1: String by Delegate()
    fun test1() {
        println(s1)
    }

    fun test2() {
        var s2: String by Delegate()
        println(s2)
    }

    companion object {
        private var s3: String by Delegate()
        fun test3() {
            println(s3)
        }

        fun test4() {
            var s4: String by Delegate()
            println(s4)
        }
    }
}

private var s5: String by Delegate()
fun test5() {
    println(s5)
}

fun test6() {
    var s6: String by Delegate()
    println(s6)
}

测试：

val test = DelegateTest()
test.test1()
test.test2()
DelegateTest.test3()
DelegateTest.test4()
test5()
test6()

Java 调用方式：

DelegateTest test = new DelegateTest();
test.test1();
test.test2();
DelegateTest.Companion.test3();
DelegateTest.Companion.test4();
DelegateTestKt.test5();
DelegateTestKt.test6();

输出：

s1: DelegateTest@7229724f
s2: null
s3: DelegateTest$Companion@4c873330
s4: null
s5: null
s6: null

可以看出，对于局部属性（在方法中声明的属性）或静态属性，thisRef 为 null，否则为属性所在对象。

委托类中的 `setValue`

如果委托一个 var 属性，希望保存属性上一次 setValue 的值，需要手动添加一个变量用于记录。

class WeirdDelegate(initValue: String = "") {
    private var localValue: String = initValue

    operator fun getValue(thisRef: Any?, property: KProperty<*>): String {
        return "This is NOT $localValue"
    }

    operator fun setValue(thisRef: Any?, property: KProperty<*>, value: String) {
        localValue = value
    }
}

var fruit by WeirdDelegate("banana")
fruit = "apple"
println(fruit) // This is NOT apple

Kotlin 标准委托

Kotlin 自带一些默认的委托实现。

延迟属性 Lazy

val lazyValue: String by lazy {
    print("Calculating...")
    "world"
}

println(lazyValue) // Calculating...world
println(lazyValue) // world

可观察属性 Observable

class User {
    var name: String by Delegates.observable("<no name>") {
        _, old, new ->
        println("$old -> $new")
    }
}

val user = User()
user.name = "Steve" // <no name> -> Steve
user.name = "Tim" // Steve -> Tim

小结

我们可以这么理解：因为 Kotlin 中类不能有字段，只有属性，val 声明的是只一个有 getter 没有 setter 的属性，var 声明的是一个既有 getter 又有 setter 的属性，可以通过：

var foo: Data
    get() { ... }
    set(value) { ... }

的方式自定义一个类属性的 getter 和 setter。如果有一批属性，他们都需要相同而复杂的 getter 和 setter，就可以通过委托属性实现，一个委托类可以帮助被委托的属性处理复杂的自定义 getter 和 setter 操作。

委托属性在 Android SharedPreferences 中的应用

Java 版本

通常，我们这么写一个 SharedPreferences 工具类：

public final class PreferencesUtil {
    private static PreferencesUtil sInstance;

    public static void init(Context context) {
        if (sInstance == null) {
            sInstance = new PreferencesUtil(context);
        }
    }

    public static PreferencesUtil getInstance() {
        if (sInstance == null) throw new RuntimeException("Uninitialized.");

        return sInstance;
    }

    private final SharedPreferences mSp;

    private PreferencesUtil(Context context) {
        mSp = PreferenceManager.getDefaultSharedPreferences(context);
    }

    public String getString(String key, String defValue) {
        return mSp.getString(key, defValue);
    }

    public void putString(String key, String value) {
        mSp.edit().putString(key, value).apply();
    }

    public int getInt(String key, int defValue) {
        return mSp.getInt(key, defValue);
    }

    public void putInt(String key, int value) {
        mSp.edit().putInt(key, value).apply();
    }

    public long getLong(String key, long defValue) {
        return mSp.getLong(key, defValue);
    }

    public void putLong(String key, long value) {
        mSp.edit().putLong(key, value).apply();
    }

    public float getFloat(String key, float defValue) {
        return mSp.getFloat(key, defValue);
    }

    public void putFloat(String key, float value) {
        mSp.edit().putFloat(key, value).apply();
    }

    public boolean getBoolean(String key, boolean defValue) {
        return mSp.getBoolean(key, defValue);
    }

    public void putBoolean(String key, boolean value) {
        mSp.edit().putBoolean(key, value).apply();
    }
}

然后这么用：

if (PreferencesUtil.getInstance().getBoolean(Constant.KEY_IS_FIRST_LAUNCH, Constant.DEF_IS_FIRST_LAUNCH)) {
    // Do something first launch, like showing Welcome.
    ...

    PreferencesUtil.getInstance().putBoolean(Constant.KEY_IS_FIRST_LAUNCH, true);
}

创建一个 PreferencesUtil 单例，在 Application 中调用 PreferencesUtil.init(context) 初始化。
代理 SharedPreferences 中的所有 getXxx()，putXxx() 方法，方便使用时不需要写 getSharedPreferences().edit().putXxx().apply() 这么长的代码。
使用时调用 PreferencesUtil.getInstance().getXxx(key, defValue) 读取，调用 PreferencesUtil.getInstance().putXxx(key, value) 写入。
写起来仍然很麻烦。每次 getInstance()，传 key，如果写入不同的 SharedPreferences 文件，还需要每次传文件名。
getXxx() 和 putXxx() 要保证 key 相同，会去字符串常量类中找，可能出错。
处理的是 SharedPreferences 文件中的同一个 key 对应的 value，用的却是两次没有关联的 util 操作。

Kotlin 委托属性版本

class PreferencesDelegate<T>(private val key: String, private val defValue: T) {
    private val sp by lazy { PreferenceManager.getDefaultSharedPreferences(AppApplication.instance) }

    @Suppress("IMPLICIT_CAST_TO_ANY", "UNCHECKED_CAST")
    operator fun getValue(thisRef: Any?, property: KProperty<*>) = with(sp) {
        when (defValue) {
            is String -> getString(key, defValue)
//            is Set<*> -> getStringSet(key, defValue as Set<String>) // Unsupported.
            is Int -> getInt(key, defValue)
            is Long -> getLong(key, defValue)
            is Float -> getFloat(key, defValue)
            is Boolean -> getBoolean(key, defValue)
            else -> throw RuntimeException("Unsupported type.")
        } as T
    }

    @SuppressLint("CommitPrefEdits")
    operator fun setValue(thisRef: Any?, property: KProperty<*>, value: T) = with(sp.edit()) {
        when (value) {
            is String -> putString(key, value)
            is Int -> putInt(key, value)
            is Long -> putLong(key, value)
            is Float -> putFloat(key, value)
            is Boolean -> putBoolean(key, value)
            else -> throw RuntimeException("Unsupported type.")
        }.apply()
    }
}

使用：

private var isFirstLaunch by PreferencesDelegate(Constant.KEY_IS_FIRST_LAUNCH, Constant.DEF_IS_FIRST_LAUNCH)

if (isFirstLaunch) {
    // Do something first launch, like showing Welcome.
    ...

    isFirstLaunch = false
}

创建一个 PreferencesDelegate 代理类，处理各个类型的 Preferences 的存取。
在使用时，创建一个代表要处理的 Preference 的对应类型的属性，使用 by Delegate 语法，用 PreferencesDelegate 类代理这个属性。
直接对变量取值就是从 SharedPreferences 文件中读取，对变量赋值即写入 SharedPreferences。
IMPLICIT_CAST_TO_ANY：这是 Kotlin 中使用 when 表达式时，当多个分支返回不同的类型时出现的 warning，表示 when 表达式的返回值类型被隐式转化成了 Any。
UNCHECKED_CAST：范型强转 warning。
CommitPrefEdits：使用 when 表达式时，静态分析无法判断 SharedPreferences.Editor 是否执行了 commit 调用。
如果委托给一个局部变量，可能出现 UNUSED_VALUE warning，即变量赋值后未被使用，但实际上委托类执行了写 SharedPreferences 操作，并不是无用赋值。

多个 SharedPreferences 文件

如果需要存取多个 SharedPreferences 文件，可以创建多个对应的委托类，继承子一个默认的 DefaultPreferencesDelegate。

open class DefaultPreferencesDelegate<T>(private val key: String, private val defValue: T) {
    /**
     * SharedPreferences file name. `<packageName>_preferences.xml`.
     */
    protected open val name: String = "${AppApplication.instance.packageName}_preferences"
    private val sp by lazy { AppApplication.instance.getSharedPreferences(name, Context.MODE_PRIVATE) }

    ...
}

class SettingsPreferencesDelegate<T>(key: String, defValue: T) : DefaultPreferencesDelegate<T>(key, defValue) {
    override val name = "settings"
}

class DataPreferencesDelegate<T>(key: String, defValue: T) : DefaultPreferencesDelegate<T>(key, defValue) {
    override val name = "data"
}

从 SharedPreferences 中移除 `key`

通过 sp.edit().remove(key).apply 移除一个 key。一个简单的实现方式：

operator fun setValue(thisRef: Any?, property: KProperty<*>, value: T?) = with(sp.edit()) {
    when (value) {
        null -> remove(key)
        is String -> putString(key, value)
        ...
    }.apply()
}

var content: String? by DataPreferencesDelegate(Constant.KEY_TODO, Constant.DEF_TODO)
content = null

这么写的不方便之处在于，这个属性可能在意义上是不可为空类型的，或者是 Int、Boolean 等类型，那么将它指定为可为空类型就不合适。如果需要更好的扩展，另写工具类支持。

读取 SharedPreferences 时指定默认值为 `null`

因为使用范型实现，并且通过 defValue 判断要存取的 SharedPreferences 的数据类型，因此这种委托写法不支持 sp.getXxx(key, defValue) 时 defValue 为 null。

Sample

最后上一段完整的 sample 代码：

// PreferencesDelegates.kt

open class DefaultPreferencesDelegate<T>(private val key: String, private val defValue: T) {
    /**
     * SharedPreferences file name.
     */
    protected open val name: String = "${AppApplication.instance.packageName}_preferences"

    private val sp by lazy { AppApplication.instance.getSharedPreferences(name, Context.MODE_PRIVATE) }

    @Suppress("IMPLICIT_CAST_TO_ANY", "UNCHECKED_CAST")
    operator fun getValue(thisRef: Any?, property: KProperty<*>) = with(sp) {
        when (defValue) {
            is String -> getString(key, defValue)
            is Int -> getInt(key, defValue)
            is Long -> getLong(key, defValue)
            is Float -> getFloat(key, defValue)
            is Boolean -> getBoolean(key, defValue)
            else -> throw RuntimeException("Unsupported type.")
        } as T
    }

    @SuppressLint("CommitPrefEdits")
    operator fun setValue(thisRef: Any?, property: KProperty<*>, value: T?) = with(sp.edit()) {
        when (value) {
            null -> remove(key)
            is String -> putString(key, value)
            is Int -> putInt(key, value)
            is Long -> putLong(key, value)
            is Float -> putFloat(key, value)
            is Boolean -> putBoolean(key, value)
            else -> throw RuntimeException("Unsupported type.")
        }.apply()
    }
}

class SettingsPreferencesDelegate<T>(key: String, defValue: T) : DefaultPreferencesDelegate<T>(key, defValue) {
    override val name = "settings"
}

class DataPreferencesDelegate<T>(key: String, defValue: T) : DefaultPreferencesDelegate<T>(key, defValue) {
    override val name = "data"
}

object PreferencesHelper {
    /**
     * Keys.
     */
    private const val KEY_IS_FIRST_LAUNCH = "is_first_launch"
    private const val KEY_TODO = "todo"

    /**
     * Default values.
     */
    private const val DEF_IS_FIRST_LAUNCH = true
    private const val DEF_TODO = "Learn Kotlin."

    var isFirstLaunch: Boolean by SettingsPreferencesDelegate(KEY_IS_FIRST_LAUNCH, DEF_IS_FIRST_LAUNCH)
    var todo: String? by DataPreferencesDelegate(KEY_TODO, DEF_TODO)
}

import kotlinx.android.synthetic.main.activity_main.todoEditText

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

        setContentView(R.layout.activity_main)

        if (PreferencesHelper.isFirstLaunch) {
            // Do something first launch, like showing Welcome.
            showWelcome()
            PreferencesHelper.isFirstLaunch = false
        }

        // Read from SharedPreferences.
        todoEditText.setText(PreferencesHelper.todo)
    }

    private fun showWelcome() {
        AlertDialog.Builder(this)
                .setMessage("Welcome!")
                .setPositiveButton("Fine", null)
                .show()
    }

    fun saveOnClick(view: View) {
        // Write to SharedPreferences.
        PreferencesHelper.todo = todoEditText.text.toString()

        Toast.makeText(this, "Save success", Toast.LENGTH_SHORT).show()
    }

    fun clearOnClick(view: View) {
        // Remove from SharedPreferences.
        PreferencesHelper.todo = null

        todoEditText.text.clear()
        Toast.makeText(this, "Clear success", Toast.LENGTH_SHORT).show()
    }
}