3 ms·
> Android and Firefox OS both also have a VM to run managed code, along with a JIT compiler. Android's VM, Dalvik, was specifically designed to be memory effici
by Yoric 13y ago
> Android and Firefox OS both also have a VM to run managed code, along with a JIT compiler. Android's VM, Dalvik, was specifically designed to be memory efficient in the case where several apps are running as separate Unix processes. Is the same true of SpiderMonkey?
Short answer: yes, SpiderMonkey has been designed to be quite memory efficient.
> But on top of this, Firefox OS and its apps add:
Actually, let me clarify something, if not for you, then for our readers: "on top of this" means essentially "on top of the kernel and HAL," rather than "on top of Android."
> [valid points] So how can you say that Firefox OS is more resource-efficient than Android? Perhaps the Android platform developers have gotten sloppy lately, since they're primarily concerned about high-end phones. But that can be remedied.
All your technical points are valid. However, you have not taken into account the fact that Android is much larger than that not to mention, conceptually, very old. Just the Core Libraries, for instance, offer at least three or four ways of reading/writing files. Most of these APIs should be removed for the sake of performance, as they were based on Java 1.0 designs from the 1990s, a time at which industry believed that disk speed would keep improving as fast as CPU speed and that concurrency was too expensive to be used. But these APIs cannot be removed, simply because too much code depends upon them, both in Android itself and in applications that Google would not want to lose. Sadly, this means that all such code is a performance hog, especially on mobile devices, since mobile storage is horribly slow in comparison to PC storage.
Now, while I am less familiar with the rest of the architecture of Android, I seem to remember this is true of many features and that many features are accidentally implemented several times in the kernel, Dalvik, the libraries and/or the frameworks, in the interest of (partial) compatibility with Posix, Linux, J2SE, etc – and tutorials.
While it would theoretically be possible to get rid of all these inter-layer duplications, and to only keep the good APIs, this effectively means breaking too much of both Android itself and of many applications. Google cannot afford to do that, as they would risk driving away all developers and users. Moreover, Google does not need to do that, as Android has always been targeted towards high-end phones. A new operating system, by opposition, with everything to win and nothing to lose, can start from a blank state. Moreover, since Firefox OS offers only high-level APIs and no NDK-style access, it is easier and will remain easier for a number of years, to perform whichever low-level refactorings are necessary to improve performance and/or memory efficiency without breaking applications.
Note that this is almost the reverse of Chrome vs. Firefox. Firefox is burdened by the number of add-ons that need to be supported, and the low-level APIs provided to these add-ons, while Chrome, starting with a blank slate and restricted public APIs, managed to rise the stakes of performance quite harshly.
- mwcampbell 13y agoYour argument is quite plausible. Android has indeed accumulated several APIs: ANSI C, POSIX, various Khronos APIs (OpenGL ES, OpenMAX), a subset of J2SE, and Android APIs (both Java and native, with some overlap between the two). I can accept that offering only web APIs leaves much more room for streamlining the lower layers of the stack. Maybe a future Firefox OS phone will run a new processor that was specifically designed to execute JavaScript. And perhaps my earlier point about HTML+CSS and web layout engines being designed for documents, not UIs, was too handwavy. One might argue that there is a sort of Greenspun's tenth rule of UI toolkits: Any sufficiently complex UI toolkit contains an ad hoc, informally specified, bug-ridden, slow implementation of half of HTML and CSS -- and then probably contains a full Web browsing engine, too. It seems to me that the Web technology stack has plenty of inelegance of its own. But no platform is perfect. Maybe the Web platform, exposed to developers on its own without making the lower layers available, really is the best we've got. Can you explain why you think the Java storage APIs are ill-suited to mobile devices?
- lbenes 13y agoNo, they are not plausible. The whole idea of using HTML, CSS, and JavaScript as the back end technology for a low-end smartphone is nuts. Even the best HTML rendering engines are CPU and memory hogs. CSS was never designed for and is nearly impossible to hardware accelerate, and JavaScript is notoriously difficult to optimize and even the best VMs run orders 3-10x slower than native code, while the JS VM takes up much more memory than the efficient dalvik. All the early reviews of Firefox OS describe it as laggy and slow. For example this one from the verge: "Lag is a major concern — apps took multiple seconds to load, to change toggles, and to make UI transitions"[1] Or this one from CNET: "unresponsive screen makes typing a laborious process requiring painstaking precision. Every action from swiping to tapping onscreen controls takes a beat until you see results, so using the phone for a prolonged period steals minutes of your time... Lag carries into the camera, which is slow to launch, snap, and reset."[2] >"designed for documents, not UIs, was too handwavy" Not for anyone who's had to work with DOM for Web apps. We know all too well as its name suggests that it was never designed for apps and is well past its expiration date. My 3yr old similarly spec'd SGS runs CM 10, Jellybean like a champ. My mom's worse spec'd 3GS is still smooth and fluid. Of course, a low end Android phone running the most resource intensive skin, TouchWiz, is going to perform poorly, but in my experience vanilla AOSP scales down quite nicely on low-end hardware. So how does this phone benefit Joe User? It's an android kernel, but the user is cut off of the diverse android app ecosystem. The performance looks terrible, and the user is locked into the Firefox browser, like Safari on iOS. [1]http://www.theverge.com/2013/2/24/4024530/ztes-open-is-the-first-official-firefox-os-phone-hands-on http://www.theverge.com/2013/2/24/4024530/ztes-open-is-the-f... [2]http://reviews.cnet.com/smartphones/geeksphone-keon/4505-6452_7-35619072.html http://reviews.cnet.com/smartphones/geeksphone-keon/4505-645...