那些年写Kotlin遇到的各种坑，您需要收藏啦

写在最前

    上一篇《一场Google IO 就让kotlin上了热搜 你怎么看？》已经介绍到了的，我们项目已经使用两年多的Kotlin了的。那么任何一门新语言在没有被官方认可之前（当然经验告诉我就算认可也难免汤坑），总是会遇到各种坑爹的问题。我想这也是为什么Kotlin早在2011年就已经问世了的，而当昨天IO大会，才会大伙所知，当然紧接着就是井喷似得席卷整个网络。

言归正传 那么项目中会遇到了哪些坑呢？

一：IDE Convert 懒惰带来的一场灾难 ，东西虽好可不要贪杯哦

Java一键convert为Kotlin

      刚上手Kotlin的时候，Android studio 插件提供了一键 convert Java File to Kotlin File 的功能，所以有时候看到老的Java代码，可能就一键转了Kotlin，然后接着写新的需求，或者某一个Java方法需要写入到Kotlin class中的时候，IDE都会帮你做转换的工作。

     But. 方便，懒惰带来的是一场灾难。

     由于Kotlin可选性，导致转换过程中IDE竟然直接给强制转换了的（a!!.value），那么那个数据可能是为null的，等上线后，某些场景下数据不正常时就会crash。

     另一方面，楼主之前插件某个版本也发现，如果原有Java类中有有 Runnable, 那么使用一键convert，IDE直接 crash 重启。

二： DexGuard 混淆 crash （NoSuchMethodError）

    我们项目采用的是dexguard来加固混淆,面临到第一个头疼的问题是服务器数据返回问题。

val drawable = imageView?.drawable ?: ColorDrawable(Color.LTGRAY)

transitionDrawable = TransitionDrawable(arrayOf(drawable, ColorDrawable()))

这段代码在没有混淆之前是ok的，但混淆之后直接crash。当时的推断是多个“ ？” dexguard在混淆过程中导致编码错误crash。解决的方案是：

if(imageView == null) return

val drawable = imageView.drawable ?: ColorDrawable(Color.LTGRAY)

三：调试的坑 让我再次生无可恋

  这一个坑分两大部分。一类是调试library，一类是正常debug调试主工程。

   先说下调试主工程的代码吧，楼主开发过程中无数次遇到的问题是，当你兴高采烈的设置断点debug调试。IDE右下角告诉你。

Kotlin plugin crash

然后。。。大多数情况下，我只是想看看服务器下发的数据是否正常，因为服务器下发的数据都是在异步的callback中回调回来的，此时你选择一个变量去参考数据，IDE会告诉你一个异常，无法查看这个数据。。。泪奔。。。

    在谈谈library调试，这里指的的是调试代码是Kotlin来写的library，此时所有的文件都直接变成了这个样子：

哭吧Kotlin library

 sorry 你无法设置断点去调试。当时楼主也是很无奈的退步，在debug过程中采用源码依赖：

调试library

四：没有三目运算

   Java中，我们随便都可以这么来写：

String content = contentStringBuilder.toString().length() >=140? contentStringBuilder.toString().substring(0,139) : contentStringBuilder.toString();

   But, 要say sorry啦，Kotlin中没有这样的语法支持了的。只能if else了的：

val a = if(some) valueA else valueB

  But 当时我们以为，这么写太蛋疼了的，就自行写了个function：

select

   那么在使用过程中就可以类似Java的三目运算，写起来一样顺畅, 用起来丝滑的不得了。

val a = select(some,valueA,valueB)

  But，直到有一天爆出来一条 java.lang.IndexOutOfBoundsException, 惊讶啊。为什么不科学啊，不可能走到另外一个value的啊。但冷静下来回顾上面写的三目运算方法，不难看出来原因，因为两个value都是当参数传入的，那么传参过程中已经进行了运算了的。。。FUCK. 我们不放弃，改造了一版算是解决了这个头疼的问题啦：

传入block

五：其他坑

1.reified 很神奇很好用的，but say sorry, java无法调用Kotlin写的reified function。所以建议都用Kotlin吧，毕竟已经成为第一语言了的现在。

2.可选性，真的是就是一个“？”  ，并不像其他语言有一个具体的类型optional，所以有的时候我也很无奈，解决方案Jake Wharton大神无奈的引入了第三方支持，具体链接可以看这里 An Optional’s place in Kotlin

3.extension 我一开始没有看具体文档的时候，最为开心的一个关键字，可以用来扩展各种想要的方法，加上操作符重载，比如不在使用坑爹的findviewbyid，犀利的DSL支持。but say no, 并不是和swift一样的概念啦，如果大伙感兴趣我抽空讲讲swift vs kotlin,带你一次性掌握两个语言。

4.可变参数 vararg vars: T 传递过程中注意要使用*vars

5. Dexguard 混淆：

  -keepattributesEnclosingMethod

写在最后

  上一篇文章《一场Google IO 就让kotlin上了热搜 你怎么看？》在第二个环节中已经提到，现在Kotlin在我们项目中表现的非常稳定，当然这是必然的，否则怎么对得起Kotlin本身的特性呢？

 以上回忆了一些坑，只是让大家少走弯路，希望能给大家带来一丝丝帮助。大胆的去拥抱Kotlin吧，我们已经躺过来了的。相信你也可以的。加上现在大佬Google都出面来支持了的，不会像当初的我们要在Kotlin论坛中提问才能解决问题。。。现在的我们是幸福的，不在孤军奋战了的！！！

   BTW~  周五愉快~。

如果您愿意听我聊技术，可以关注我的个人公众号SKMacTalk：

SKMacTalk