en的加载时区名称

Question

我有类似的东西

I/global  ( 3622): Loaded time zone names for en in 355ms.
I/global  ( 3622): Loaded time zone names for en in 307ms.
I/global  ( 3622): Loaded time zone names for en in 309ms.
I/global  ( 3622): Loaded time zone names for en in 310ms.
I/global  ( 3622): Loaded time zone names for en in 324ms.

我不知道这个日志的来源。

我正在对这个主题进行一些研究，我猜它来自

new Date();

但我不确定。

我需要建议我应该做些什么来加快速度。我的应用程序在这个时刻非常慢，并且延迟正好在这五行以上，只需要大约一秒半的时间来读取时间：（。

如果你建议放一个全局变量并阅读时间只是抱歉我不能这样做:(。我需要时间在我的功能当时（不可能只读出时间： （）。

Answer 1

我发现了我的问题

问题在于，由于SimpleDateFormat api的设计，现在无法绕过这个问题。只有更快的手机可以通过花更少的时间来收集这些字符串来解决这个问题。

所以我希望android skd的下一个版本和新手机中的时区没有问题。

直到那时小心这一行

 SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS Z");

导致延迟来自那里

如果你使用没有时区的格式，它可以完美地工作（没有延迟）

 SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS");

Answer 2

在解析包含日期的内容流时，我也注意到了这一点。我意识到在我的情况下（可能是我们许多人的情况），日期格式字符串对于每个创建的SimpleDateFormat对象都是相同的。

所以，我设法通过创建一个SimpleDateFormat对象并在需要解析日期时重用它来解决这个问题。根据代码的结构，有太多的实现方法，所以我不会详细介绍。

当然，在创建对象时，加载时区的延迟仍然会发生一次。

Answer 3

确保只实例化一个SimpleDateFormat对象，然后在需要的地方重复使用它。 这样，时区名称只会加载一次。