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

特点

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

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

当异常不仅仅是异常

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

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

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

在Java中，当我们定义一个类的时候，总会出现一些变量是必须要填写的，而另一些是可选的。比如像下面这样，我们定一个Person类，其中name是必须填写的，而性别sex和isChinese可选，如果不填写就直接使用默认值。

在Kotlin中，定义方法很有趣，不仅仅因为方法的关键字是fun(function前几个字符)，还是因为你会惊奇的发现，它允许我们在方法中定义方法。如下

1
2
3
4
5
6
7
8

fun methodA() {
   fun methodB() {

   }
   methodB() //valid
}

//methodB() invalid

在Java或者是Android编程中，我们一般都会使用到Map，比如HashMap这样的具体实现。更高级一点，我们可能会使用WeakHashMap。

WeakHashMap其实和HashMap大多数行为是一样的，只是WeakHashMap不会阻止GC回收key对象（不是value），那么WeakHashMap是怎么做到的呢，这就是我们研究的主要问题。

我们在编程中，无时无刻地都在于方法打交道，而在方法中，我们很难不使用局部变量，比如我们有下面的这样一段很简单的代码

1
2
3
4

public void dump() {
    String localName;
    System.out.println("dump localName=" + localName);
}

没有代码，就没有bug。程序员在编码时，总会比不避免的出现bug。倒不是因为我们热爱制造bug，创造机会和测试妹子频繁沟通。而是现实情况很复杂，存在着很多不确定性。尤其是那些崩溃从stacktrace上来看，完全想象不到和项目代码之间的直接联系。

用了一年宽带马上就要到期了，去联通营业厅咨询了一下，发现联通已经悄悄的把我的100M免费升级成了300M(做好事为什么不告诉我一声)。心中划过一丝窃喜，但是随后脑海中抛出了一个疑问，都升到了300M了，怎么丝毫没有感觉到速度提升呢？

我们在编程中的函数或者是方法，大多数都是有参数的。参数对于方法来说是很重要的输入数据，传入的参数值的合法性影响着方法的稳定性，严重时甚至可能导致崩溃问题的出现。

正所谓，要想没有bug，就一行代码也不写。App到了用户的手里，肯定是崩溃越少越好。Android中的崩溃处理和iOS不太一样，iOS崩溃通常是闪退，而安卓会出现如下的蹩脚的对话框

当你的用户看到类似这样的崩溃对话框时，心中得到“这届程序员不行啊”的感慨也不足为奇。

一直以来我都有强迫症，尤其是毕业工作后，明显地感觉更加严重了。经常反复确认水龙头有没有关，锁门后下楼梯，往往又要上来检查一下是否真的锁上。总是担心天然气气有没有关紧。如此种种，每一天在出门离家的时候都是最痛苦的时段。

在Android中，我们对于View进行模拟点击事件，很容易，比如调用View.performClick即可。

但是有些时候，我们想要更加精细的点击，比如View的某一区域或者某一点进行点击。比如下面的例子。

2017年 Kotlin 被 Google 钦定为 Android 开发官方语言之一后，便如火如荼。很多团队开始应用了Kotlin，可谓是收益良多，可是也有一些问题，一个比较明显的就是Kotlin应用后编译速度会比较慢。这种感觉就像我们从Eclipse迁移到Android Studio变慢差不多。本文将尝试介绍一些方法来改善这一问题。

关于项目编译慢有很多原因，在Android项目中，通常会和Kotlin和Gradle有关系。首先我们通过一组图就能发现这其中的问题。其中

• 红色代表Java,青色代表Kotlin
• X轴代表编译次数数据，Y轴达标消耗的时间
• Java的项目和Kotlin的项目实现功能一致，无其他额外差别

一直以来技术小黑屋的博客都运行良好，总以为一个全部静态的博客不会导致被黑。直到最近才着实地体验了一次被黑的滋味。仅以此文记录一下，便于给同样问题的人一些帮助。

大概是周三（2018年1月17号）的时候，有人反馈，访问我的网站，会跳转到支付宝。当然还奇怪，调到支付宝有个甚用，后来使用手机上的浏览器才发现。这个跳转回自动的打开支付宝然后领取红包。又是一起为了支付宝红包的行为。以前听说过用有人用基站发短信领取，没想到居然这么快居然和我扯上关系了。

在我们尝试使用Kotlin作为开发语言的时候，应该会想到在Kotlin中如何定义一个常量，就像Java中这样的代码一样

今天我将给大家分享一下我学习Android的一些方法和想法，分享中并不局限于Android哪一块怎么学习。而是一个总体的，普适性的学习套路和方法。希望可以帮助大家解决一些问题。

注意本文为知乎Live底稿，知识点相对分散，后面部分包含了一些听众提出的问题，但是不影响总体的阅读和理解。

在编程中，我们都应该接触到设计模式，无论是从时间总结，亦或者是从书上习得后尝试使用。这其中单例模式，是我们编程过程中很常见，也很简单的一种设计模式。我曾经写过一篇比较通用的关于该模式的文章，即单例这种设计模式。

目前，随着Google钦定Kotlin为Android 开发官方语言，Kotlin的学习热潮也应声而起。本文尝试讲解单例模式在Kotlin的具体实现和应用。希望能够对大家学习使用Kotlin有所帮助。

Google IO 2017宣布了 Kotlin 会成为 Android 官方开发语言。一时间朋友圈和Android圈被各种刷屏。当然我也顺势而为发布了一篇的文章《为什么我要改用Kotlin 》，着实狠狠地蹭了一波热度（尽管这样会被鄙视）。眼下Android圈已经躁动了，甚至严重到如果对Kotlin视而不见就显得自己不像一个合格的Android程序员。

本文尝试从一个客观全面一点儿的角度来看待这件事情，尽力为大家提供一个比较理性的观点供参考。

写在前面的话，作为一个不熬夜的人，一觉醒来发现Kotlin成为了Android的官方语言，可谓是大喜过望。为了趁热打铁，我决定提前三天放出原定本周日Release的文章。希望能及时让大家了解一下Kotlin。

相信很多开发人员，尤其是Android开发者都会或多或少听说过Kotlin，当然如果没有听过或者不熟悉也没有关系。因为本篇文章以及博客后期的内容会涉及到很多关于Kotlin的知识分享。

在写这篇文章前的一个多月，Flipboard中国的Android项目确定了正式将Kotlin作为项目开发语言，这就意味着新增的代码文件将以Kotlin代码格式出现，而且同时旧的Java代码也将会陆陆续续翻译成Kotlin代码。在使用Kotlin的这段时间，被它的简洁，高效，快捷等等特点震撼，所以有必要写一篇文章来谈一谈Kotlin的特性，如若能取得推广Kotlin的效果则倍感欣慰。

在应用开发中，我们常常会进行日志打印或者debug调试，以此来分析运行时的一些信息，便于发现bug和问题。Android Studio的Debug功能很好用，但是有时候有些情况下，就显得不是那么快捷和便利。