Your SlideShare is downloading. ×
0
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Day2_3 performance_optimization
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Day2_3 performance_optimization

266

Published on

http://winstore.vn

http://winstore.vn

Published in: Technology, Art & Photos
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
266
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. PERFORMANCE OPTIMIZATION Cao Phong Developer Tech Support Manager Aug 07, 2013
  • 2. WHY OPTIMIZE Most of the development tasks for the typical mobile application can be done in many different ways. Different implementation techniques lead to different application performance and essentially different responsiveness of user interface. Responsiveness of UI is one of the important factors for application success.
  • 3. • 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result. • 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data. • 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect. Miller, R. B. (1968) Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277
  • 4. CHOOSING GUI STRATEGY LCDUI Forms Canvas GameCanvas LWUIT
  • 5. LCDUI FORMS Fast, simple and standard way of making UI. On full touch Asha very attractive looking and have huge UX improvements. Not as fast as Canvas. Animation on a Form is much slower than on a Canvas, and there is no way to influence the vertical scroll position, animate transitions between screen, or shift to a full screen view. You can, however, slightly increase the performance when changing screens by using just one Form and re-populating it with new Items.
  • 6. CANVAS Highly customizable way of making UI. You have to take care of render timing yourself, or you can use Nokia’s FrameAnimator class to quickly create effects such as kinetic scrolling. Any part of your code can call Canvas.repaint() to signal that painting should occur soon. The most important performance tip for navigating through a Canvas-based UI is to implement your own View class to represent each screen, and paint all Views on one Canvas rather than switching from one Canvas to another, which can be slow and does not give you the possibility of animating the transition for smooth effect.
  • 7. GAMECANVAS GameCanvas is double buffered with more control over the painting cycle and threading. Unlike Canvas, you should create your own Thread, which calls GameCanvas.paint() directly to fill the graphics buffer, and then GameCanvas.flushGraphics() to instantly blit the graphics buffer onto the screen.
  • 8. LWUIT LWUIT (Lightweight User Interface Toolkit) is a toolkit for creating Java SWING-like applications without some of the complexity of SWING. Like Form, it offers basic components, but it adds to this better layouts, styles and theming, bundling own fonts into your application, and animated screen transitions. Canvas, but it is a large and complex library written to be a general purpose replacement for the default UI on many different phones. LWUIT and the associated themes and any fonts you include quickly make your JAR file grow quite large. http://projects.developer.nokia.com/LWUIT_for_Series_40
  • 9. JAVA HEAP MEMORY On Series 40 (well, FT) only from 2 to 4 MB – use it wisely Instances of classes (objects) and primitive types are created in the heap. Total number of methods in classes loaded by JVM has a direct impact on how much heap space is left for other data. These memory allocations are permanent for the runtime of the application and are not dynamically unloaded by the JVM once a class is no longer in use.
  • 10. RECURSIVE ALGORITHMS AND STACK MEMORY Variables passed as arguments to a method are passed on the current thread’s stack. Method variables of primitive types are also allocated on the stack. Recursive algorithms are algorithms where a method calls itself in a loop to complete a task. As a result, they create multiple stack frames. – They use a lot of stack memory. The same method is called repeatedly, and only as the application completes does it unwind the queued stack frames. This extra stack memory is often not useful, and stack memory per thread is limited and such heavy stack use may well cause an OutOfMemoryException well before you are actually out of heap memory. – Recursive algorithms can be slow. Each method call includes a certain amount of overhead, which is not really necessary since a recursive algorithm can be unwound into a non-recursive equivalent loop that does not include the relatively heavy method call.
  • 11. ARCHITECTURE CHANGES Carefully consider architecture of your drawing loop and user input loops and decouple them whenever possible. Explore WeakReference introduced in CLDC 1.1 for memory management.
  • 12. WEAKREFERENCE OBJECT CACHING Best pattern for using all available heap memory, but never running into the dreaded OutOfMemoryError. CLDC 1.1 WeakReference When an object is referenced by a WeakReference, and not using traditional Object pointers, this is a signal to the garbage collector that is has permission to collect the object if memory is running low. You have to maintain own HashTable of Objects To understand this pattern better look at Tantalum Mobile: http://projects.developer.nokia.com/Tantalum
  • 13. public void remove(final Object key) { if (key != null) { hash.remove(key); } } public boolean containsKey(final Object key) { if (key != null) { return hash.containsKey(key); } return false; } public int size() { return hash.size(); } public void clear() { hash.clear(); } } public class WeakHashCache { protected final Hashtable hash = new Hashtable(); public Object get(final Object key) { final WeakReference reference = (WeakReference) hash.get(key); if (reference != null) { return reference.get(); } return null; } public void put(final Object key, final Object value) { synchronized (hash) { if (key == null) { return; } if (value == null) { hash.remove(key); return; } hash.put(key, new WeakReference(value)); } }
  • 14. RENDER CACHING One of the common performance needs is to make your application paint, in particular scroll, smoothly and quickly. You can paint items each into their own Image, keeping that pre-painted Image in a cache, and reusing it as the object moves around the screen. Essentially, WeakReference cach of pre-painted Images. To understand this pattern better look at Tantalum Mobile: http://projects.developer.nokia.com/Tantalum
  • 15. BAG OF TRICKS Use final – class, method, variables Avoid enumerations Don’t make it static if it’s commonly called from instances Final int n = vector.size() before a classic for() loop Minimize how much external RAM you use. Example: copy from one array back into the same array is faster than copy from one array into a second- more primary cache hits in RAM.
  • 16. FILE SYSTEM (FLASH MEMORY) CACHING Flash memory is slow, but faster then Web. Cache downloaded data from previous session. Improve startup time of app, by loading from disk cache instead of new Web requests. RMS and File System (JSR-75) same speed, but with RMS no security prompts. Underwater stones: still remember, Flash memory is slow. Architect your application to use asynchronous loading /saving of data from / to disk cache.
  • 17. HASH ACCELERATION Some iterative algorithms are slow. Proper usage of collections types of data structures can increase performance. Vector.contains() is very slow, but Hashtable.containsKey() is very fast. Reconsider your algorithms to use Hashtables. Usage can be found in very surprising places. For example, Font.stringWidth() is slow, but necessary for drawing multiline text on Canvas. Creating a Hashtable with the width in each character you have used in the Font can transform this into a fast operation and increase Canvas.paint() speed.
  • 18. STRING CONCATENATION If you are going to concatenate a large number of small Strings, use: StringBuffer.append() instead of the String += operator. String is much slower because every time you concatenate a string to another with += operator, a new StringBuffer is created under the hood. Depending on the number of concatenations, a single explicit StringBuffer can be many times faster than multiple implicit StringBuffers created by String addition.
  • 19. PERFORMANCE SUMMARY Compare Algorithms – Talk to colleagues and pick the best algorithm; having the best possible algorithm is the most effective way to optimize performance. Simple Architecture – Keep your architecture simple and to the point without extra layers of method calls or objects for artificial abstraction. Mobile front end code does not last for ever, so over-engineering and excessive abstraction into multiple classes will slow you down compared to simple use of variables.
  • 20. PERFORMANCE SUMMARY Manage Memory with WeakReference Caching – Avoid memory problems by always accessing image data in memory using a WeakReference Cache. – Create a type of virtual memory by duplicating the WeakReference cache contents in Flash memory (Record Management System) so that you can quickly recover items which are no longer available in RAM.
  • 21. PERFORMANCE SUMMARY Profile your app towards the end of project – Profile your application in an emulator. – Also test the actual run-time of critical code sections on the phone using System.currentTimeMillis() to see and carefully measure the effects of your code changes.
  • 22. SPECIAL THANKS Paul Houghton Michael Samarin
  • 23. THANK YOU QUESTIONS?

×