前言

工作中遇到一个崩溃，将无关逻辑去掉，最后的崩溃部分是：

1if (sparseArray.get(1) != null) {  
2  Log.i("SparseArray", sparseArray.get(1).toString());  
3}

抛出的异常是空指针：java.lang.NullPointerException，其实根据经验也知道是线程安全问题，但是排查的过程中却越来越觉得我们的应用场景中不应该出现 null 的存在。

前言

上一篇讲了在 2022 年底到 2023 年初一台性能还不错并且兼顾了兼容性的 NAS 硬件选型思路，算下来价格并不便宜，但是从兼容性和零件可替换性上还是不错的。本篇更多的是关心整体系统基建而非应用层软件。如果对 Linux 不够熟悉，直接无脑 Windows Server 什么都不用折腾。

前言

之前使用的是多年前很火的威联通 453Bmini，2000 块钱 4 盘位的成品 NAS，性价比很高，开箱即用。虽然很多人认为可用性不如群晖，但是我个人的使用不喜欢依赖某一个品牌的生态，大多是开源组装的，所以对我来说威联通和群晖没什么本质区别。慢慢的用途越来越多，这款 NAS 选用的 J3455 性能低下和硬盘无法休眠实在太吵成了我的困扰，特别在理清了我本身不需要任何成品 NAS 生态的需求后，自己组装一台 NAS 成了唯一选择。

子线程更新 UI 异常设计理念及简单源码解析

初学者可能会犯在子线程更新 UI 的错误，例如：

1thread { imageView.setBackgroundColor(Color.RED) }

一旦运行，应用会直接崩溃并抛出异常，这也是我们 Android 开发的一条铁律：在子线程中不能更新 UI。

那么为什么 Android 不让子线程更新 UI 呢？原因在于现在屏幕刷新率最低是 60Hz，意味着最多每 16ms 就会刷新一次屏幕，所以 UI 更新要尽可能快速，否则会丢帧导致卡顿。那么 UI 更新操作就不能加锁，频繁的加锁释放锁可能会延长 UI 渲染时间，但是不加锁如果允许子线程更新 UI 会导致多个线程对 UI 同时更新，造成线程不安全而导致 UI 最终效果无法想象，所以 Android 直接限制了子线程更新 UI，实际上不只是 Android 有这种限制，常见的 UI 框架基本都是单线程模型。

前言

有时 Github 网络的不稳定性实在令人头痛，push 总是失败，而且需要把主仓库放在 Github 而非 Gitee 等国内平台，虽然可以通过配置代理进行，不过也可以曲线救国，选择通过 push 到国内代码管理平台，然后通过 CI 平台自动推送到 Github。

阿里云效综合了代码仓库和 CI 平台，私有代码仓库免费，免费构建时间足够支撑我们这点小事，并且执行环境可以选香港保证了能 push 到 GitHub，所以选择了阿里云效。

理论上所有能通过 git push 触发 CI（CI 的基本操作了）并且基础环境存在 git 而且网络良好的平台都可以按照本文方法进行，甚至有更简单的比如 Gitlab 直接支持推送到 Github，至于本文为何没有选用 Gitlab，纯属个人偏好。