应用Kotlin之后，涉及到注解的注解处理器依赖也会由annotationProcessor替换成kapt，和最初应用Kotlin一样，总会让人一种感觉，一番应用Kotlin和Kapt之后，编译耗时更长了，不过好在Kotlin和Google 在这一方面做了很多的优化和改进，本文将简单介绍一些配置，来实现项目编译关于kapt这方面的加速。

在很早的时候，小黑屋就介绍过如何研究Kotlin，其中涉及到了查看字节码和反编译成Java代码的方式，相信很多人研究过的人，都会或多或少遇到过Intrinsics.checkParameterIsNotNull这样或者类似的代码。

这之前的文章中，我们介绍过如果通过Kotlin编译器参数实现将所有的warnings按照errors对待，主要的实现方法是这样

1
2
3
4

//Code to be added
kotlinOptions {
    allWarningsAsErrors = true
}

我们在编程中，出于复用和高效的目的，我们使用到了泛型。但是泛型在JVM底层采取了类型擦除的实现机制，Kotlin也是这样。然后这也带来了一些问题和对应的解决方案。这里我们介绍一个reified用法，来实现更好的处理泛型。

经常用终端的人都知道，终端命令有很多选项可以指定，这里我们以相关的kotlinc为例，我们可以在终端这样指定选项

1
2
3
4
5

kotlinc -Werror ./app/src/main/java/com/example/compileroptionssample/Simple.kt
error: warnings found and -Werror specified
app/src/main/java/com/example/compileroptionssample/Simple.kt:4:19: warning: unnecessary safe call on a non-null receiver of type String
    println(string?.toString())
                  ^

众所周知，Kotlin通过语法糖的形式实现了很多便捷和高效的方法，因此研究Kotlin代码通常是需要研究字节码或者反编译后的java文件。

比如这样的代码

1
2
3

fun String.toConsole() {
    println(this)
}

之前遇到过这样的问题

• 从微信官网下载微信Mac版安装
• 后来App Store提示有新的微信更新
• 但是每次打开都是这样的画面，提示上一个账户（主动更换过账户）的信息
• 而且上一个账户基本弃用，但是也无法使用当前账户更新

最近接触了一些面试者，在面试过程中有涉及到内存泄露的问题，其中有不少人回答说，如果文件打开后，没有关闭会导致内存泄露。当被继续追问，为什么会导致内存泄露时，大部分人都没有回答出来。

本文将具体讲一讲 文件(流)未关闭与内存泄露的关系。

最近由于机缘巧合，结合最近工作中遇到的一些问题，深入了解了文件描述符(File Descriptor，简称FD，以下使用 FD 称谓)。预计会有两到三篇关于 FD 的文章陆续出来。首篇也就是这篇，作为基础篇，介绍一些关于通用 FD 的内容知识。

目前而言，几乎所有的编程语言都是使用英文来表示，在英文中，使用缩写很普遍，比如URL(Uniform Resource Locator)能够很简单高效地向他人阐述要表达的概念。

然后，在现实的开发过程中，缩写有时候会被滥用，甚至是脱离了其高效传递信息的意思。

最近和华章搞了一个小合作，把最新出的一些关于Android的书拿出来免费送给大家，如下有四本书，涉及了Kotlin，Android ART,埋点和Flutter。

参与方式：很简单，微信扫描或者长按识别书籍下面的抽奖小程序，然后坐等开奖就可以了。

Kotlin 以其简洁实用的语法，赢得了很多Java 开发者，尤其是 Android 开发者的喜爱与应用。然而，虽然我们使用 Kotlin 进行编码，可能并没有书写出地道的 Kotlin 代码，亦或者是遵照写Java的思维，用Kotlin的语法 来编码。

本文将通过多出代码示例，分为Do not（不建议）和Do（建议）两部分，分别代表着不太好的实现和推荐的实现方式，来展示地道的 Kotlin 编码方式。

本文系CSDN约稿，具体转载事宜请沟通CSDN。

作者 : 段建华
责编 : 唐小引
出品 : CSDN（ID：CSDNnews）

【CSDN 编者按】近些年来，编程语言流行度的变化其实不大，在 TIOBE 编程语言排行榜上，Java、C、C++ 固若金山，也就只有 Python 会攻城略地成为第四。在这 TOP3 之中，Java 以其非常优秀的普适性，可以用于前后端开发，再加上非常成熟的 JVM 虚拟机以及整个 Java 生态，让 Java 这个老大哥常年雄踞 TOP1，在 CSDN 的 Java 相关的文章之中，常有用户留言调侃“Java：你们随便争，反正我 Java 是第一”也可窥见一二。

而从两年前 Google 正式宣布 Kotlin 成为 Android 官方支持的语言开始，对于“Kotlin 即将取代 Java”的讨论便甚嚣尘上从未停歇。彼时，Kotlin 这个诞生于 2011 年的小伙子让已经使用了 Java 多年的 Android 开发者们有了点不可言说的滋味。同时，在过去的数年之间，伴随着 Oracle 与 Google 纷争不止，业界“Oracle 要玩死 Java”之声亦是不绝于耳。

最近“从开源到跑路”的事件逐渐增多，给涉事企业造成了不小的损失。因而相关的防范工作显得愈发重要。

客观而言，人为手动的防范显得原始和笨拙，好在git提供了相关的钩子方法，为我们这里的防范提供了可行性。

这里我们以git push 命令对应的pre-push钩子为例，因为想要开源出去，这个命令通常是必须执行的。

在Kotlin中，有很多很酷很实用的特性，比如Lambda和高阶函数，利用这些特性，我们可以更加快速的实现开发，提升效率。

比如我们实现一个捕获Throwable，安全执行部分代码的高阶函数

1
2
3
4
5
6
7
8
9
10
11
12
13

fun safeRun(runnable: () -> Unit) {
    try {
        runnable()
    } catch (t: Throwable) {
        t.printStackTrace()
    }
}

fun testNormalSafeRun() {
    safeRun {
        System.out.println("testNormalSafeRun")
    }
}

读到这个标题，多数人会有疑惑，什么是货物崇拜编程，其实最根本的问题可能是什么是货物崇拜。想要了解这些就不得不说货物崇拜(Cargo Cults，又译货物运动)的起源

第二次世界大战太平洋战争时，美军于塔纳岛建立一临时基地。当时岛上的原住民看见美军于“大铁船”（军舰）内出来，皆觉得十分惊讶；他们也看到，有一些“大铁鸟”（军用飞机）运送穿着美军军服的人及许多物资。这些原住民看见这种情况均感到很惊讶，并觉得这些“大铁船”及“大铁鸟”十分厉害。加上美军也提供部分物资给原住民，而这些物资对原住民来说十分有用，结果这些原住民将美军当作神。

第二次世界大战结束后，美军离开塔纳岛，只留下一些美军军服及一些货物。塔纳岛原住民便认为这些货物具有神奇力量，又相信“神”（美军）他日会回来并带来更多货物，使他们展开一个幸福新时代。但是美军当然再也没有回来塔纳岛，因此这些原住民便自己发展出一套敬拜仪式，崇拜美军军服及货物；表现形式是原住民会穿着美军军服、升起美国国旗，图腾则是木刻的飞机。

作为程序员，我们总是和方法打交道，不知不觉都会接触Long method(方法体较长的方法)，不论是自己写的还是他人写的，而Long method(长方法)往往是问题的体现，代表着代码有一种坏的味道，也意味着需要对这段代码进行重构处理。

使用Retrofit配合GsonConverter，我们能很好地将网络响应内容转换成对应的对象。比如像下面这样。

最近在研究一下class字节码的东西，尝试将class文件反编译成java文件。尝试了很多的工具，比如JD-GUI及其插件以及各种在线反编译，始终感觉不够酷，毕竟我是一个比较依赖终端的人，所以尝试找一些能否在终端可以实现反编译的工具。

问题场景 在项目的App中，有一个ViewPager，它内部包含了WebView，而内部的webview加载了一个可以滑动的网页。

当我们在网页滑动的时候，会直接切换到下一个viewpager的页面，而不是优先响应webview的滑动。

之前的文章JVM 如何处理未捕获异常 我们介绍了JVM如何处理未捕获异常，今天我们研究一个更加有意思的问题，就是在JVM中如果发生了未捕获异常，会导致JVM进程退出么。

关于什么是未捕获异常，我们在之前的文章已经介绍过，这里不再赘述，如欲了解，请阅读JVM 如何处理未捕获异常

最近很多同事反馈使用Charles抓包出现了很多unknown的问题，现象如下图

查看右侧的原因，给出的结果是这样的

这里将讲解如何解决这个问题，但是开始阅读之前，请确认符合如下的条件

• 本文仅适用于Android 7及之后设备
• 待抓包的应用设置了targetSDK 为24及其以上
• 已经配置好了charles的证书

好的，开始了。

继之前的文章 详解JVM如何处理异常，今天再次发布一篇比较关联的文章，如题目可知，今天聊一聊在JVM中线程遇到未捕获异常的问题，其中涉及到线程如何处理未捕获异常和一些内容介绍。

在之前的《详解JVM如何处理异常》提到了守护线程，当时没有详细解释，所以打算放到今天来解释说明一下JVM守护线程的内容。

特点

• 通常由JVM启动
• 运行在后台处理任务，比如垃圾回收等
• 用户启动线程执行结束或者JVM结束时，会等待所有的非守护线程执行结束，但是不会因为守护线程的存在而影响关闭。

无论你是使用何种编程语言，在日常的开发过程中，都会不可避免的要处理异常。今天本文将尝试讲解一些JVM如何处理异常问题，希望能够讲清楚这个内部的机制，如果对大家有所启发和帮助，则甚好。

当异常不仅仅是异常

我们在标题中提到了异常，然而这里指的异常并不是单纯的Exception，而是更为宽泛的Throwable。只是我们工作中习以为常的将它们（错误地）这样称谓。

关于Exception和Throwable的关系简单描述一下

• Exception属于Throwable的子类，Throwable的另一个重要的子类是Error
• throw可以抛出的都是Throwable和其子类，catch可捕获的也是Throwable和其子类。