本文将介绍如何使用 Kotlin 的高阶函数，如sumBy, reduce, fold, map，filter，forEach 等，来应对常见的集合数据处理场景。不了解高阶函数的同学可以先看下之前的文章。

遍历求和 sumBy

场景：输入一个账户列表List，求这些账户的财产总和sum。

一般来说 Java 可以这样写：

public int getAccountsSum(List accounts) {
    int sum = 0;
    for (Account a: accounts) {
        sum += a.value;
    }
    return sum;
}

Kotlin 可以使用高阶函数 sumBy：

val sum = accounts.sumBy { it.value }

那么sumBy做了什么呢？点击源码可以看到，其实它做的事情和上面 Java 实现的getAccountsSum是一样的，只是增加的值是通过我们传入的 lambda 来计算，而不是写死的Account.value。这种通过传入函数来完成函数功能的函数，被称为高阶函数，高阶函数也因此具有很高的通用性和复用效率。

不仅传入函数作为参数的函数被称为高阶函数，返回值为函数的函数也同样被称为高阶函数。

遍历求值 reduce

sumBy有一点不好，他只能求和，而且只接受Int和Double两种类型的值（sumBy：不然我起这个名字干嘛？）。如果我们要得到一个更复杂的逻辑的结果呢？

场景：输入一个列表List，返回它们全部相乘的结果。

Java：

public int getResult(List values) {
    int result = 0;
    for (Account a: accounts) {
        result *= values;
    }
    return result;
}

Kotlin 我们可以使用reduce：

val result = values.reduce { acc, v -> acc * v }

reduce 的逻辑是：将初始值acc设置为集合的第一个值，然后从第二个值开始，依次执行acc = lambda(acc, v)，遍历完后返回acc。**reduce不仅限做加法运算，它比sumBy具有更广的通用性。

那如果reduce可以代替sumBy，为什么还需要sumBy？——因为它写起来更简单呀！

如果集合为空，reduce会抛出 UnsupportedOperationException(“Empty collection can’t be reduced.”)

更通用的遍历求值 fold

细心的同学已经发现了，sumBy的场景和reduce的场景用的是不同的数据结构。因为acc会被初始化为集合的第一个元素，所以reduce函数的输出也被限制为集合的范型类型。也就是说，sumBy的场景无法用reduce代替。

那 Kotlin 有没有能指定acc类型的高阶函数？有的，它叫fold。

我们再回到sumBy的场景：输入一个账户列表List，求这些账户的财产总和sum：

val result = accounts.fold(0) { acc, v -> acc + v.value }

fold比reduce多了一个参数——初始值，用来赋值给acc。得益于范型，我们可以通过这个办法来指定acc的类型。这样一来，fold可以完美替代sumBy的场景。而相比fold，sumBy更专用，表意更清晰，写起来也更简洁。

fold还有另一点好：因为acc由传入参数初始化，所以没有集合不能为空的限制。所以绝大部分情况下，我都建议使用fold来代替reduce。

JavaScript 的 reduce 函数就是 Kotlin 的 fold 函数。u1s1，Kotlin 的 reduce 函数挺危险的，还有类型限制，不建议使用。

过滤集合 filter

场景：输入一个账户列表List，返回资产小于 100 的账户：

Java：

public List getPoorAccounts(List accounts) {
    List qbAccounts = new ArrayList<>(); // 想起虾米音乐的 穷逼 VIP 了
    for (Account a: accounts) {
        if (a.value < 100) {
            qbAccounts.add(a);
        }
    }
    return qbAccounts;
}

Kotlin 可以使用filter函数：

val qbAccounts = accounts.filter { it.value < 100 }

filter的逻辑是，新建一个空的 ArrayList()，然后把 lambda 返回值为 true 的元素加入到这个列表里。

列表生成列表 map

场景：输入一个账户列表List，找到所有资产大于 10000 的账户，封装成 VIP 账户返回：

Java：

public List getVipAccounts(List accounts) {
    List vipAccounts = new ArrayList<>();
    for (Account a: accounts) {
        if (a.value >= 10000) {
            vipAccounts.add(new VipAccount(a));
        }
    }
    return vipAccounts;
}

Kotlin 可以通过filter函数加map函数完成：

val vipAccounts = accounts
        .filter { it.value >= 10000 }
        .map { VipAccount(it) }

第一步我们用filter函数筛选出资产大于 10000 的账户，然后用map函数将过滤后的每一个账户转换为VipAccount。map的逻辑也很简单，它回返回一个和调用者大小相同的列表，具体的元素值为 lambda 的执行结果。

实在不适合，就用 forEach 吧

如果遇到了已知高阶函数都不适合的场景，不妨试试用forEach代替传统的 for 循环。为什么？因为写起来稍微简单一点。。

accounts.forEach {
    println("account: $it")
}

什么？你还想要 index下标？

accounts.forEachIndexed { index, account ->
    println("index: $index")
    println("account: $account")
}

不仅forEach有下标版本forEachIndexed，几乎所有高阶函数都有对应的 Indexed 版本。

Kotlin 官方提供了数十个高阶函数，但其实掌握了以上几个高阶函数，基本可以 cover 所有场景了。其他的只是写的简洁还是写的复杂一点的区别。而且你还有另一条路可以走：自己写一个特定的高阶函数。

担心性能？

大家可能会担心，如此频繁的声明 lambda，会不会使得类的数量大量膨胀？其实官方提供的高阶函数，都是用inline关键字修饰的。这意味着不仅高阶函数的调用最终会被函数的实际代码代替，而且声明的 lambda 也会被解析成具体的代码，而不是方法调用。所以Kotlin 高阶函数用 inline 关键字修饰，所以 lambda 不会生成新的 jvm class。而我们在声明自己的高阶函数时，也应该用inline关键字修饰，防止类数量膨胀。

大家可能担心的另一点，像map，filter这样返回列表的高阶函数，每一次操作都会生成一个列表，这会不会增加垃圾回收的压力？答案是会的。但如果数据量不是万级别的，操作频率不是毫秒级别的，对性能的影响实在小之又小，特别是在移动端的场景更是难以遇到。但我们还是要了解高阶函数对性能开销，在对性能要求高的位置避免对象申请（如UI绘制的回调）。

Java 有高阶函数吗？

Java 也类似高阶函数的能力，如 Collections.sort 这种允许自定义排序的方法，和 Java 8 的 steam API。但因为 Java 没有 inline 无法有效的优化 lambda，且 Java 的 lambda 没有完整的闭包特性，无法修改外部变量。还有一些语法的原因，Java 的高阶函数使用起来相对没有那么舒服。

版权所有，转载请注明出处：
https://sickworm.com/?p=1833