在之前的《详解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功能很好用，但是有时候有些情况下，就显得不是那么快捷和便利。

Kotlin是一门让人感到很舒服的语言，相比Java来说，它更加简洁，省去了琐琐碎碎的语法工作，同时了提供了类似Lambda,String template,Null Safe Operator等特性。让开发者用起来得心应手。

目前绝大多数的Android项目都是基于Grale了，因为Gradle确实给我们带来了很多便利，然而，在使用了Gradle后，最大的不满就是编译起来太慢了。解决慢的问题无非有两种方法

• 提升硬件配置，选择CPU和内存和硬盘等更优的硬件
• 在软件方面，减少不必要的耗时，充分利用现有机器的性能。

本文的主要经验围绕着如何减少不必要的耗时操作和如何充分利用机器性能展开。

是什么

• 静态的Java和Android bug分析利器
• 由Google出品
• 由error-prone接管compiler,在代码编译时进行检查，并抛出错误中断执行
• 在抛出错误的同时给出具体的原因和相应方案
• error-prone github 地址为 https://github.com/google/error-prone

自从Android中引入RecyclerView之后，它就逐步的替换掉了ListView和GridView。本文很简单，行文目的是记录和备忘。如果能帮到你，那再好不过了。

在Android中，性能优化是我们持之不懈的工作。这其中，在主线程执行耗时的任务，可能会导致界面卡顿，甚至是ANR（程序未响应）。当然Android提供了很多优秀的工具，比如StrictMode，Method Tracing等，便于我们检测问题。

这里，本文将介绍一个更加简单有效的方法。相比StrictMode来说更加便于发现问题，相比Method Tracing来说更加容易操作。