I would like to add some more references here within the context of Memory management.
--------------------------
http://www.draconianoverlord.com/2010/11/23/gwt-handlers.html
To avoid application-level memory leaks, when adding event handlers, you need to think about:
What is the scope of the event source (the widget or the EventBus)?
What is the scope of the event handler (the presenter)?
And then:
AA] - If the scopes are the same: you can ignore the HandlerRegistration and trust that GWT/the garbage collection will clean things up for you.
BB] - If the handler scope is longer-lived than the source scope: the handler would keep the source in memory, so you need to call removeHandler() when appropriate.
CC] - If the source scope is longer-lived than the handler scope: the source would keep the handler in memory, so you also need to call removeHandler() when appropriate.
=============================
It seems there are quite a few ways that the average (or, in my case, below average) dev can get in trouble:
(In theory, we would never create application-level memory leaks, but....)
- Creating handlers (from a disposable Activity which will add new handlers on each page/place visit) on widgets in a long-lived, Singleton view
+ Declaring GWT or custom widgets in a UiBinder file (or any long-lived view component) where the disposable activity adds handlers
++ I assume this is where we note the GWT standard of "MVP" and not allowing the activity to directly add handlers but have the view contact the Activities interface: presenter.onSomeClick();
- Bypassing the Resettable ActivityManager-provided eventBus
- Basically doing anything out of GWT/fundamental standard operation which creates situations BB && CC from above.
------------------------------
https://code.google.com/p/google-web-toolkit/wiki/UnderstandingMemoryLeaks
https://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks
http://www.draconianoverlord.com/2010/11/23/gwt-handlers.html
https://groups.google.com/forum/#!searchin/google-web-toolkit/Remove$20event$20handlers$20or$20not?/google-web-toolkit/7aHqw-C-Oy0/OOTxO8386BUJ
On Wednesday, May 1, 2013 2:12:37 PM UTC-4, Ashton Thomas wrote:
--Does anyone know of a list of best practices for handling Performance/Memory/etc while using Activities, Widgets, UiBinder, ClickHandlers, etc.?Such as:- Making sure widgets/components are GC'ed- Patterns for reusing widgets/components instead of rebuilding- Widgets to avoid or lean toward- Events/Handlers patterns/anti-patterns- Using Scheduler.get().scheduleDeffered() to break executions up to achieve 60fps? - Non-GWT-specific such as: Write to DOM all at once / avoid layouts (repaint/reflow)- Looking for more GWT-specific Best Practices to achieve the best performance and memory usage- Use HTMLPanel or DIV when just laying things out (similar examples?)?- Other tips BP's for creating high performance apps w/GWT?+ What are bad things we can do?+ Most common mistakes that kill performance etc?I've tried to include some reference I've come across which seemed to be helpful (GWT or Non-GWT):Some Links I've collected:Some Random Notes I've collected:- Pointers / Issues / Best Practices- CSS Selector (more specific - on right-most side)- Reduce DNS Lookup- Avoid Redirects - DO NOT REDIRECT- Make Fewer HTTP requests- Flushing the document early when you have import info (link to resources to start downloading)- Use A CDN- gzip everything- cache headers set correctly on everything- optimize images + use correct size- Mobile vs Desktop version of images- Pick correct format/quality/size- Use Transloadit on upload to create options for all images- We aren't an image service so this is fine- Expires and Etags- Stylesheets at top- local scripts async when possible- sync scripts block document parser- place scripts at bottom- Minify, concatenate files- 60FPS (16.666ms per execution) - Buttery Smooth- check out hardware gpu acceleration- don't update these parts at all- Eliminate Memory Leaks / work with GC- Must do this at the app level - current framework does this very well- Test on mobile devices / record on mobile devices (not emulators)- GPU, CPU- Network- etc is far different- Avoid reflow/layout (read,write,read... group 'reads' then 'writes')- JS blocks ui thread, don't have long-running js executions- Put js scripts at the bottom on a host file/page + combine js files (or just inline!)- or the "async" keywork param on the link (hack-ish but good)- download in background- +Execute as soon as possible- *You can't modify doc.write() in the script.- Also have "defer"- download in background- not executed immediately (use only when order of execution matters; use async other times)- default is "regular"- ** Actually "async" and "defer" script tags suck right now- There is a hack to insert the js files with tag "notJs" (random) and then onLoad change it back to js correct tag..- * You can dynamically load js files via embedded js (it will be non-blocking)- Execution begins immediately after download - timing not guaranteed- Images must be exactly same natural size as display size- Very Common Jank cause- BEST PRACTICE: Create a Best PROCESS -> Test/Record/TrialError- Avoid complicated styling- Complicated Styles- Overlaying styles- /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --show-paint-rects - Huge- See how large the view-port repaint area is for small or big things (hover, insert,etc)- *This may be built into Chrome Dev Tools now- use Chrome Dev Tools (Frame -> Janks)- OnScroll- Doing things onScroll is f-ing terrible- SetTimeout- Don't do it- f-ing bad- GPU Acceleration- When we have a large area (that may be scrolled) that DOESN"T CHANGE- Not just for video- Changing will cause poor performance- CSS Animations offloaded to GPU (not fully complete for all browsers - in terms of pert)- Know Reflow vs Repaint (Layout may mean both)- *Get CSS to user/browser fast/first (put it at the top)- JS can block CSS- Use async scripts- AVOID DOC.WRITE() //I need to look into the extent of this- Critical Path Explorer- Let the browser know of all resources as fast as possible (w/non-blocking and good order)- Don't use CSS universal selector or ancestor elements (make selective -no general- selectors in css)- Prefer Class and ID selectors over tag selectors- AppCache- Actually not a great option if you have many pages- Okay for single page web apps
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment