1

I'm currently writing an iOS app that uses a UIWebView for surfing around pages. Sometimes I need to dynamically remove elements in the UIWebView using stringByEvaluatingJavaScriptFromString:, but this locks up the main UI for sometimes up to 2 seconds on my first gen iPod touch, and maybe half a second on an iPhone 3GS. The JavaScript I'm using to remove it by is simply:

element.parentNode.removeChild(element);

Nothing more complicated than that. At the same time I'm doing some very basic 2D rendering in OpenGL ES, and if rerendering the UIWebView wouldn't lock up I would use just simple CoreAnimation on the main thread. Could it be that it has to recalculate the DOM tree, all element positions etc? Should this really lock up the main UI thread? Is it that I'm calling stringByEvaluatingJavaScriptFromString: that locks up everything? Is this normal and to be expected on this kind of hardware? The odd thing is it is able to render some semi-complex MooTools animations in the webview, with opacity and height changes, but removing one single element takes several seconds.

Does anyone have any ideas in improvements? Maybe just hiding elements using visibility: hidden is better, or setting opacity: 0? Any thoughs or wise words of experience?

Erik Rothoff
  • 4,826
  • 9
  • 41
  • 59

1 Answers1

4

DOM tree manipulations are horribly slow in all browsers, especially iOS Safari. The key factor is size of the DOM tree. Because of this, the best advice is to delete as you go (don't use visibility:hidden).

If you can possibly avoid using direct dom manipulation and instead use setInnerHTML(), this will yeild much better performance. I've seen it work in the order of 100 times faster. It is counter-intuitive, but doing a whole lot of string manipulation and then throwing a string at the browser is much faster. This is because browsers are optimised to render DOM trees from strings.

In your case setInnerHTML might only be helpful if you are trying to delete a number of nodes at the same time. If you are only deleting one node, you're stuck - just try to keep the DOM small.

Hope this helps.

TJez
  • 1,969
  • 2
  • 19
  • 24
  • The thing I found to work best was setting opacity: 0, which is a bit strange, but I guess it's because that is hardware accelerated. I'll give the setInnerHTML a whirl! – Erik Rothoff May 05 '11 at 12:47
  • Setting opacity to 0 is fast because you bypass doing a reflow of the page, since all the dimensions are the same. Consider that keeping the element around will still slow things down for any future manipulations. But if you don't need to worry about future manipulations, then great... opacity is a good solution! – TJez May 15 '11 at 20:12