Today we are delighted to share these app has hit more than 100 million monthly active users. It's the fastest-growing version of Facebook to reach 100 million users in under nine months. It has an APK that is less than 1 MB in size, meaning people can download it in seconds even on slow connections. The app now supports 56 languages and is most popular in Brazil, India, Indonesia, Mexico, and the Philippines.
Why Facebook Lite
It's important to us for everyone to have a great experience using Facebook on their phone, no matter the device they're using or the connection they are on. Because of various network conditions and types of hardware, experiences can differ. Although 2G mobile networks cover up to 96% of people globally and are used for basic data connectivity by over half the world’s population, at least 1.6 billion people still live in places where mobile broadband networks (3G and 4G) are not available, making data access difficult. Even for people on 3G networks, the intermittency and stability of the connection are often the biggest barriers to delivering a great mobile experience.
Through our research in emerging markets and in seeing how people use our apps, we know that cost of data and overall data usage is extremely important to people. So we've been working to reduce data usage for people in emerging markets when they want to access Facebook. In addition to continuing to improve how the Facebook for Android app performs on 2G networks, we introduced Facebook Lite in 2015 to address those constraints. Our goal when we launched was to deliver a lightweight, fast, and native Facebook experience for people using typical Android phones and network connections in emerging markets.
To reach the APK size target, the Lite APK doesn't have the product code and resources found in a typical Android app. The Lite client is a simple VM that provides various capabilities to interact with the OS (such as read a file, open the camera, create an SQLite database, and so on) and a rendering engine to drive the Android UI. Product code is written on the server and is expressed in terms of the capabilities the client has. Resources are sent down from the server as needed and cached. So it has infinite scalability for building additional product without bloating the APK.
The Lite architecture is designed to let the server side do the heavy lifting, which enables the app to work well on very low-powered devices, like the LG Optimus ME. The server fetches data from the Facebook backend services and sends down screens to the client in the form of a compressed UI tree similar to a DOM, which the client then renders. As a client talks to only a single server in a session, the server can push data to the client in addition to the client requesting data.
Instead of using HTTPS, Lite uses a custom message protocol over TLS (directly over TCP). Compressed message exchange takes place over the persistent TLS connection the client establishes to the server for the duration of the session. This design opens the door for a lot of optimizations that help with reducing data usage and performing on 2G networks.
Lite has a set of image servers that talk to the CDN and other image stores to enable the Lite server to serve exact-size images to the client.
Small APK size
Downloading a typical app with 20 MB APK can take more than 30 minutes on a 2G network, and the download is likely to fail before completion, due to the flaky nature of the network. Restricting our APK size makes it easier for people to download it. This also means that people have to use less data to upgrade the app. Thus, we took significant care to minimize the app's APK size. As mentioned before, the app is designed so that the client is a generic VM and the product code is on the server. Elements that tend to bloat APKs, like translations of strings and PNG resources, are sent down from the server on demand and cached rather than built into the APK. In various places, to save data and size, we use Unicode symbols instead of image resources to represent icons.
Optimizing for slower connections and data efficiency
Lite's network stack optimizes for working on 2G networks and reducing data usage. To achieve an extremely byte-efficient wire protocol, instead of using HTTPS, Lite uses a custom message protocol over TLS (directly over TCP). One of the biggest pain points in a 2G network is that establishing a connection can be very slow; it can take multiple seconds. As most Lite traffic flows over a single connection to the backend, this pain point is mitigated in comparison.
Taking advantage of the fact that the client talks repeatedly to the same server, dynamic shared dictionary compression is applied to messages across a session. We use LZMA2 compression for server-to-client messages due to the great compression ratio as well as the low resource usage in decompression. We use DEFLATE for client-to-server messages.
These design choices help Facebook Lite achieve best-in-class performance metrics on interactions like login, start-up time, pull-to-refresh, and image-loading times on low-bandwidth intermittent networks.
With Facebook Lite, our goal is to provide the best possible Facebook experience to everyone, no matter their device or connection. And we hope that by sharing how we built the app, we can encourage more people to build for the next billion coming online.
Why Facebook Lite
It's important to us for everyone to have a great experience using Facebook on their phone, no matter the device they're using or the connection they are on. Because of various network conditions and types of hardware, experiences can differ. Although 2G mobile networks cover up to 96% of people globally and are used for basic data connectivity by over half the world’s population, at least 1.6 billion people still live in places where mobile broadband networks (3G and 4G) are not available, making data access difficult. Even for people on 3G networks, the intermittency and stability of the connection are often the biggest barriers to delivering a great mobile experience.
Through our research in emerging markets and in seeing how people use our apps, we know that cost of data and overall data usage is extremely important to people. So we've been working to reduce data usage for people in emerging markets when they want to access Facebook. In addition to continuing to improve how the Facebook for Android app performs on 2G networks, we introduced Facebook Lite in 2015 to address those constraints. Our goal when we launched was to deliver a lightweight, fast, and native Facebook experience for people using typical Android phones and network connections in emerging markets.
To reach the APK size target, the Lite APK doesn't have the product code and resources found in a typical Android app. The Lite client is a simple VM that provides various capabilities to interact with the OS (such as read a file, open the camera, create an SQLite database, and so on) and a rendering engine to drive the Android UI. Product code is written on the server and is expressed in terms of the capabilities the client has. Resources are sent down from the server as needed and cached. So it has infinite scalability for building additional product without bloating the APK.
The Lite architecture is designed to let the server side do the heavy lifting, which enables the app to work well on very low-powered devices, like the LG Optimus ME. The server fetches data from the Facebook backend services and sends down screens to the client in the form of a compressed UI tree similar to a DOM, which the client then renders. As a client talks to only a single server in a session, the server can push data to the client in addition to the client requesting data.
Instead of using HTTPS, Lite uses a custom message protocol over TLS (directly over TCP). Compressed message exchange takes place over the persistent TLS connection the client establishes to the server for the duration of the session. This design opens the door for a lot of optimizations that help with reducing data usage and performing on 2G networks.
Lite has a set of image servers that talk to the CDN and other image stores to enable the Lite server to serve exact-size images to the client.
Small APK size
Downloading a typical app with 20 MB APK can take more than 30 minutes on a 2G network, and the download is likely to fail before completion, due to the flaky nature of the network. Restricting our APK size makes it easier for people to download it. This also means that people have to use less data to upgrade the app. Thus, we took significant care to minimize the app's APK size. As mentioned before, the app is designed so that the client is a generic VM and the product code is on the server. Elements that tend to bloat APKs, like translations of strings and PNG resources, are sent down from the server on demand and cached rather than built into the APK. In various places, to save data and size, we use Unicode symbols instead of image resources to represent icons.
Optimizing for slower connections and data efficiency
Lite's network stack optimizes for working on 2G networks and reducing data usage. To achieve an extremely byte-efficient wire protocol, instead of using HTTPS, Lite uses a custom message protocol over TLS (directly over TCP). One of the biggest pain points in a 2G network is that establishing a connection can be very slow; it can take multiple seconds. As most Lite traffic flows over a single connection to the backend, this pain point is mitigated in comparison.
Taking advantage of the fact that the client talks repeatedly to the same server, dynamic shared dictionary compression is applied to messages across a session. We use LZMA2 compression for server-to-client messages due to the great compression ratio as well as the low resource usage in decompression. We use DEFLATE for client-to-server messages.
These design choices help Facebook Lite achieve best-in-class performance metrics on interactions like login, start-up time, pull-to-refresh, and image-loading times on low-bandwidth intermittent networks.
With Facebook Lite, our goal is to provide the best possible Facebook experience to everyone, no matter their device or connection. And we hope that by sharing how we built the app, we can encourage more people to build for the next billion coming online.
0 comments:
Post a Comment