週四，Facebook Engineering blog 發表了一篇名爲《Improving Facebook on Android》博文。博文從四個方面(Performance,Data Efficiency,
Networking,Application Size)講述了Facebook是如何優化app保證其在不同國家不同類型Android設備上都能表現出良好性能的。由於原文內容比較
容易理解，這裏就直接給出原文，以使上邊鏈接打不開的同學也能看到。《菜鳥成長史：http://blog.csdn.net/zjbpku》
In an effort to connect the next five billion, Facebook began to shift to a mobile-first company about
two years ago. We trained hundreds of employees on mobile development, restructured internal
teams to build for all platforms, and moved to a fast-paced release cycle.
However, our mission extends far beyond building and delivering the best experience on high-end
smartphones and LTE networks. We want Facebook to work for everyone – no matter the region,
network condition, or mobile device.
To help accomplish this goal, a team of product managers and engineers traveled to Africa to
examine mobile performance in developing countries. We purchased several different Android
handsets to test the latest version of the Facebook app – and the testing process proved to be
difficult. The combination of an intermittent, low-bandwidth network connection and a lack of
memory space on the devices resulted in slow load times and constant crashes. We even burned
through our monthly data plans in 40 minutes.We returned to our offices in Seattle, London, and
Menlo Park determined to enhance theFacebook experience on Android – and soon made major improvements
in performance, data efficiency, networking, and application size.
Performance
In terms of performance, we wanted to improve slow start times on old devices. In the beginning,
we focused on instrumenting the startup path and understanding the bottlenecks. There was no
silver bullet in this process – we needed to carefully identify and remove each potential bottleneck.
For example, we found that start times were slower on single-core devices because too many
features concurrently initialized themselves on application startup. We made sure to defer these
initializations until after startup and, in some cases, until the features are used.
We also wanted the stories in News Feed to load faster. In order to rapidly display cached content
on poor networks, we now fetch stories earlier in the process to allow more time to set up
connections and download News Feed. The cold start path has been automated to ensure that we
prevent further regressions in these areas.These changes reduced start times by more than 50 percent
in the six months following the trip to Africa.
Data efficiency
Next, we realized that data is extremely expensive in emerging markets, and purchasing more
data is often a laborious process. Thus, there needed to be a concerted effort to reduce data
consumption within the Facebook app. Interacting with photos is an important part of the
Facebook experience, but it takes a sizable amount of data to download them. If we could
optimize the download size, we could improve data savings and perceived app performance.
First, we investigated the use of alternative compression formats for image transmission. We built
tools to evaluate the impact of several different compression formats on data sizes and eventually
settled on WebP. It offered both great compression performance and efficient support from
Android. The use of WebP for transmitting Facebook images resulted in data savings of 25 to 35
percent compared with JPG, and 80 percent compared with PNG. This all happened without perceived
impact on quality.The next step was to work on loading images at a resolution that devices had the
ability to handle.In the past, we loaded images at maximum resolution to allow for the zoom-in feature.
However,on these kinds of devices this feature was used infrequently. We changed the process of loading
images to only request resolutions equivalent to the size of the viewport in which the images will
appear. Instead of loading a full image, the device only loads the image it needs to show (such as
a thumbnail, preview, or full image at lower resolution). Of course, if someone wants to zoom-in
on an image, we then download a higher resolution image.Finally, we looked over the process used to
cache and reuse images. We tested a number of potential caching strategies, as well as sizes for our
caches, and fine-tuned both to minimize the evictions for images that could be accessed again.
As was the case with performance, it was important to avoid regressing our data efficiency in the
future. We built automated tests and an elaborate system that can attribute data usage to
individual features. This allows Facebook features to understand their data usage in production
and make adjustments if it increases unexpectedly.The work on data efficiency resulted in a 50 percent
reduction in data use compared with earlier last year.
Networking
We also invested heavily in improving the efficiency and reliability of our networking stack. It was
important to implement more modern networking concepts in emerging markets because our
stacks struggled to perform in regions with intermittent networks.
Facebook was an early adopter of OkHttp, a networking stack open-sourced by Square, and it’s
now the stack used by the Android app. OkHttp allows us to support fast retries for intermittent
network situations, take advantage of the SPDY protocol for faster concurrent network
transmissions, and enable powerful instrumentation across the networking stack.
After switching to OkHttp, it became a goal to decrease the number of reports regarding failed
image loads in News Feed. We fine-tuned our image pre-fetching algorithms and altered the
process through which we queue images for download. The process now ensures that the
images expected to be downloaded next are prioritized in the queue and that no images are stuck
in the queue for too long.In combination with better data usage for images, reports of slow or failed
image loads dropped by almost 90 percent over the past year.
Application size
The most popular mobile devices in Africa have little disk space available, which is a significant
barrier to installing app upgrades. This means that people in developing countries often use older
versions of the app that don’t have up-to-date features or take advantage of the improvements
described in this blog post.Our colleagues in the Facebook London office focused on improving app
size efficiency. They approached this problem by utilizing Google Play’s ability to upload multiple
APKs for different Android OSes and screen resolutions. This allows us to exclude excess code for features or
resources not supported on certain mobile devices.As with the other areas, instrumentation and testability
were important to making sure we could bring the app size down. We now have tools that calculate how
each feature contributes to app size and analyze device size regressions.In the end, the app size has
been reduced by 65 percent compared with the beginning of the year.
What comes next?
Our trip to Africa really highlighted the importance of our work on mobile performance, data
efficiency, networking reliability, and application size for emerging markets. We’ve made a
concerted effort to improve in all these areas and achieved a significant amount of success in the
past year.
The lessons learned have already impacted the development of new features. We test all major
features and changes in poor networking scenarios. We have automated verification for various
performance and efficiency characteristics, which allows the features team to receive immediate
feedback on the impact of their code. We also expanded our playbook to other apps, such as
Messenger and Instagram.We will continue to innovate to make the Facebook experience better in emerging
markets, and share tools and information that can help developers build apps that work well on different
handsets, network environments, and operating systems.
注：以上英文內容來自：Facebook Code https://code.facebook.com/posts/485459238254631/improving-facebook-on-android/