次の10億人のユーザーのためにアプリを構築する（Google I/O'19 (Build Apps for the Next Billion Users (Google I/O'19))

字幕表動画を再生する

[GOOGLE LOGO MUSIC]
00:00:03,690 --> 00:00:06,410 YACINE REZGUI: Next billion users, or NBU,
are countries where half of the population or more
is not connected yet to the internet.
They have a different way to interact
with the internet, a different way to use their smartphone.
And we're going to highlight you all those cases
in this presentation.
First, let's have a situation on the ground.
00:00:28,980 --> 00:00:31,870 As you can see, the next billion users
are spread out, three different continents--
Asia, Africa, and Latin America.
For some of them, internet is just
the beginning of a new era.
00:00:49,880 --> 00:00:52,730 We usually think about the next billion users as something
in the future, something which is not ready yet.
As shown on the map, numerous countries
already part of the internet.
Some countries in Asia as a whole region account
for 50% of the smartphone market--
Vietnam, Philippines, Indonesia, they
are part of the Southeast Asia, which
accounts for 350 million users on the internet.
And India itself accounts for 40 million new users every year.
Again, we usually think as the next billion users
that we have a timeline, we have a time to think about it.
It's already big.
It's already present, and just continue
to be bigger and bigger in the upcoming years.
00:01:45,720 --> 00:01:48,270 For them, phone is not only a device
to connect to the internet, it's the only device
they will have access to you.
So you should not expect your users
to have access to a computer or tablet
to access your applications.
00:02:02,760 --> 00:02:04,880 They have a mobile-only mindset.
And, as an example, Nigeria has only 11%
of the population having access to a computer.
They have an instinct for ubiquitous computing.
In India, 30% of the search made on Google are using voice.
It's not a net case, it's not a power user thing to do there.
It's really normal.
They have natural interaction with the smartphone.
They will use it in all the possible ways.
Lastly, they have a huge demand for localized content.
English is the first language on the internet,
but it doesn't mean it's a language understood
by all the users over there.
They don't only want translated content.
They want content adapted for them-- for their culture,
their environment.
00:02:56,320 --> 00:02:59,739 Also, you should expect users to change their language quite
often based on the environment--
Maybe at work with family, with friends,
based on that current location.
They will just continuously change language.
It's not something rare for them.
It's really often.
00:03:17,280 --> 00:03:21,540 As shown on the map, numerous countries who are NBU
are part of Asia and Africa.
Both continents accounts for 119 official languages.
In India, you have 314 million people
who can speak two languages and sometimes even more.
Again, in India, you had 23 official languages written
in 13 different scripts.
It brings some challenges in terms of content display
and font-swapping.
00:03:55,550 --> 00:03:59,330 Hindi, which is one of the official languages in India,
is not even on the top 30 languages in the web,
even though it's the fourth most spoken language
around the world.
Nigeria itself as a country has 500 spoken languages
around the whole country.
Even though English may be the official language there,
people will use their local language because, again, it's
part of their culture.
You cannot deny that.
00:04:27,840 --> 00:04:32,489 Also, they have another diversity in terms of hardware.
They will have different devices, different brands.
And you have to account for them whenever you are
developing your application.
00:04:43,240 --> 00:04:46,300 Some of them you may already know, some OEMs.
Obviously Samsung is there.
But also some Chinese OEMs, as Huawei,
Oppo, OnePlus, and Xiaomi.
In Nigeria, you have also Everyone.
And in India, you have MicroMax.
Transsion is the first Android Go OEM around the world.
And maybe you've never heard of it.
They have commonly lower specs devices,
but you should not target only those.
You should think about it as a spectrum.
Some people may have higher spec devices, some of them lower,
and you have to account for all of them.
00:05:24,270 --> 00:05:27,440 Lastly, they have long wear hardware upgrade.
You should think about it whenever
you estimate your operational costs developing an application
targeting those markets.
00:05:39,050 --> 00:05:42,650 We usually think about offline as a narrow state.
You're in a plane, in a train, in a building where
the signal is not strong.
Well actually, it can be a choice for them.
Offline usually is just a temporary mistake,
the way we think about it in Western countries.
But in those NBU countries, 95% of the users
are on prepaid plans.
Even though 4G and 3G is definitely
cheaper years after years, people just turn it off
whenever they don't need it.
So whenever you're showing a banner, you're not connected,
well, they're already aware of it.
They are the one who set it off.
00:06:24,770 --> 00:06:27,770 Also, Wi-Fi is not always reliable.
So you can't expect people to download resources
over Wi-Fi because they may not have it at home.
Sometimes 4G is even faster than Wi-Fi.
00:06:39,550 --> 00:06:42,010 Some websites may be also offered
for free, on mobile plans, or restricted
by government regulation.
So whenever you're integrating with third parties,
think about it whenever you're developing your apps
targeting those markets.
00:06:58,230 --> 00:07:02,220 We usually think about diversity as a problem,
as just too many parameters to account for.
We would love just to have one single standard
but that's just denying their diversity.
We think diversity at Google is not a problem, it's an asset.
It's a growth opportunity for your markets.
00:07:25,300 --> 00:07:30,500 As shown earlier, again, many countries which are NBUs
are part of Asia, which already accounts
for 50% of the smartphone market and will
account for 50% of the upcoming growth
on the smartphone market.
You have to compare that to mature markets
like Western countries where you have
already a huge penetration of internet and smartphone access.
00:07:51,150 --> 00:07:55,380 Over the next 1.6 billion new connections,
40% will come from these top five countries.
Four of them are next billion users--
Nigeria, India, Pakistan, and Indonesia.
Also, the surrounding countries will
be affected by that growth.
So again, think about it, the next billion users are already
there.
And they're just waiting for your apps
to be compatible with them.
Now I'm going to hand over to my colleague, Rajeev--
Amrit, my bad-- is going to talk about improving
your application by adopting Google products that
can help you to do that.
To you, Amrit.
AMRIT SANJEEV: Thanks, Yacine.
00:08:42,110 --> 00:08:43,280 Hi, everyone.
My name is Amrit Sanjeev.
I'm a developer advocate at Google based in India.
And, in this section, I want to talk about some
of the Google products that you can use in order
to help give a better user experience for your users
in the NBU market.
Let's start with app bundles.
App size is a key factor that users
consider when they install an app in these markets.
By switching an upload format to app bundles,
you allow player to distribute an APK that's
optimized in terms of resources, code, and languages
based on your device's configuration.
This helps greatly reduce the initial install size
of the application and also the install friction
that users have.
I want to call out an example here--
RedBus, which is a ticket-booking app from India
who switched over to app bundle format
and reduced their APK size by 30%.
This, in turn, helped them increase their conversions
by 6%.
And the best part of it is that they
didn't have to change a single line of code
to achieve this result.
To optimize even further, you can
choose to deliver functionality as on-demand
rather than package it all together
in the initial install.
This can be achieved by using the on-demand feature
with app bundles.
By adopting on-demand features, you
not only reduce the initial install size,
but also the space that you actually take on the device.
A lot of users run out of space on devices in these regions
regularly.
The other important factor is that based on usage,
you can choose to remove modules and save space for the user.
An example I want to call out is PayTM,
who initially reduced their app size using app bundles
and then further optimized by removing some of their modules
as on-demand modules, and reduced the app
size by a further 20%.
00:10:49,720 --> 00:10:50,960 And they're not done yet.
They're making further changes and improving on this number
even further.
To extend this even further, you could use conditional modules
to install certain modules based on your device
configuration or user's locale during the initial install.
Let me explain this with an example for you guys.
Assume that you have an app which you want to release it
to two different countries.
But in each of these countries, you
have completely different payment instruments
of support, which would mean that you would have
completely different workflows, assets, and libraries required
for realizing each of the payment workflows.
One way of doing this would be to package all of this
into a single payment module and, at runtime,
decide which workflow to show to the user
depending on which locale he is using the app from.
With conditional modules, you could actually
separate this into two different modules and during install time
decide which module needs to be packaged with the app based
on the user's locale.
That way your device would only get
the portions of code and the workflow that it will ever use.
The second payment module will not be there at all.
00:12:12,390 --> 00:12:15,260 As Yacine mentioned, BOU countries
have a lot of official languages.
For example India, has 23 official languages.
But the interesting thing here to note
is that users usually set their device language to be English.
And it's a very common practice for applications
which cater for these markets to have an in-app setting where
users choose the language for localizing content
on their app.
Now, when you take app bundles for instance,
app bundles use the device language
to optimize what language resources need
to be packaged along with the APK during the installation.
And with language splits API, you actually
bring the best of both worlds.
Using this API, the developed can then
fetch additional language resources
for different languages, say, when
the user is selecting a new language from the settings.
00:13:09,820 --> 00:13:12,140 I talked about install size for some time.
Let's talk about how app upgrades happen in this region.
App upgrade cycles are usually longer,
which means you will end up having situations where you
will have more versions of your app in the real world
to support.
This has side effects.
It not only increases your operational cost,
but you have to deal with situations where
users negatively rate your app for bugs
you have already fixed.
But they are still experiencing it
because they never upgraded it.
Now, in in-app upgrade API helps you fix some of these problems.
It allows you to show a dialog to the user informing them
that a new update is available.
The best part of this API that it actually
takes into account the player's targeting rules
before showing it to the user.
That is, if your stage is rolling out only 5%
of your users, only those 5% of users
actually see the upgrade dialog.
It's the same case with people who are on a different channel,
say your alpha channel of your application.
And you release only to alpha, only those users
will actually see this.
00:14:22,740 --> 00:14:25,110 I want to now switch over to SMS.
Two-factor authentication is very common in NBU countries.
This is because a lot of payment modules
are actually two-factor authentication based.
And more and more applications are
requesting for SMS permission to ensure
that they can make the OTP flow much more smoother
by auto-filling it for the user.
But with growing privacy concerns, a lot of users
are reluctant to give this permission, and also
worried about how much information they're
passing to an app by giving them complete access to their SMS
inbox.
Last year, we introduced SMS Retriever API, which kind of
solved this problem to a good extent,
where an OTP message could be passed through an application
without the user giving this permission.
But it required the SMS message to be
formatted in a certain way.
To be more precise, it a hash code towards the end of it,
which allowed the API to identify
that the particular OTP message is
for a particular application.
That's great when the SMS are sent
by the application's service.
But imagine a case of a bank application.
They have to deal with hundreds of applications
or thousands of them.
And in such cases, you will have to do a look-up
to figure out which hash code has
to be attached to the end of the message
before you send it out to the client.
And that's kind of inefficient.
So that's where the SMS and the API comes into the picture.
The workflow remains pretty much the same.
But in this case, when the OTP is actually
received on the device, that is the OTP message
is on the device, the system would recognize
using some smarts-that hey, this is an OTP message,
and short dialog to the user asking him
permission to pass that message to the application.
If the user approves it, the OTP message
is passed to the application, and the rest of the flow
can automatically continue.
The advantage here is that there is no additional formatting
required.
There's no SMS permission required for this.
I want to call out an example here,
of Zomato, which is a food delivery and restaurant booking
app from the region, which was able to remove SMS read
permission completely from their application by using this API.
They were part of our early access program.
And they've reported to us that their user flow has now
improved in speed and users are having a much better experience
because of this.
Moving on to real world performance,
no matter where you're launching your app,
understanding the real world performance of your app
is really important once you ship it.
But it's even more critical in NBU markets because
of the plethora of devices available there
and the wide range of conditions, hardware,
network situations prevalent in these regions.
Firebase Performance Monitoring SDK
is one such SDK that you can add to your app, which will then
collect statistics automatically,
visualizes it, and even identifies
and highlights problems for you.
This allows you to fix problems before users actually see this,
giving a better experience for your users.
I want to highlight the work that [INAUDIBLE] apps
did with data that they actually derived from these Firebase
Performance consults.
They were able to reduce their apps cold start-up time
by 50% for users on the 2G network.
And this gave a great experience for those users.
They used the data that was visualized by Firebase Console
and identified an issue with which
was particularly happening on 2G networks, and fix this,
immediately giving a better experience for the users.
And lastly, I want to talk about localization.
When we talk about localization, a lot of times people
think about the language in which
the content is shown on the device or within the app.
Now, that's absolutely important-- no doubt.
But there are other things that you can do in this aspect.
You could use things like localized graphics and store
listings based on the user's language and Play Console.
This helps improve conversions for your app.
We have recently introduced country-based targeting, which,
again, is targeted towards using--
targeted towards improving user conversions for your apps.
One of our early access partners, Cookbook
actually increased conversion rates
by 17% using this feature.
If you want to understand more about what they did,
they wrote an excellent blog about it.
And you should check that out.
00:19:26,540 --> 00:19:28,540 And, lastly, I want to call out that this is not
an exhaustive list of products you can use.
I've only called out a few of them here,
which basically has given a lot of advantages
to some of our partners who cater for these regions.
Now I'd like to hand it over to my colleague Rajeev, who
talk to you about how to optimize
apps for low-end devices.
Thank you.
[APPLAUSE]
RAJEEV KUMAR: Thank you.
00:19:53,010 --> 00:19:54,650 Thanks, Amrit.
Hello, everyone.
My name is Rajeev Kumar.
I work on Android Go project.
And Android Go is a platform for devices running 1GB or less
RAM, minimum eight gigs of internal storage,
and low-end CPU codes.
Today, I'm going to talk about some of the best practices
that me and my team has used to optimize apps on disk,
to optimize the apps on RAM.
And I'm also going to talk about some of the techniques
we use to keep apps responsive.
So let's talk about APK size.
Why does APK size matter?
It matters because it impacts the time it
takes to load your application.
It also impacts the RAM it takes to load your application.
And it also impacts the battery it
takes to load your application.
So what can you do to reduce your APK size on disk?
Use Proguarding.
It really helps.
We have used Proguarding on systems apps like Launcher
and Bluetooth APK.
And just by enabling Proguarding,
we were able to gain around 25% of disk space.
But [INAUDIBLE] your public API and Proguard flags the
file so that you don't wipe it out with Proguarding.
So how could you learn more about your API structure?
We have used APKAnalyzer tool to look
at what part of application is contributing to the APK size.
And let's say you determine the APK size was bigger
because of the resources, you would
be able to use Shrink Resources together with [INAUDIBLE]
Enable in your [INAUDIBLE] project to reduce your APK
size significantly.
What else you can do?
You may consider to use specific densities.
For example, you can target MDPI for certain devices
and therefore not include resources for higher density.
00:22:17,620 --> 00:22:21,810 As Amrit mentioned, the app bundles
could also help to reduce your APK size
or your initial download size.
Let's take an example.
The Photos app can have the viewing capability as well as
the editing capability.
You may decide to not include editor to begin with,
and only download the reader module when
a user clicks on the editing part of the application.
You may also consider to use reduced set up
language in your application, and therefore your resources
is going to be smaller, and APK size is
going to be a smaller as well.
00:23:04,163 --> 00:23:08,050 Now, continuing on the theme of reducing your APK size,
let's talk about the MA size in your application.
How can you reduce MA size in your application?
Consider compressing PNG and JPEG, crunching PNG files,
and, if possible, use WebP file format,
which is great on saving the disk size
and has a decent rendering performance.
You may consider to use vector graphics
for reducing independent icons in a scalable media.
By doing so, you would not be including the static resources.
And, therefore, your APK size is going to be a smaller.
What else you can do?
Avoid enumerations.
A single enum can take up to 1 to 1.4 kilobytes
size in your cluster to desk file.
If possible, use [INAUDIBLE] with Proguarding, and it
will replace your enumeration built into your constants.
Remove debug symbol from your native binaries.
They are great for developing your application.
However, it can take significant amount of APK size.
And, while extracting native libraries,
by doing so, you will be instructing packet manager
to not to copy .SO file from your application to the file
system.
And as a nice side effect, your update size
is going to be a smaller.
00:24:41,450 --> 00:24:47,180 Now I want to talk about how to reduce your app size in RAM.
So how would you monitor your app size in RAM?
Use Android Compiler, which comes with Android Studio,
to generate heap dump for your application.
You may also use the ADB command,
which is ADB shell am dumpheap to generate Java heap dump as
well as native heap dump.
And with the debug working on your application
and with these heap dumps, you would have a pretty good idea
about what part of your application
is contributing to the RAM size.
00:25:23,920 --> 00:25:28,300 So let's say system is under memory pressure.
What can you do to reduce memory pressure on the system?
For this, the activity manager service
provides a callback called on prem memory, which
you can implement in your activity
and can release resources and cache objects
to reduce memory pressure on the system.
What else?
Do not create unnecessary processes
unless they are short-lived.
Long-lived processes can contribute to the memory
of your application.
Use services sparingly.
If possible, consider using Java Scribbler,
which is constraint-aware.
It can take into account the system memory
pressure, the network conditions,
as well as the battery.
Consider using optimized data containers, which
are array map, array set, sparse array, sparse Boolean array,
longest sparse array.
These are optimized for using memory efficiently,
and can save your app to have less RAM size.
00:26:42,070 --> 00:26:46,210 Continuing on the theme of reducing APK size in RAM,
you should consider avoiding memory churn
by reducing the number of garbage collection events
to occur.
And for this, you should avoid allocating objects
in the performance-critical area of your application.
And those areas are on layout, on draw, on major, et cetera.
00:27:11,570 --> 00:27:15,510 I talked about reducing the memory churn
by reducing the number of garbage collection.
It not only impacts the memory but it also
can impact your app responsiveness
by eating your app's frame.
So now in this slide I'm going to talk about how
to keep your app responsive.
And, for that, start with do not drop data.
Let's say you are an email application
in which [INAUDIBLE] composing an email,
and some other application saves on top.
In this case, you want to save data
so that when your application comes back again on top,
you want it to store data so that user does not lose data.
Do not expose raw data.
Consider using content provider, which is the consistent way
to sell your data across application,
within your application as well.
Do not interrupt user.
Consider not to call a start activity
from broadcast receiver or from a background service.
If possible, consider using notification manager to set up
a notification to which you can come back to your application
by looking at that notification.
Got a lot to do?
Consider doing it in a thread, maybe in a background thread
to avoid any long-running processes running
in your main thread.
If possible, you may also consider
to use the JavaScribbler for the processes which are
going to take longer duration.
As I mentioned earlier, it is constraint-aware
and can scribble your job when system is processing your job.
Do not overload signal activity for the devices of--
devices.
You may consider your application
as a federation of activity.
And by doing so, you would be making your application
more maintainable.
And, as a nice side effect, it will work well
with the application history and the backstretch model.
00:29:27,580 --> 00:29:30,490 Continuing on the theme of keeping your app responsive,
design your UI so that it works with different screen sizes.
Your resources, your images sort of scale up and down based
on the screen sizes.
And, lastly, do conserve device battery.
A mobile device is not so mobile if it is constantly
connected to the wall charger.
Two of the main contributors of the battery drain
are the processor and the radio signal.
So it's important to do as little processing as possible
and to use network as infrequently as possible.
00:30:14,410 --> 00:30:17,140 Now, this brings the end of our presentation.
But by no means this is the [INAUDIBLE] list
of techniques and best practices you
may use in your application.
To learn about the full list of practices and techniques,
you can go to developer.androi d.com/performance.
We hope this presentation may have helped you to learn more
about the techniques you can use for making
your application have a level for next billion users.
Thanks a lot.
[GOOGLE LOGO MUSIC]