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

しかし、よくわかりません。

物事をスピードアップするために何をすべきかアドバイスが必要です。現時点で非常に遅いアプリケーションがあり、遅延は正確にこの 5 行上にあり、時間を読み取るだけで約 1 秒半かかります :(。

あなたがアドバイスするのは、グローバル変数を入れて時間を1つだけ読むことです。申し訳ありませんが、それはできません:(。

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 オブジェクトを 1 つだけ作成し、日付を解析する必要があるたびにそれを再利用することで、この問題を解決することができました。コードの構造によっては、これを実装する方法が多すぎるため、詳細には触れません。

もちろん、タイム ゾーンの読み込みの遅延は、オブジェクトの作成時に 1 回発生します。

于 2012-12-13T15:43:14.220 に答える
0

SimpleDateFormat オブジェクトを 1 つだけインスタンス化し、必要な場所で再利用してください。この方法では、タイム ゾーン名は 1 回だけ読み込まれます。

于 2013-08-28T08:46:32.533 に答える