Build for Billion – Android.

Tram Ho

Hello everyone, today we will learn together about Build for Billion in Android. Google’s text is so and we will understand simply how to build applications for billions of users, things to avoid, consider when developing applications.

1. Overview.

As you know, the smartphone market is very large with billions of users – meaning billions of potential customers for you to exploit, to do this requires the application of technology and design. carefully. You not only need to meet the technical requirements, but also make sure the content you provide is new, unique to the user and, importantly, delivers what the user wants and designs according to. exactly that desire. There are also a lot of other issues such as multilingualism, cultural factors, text presentation factors, gender age issues of users in general. Ok so we have finished the introduction to the problem.

2. What do we need to care about?

To solve the above-mentioned problem and achieve the purpose of Build for Billion we have the following basic things to consider:

  • Connectivity
  • Devide capability
  • Data cost
  • Battery consumption
  • Ui and content

3. Connectivity for billions.

The first issue is Connectivity . Google has said that more than half of the world’s users are experiencing applications with 2g networks and we can’t bring them 5g so to improve their experience, optimize. The app is for low-speed connections and provides offline mode by storing data and processing images for optimal performance.

  • Optimize images: Loading images is always a very expensive job, both in terms of hardware resources and network resources, fortunately we have a lot of solutions to this problem such as using lighter image formats. or use third party libraries, etc.
    • Use WebP format images: This one you know for a long time, this image format is usually smaller than png and jpg with the quality of at least almost the same even when accepting lossy, the quality The amount of photos is also not bad And of course we will have faster application load data saving more. And for a long time Android Studio has supported this conversion.
    • Use dynamic size images: This one is more about processing. You will rely on the device (eg configuration, network connection type or screen size, etc.) to request the appropriate image load. If the device is using 2g then we load low quality images only for users to wait longer. In addition, libraries also provide us with a place holder to enhance the experience or to provide a thumbnail image during the loading process.
    • Finally, use the 3rd party library. Lots of libraries and developers also provide us with parameters such as display, output quality, color bit format and so on. You will use these factors to select your library. Google mentioned a few options like Glide or Picasso .
  • Optimize network connection:
    • Building offline mode: This is not just storing or cached data but also arranging requests into the queue so that they can be ready to recover when there is a network connection. If possible, applications should not notify users that the connection has been lost. Only when the user performs an operation that requires a network connection will notify the user to avoid interrupting the experience.
    • Use Room to store data.
    • Avoid duplicate requests: Maximum storage of data can be stored offline. Here Google has introduced about DiskLruCache ( ) you can learn more.
  • Adjust the data connection: The application needs to adapt to the types of network connections that users have as well as changes that may occur during use.
    • Priority bandwidth: For example, when the user has a 4g connection and wifi, of course it must use wifi, you also need to prepare for the case that wifi is turned off and users turn to 4g. Of course, this is an example.
    • Load the existing information for the user, for example, if the user is on a 2g network, when entering the shopping app, you should only load the first page where the user is directly interacting. Other content can be loaded later, such as information on other tabs, for example.
    • Use less bandwidth on slower connections: As mentioned above, you will decide what information to load based on user network connection, for example, loading an image with 2g and wifi is completely different. , with wifi, high-quality images are priority and with 2g then load is priority so when detecting a poor user network, you should only request low-quality images. To do this you can use:

  • Detect network changes and adapt to changes: This part is similar as above, but you will use the broadcast CONNECTIVITY_CHANGE to listen to the change event and then check the network connection.

4. Device capability for billions.

Smart phone devices come in a variety of sizes and configurations and you have to make sure your application can reach as many users as possible. To do that you need to optimize for many screen sizes, device configuration such as Ram.

  • Support for multiple screen sizes: This you all know and I will list as simple as follows:
    • Use dp unit to display (independent of pixels, note this when custom view)
    • Test, yes test on all screen sizes you want to support.
  • Provide backward compatibility: Not all your users are using the latest, best version of Android platform devices. Here are some ways you can improve backward compatibility, making your app available to as many people as possible.
    • Set your targetSdkVersion and minSdkVersion appropriately
    • Using Android Support libraries : One of the most common examples is marterial design, you will need support lib for devices under 5.0 (Devices do not support)
    • Using Google Play services : Google Play services brings Google APIs well and is independent of the Android platform version. You can use features from Google Play services to provide the best Google experience on Android devices. An example might be GcmNetworkManager ( )
  • Use memory effectively: Flexible adjust your memory to ensure compatibility between devices with different RAM configurations. Methods such as isLowRamDevice() and getMemoryClass() help identify memory constraints. Based on this information, you can reduce your memory usage size. For example, you can use lower resolution images on low memory devices.
    • Limit long-running processes: Long-running processes will remain in memory and may slow down the device. For example, you should use Firebase Cloud Messaging (FCM) and GcmNetworkManager to avoid long-running background services and reduce memory pressure on users’ devices.
    • In addition, if you want to take a higher level than you can Benchmark application, Android Studio has supported this for a long time with Android Profiler

5. Reduced data cost for billions.

Data plans in some countries can account for up to 10% of a user’s average monthly income. This means minimizing the download size of the application and allowing users to control how your application uses data that can be of great benefit to many users. Minimize download size also saves space in internal memory. There are several things you can do to help optimize the amount of data your application uses, both over the network and in internal memory.

  • Reduce application size: The asset directory is always the place to make the application size increase. This everyone knows and then someone forgets. The first is:
    • Using vector images, the image format is very small and scalable, so it should be used if possible.
    • In places where vector images cannot be used, use Webp format images.
    • In addition, you can also use Multi Apk to minimize application size for each device type.
    • In addition, you may see some of their large games or applications or separate sections into separate download components, users will select the packages they want to download.
  • Minimize code size: Android has supported this for a long time with ProGuard . You can also enable resource shrinking by setting minifyEnabled=true , shrinkResources=true in your build.gradle file.
  • Support moving the app to an external memory card by installing the android:installLocation card in the application’s Manifest file.
  • Testing cached application memory, such as google chrome, can take up to several hundred megabytes of cached data. I don’t think it’s bad, but I want to say this memory can be very large and this bloat will take up a lot of memory. Make sure you have put your cached data into getCacheDir() – the system can delete the files placed here when needed.
  • Finally, provide network options for users: Many applications in the settings have the option of mobile data network or wifi for users, this is very good for the user experience.

6. Reduce battery consumption.

  • Your application should minimize activity when running in the background and when the device is running on battery power.
  • Limiting the use of sensors, such as GPS sensors, can drain your battery a lot. You can use the API FuseLocationProvider to manage location in a basic way. It provides a simple API for you to specify requirements, such as high accuracy or low battery usage. It also optimizes your device’s battery power usage by storing locations.
  • Restrict Wake Lock . Avoid using Wake Lock because they prevent the device from entering a low power state. This makes the device consume a lot of battery power in the meantime.
  • Use GcmNetworkManager to schedule tasks and allow Google Play services to work on the system. This greatly simplifies common tasks such as waiting for a network connection, charging status, etc. Use GcmNetworkManager to perform unnecessary background activity while the device is charging and connected to the network.

7. UI and content for billions.

  • Fast and responsive user interface: Touch feedback with touchable items: Touch feedback creates an additional tactile feel for the user interface. You should make sure your application provides touch feedback on all touchable elements to reduce application latency.
  • The user interface must always be interactive: The user experience will be very bad if at some point the user cannot interact with the interface they are seeing.
  • Set a goal of 60 frames per second on low-cost devices: Android will refresh the screen at 60 frames per second, meaning that somewhere you have 16ms to make changes. Can consider removing animations on weak devices.
  • Use the boot screen on slow-start applications: These applications often need to load a lot of input data. Designing a startup screen for a few seconds will not bother users instead of having to look at a pure white screen because of loading data for too long.
  • In addition, you should also pay attention to multilingual support and RTl layout to suit different regions and localities: Refer to ICU4J Android Framework APIs or Support different languages and cultures ( https: // developer. )

8. Summary.

Above I have briefly introduced about Build for Billion that Google has instructions. Thank you for following the article. You can also refer to the source of this article at

Share the news now

Source : Viblo