blocks|key|995313|text|我可以用joda的版本1，1.5和1.62来确认这个问题。作为另一种选择，Date4J对我来说工作得很好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|995314|http://www.date4j.net/|offset|length|995315|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|M|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

I can confirm this issue with version 1, 1.5 and 1.62 of joda. Date4J is working well for me as an alternative.

<a href="http://www.date4j.net/" rel="nofollow">http://www.date4j.net/</a>

blocks|key|781042|text|我也遇到了这个问题。Jon+Skeet的怀疑是正确的，问题是时区的加载效率非常低，打开一个jar文件，然后读取清单来尝试获取此信息。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|781043|然而，仅仅调用DateTimeZone.setProvider([custom+provider+instance+...])是不够的，因为出于一些我不理解的原因，DateTimeZone在调用getDefaultProvider()的地方有一个静态初始化器。|offset|length|style|CODE|781044|为了完全安全，您可以在调用joda中的任何内容之前通过设置此系统属性来覆盖此默认值。|781045|例如，在您的活动中添加以下内容：|781046|@Override
public+void+onCreate(Bundle+savedInstanceState)+{
++++System.setProperty("org.joda.time.DateTimeZone.Provider",+
++++"com.your.package.FastDateTimeZoneProvider");
}|code-block|syntax|javascript|781047|然后你所要做的就是定义FastDateTimeZoneProvider。我写了以下内容：|781048|package+com.your.package;

public+class+FastDateTimeZoneProvider+implements+Provider+{
++++public+static+final+Set<String>+AVAILABLE_IDS+=+new+HashSet<String>();

++++static+{
++++++++AVAILABLE_IDS.addAll(Arrays.asList(TimeZone.getAvailableIDs()));
++++}

++++public+DateTimeZone+getZone(String+id)+{
++++++++if+(id+==+null)+{
++++++++++++return+DateTimeZone.UTC;
++++++++}

++++++++TimeZone+tz+=+TimeZone.getTimeZone(id);
++++++++if+(tz+==+null)+{
++++++++++++return+DateTimeZone.UTC;
++++++++}

++++++++int+rawOffset+=+tz.getRawOffset();

++++++++++++//sub-optimal.+could+be+improved+to+only+create+a+new+Date+every+few+minutes
++++++++if+(tz.inDaylightTime(new+Date()))+{
++++++++++++rawOffset+%2B=+tz.getDSTSavings();
++++++++}

++++++++return+DateTimeZone.forOffsetMillis(rawOffset);
++++}

++++public+Set+getAvailableIDs()+{
++++++++return+AVAILABLE_IDS;
++++}
}|781049|我已经测试过了，它似乎可以在带有joda+1.6.2版本的Android+SDK+2.1%2B上工作。当然，它可以进一步优化，但在分析我的应用程序(mogwee)时，这将DateTimeZone初始化时间从~500ms减少到~18ms。|781050|如果您使用proguard来构建您的应用程序，则必须将这一行添加到proguard.cfg中，因为Joda希望类名与您指定的完全相同：|781051|-keep+class+com.your.package.FastDateTimeZoneProvider|781052|entityMap|0|LINK|mutability|MUTABLE|url|https://market.android.com/details?id=com.mogwee^0|0|7|1K|2P|K|0|0|0|0|B|O|0|0|20|6|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@$D|1A|E|1B|F|G]|$D|1C|E|1D|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1E|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1F|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|1G|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|1H|8|@$D|1I|E|1J|F|G]]|9|@]|A|$]]|$1|S|3|T|5|N|7|1K|8|@]|9|@]|A|$O|P]]|$1|U|3|V|5|6|7|1L|8|@]|9|@$D|1M|E|1N|1|1O]]|A|$]]|$1|W|3|X|5|6|7|1P|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|N|7|1Q|8|@]|9|@]|A|$O|P]]|$1|10|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]]|11|$12|$5|13|14|15|A|$16|17]]]]

I also ran into this problem. Jon Skeet's suspicions were correct, the problem is that the time zones are being loaded really inefficiently, opening a jar file and then reading the manifest to try to get this information.

However, simply calling <code>DateTimeZone.setProvider([custom provider instance ...])</code> is not sufficient because, for reasons that don't make sense to me, DateTimeZone has a static initializer where it calls <code>getDefaultProvider()</code>.

To be completely safe, you can override this default by setting this system property before you ever call anything in the joda. 

In your activity, for example, add this:

<pre><code>@Override
public void onCreate(Bundle savedInstanceState) {
 System.setProperty("org.joda.time.DateTimeZone.Provider", 
 "com.your.package.FastDateTimeZoneProvider");
}
</code></pre>

Then all you have to do is define <code>FastDateTimeZoneProvider</code>. I wrote the following:

<pre><code>package com.your.package;

public class FastDateTimeZoneProvider implements Provider {
 public static final Set&lt;String&gt; AVAILABLE_IDS = new HashSet&lt;String&gt;();

 static {
 AVAILABLE_IDS.addAll(Arrays.asList(TimeZone.getAvailableIDs()));
 }

 public DateTimeZone getZone(String id) {
 if (id == null) {
 return DateTimeZone.UTC;
 }

 TimeZone tz = TimeZone.getTimeZone(id);
 if (tz == null) {
 return DateTimeZone.UTC;
 }

 int rawOffset = tz.getRawOffset();

 //sub-optimal. could be improved to only create a new Date every few minutes
 if (tz.inDaylightTime(new Date())) {
 rawOffset += tz.getDSTSavings();
 }

 return DateTimeZone.forOffsetMillis(rawOffset);
 }

 public Set getAvailableIDs() {
 return AVAILABLE_IDS;
 }
}
</code></pre>

I've tested this and it appears to work on Android SDK 2.1+ with joda version 1.6.2. It can of course be optimized further, but while profiling my app (<a href="https://market.android.com/details?id=com.mogwee">mogwee</a>), this decreased the DateTimeZone initialize time from ~500ms to ~18ms.

If you are using proguard to build your app, you'll have to add this line to proguard.cfg because Joda expects the class name to be exactly as you specify:

<pre><code>-keep class com.your.package.FastDateTimeZoneProvider
</code></pre>

blocks|key|781087|text|我只需要在我的应用程序中使用UTC。因此，按照unchek的建议，我使用了|type|unstyled|depth|inlineStyleRanges|entityRanges|data|781088|System.setProperty("org.joda.time.DateTimeZone.Provider",+"org.joda.time.tz.UTCProvider");|code-block|syntax|javascript|781089|JodaTime实际上使用org.joda.time.tz.UTCProvider作为辅助备份，所以我想为什么不使用它作为主要用途呢？到目前一切尚好。它加载得很快。|offset|length|style|CODE|781090|entityMap^0|0|0|D|S|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@$I|R|J|S|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I only need UTC in my application. So, following unchek's advice, I used

<pre><code>System.setProperty("org.joda.time.DateTimeZone.Provider", "org.joda.time.tz.UTCProvider");
</code></pre>

<code>org.joda.time.tz.UTCProvider</code> is actually used by JodaTime as the secondary backup, so I thought why not use it for primary use? So far so good. It loads fast.

blocks|key|995470|text|我为自己找到了解决方案。我加载UTC和默认时区。所以它的加载速度非常快。我认为在这种情况下，我需要捕获广播时区更改并重新加载默认时区。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|995471|public+class+FastDateTimeZoneProvider+implements+Provider+{
++++public+static+final+Set<String>+AVAILABLE_IDS+=+new+HashSet<String>();
++++static+{
++++++++AVAILABLE_IDS.add("UTC");
++++++++AVAILABLE_IDS.add(TimeZone.getDefault().getID());
++++}

++++public+DateTimeZone+getZone(String+id)+{
++++++++int+rawOffset+=+0;

++++++++if+(id+==+null)+{
++++++++++++return+DateTimeZone.getDefault();
++++++++}

++++++++TimeZone+tz+=+TimeZone.getTimeZone(id);
++++++++if+(tz+==+null)+{
++++++++++++return+DateTimeZone.getDefault();
++++++++}

++++++++rawOffset+=+tz.getRawOffset();

++++++++//sub-optimal.+could+be+improved+to+only+create+a+new+Date+every+few+minutes
++++++++if+(tz.inDaylightTime(new+Date()))+{
++++++++++++rawOffset+%2B=+tz.getDSTSavings();
++++++++}
++++++++return+DateTimeZone.forOffsetMillis(rawOffset);
++++}

++++public+Set+getAvailableIDs()+{
++++++++return+AVAILABLE_IDS;
++++}
}|code-block|syntax|javascript|995472|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I found solution for me. I load UTC and default time zone. So it's loads very fast. And I think in this case I need catch broadcast TIME ZONE CHANGE and reload default time zone.

<pre><code>public class FastDateTimeZoneProvider implements Provider {
 public static final Set&lt;String&gt; AVAILABLE_IDS = new HashSet&lt;String&gt;();
 static {
 AVAILABLE_IDS.add("UTC");
 AVAILABLE_IDS.add(TimeZone.getDefault().getID());
 }

 public DateTimeZone getZone(String id) {
 int rawOffset = 0;

 if (id == null) {
 return DateTimeZone.getDefault();
 }

 TimeZone tz = TimeZone.getTimeZone(id);
 if (tz == null) {
 return DateTimeZone.getDefault();
 }

 rawOffset = tz.getRawOffset();

 //sub-optimal. could be improved to only create a new Date every few minutes
 if (tz.inDaylightTime(new Date())) {
 rawOffset += tz.getDSTSavings();
 }
 return DateTimeZone.forOffsetMillis(rawOffset);
 }

 public Set getAvailableIDs() {
 return AVAILABLE_IDS;
 }
}
</code></pre>

blocks|key|781230|text|此快速注释用于完成来自@Steven的关于date4j的回答|type|unstyled|depth|inlineStyleRanges|entityRanges|data|781231|我在我最弱的安卓设备(HTC+Dream/Sapphire+2.3.5)上运行了一个快速而肮脏的基准测试，比较了java.util.Date、jodatime和date4j。|offset|length|style|CODE|781232|详细信息:正常构建(无前卫)，为jodatime实现FastDateTimeZoneProvider。|781233|代码如下：|781234|String+ts+=+"2010-01-19T23:59:59.123456789";
long+d1+=+System.currentTimeMillis();
DateTime+d+=+new+DateTime(ts);
long+d2+=+System.currentTimeMillis();
System.err.println("datetime+:+"+%2B+dateUtils.durationtoString(d2+-+d1));
d1+=+System.currentTimeMillis();
Date+dd+=+new+Date();
d2+=+System.currentTimeMillis();
System.err.println("date+:+"+%2B+dateUtils.durationtoString(d2+-+d1));

d1+=+System.currentTimeMillis();
hirondelle.date4j.DateTime+ddd+=+new+hirondelle.date4j.DateTime(ts);
d2+=+System.currentTimeMillis();
System.err.println("date4j+:+"+%2B+dateUtils.durationtoString(d2+-+d1));|code-block|syntax|javascript|781235|结果如下：|781236|+++++++++++debug+++++++%7C+normal+
joda+++++:+3s+(3577ms)+%7C+0s+(284ms)
date+++++:+0s+(0)++++++%7C+0s+(0s)
date4j+++:+0s+(55ms)+++%7C+0s+(2ms)+|781237|最后一件事，罐子的大小：|781238|jodatime+2.1+:+558+kb+
date4j+++++++:+35+kb|781239|我想我会试一试date4j。|781240|entityMap^0|0|1K|E|1Z|8|28|6|0|Q|O|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@$D|14|E|15|F|G]|$D|16|E|17|F|G]|$D|18|E|19|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1A|8|@$D|1B|E|1C|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1D|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|1E|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|1F|8|@]|9|@]|A|$]]|$1|S|3|T|5|N|7|1G|8|@]|9|@]|A|$O|P]]|$1|U|3|V|5|6|7|1H|8|@]|9|@]|A|$]]|$1|W|3|X|5|N|7|1I|8|@]|9|@]|A|$O|P]]|$1|Y|3|Z|5|6|7|1J|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|11|$]]

This quick note to complete the answer about date4j from @Steven

I ran a quick and dirty benchmark comparing <code>java.util.Date</code>, <code>jodatime</code> and <code>date4j</code> on the weakest android device I have (HTC Dream/Sapphire 2.3.5). 

Details : normal build (no proguard), implementing the <code>FastDateTimeZoneProvider</code> for jodatime. 

Here's the code: 

<pre><code>String ts = "2010-01-19T23:59:59.123456789";
long d1 = System.currentTimeMillis();
DateTime d = new DateTime(ts);
long d2 = System.currentTimeMillis();
System.err.println("datetime : " + dateUtils.durationtoString(d2 - d1));
d1 = System.currentTimeMillis();
Date dd = new Date();
d2 = System.currentTimeMillis();
System.err.println("date : " + dateUtils.durationtoString(d2 - d1));

d1 = System.currentTimeMillis();
hirondelle.date4j.DateTime ddd = new hirondelle.date4j.DateTime(ts);
d2 = System.currentTimeMillis();
System.err.println("date4j : " + dateUtils.durationtoString(d2 - d1));
</code></pre>

Here are the results :

<pre><code> debug | normal 
joda : 3s (3577ms) | 0s (284ms)
date : 0s (0) | 0s (0s)
date4j : 0s (55ms) | 0s (2ms) 
</code></pre>

One last thing, the jar sizes : 

<pre><code>jodatime 2.1 : 558 kb 
date4j : 35 kb
</code></pre>

I think I'll give date4j a try.

blocks|key|781302|text|如果你必须对你的日期进行精确的时区计算，plowman提供的最高答案是不可靠的。以下是可能发生的问题的示例：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|781303|假设您的DateTime对象设置为凌晨4:00am，也就是夏令时开始后的一小时。当Joda在凌晨3:00之前(即夏令时之前)检查FastDateTimeZoneProvider提供程序时，它将获得一个具有错误偏移量的DateTimeZone对象，因为tz.inDaylightTime(new+Date())检查将返回false。|offset|length|style|CODE|781304|我的解决方案是采用最近发布的joda-time-android+library。它使用Joda的核心，但确保仅在需要时才从原始文件夹加载时区。使用gradle设置起来很容易。在项目中，扩展Application类并在其onCreate()上添加以下内容|781305|public+class+MyApp+extends+Application+{
++++@Override
++++public+void+onCreate()+{
++++++++super.onCreate();
++++++++JodaTimeAndroid.init(this);
++++}
}|code-block|syntax|javascript|781306|作者去年在a+blog+post上写了关于它的文章。|781307|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/dlew/joda-time-android|1|http://daniel-codes.blogspot.pt/2013/08/joda-times-memory-issue-in-android.html^0|0|4|8|1S|O|30|C|3H|T|0|2M|B|31|A|E|P|0|0|0|5|B|1|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@$D|12|E|13|F|G]|$D|14|E|15|F|G]|$D|16|E|17|F|G]|$D|18|E|19|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1A|8|@$D|1B|E|1C|F|G]|$D|1D|E|1E|F|G]]|9|@$D|1F|E|1G|1|1H]]|A|$]]|$1|J|3|K|5|L|7|1I|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|1J|8|@]|9|@$D|1K|E|1L|1|1M]]|A|$]]|$1|Q|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]|Y|$5|T|U|V|A|$W|Z]]]]

The top answer provided by plowman is not reliable if you must have precise timezone computations for your dates. Here is an example of problem that can happen:

Suppose your <code>DateTime</code> object is set for 4:00am, one hour after daylight savings have started that day. When Joda checks the <code>FastDateTimeZoneProvider</code> provider before 3:00am (i.e., before daylight savings) it will get a <code>DateTimeZone</code> object with the wrong offset because the <code>tz.inDaylightTime(new Date())</code> check will return false.

My solution was to adopt the recently published <a href="https://github.com/dlew/joda-time-android" rel="nofollow noreferrer">joda-time-android library</a>. It uses the core of Joda but makes sure to load a time zone only as needed from the raw folder. Setting up is easy with gradle. In your project, extend the <code>Application</code> class and add the following on its <code>onCreate()</code>:

<pre><code>public class MyApp extends Application {
 @Override
 public void onCreate() {
 super.onCreate();
 JodaTimeAndroid.init(this);
 }
}
</code></pre>

The author wrote <a href="http://daniel-codes.blogspot.pt/2013/08/joda-times-memory-issue-in-android.html" rel="nofollow noreferrer">a blog post</a> about it last year.

blocks|key|995612|text|使用dlew/joda-time-android+gradle依赖，它只需要22.82ms(毫秒)。所以我建议你使用它而不是覆盖任何东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|995613|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/dlew/joda-time-android^0|2|M|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Using <a href="https://github.com/dlew/joda-time-android" rel="nofollow noreferrer">dlew/joda-time-android</a> gradle dependency it takes only 22.82 ms (milliseconds). So I recommend you using it instead of overriding anything.

Using Joda 1.6.2 with Android

The following code hangs for about 15 seconds. 

<pre><code>DateTime dt = new DateTime();
</code></pre>

Originally posted this post 
<a href="https://stackoverflow.com/questions/4542867/android-java-joda-date-is-slow-in-eclipse-emulator">Android Java - Joda Date is slow in Eclipse/Emulator -</a>

Just tried it again and its still not any better. Does anyone else have this problem or know how to fix it?

Android Java - Joda Date is slow

Android

在Android上使用Joda 1.6.2下面的代码挂起了大约15秒。DateTime dt = new DateTime();我最初在上发布了这篇文章我又试了一次，还是没有好到哪里去。还有没有人有这个问题或者知道如何解决它？

问Android Java - Joda日期很慢
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Android Java - Joda日期很慢EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Android Java - Joda日期很慢
EN