Placeholder Image

字幕列表 影片播放

  • [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]

[GOOGLE LOGO MUSIC]

字幕與單字

單字即點即查 點擊單字可以查詢單字解釋

B1 中級 美國腔

為下一個十億用戶打造應用(Google I/O'19) (Build Apps for the Next Billion Users (Google I/O'19))

  • 113 5
    MisoHong 發佈於 2021 年 01 月 14 日
影片單字