很多时候，我们需要进行多个文件的查找并替换，虽然IDE有这样的可视化功能，但是偏爱终端的人还是想要尝试用脚本实现一把。如下是一个简单的脚本来实现多文件的查找替换处理。

OkHttp是可以说是Android开发中，每个项目都必需依赖的网络库，我们可以很便捷高效的处理网络请求，极大的提升了编码效率。但是有时候，我们使用OkHttp也会遇到这样的问题

崩溃的stacktrace

1
2
3
4
5
6
7
8
9
10
11

 E AndroidRuntime: FATAL EXCEPTION: OkHttp Dispatcher
 E AndroidRuntime: Process: com.example.okhttpexceptionsample, PID: 13564
 E AndroidRuntime: java.lang.NullPointerException: blablabla
 E AndroidRuntime:    at com.example.okhttpexceptionsample.MainActivity$createNPEInterceptor$1.intercept(MainActivity.kt:61)
 E AndroidRuntime:    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
 E AndroidRuntime:    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
 E AndroidRuntime:    at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
 E AndroidRuntime:    at okhttp3.RealCall$AsyncCall.run(RealCall.kt:136)
 E AndroidRuntime:    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
 E AndroidRuntime:    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
 E AndroidRuntime:    at java.lang.Thread.run(Thread.java:784)

很多时候，我们需要根据包名来查找一些依赖所在的jar包，比如我们想要查找com.alipay这个包及其文件所在的jar包。

最笨拙的办法可能是这样

• 一个一个jar包查找，再利用一些工具来验证。

其实，大可不必，我们需要简单实用如下的脚本就能解决这个问题。

在日常的开发过程中，我们利用grep可以方便快捷的查找感兴趣的日志内容，极大地提升了开发和排错效率。但是有时候，我们也会遇到一些问题，比如。

接触过Kotlin之后，我们会利用其扩展方法特性创建很多便捷的方法来实现更好更快的编码。比如我们对于RxJava进行一些简单的扩展方法实现。

JvmName注解是Kotlin提供的一个可以变更编译器输出的注解，这里简单的介绍一下其使用规则。

应用在文件上

未应用@JvmName

1
2
3
4
5
6
7
8

package com.example.jvmannotationsample

import android.net.Uri


fun String.toUri(): Uri {
    return Uri.parse(this)
}

相比 Java，使用 Kotlin 编程的时候，我们和kotlin编译器的交互行为会更多一些，比如我们可以通过inline来控制字节码的输出结果，使用注解也可以修改编译输出的class文件。

这里介绍一个和kotlin编译器更加好玩的特性，contract。可以理解成中文里面的契约。

应用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，我们能很好地将网络响应内容转换成对应的对象。比如像下面这样。