When switching the language in the Android system, it will bring an interesting BUG: simpledateformat takes a long time to process the "Z" Time Zone Field. If you call this method multiple times in a listview, you will find that the listview is not smooth during scrolling. The console output is as follows:
I/resources (471): loaded Time Zone names for en_us in 1904 Ms. <br/> I/resources (471): loaded Time Zone names for en_us in 1400 ms. <br/> I/resources (471): loaded Time Zone names for en_us in 1260 Ms. <br/> I/resources (471): loaded Time Zone names for en_us in 1360 Ms. <br/> I/resources (471): loaded Time Zone names for en_us in 1232 Ms. <br/> I/resources (471): loaded Time Zone names for en_us in 1344 Ms. <br/> I/resources (471): loaded Time Zone names for en_us in 1228 Ms.
Other developers' feedback is as follows:
Http://stackoverflow.com/questions/3905545/android-load-timezone-too-long-loaded-time-zone-names-for-en-us
Http://stackoverflow.com/questions/2853058/weird-parsing-date-string-error-in-android-2-0-emulator
This is because the time zone field is designed for delayed initialization in the Android system. It is obtained only when it is used for the first time and saved in the cache, it will be obtained from the cache later. However, based on the previous simpledateformat API design, there is no way to achieve this goal. This problem has been repeatedly mentioned in the official Android issues, and has never been resolved since it was discovered in 2009. See: http://code.google.com/p/android/issues/detail? Id = 3147 and http://code.google.com/p/android/issues/detail? Id = 16126.
In addition to looking forward to fixing this problem in the Android system or increasing system hardware support, it is basically difficult to handle the native bug of this system, but we can improve this problem through a simple method. The core idea is the Offset Value of the cache time zone. We only need to obtain and store the offset value when loading for the first time, and then calculate the actual time value based on the offset value each time later. The Code is as follows:
Public static long cachedtime =-1; <br/> Public static long mtimetolong (string time) {<br/> simpledateformat format = new simpledateformat (<br/> "yyyy-mm-dd hh: mm: Ss. SSS "); // obtain the time format without the time zone <br/> try {<br/> date = format. parse (time); </P> <p> If (cachedtime =-1) {// when the value is set for the first time <br/> simpledateformat localformat = new simpledateformat (<br/> "yyyy-mm-dd hh: mm: Ss. sssz "); // obtain the time format with the time zone </P> <p> date localdate = localformat. parse (time); </P> <p> long localtime = localdate. gettime (); <br/> cachedtime = localtime-date. gettime (); // calculate the travel value and store <br/> return localtime; <br/>}else {// value after the first time <br/> return date. gettime () + cachedtime; <br/>}< br/>} catch (parseexception e) {<br/> E. printstacktrace (); <br/> return 0; <br/>}< br/>}
In this simple way, We can temporarily solve the difficult bug of the Android system, which brings a different way to solve the problem.