1

我有这样的东西

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();

但我不确定。

我需要建议我应该怎么做才能加快速度。我的应用程序此时非常慢，延迟正好在上面的这五行，它需要大约一秒半才能读取时间:(。

如果您的建议是放置一个全局变量并仅读取时间，对不起，我不能这样做:(。当时我需要在我的函数中使用时间（不可能仅读取时间:(）。

4

3 回答 3

6

我发现了我的问题

问题是，由于 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");
于 2012-01-17T08:24:48.203 回答
2

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

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

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

于 2012-12-13T15:43:14.220 回答
0

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

于 2013-08-28T08:46:32.533 回答