为何使用SimpleDateFormat时触发ANR错误？

嘿，这个问题我做Android列表优化时也碰到过，咱们一步步拆解清楚：

为什么会触发ANR？ #

从你的错误日志和代码逻辑来看，核心问题出在重复创建SimpleDateFormat实例的高昂成本：

• SimpleDateFormat的构造过程远不止表面看起来那么简单，从栈追踪能看到它会触发一连串的clone操作（从Format到NumberFormat再到DecimalFormat），这些操作涉及native方法调用，单次初始化就有不小的开销。
• 你在主线程里连续调用这个方法100次，等于重复执行了100次这些高成本的初始化操作，累计耗时直接触碰到了Android主线程的ANR阈值（主线程阻塞超过5秒就会触发ANR）。

另外补充一点：SimpleDateFormat本身不是线程安全的，但这次的ANR并非线程安全问题导致，纯粹是重复初始化的耗时堆积。

怎么解决？ #

这里有几个靠谱的优化方案，按推荐度排序：

1. 复用SimpleDateFormat实例（用ThreadLocal规避线程安全问题） #

既然每次创建实例成本高，那我们就复用它。但因为SimpleDateFormat线程不安全，所以用ThreadLocal给每个线程分配独立的实例，既实现复用又不会有线程冲突：

// 用ThreadLocal存储每个线程的SimpleDateFormat实例
private static final ThreadLocal<SimpleDateFormat> SDF_CACHE = new ThreadLocal<>();

public static String getTimeFormat(Long unixSeconds, String pattern) {
    SimpleDateFormat sdf = SDF_CACHE.get();
    // 如果实例不存在，或者当前pattern和缓存的不一致，再创建新实例
    if (sdf == null || !sdf.toPattern().equals(pattern)) {
        sdf = new SimpleDateFormat(pattern);
        sdf.setTimeZone(timeZone);
        SDF_CACHE.set(sdf);
    }
    Date date = new Date(unixSeconds);
    return sdf.format(date);
}

这样100次调用里，只要pattern不变，就只会创建一次SimpleDateFormat，直接把初始化开销降到最低。

2. 把日期转换放到子线程执行 #

如果你的通知列表是批量加载的，完全可以把所有时间戳的转换操作放到子线程（比如用Kotlin协程、RxJava或者AsyncTask），转换完成后再回到主线程更新UI。这样主线程完全不会被阻塞，从根源上避免ANR。

3. 用更高效的日期格式化工具（推荐） #

如果你的项目支持Android API 26及以上，直接用Java 8引入的java.time.format.DateTimeFormatter——它是线程安全的，初始化成本更低，API也更友好。如果要兼容更低版本，就用ThreeTenABP这个官方推荐的Java 8日期工具兼容库，用法和DateTimeFormatter一致：

// 以ThreeTenABP为例，兼容低版本Android
public static String getTimeFormat(Long unixSeconds, String pattern) {
    DateTimeFormatter formatter = DateTimeFormatter.ofPattern(pattern)
            .withZone(ZoneId.of(timeZone.getID()));
    Instant instant = Instant.ofEpochMilli(unixSeconds);
    return formatter.format(instant);
}

这个方案不仅解决了ANR问题，还彻底避开了SimpleDateFormat的线程安全坑。

内容的提问来源于stack exchange，提问作者anvesh boddupalli