4 ms·
I spent an inordinate amount of time fighting webkit before switching all of our stuff to native. The four biggest problems, I think, with the state of webkit
by newhouseb 15y ago
I spent an inordinate amount of time fighting webkit before switching all of our stuff to native. The four biggest problems, I think, with the state of webkit are:
1) Implicit memory management of large images/surfaces isn't reliable. There's basically nothing you can do (outside of not doing anything) to prevent your page from crashing webkit if you use too many (where too many is undefined) accelerated elements/total texture space. There's no "Running low on memory" callbacks or means to explicitly remove a recently drawn image from memory outside of removing it from the DOM and crossing your fingers.
2) Lack of proper prioritization in javascript. One of the things that IOS focuses on a lot is separating out user interaction on the main thread from everything else on background threads. In JS, if you're not careful and you do an innerHTML in the wrong spot, you can lock up a bunch of user interaction or delay an AJAX request that would otherwise be executing. Maybe the answer here is something like .updateInnerHTMLWithCallback(function foo(){}) to prevent breakage of JS that does expect the DOM to be consistent after an innerHTML update. (Edit: Oh I forgot, we actually did something similar to this by doing all of our innerHTML updates in setTimeout'ed functions with a 1ms delay). There's a lot of weird stuff around loading images and keeping UI responsiveness then as well.
3) No cache beyond pure source code between separate user sessions. One of the biggest issues for us was initial load time (parsing and calculating CSS, parsing and running JS, and blitting down accelerated DOM elements, etc). Once everything was loaded we could imitate a native-level experience, but this often would be 10-15 seconds in. Perhaps an intermediate cached file (kind of like python's pyc) would help alleviate this.
4) Debugging. This was covered, but ugh, what a nightmare. At a certain point I was booting up XCode instruments and tracing through webkit code to figure out what parts of our JS/CSS/etc to optimize.
- icebraining 15y agoI'm not a mobile webdev, but about (2), did you try using Webworkers for the background tasks? iOS Safari supports it nowadays, right?
- freddywang 15y agoWeb workers doesn't really work. Somehow, It still blocks the main UI thread.
- ef4 15y agoThat's a bummer. I was planning to rely on them soon. Any links to more detail?
- newhouseb 15y agoYeah, but they must be in a separate file, among other things. They're really not feasible for lightweight dispatch like GCD is.
- mcrider 15y agoFor 1) I discovered a hard limit on image sizes a while back when I was writing an (abandoned) Phonegap App: http://bit.ly/J4CT0I http://bit.ly/J4CT0I
- huskyr 15y agoConsidering 4), i just discovered iWebInspector (http://www.iwebinspector.com/ http://www.iwebinspector.com/) which allows using the normal Safari developer tools for the iOS simulator. It's wonderful, free, and i don't really get why i haven't discovered this tool a few months earlier. Would have saved a lot of headaches :)
- noisebleed 15y agoYeah, that's a super useful program. The feature it's based on was only introduced in iOS 5 ( http://hiediutley.com/2011/11/22/debugging-ios-apps-using-safari-web-inspector/ http://hiediutley.com/2011/11/22/debugging-ios-apps-using-sa... ) .. it would have saved me countless hours of misery over the past couple of years if it was possible before.