What's different about Firefox for Android
I've been working for the last six months on Firefox for Android (also
known as "Fennec"). Here are some thoughts about the challenges in building a
mobile browser, and the particular choices we've made.
Along the way, I'll try to answer some frequently-asked questions, like "Why
is Firefox so huge on Android?" and "Why should I care?"
Why
People often ask us why Android needs another web browser. These are a few
things Firefox does that other Android browsers don't:
Syncs bookmarks, tabs, history, passwords, and form data
to and from your phone. Firefox Sync and the Firefox Awesomebar help you
enter URLs and passwords with less typing, and move seamlessly between your
desktop and your mobile phone.
Allows extensions to customize every part of the user interface.
Adblock Plus and NoScript are two mobile Firefox add-ons that take
advantage of this deep extensibility. (Note: both are compatible with the
last stable release of Firefox for Nokia Maemo; they'll need to be updated
to support the pre-release Android versions.)
Uses the Jaegermonkey JIT, which is getting faster all the
time. It runs JavaScript much faster than the Android 2.1 browser, and is
starting to overtake the Android 2.2 browser on the benchmarks in SunSpider
and similar suites.
Supports web technologies like SVG, ECMAScript 5, WebM, and HTTP Strict
Transport Security. Firefox for Android currently scores 217 points plus 9
bonus points on html5test.com. (Warning: Those
tests can be deceptive; use them as a starting point for comparison only.)
Another difference is that Firefox is built by Mozilla, a non-profit
organization with a mission to promote openness, innovation, and
opportunity on the web. We want our work on the mobile web to benefit
everyone, not just Firefox users - just as Firefox on the desktop helped
create a new era of innovation and standards for users of all web browsers.
Competition and choice
There are many other browsers for Android, but all of them use the built-in
WebKit rendering engine (except Opera Mini, which uses a proxy server for
rendering). The same is true for Apple iOS, which is also based on WebKit
– as are the latest versions of BlackBerry, Symbian, and Palm webOS.
There's nothing wrong with WebKit. It's a great project. But a growing
number of mobile sites work only on WebKit (or even just on iOS or Android).
This is dangerously similar to the web ten years ago, when Internet Explorer
had an overwhelming market share and many sites used IE-specific markup. This
made it very hard for other browsers to compete, which killed the incentive
for the dominant browser to keep improving.
Upcoming platforms like MeeGo and Windows Phone may give WebKit some real
mobile competition - but many users still won't be able to choose new browser
technology without buying new hardware (and often new service contracts). We
think people should have a meaningful choice of browsers on their existing
phones, just like they do on their computers.
Reusing vs. extending
Part of the point of Firefox is to provide an alternative to the built-in
browser engine. Firefox for Android is built on the same Gecko engine as
Firefox 4 for desktop. That's how it can add new capabilities like
Sync, SVG, and ES5.
Many mobile platforms do not allow browsers to include low-level components
like JIT compilers. On platforms like BlackBerry that support only "managed"
languages like Java, this is true for technical reasons. On others like iOS,
it is forbidden purely as a policy decision. Fortunately there are still
platforms like Android, webOS, and Maemo that let apps bundle any libraries
they want.
Although Android allows us to distribute our own rendering engine and
JavaScript compiler, it really is not built with applications like Firefox in
mind. Many Android phones were built with around 64 MB to 512 MB for apps.
Users who think nothing of a 12 MB download to install Firefox or Chrome on a
laptop will certainly think twice before installing it on one of these phones!
Fortunately storage space is much larger on most new phones, but this is still
an issue on existing hardware.
Android NDK packaging: Problems and solutions
Android's WebKit libraries are installed on the system partition, and are not
part of any app. Firefox doesn't have that luxury; its must include the Gecko
libraries in its APK file.
Due to a quirk of the Android NDK, apps' native libraries are saved in two
places - compressed inside the APK, and extracted to a folder for loading.
For apps like Firefox that are mostly native code, this more than doubles the
installation size. Current pre-release versions of Firefox use 30 to 40 MB of
storage. Other NDK apps like Google Earth pay the same double storage
penalty.
To solve this problem, Mozilla's Michael Wu is writing a custom dynamic
linker, so Firefox can load libraries directly from the APK without
installing them to a folder. This cuts the installed size in half, but
increases the startup time slightly. For newer phones with 1 GB or more of
internal storage, we might choose to let Firefox take more space but start
faster. On phones with less storage, we can use the custom linker to save
space. We're also working on other ways to make startup faster.
System components have another advantage: They can be optimized for specific
hardware. In contrast, apps usually come in a single flavor for all devices.
Firefox for Android can use ARMv7 features like Thumb-2 and NEON to run as
fast as possible on high-end Android phones - but when it's built with these
optimizations it can't run at all on low-end hardware. To run optimally on
all current hardware, we'd need different builds for different devices. For
now, we are focusing on the current high-end phones, which will likely be next
year's mainstream hardware.
Try it out
To check if your phone is compatible and download a test build, see the
Firefox for Android web page. Our pre-beta nightly builds are already
much faster than the alpha release from a few weeks ago. This is still
pre-release software, and we aren't done stabilizing and optimizing it - but
we are working hard. Let us know what you think!
If you don't want to mess with nightly builds, look for our first beta release
very soon now. Beta 1 will include our first batch of speed and stability
improvements. And beta 2 will include even more exciting changes like the
new Android skin, reduced installation size, and OpenGL-accelerated
compositing.
If Fennec doesn't work on your phone, you can also test it on
other platforms. And we hope increased choice will encourage all
browsers to innovate and learn from each other, so your mobile experience
will improve no matter which browser you use.
Syndicated 2010-10-04 23:00:00 from Matt Brubeck