SDK Version: M3
First of all, define what do we mean under "speed": in one hand its the time that the code needs to execute, on the other hand its the time the user needs to wait for the user interface. The two things can greatly differ, of course you must optimize the code performance, but the most important is what the user sees from it. Don’t make the user wait, unless its necessary.
Do not pull back the ui thread
The very basic principle is to never run slow operations on the user interface thread! If you do this the interface will freeze until the operation is executed, which is not a nice user experience. If the execution takes too long the android system will detect it and offer the opportunity to the user to force close the frozen application:
http://downloadandroid.info/wp-content/uploads/2010/08/image71.png
Even if the performance of code is very good if you do the work in the ui thread, the nice code goes to waste.
Slow operations
So, which are these slow operations, for example? The most unreliable in speed is network communication. The dispersion on the speed is big, so there is a chance to finish it fast, but it often can take very long time, so never execute network communication in the ui thread.
Database access and sd card operations, especially writing are a bit slow too. In database never forget proper indexing, it can extremely affect database speed.
Emulator and real device
There are differences in speed between the emulator on pc and a real device. The emulator needs a lot of processor speed, if you don’t have a powerful machine the application can seem slow, however it runs fast on a real device. The opposite can also happen, the real device uses sd card, the emulator uses the pc’s hard drive, which means much faster file access.
Notify the user
When the user have to wait, notifying the user, that he have to wait and the application is working, it is not frozen, showing loading animations etc. makes a better user experience.
http://www.helloandroid.com/
First of all, define what do we mean under "speed": in one hand its the time that the code needs to execute, on the other hand its the time the user needs to wait for the user interface. The two things can greatly differ, of course you must optimize the code performance, but the most important is what the user sees from it. Don’t make the user wait, unless its necessary.
Do not pull back the ui thread
The very basic principle is to never run slow operations on the user interface thread! If you do this the interface will freeze until the operation is executed, which is not a nice user experience. If the execution takes too long the android system will detect it and offer the opportunity to the user to force close the frozen application:
http://downloadandroid.info/wp-content/uploads/2010/08/image71.png
Even if the performance of code is very good if you do the work in the ui thread, the nice code goes to waste.
Slow operations
So, which are these slow operations, for example? The most unreliable in speed is network communication. The dispersion on the speed is big, so there is a chance to finish it fast, but it often can take very long time, so never execute network communication in the ui thread.
Database access and sd card operations, especially writing are a bit slow too. In database never forget proper indexing, it can extremely affect database speed.
Emulator and real device
There are differences in speed between the emulator on pc and a real device. The emulator needs a lot of processor speed, if you don’t have a powerful machine the application can seem slow, however it runs fast on a real device. The opposite can also happen, the real device uses sd card, the emulator uses the pc’s hard drive, which means much faster file access.
Notify the user
When the user have to wait, notifying the user, that he have to wait and the application is working, it is not frozen, showing loading animations etc. makes a better user experience.
http://www.helloandroid.com/
