将APP转换成100%Kotlin总结
码字不易，转载请注明转自：http://blog.csdn.net/u011176685/article/details/52673390
简书博客：http://www.jianshu.com/users/88579080227b
题外话：国内社区逛多了，有点慢慢失去新鲜感。或许很多已经见多了.....推荐几个国外的网站,Android Weekly,Trending Java repositories on GitHub today。其实在我写的《Android优秀资源整理合集(论菜鸟到高级攻城狮)》 也提到过。有兴趣的可以了解下。逛的过程中，发现这篇文章可能大家会用到，但是由于语言问题，可能没有太大的耐心。希望对需要的同学，有所帮助。
*********************************************进入正题***********************************
这只是关于Kotlin的一部分，点击这查看第二部分，在我讨论Kotlin语言设计的地方
我已经关注Kotlin的发展有一段时间了，Kotlin是一个基于 JVM ，兼容Java的新的编程语言。随着Kotlin版本1.0.2的发布，带来的增量编译和在标准库大量减少的方法数量，我开始渴望在项目中使用它。
我是Keepsafe应用锁app的首席工程师，该app和大多android应用app都是通过java语言开发的。Java有很多现代编程语言的不足的地方，尤其是Android支持Java 7的版本。为了解决这个问题，通常是使用类库，例如为了lambdas和关闭资源使用Retrolambda，为了不可变集合和有效函数使用Guava，为了view的绑定使用ButterKnife或者为了函数式编程使用ReactiveX。但是，这些类库也有很多缺点，你依赖的每个类库给APK添加方法，Retrolambda时常会增量构建失败。
即使有这些库，Java代码也很冗余。在90年代Java的设计者认为，你的代码要经过大量的设计是个不错的主意，但今天显然是不必要的。Kotlin提供了一个经过深思熟虑的语法和广泛的标准库，消除许多存在于Java中的痛点。因此，在多天的努力中，我将整个App Lock应用程序锁定app的代码转换成Kotlin。这里是我在转换过程中的想法和总结。
Kotlin vs Java in App Lock
通过它的标准库添加的方法数量，是大家提高转换成Kotlin关注的地方。由于像support library和GMS这些类库，会提高许多app在Dex 方法数量限制 上的风险。在重写前后，我使用dexcount gradle插件来对方法分解。最终的结果是，总的方法数在proguard之后，从5491变成4987下降了10%（不包括GMS和appcompat的统计）。代码数从java的12371行变成Kotlin的8564行，减少了30%。
app从Java转成Kotlin，总的方法数减少了10%，总的代码行数减少了30%。
方法数减少的结果既是Kotlin本身是一种更加简洁的语言导致的，同时也证明很多以前在Java中使用质量不错的库将不再需要的事实。
Retrolambda
Retrolambda 为每一个添加多个方法的lambda自动生成一个匿名类。Kotlin有用到一个lambda可以无需增加任何额外的方法来内联方法。
public inline fun T.apply(block: T.() -> Unit): T {
block(); return this
} 例如，非常有用的标准库函数 应用
通过这种方式调用
myObject.apply { /* modify myObject */ }你在定义一个lambda函数调用时，没有匿名类生成，由于这个调用，没有额外的方法被添加，也没有发生内存分配。事实上，应用函数本身，就像大多数在Kotlin标准库内部关联函数，不会导致一个方法在编译代码过程中被添加。
Guava
Guava整体被具有更易于使用的额外优势的Kotlin标准库所代替。Big Guava ComparisonChain可以被kotlin.comparisons函数用一些字符代替。
// Guava
ComparisonChain.start()
.compareTrueFirst(lhs.isActive(), rhs.isActive())
.compare(lhs.lastName(), rhs.lastName())
.compare(lhs.firstName(), rhs.lastName())
.result();
//Kotlin
compareValuesBy(lhs, rhs,
{it.active},{it.lastName},{it.firstName})Guava null-safety可选的类在Kotlin里面被创建 。
// Guava
return Optional.of(value).or(defaultValue);
// Kotlin
return value ?: defaultValueGuava的lazy fields和前提条件类也被Kotlin的标准库所代替
// Guava
private Supplier lazyField = Suppliers.memoize(
() -> "value");
public String getField() {
return lazyField.get();
}
// Kotlin
val field bylazy{"value"}
// Guava
Preconditions.checkNotNull(value, "error %s", arg);
// Kotlin
checkNotNull(value){"$arg"}几乎所有的Guava的集合类都在Kotlin中存在。即便Guava所有的这些功能，整个Kotlin标准库仍单独比Guava小。
ButterKnife
ButterKnife依然被用于Kotlin中，但是Kotlin Android Extensions 提供了一种更加简洁的方法来绑定view。也存在其他的解决方案如Kotterknife和Anko，但是我发现当前通常的xml布局使用Kotlin Android Extensions是处理view最好的方式。Kotterknife比extensions需要更多的引用。Anko会添加大量的方法，而且它的DSL往往较为复杂并且比XML性能低。
RxJava
RxJava也是非常棒的，我在App Lock的很多地方使用它。但由于Java的Android上并没有对集合功能的方法，我有时会用RxJava作为替代品。
Observable.from(collection)
.filter(it -> it.isActive())
.map(it -> it.size())
.reduce((it, sum) -> it + sum)
.toBlocking().single();在Kotlin里可以被替换成：
collection.filter { it.isActive() }
.map { it.size() }
.reduce { it, sum -> it + sum }Kotlin入门
如果你已经有一定java基础，学习Kotlin很容易。你可以通过Kotlin Koans online 学习，使用reference documentation 编写。Jake Wharton也提供了很多Kotlin有用的语法功能的说明 。
关于Kotlin最好的一部分是它能够在Java和Kotlin直接相互调用。所以你并不需要你的整个代码库一次转换。我建议你最开始的时候，从一个重写的单独文件开始。IntelliJ具有自动从Java转换成Kotlin的功能，但是它经常会产生不正确的代码。因此，更好的做法是从一个草稿开始，直到你对编程语言很熟悉的时候。
一旦你具备一定基础知识后，我建议选择一些依赖现有的Java代码，并将其转化为Kotlin。像Android上面的fragment的activity的ui代码是一个很好的实践的地方。选取一个没有依赖的类，允许你只关注你的工作代码，无需担心任何接口正在发生变化。保持Kotlin的开放，使你可以快速的处理正在编译时产生的语法或者标准库相关问题。你也可以开始就选择Kotlin编写,来代替把Java转换成Kotlin。但是我发现从被转换的代码选取的不太明显的语法比试图从一张白纸弄明白更加容易。大多数情况下，自动转换是一个不错的选择，它出问题的地方通常也很容易解决。
当你正在学习Kotlin时，需要明确目的是避免项目不堪重负。如果你还没有使用像MVP或者MVVM，不用担心试图在同一时间学习。不要担心找不到可用的Kotlin库。只关注在你所知道的关于Java和Kotlin转换的知识。如果您仍然有痛点，那么你可以添加更多的库或设计模式。
你应该将你的代码库一次性替换吗？
当你在你的代码库里面提供了很多Kotlin后，你必须决定是否一次全部转换成Kotlin，或者把它变得更慢。幸运的是，Kotlin兼容Java，两者相通。你可以同时将单独的类转换，也可以让两种语言一起并存运行。
对于大的代码库，将所有的转换成一个正式版本会需要大量的工作量。在Keepsafe主要的app里面，截止至写这篇文章时，大约15%的代码是Kotlin.在该应用程序，如果我们不得不明显更改一个Java类，我们通常会将类转换为Kotlin，我们也正在为此努力。这让我们可以稳定的提高代码库，而不会在新特性上减慢我们的工作。
但是，如果你的项目足够小，你可以转换到100％Kotlin，这是值得考虑的。当你不必维护Java的兼容性，可以简化您内部API，并删除了很多我前面谈到的库。您可以将静态工具类转换成扩展功能，并采取Kotlin更强的类型推断的优势。
最后的思考
Kotlin是一种伟大的编程语言，是对Java的巨大改善。将App Lock转换成Kotlin,让app更快，更小，相比之前更少的bug。Kotlin语言现在已经足够成熟，不管在任何一种工具，语言，或标准库，没有重要的功能缺失。如果你想知道现在是否尝试Kotlin或者你应该等待一段时间，我可以告诉你，现在Kotlin准备在全职生产使用。如果你使用Android或其他Java环境都是Kotlin可能的工作的地方，你应该为自己尝试一下Kotlin。
........................................
这是在Kotlin系列第一篇文章。关注Keepsafe Engineering 获取以后更多文章推送。你对使用Kotlin感兴趣吗？看一看Keepsafe Kotlin空缺的工作。
看看翻译这篇文章的响应，如果不多的话，后面作者还有两篇文章，大家可以自行看下。如果不错的话，我后面再抽时间把另外两篇也翻译下。翻译也是体力活，，我先去喝杯水休息下。
译文：https://medium.com/keepsafe-engineering/lessons-from-converting-an-app-to-100-kotlin-68984a05dcb6#.eih952jr4
欢迎关注微信公众号，专注于Android深度文章和移动前沿技术分享
