Memory Management for Flex and AIR Developers

921 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
921
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Memory Management for Flex and AIR Developers

  1. 1. Memory Management for Flex and AIR Developers Presented by Jun Heider, ACI RealEyes Media jun@realeyesmedia.com
  2. 2. About me • Jun Heider – Adobe Certified Flex developer and instructor – I work for RealEyes Media in sunny Denver, CO http://www.realeyesmedia.com – I have worked on Flex/AIR applications and consulting for Fortune 500 financial corporations, government, and many other private sector firms such as Chase Manhattan, US Navy, and GLOBE/UCAR – Blog http://office.realeyesmedia.com/blogs/jun Memory Management for Flex Developers
  3. 3. Synopsis • The emergence of Flex-based applications in the enterprise and the push of AIR-based applications to the desktop has prompted an awakening of Flex/AIR developers in the area of memory management. • Due to the lazy nature of the Flash Player 9 garbage collection routines, memory consumption left unchecked can quickly drive the high-performance required in your applications downhill. • However, with the proper approach and methodical systematic development processes, memory management techniques can be utilized to keep memory consumption to a minimum. Memory Management for Flex Developers
  4. 4. Why do we care about memory management? • We want our applications to run fast (Stare too long at a busy cursor…your eyes will go bad and your temper will rise) • We want our applications to be stable (No memory leaks or browser crashes) • We want our applications to treat their host OS and neighboring processes with respect (Save some system memory for the other applications…jeez) • We want our code to hold up to industry standards and best practices (Well, most of us do…) Memory Management for Flex Developers
  5. 5. Why do we care about memory management? • There are many types of memory-intensive situations that require attention: – Large datasets/assets (Catalog management application, Photo gallery application) – Extended runtime requirements (8 hours a day for example) – Large forms with several views and many controls (Home loan application) – Lesser spec’d hardware (RAM-constrained) Memory Management for Flex Developers
  6. 6. Why do we care about memory management? • DEMONSTRATION – Two applications with almost the same code base – The difference is one application uses memory management techniques and best practices while the other does not Memory Management for Flex Developers
  7. 7. Memory management, how shall we proceed? 1. Background information: Before we start, we need to know how Flash Player 9 handles memory management 2. Best practices: When we code, we need to help the Flash Player figure out what needs to be managed 3. Tips and tools: When we debug and refactor, we need to know how to monitor and diagnose memory management issues Memory Management for Flex Developers
  8. 8. Background information - disclaimer • I am not an engineer on Adobe’s Flash Player team • I have collected the background information from multiple sources several of them being Adobe engineers with access to developers on the Flash Player team • Being that the sources agree with each other and I have not seen any indication otherwise I have a good feeling that this information is accurate • Based on the background information and my own debugging and code development I have a good feeling that this information is accurate Memory Management for Flex Developers
  9. 9. Background information - How does the Flash Player manage memory? • The Flash Player has a specific process when requesting additional memory from the system (allocation) • The Flash Player uses a garbage collection model when releasing memory back to the system (deallocation) • There are pros and cons to each of the above Memory Management for Flex Developers
  10. 10. Background information – memory allocation • When memory is needed from the system Flash Player will request a large chunk of memory from the OS rather than requesting smaller chunks more frequently • Flash Player breaks these large chunks into pools of smaller chunks and then hands them out as needed • When more memory is needed Flash Player will maybe run garbage collection, and if necessary request another large chunk from the OS which it will then break into another pool of smaller chunks Memory Management for Flex Developers
  11. 11. Background Information – memory allocation • DEMONSTRATION – The following demonstration illustrates the way in which Flash Player normally allocates memory – Caveat: This does not hold true for larger data objects such as bitmaps which require a large chunk of non-pooled memory Memory Management for Flex Developers
  12. 12. Demonstration (Flash Player Allocation animation) Operating System Greedily, Flash Player requests more memory than it Memory request is approved needs – 1024 bytes* -- to minimize calls to the OS A request is 256 Bytes made for 256 Flash Player bytes 256 Bytes 256 Bytes 256 Bytes *Actual numbers my Memory allocated vary Memory Management for Flex Developers
  13. 13. Background information – memory allocation (PROS and CONS) • PROS – Performance: Rather than making many requests to the system for small chunks of memory Flash Player makes more infrequent requests for large chunks of memory saving processor cycles and the response time of your application • CONS – Greedy allocation: When Flash Player makes a request to the system for memory it will request large chunks of a pre-determined size rather than small chunks sized for immediate need – Memory footprint: With many large chunks of memory with little pieces of unused memory, over time the Flash Player will never release all unused memory back to the system Memory Management for Flex Developers
  14. 14. Background information – memory deallocation • When new memory is requested, Flash Player may run garbage collection: – The garbage collection process will use the following algorithms to find unused memory: • Deferred reference counting • Mark and sweep – If unused memory is found then garbage collection may try to consolidate used portions to try and deallocate some of the large chunks back to the system Memory Management for Flex Developers
  15. 15. Background information – memory deallocation • DEMONSTRATION – This demonstration illustrates the way in which Flash Player garbage collector works Memory Management for Flex Developers
  16. 16. Demonstration (Garbage Collection Animation) Release of 256 Bytes 256 Bytes 256 Bytes Allocated 256 Bytes 256 Bytes Request 256 Bytes 256 Bytes for 256 Request for Free – not GC’d Bytes 256 Bytes 256 Bytes 256 Bytes Free Memory almost out, run GC! Garbage Collection Run 1 256 Bytes 256 Bytes Free to be 256 Bytes 256 Bytes released 256 Bytes 256 Bytes back to the 256 Bytes 256 Bytes OS Garbage Collection Run 2 Memory Management for Flex Developers
  17. 17. Background information – memory deallocation • The Flash Player garbage collection routine deferred reference counting works by counting STRONG references** against a particular object • If the object has a reference count of 0 then the memory used to store it will become a candidate for reuse by the player or release back to the system • This algorithm does not count weakly referenced event listeners** or weak object references** **We’ll discuss what these are in a little bit Memory Management for Flex Developers
  18. 18. Background information – memory deallocation • The Flash Player garbage collection routine mark and sweep works by starting at the root and working it’s way down the hierarchy of memory objects • The memory used to store objects NOT reachable via the parent-child hierarchy will be eligible for reclamation by the player or release back to the system Memory Management for Flex Developers
  19. 19. Background information – memory deallocation • DEMONSTRATION – This demonstration illustrates the way in which Flash Player deallocates memory using deferred reference counting and mark and sweep – http://www.gskinner.com/blog/archives/2006/09/garbage_collect.ht ml Memory Management for Flex Developers
  20. 20. Background information – memory deallocation (PROS and CONS) • PROS – Performance: Since it doesn’t run all the time and every time, it saves on processor cycles and response time of your application • CONS – Indeterminate: garbage collection only runs when more memory is needed but not every time – Iterative: It may take a few passes for garbage collection to finish consolidating pools or release memory back to the system – Involuntary: There is no supported/recommended way for a developer to force a garbage collection run Memory Management for Flex Developers
  21. 21. Best practices – how do we help with memory management? • As developers, we work with the knowledge of how the Flash Player allocates and deallocates memory • This knowledge is used to determine memory management best practices when coding Memory Management for Flex Developers
  22. 22. Best practices – thoughts on allocation • Thought: – Once a large chunk of memory is allocated to the Flash Player, there is a chance that the chunk will never be released back to the system • Observations: – The key is to only use memory when necessary – Deferred loading and instantiation assist with frugal memory consumption Memory Management for Flex Developers
  23. 23. Best practices – allocation concerns • Based on Flash Player memory allocation observations we need to keep the following in mind while coding: – Datasets retrieved from services – Assets loaded in at runtime – Components Memory Management for Flex Developers
  24. 24. Best practices – allocation concerns • Dataset retrieved from services: – Start with estimating the number of records a user will need right off the bat, this will be the initial data pull – You can retrieve the rest of the data using paging – Use <mx:DataService/> and FDS Data Management Service destinations with the paging feature enabled Memory Management for Flex Developers
  25. 25. Best practices – allocation concerns • Assets loaded in at runtime: – Assets include: images, sound, video, and other SWFs – The more assets you load, the more memory required: use discretion when loading assets in at runtime – Either load in assets one-by-one or try to predict the number of assets that will actually be used Memory Management for Flex Developers
  26. 26. Best practices – allocation concerns • Components – Make use of deferred instantiation, and manual creation methods – Be very wary of creationPolicy="all" – Also, when using the combo of removeChild() and addChild() on a component, see if there is a way to reuse the component vs. adding and removing brand new instances Memory Management for Flex Developers
  27. 27. Best practices – thoughts on deallocation • Thoughts: – We can never be sure when garbage collection will run or what it will handle during each run – Based on the way garbage collection works, we can never be sure when our objects will be garbage collected • Observations: – The key is to do everything in our power to remove references as soon as they’re no longer needed Memory Management for Flex Developers
  28. 28. Best practices – deallocation concerns • Based on Flash Player memory deallocation observations we need to keep the following in mind while coding: – Object references (namely complex objects) – Event listeners – Service connections – Modules – Assets Memory Management for Flex Developers
  29. 29. Best practices – deallocation concerns • Object references (namely complex objects) – Be wary of complex objects such as arrays, dictionaries, and large developer-defined objects – There is no built-in way to weakly reference another object, so remove references when you’re done with them Memory Management for Flex Developers
  30. 30. Best practices – deallocation concerns • Event listeners – It is good practice to try and use weakly referenced event listeners whenever possible // The last argument is useWeakReference:Boolean // which defaults to FALSE myChild.addEventListener(MouseEvent.CLICK,onClick,false,0,true); – If you add a strongly referenced listener try to remove the listener when you are done with it myComponent.removeEventListener(MouseEvent.CLICK,onClick,false); Memory Management for Flex Developers
  31. 31. Best practices – deallocation concerns • Service connections – In other programming languages its best practice to close a file when you’re done writing to it, in a similar way it is good to close service connections when you’re not using them any more: • DataService: myDataService.disconnect(); • RemoteObject: myRemoteObject.disconnect(); • WebService: myWebService.disconnect(); • HTTPService: myHTTPService.disconnect(); • Socket: mySocket.close(); • NetConnection: myNetConnection.close(); Memory Management for Flex Developers
  32. 32. Best practices – deallocation concerns • Modules – Don’t unnecessarily load or unload modules – If you need to unload a module you will need to make sure to remove all references pointing into the module – Regarding references: event listeners are backward! In other words if a module adds a listener to an event dispatched by it’s parent, the parent application references the module! Memory Management for Flex Developers
  33. 33. Best practices – deallocation concerns • Assets – Assets include: images, sound, video, and other SWFs – Make sure to remove references to assets when they’re done being used by setting the references to null Memory Management for Flex Developers
  34. 34. Best practices – what about AIR? • The AIR runtime is based on Flash Player 9 • If you develop AIR apps with ActionScript 3 and MXML, the things we learn about Flex also apply to AIR…in other words, for the most part we’re addressing both platforms at the same time! ☺ Memory Management for Flex Developers
  35. 35. Best practices – what about AIR? • AIR has access to NativeWindow while Flex does not • After instantiating a NativeWindow you must issue a close() before it can become a candidate for garbage collection • If you want the DisplayObject instances in your NativeWindow to become eligible for garbage collection, remove external references to them BEFORE issuing a close()! Reason being most properties and methods of a NativeWindow are no longer available after running close() Memory Management for Flex Developers
  36. 36. Best practices – what about AIR? • AIR has access to FileStream while Flex does not • Be wary of opening a FileStream object in asynchronous mode: pending operations and event handlers listening for them to finish can prevent the FileStream object from being garbage collected Memory Management for Flex Developers
  37. 37. Best practices – give me examples! • DEMONSTRATION – During this demonstration, various best practices will be shown and contrasted with their non-optimized counterparts Memory Management for Flex Developers
  38. 38. Tips and tools – what is available to help us with memory management? • Some tips on debugging and refactoring would be nice • It would be nice to have some utility classes or interfaces to assist us with facilitating memory management in our applications • We need some tools to assist with monitoring and debugging our applications: – What kind of memory footprint does our application have? – Are there any memory leaks? – What happens to memory management if I make a slight change to the code? Memory Management for Flex Developers
  39. 39. Tips and tools – pay attention during debugging and refactoring • During the testing or maintenance phase, keep an eye on memory consumption and pay attention to what’s happening in the application when utilization spikes. • Try not to change too much code at once before re-testing to see if modifications have made a positive impact • Make sure that you are keeping revisions – preferably with developer notes – in case you need to revert or re-test! Memory Management for Flex Developers
  40. 40. Tips and tools – some times memory can be consumed by the weirdest things • Memory can be consumed by: – Mouse movement – Modal pop-ups – Service polling – Scrolling within components • When debugging, keep the above in mind, and don’t get too concerned with slight variances in memory allocation statistics (In other words, look at memory allocation at a higher level) • Also, based on the above, the way in which a user interacts with an application will skew the results between debugging iterations Memory Management for Flex Developers
  41. 41. Tips and tools – when debugging, forget the user • Use non-interactive repeatable sequences when debugging. • If it’s available to you, use the Flex automation framework and QTP so that multiple functional test runs through an app will be identical Memory Management for Flex Developers
  42. 42. Tips and tools – utility classes • It would be nice to have utility classes or interfaces to: – Know how much memory is being consumed – Allow us to log memory consumption for later analysis – Allow us to create weak object references – Help us with the cleanup process when objects are no longer needed Memory Management for Flex Developers
  43. 43. Tips and tools – utility classes • DEMONSTRATION – During this demonstration utility classes/interfaces that assist with memory management practices will be shown Memory Management for Flex Developers
  44. 44. Tips and tools – help me debug… • Various tools and methods to debug memory consumption: – Manual debugging: • System.totalMemory • Timer • trace() – Flex Builder 3 Profiler • Currently in Beta http://labs.adobe.com/technologies/flex/ • Really granular • Integrated into Flex Builder – REDbug • Currently in Beta http://www.realeyesmedia.com/redbug/ • Easy to compare multiple test runs side by side • Load/Save results to/from file Memory Management for Flex Developers
  45. 45. Tips and tools – help me debug • DEMONSTRATION – During this demonstration the various debugging tools will be used to debug sample code Memory Management for Flex Developers
  46. 46. In summary • Flash Player 9 memory management is an involuntary system that has been architected for player performance and not necessarily 100% optimal memory utilization • Utilizing best practices, specialized utility classes, and specialized interfaces during code development optimizes how your code interacts with Flash Player memory management • Debugging your application using available tools allows you to profile and optimize memory management in your application Memory Management for Flex Developers
  47. 47. Memory management – who/what else can we learn from? • Acknowledgements: Grant Skinner, Alex Harui, and Kyle Quevillon • Resource Links: – Grant Skinner • http://www.adobe.com/devnet/flashplayer/articles/resource_management.html • http://www.adobe.com/devnet/flashplayer/articles/garbage_collection.html • http://www.gskinner.com/blog/archives/2006/06/as3_resource_ma.html • http://www.gskinner.com/blog/archives/2006/07/as3_resource_ma_1.html • http://www.gskinner.com/blog/archives/2006/08/as3_resource_ma_2.html • http://gskinner.com/talks/resource-management/ • http://www.gskinner.com/blog/archives/2006/06/understanding_t.html • http://www.gskinner.com/blog/archives/2006/07/as3_weakly_refe.html • http://www.gskinner.com/blog/archives/2006/07/as3_dictionary.html • Just call him Mr. GC! Memory Management for Flex Developers
  48. 48. Memory management – who/what else can we learn from? (continued) – Alex Harui • http://blogs.adobe.com/aharui/2007/03/garbage_collection_and_memor y.html • Numerous well-written posts on Flexcoders! – Kyle Quevillon • http://blog.739saintlouis.com/2007/03/28/flash-player-memory- management-and-garbage-collection-redux/ • Awesome Adobe Flex support individual! Memory Management for Flex Developers

×