
Korean: 
안녕하세요
R8 코드축소에 대한 이번 회의에
참석해 주셔서 감사합니다
제 이름은 소렌 계서입니다
저는 소프트웨어 엔지니어이자
R8 프로젝트의 기술 책임자입니다
회의의 주제를 말씀드리겠습니다
먼저 R8의 관점에서
코드축소의 의미를 간단히 살펴본 후
R8을 통해 어떤 자원을 절감할 수 
있는지 말씀드리겠습니다
그런 후 코드축소
절차를 어떻게 진행하는지와
Android 스튜디오에서
구성되는 방식을 개관하겠습니다
다음 순서로 크리스토퍼 아담슨씨가
우리의 고급 코드축소 알고리즘에 대해 
자세히 설명해 드리겠습니다
R8 코드축소란 무엇일까요?
R8에서의 코드축소란 크기에 맞추어
코드를 최적화하는 것입니다
즉 앱 내 코드의 양을
최대한 줄이는 것입니다
Android의 경우 앱 내 텍스트 
파일의 크기와 관련 있습니다
크기가 작은 앱은 여러분과
생태계 모두에 도움이 됩니다
특히 신흥 시장에서
더 많은 설치가 이루어질 것이며
더 많은 사용자가
휴대전화에서 여러분의 앱을

Spanish: 
[música]
Buenas tardes
y bienvenidos a esta presentación
sobre reducción con R8.
Me llamo Soren Gjesse.
Soy ingeniero de software y director
de tecnología de proyectos con R8.
Esta es la agenda
de nuestra breve presentación.
Primero, definiré la reducción
en relación con R8
y les daré una idea
de lo que pueden ahorrar
mediante su uso.
Luego, describiré el proceso de reducción
y su configuración en Android Studio.
Por último, Christoffer Adamsen
hará un resumen
de uno de nuestros algoritmos
más avanzados.
¿Qué es la reducción con R8?
La reducción con R8
es optimizar el tamaño del código.
El objetivo es reducir
la cantidad de código de su app
tanto como sea posible.
Para Android, deben reducir el tamaño
de los archivos de texto de la app.
Una app chica
los beneficia a ustedes y al ecosistema.
Implica más instalaciones,
especialmente en mercados emergentes.

English: 
[MUSIC PLAYING]
SOREN GJESSE: Good afternoon,
and welcome to this talk on R8
shrinking.
My name is Soren Gjesse.
I'm a software engineer and a
tech lead on the R8 project.
So this is the agenda
of this short talk.
First, I'll touch briefly
upon what shrinking
means from an R8
perspective followed
by giving you an idea of
what you can potentially
save by using R8.
Then I'll give an overview of
how the shrinking process works
and how it's configured
in Android Studio.
Then Christoffer Adamsen
will take over and give you
a detailed rundown of one of
our more advanced shrinking
algorithms.
So what is R8 shrinking?
Well, in terms of R8, shrinking
means optimizing code for size.
It's all about reducing the
amount of code in your app
as much as possible.
And for Android, we are
talking about the size
of the text files in the app.
Having a small app is a benefit
for both you and the ecosystem.
It means more installs,
especially in emerging markets,
and also means that more
people are more likely to keep

Indonesian: 
Selamat siang.
Selamat datang di presentasi
penyusutan R8.
Nama saya Soren Gjesse,
engineer software dan pimpinan
bidang teknologi untuk proyek R8.
Berikut adalah agenda
presentasi singkat ini.
Pertama, saya akan
membahas secara singkat
arti penyusutan R8, kemudian
gambaran efisiensi yang bisa dicapai
menggunakan R8.
Lalu, dilanjutkan dengan
ringkasan proses penyusutan
dan konfigurasinya di Android Studio.
Kemudian,
Christoffer Adamsen akan menjelaskan
lebih dalam tentang salah satu
algoritme penyusutan kami
yang terbaru.
Apa itu penyusutan R8?
Dalam konteks R8, penyusutan
artinya mengoptimalkan kode demi ukuran.
Artinya, mengurangi
sebanyak mungkin kode
dalam aplikasi.
Di Android, maksudnya 
adalah ukuran
file teks di aplikasi.
Ukuran aplikasi yang kecil berguna
bagi Anda dan ekosistem
karena akan makin banyak diinstal,
terutama di pasar berkembang
dan juga berarti akan ada
lebih banyak orang yang

Chinese: 
[音乐]
下午好，欢迎聆听R8压缩
演讲
我是Soren Gjesse
现为R8项目软件工程师兼技术主管
今天的内容有
首先，我简要介绍一下
R8视角下压缩的含义
然后讲解R8可以精简
哪些内容
之后，我将概述压缩过程的工作原理
以及Android Studio如何配置
然后轮到Christoffer Adamsen
他会详细展示我们的一个高级
压缩算法
R8压缩是什么？
就R8而言，压缩意味着优化代码大小
关键在于尽量减少应用中的
代码数量
对于Android而言，我们说的是应用中
文本文件的大小
应用小巧对个人和生态系统都有益处
这会带来更多安装量，特别是在新兴市场
也会让更多人在手机上

Portuguese: 
Boa tarde e bem-vindos
a esta apresentação
sobre redução com o R8.
Meu nome é Soren Gjesse.
Sou engenheiro de software
e líder técnico no projeto R8.
Esta é a programação
desta curta apresentação.
Primeiro, falarei um pouco
sobre o que é a redução
pela perspectiva do R8.
Em seguida, mostrarei o que você pode
reduzir usando o R8.
Depois, mostrarei uma visão geral
de como os processos de redução funcionam
e como configurá-los no Android Studio.
Depois disso, Christoffer Adamsen
fará um resumo detalhado
de um dos nossos
algoritmos de redução mais avançados.
O que é a redução com o R8?
Nos termos do R8, redução significa
otimizar o tamanho do código.
Trata-se de reduzir
a quantidade de código no app
o máximo possível.
Para o Android, isso significa o tamanho
dos arquivos dex no app.
Criar um app pequeno
beneficia você e o ecossistema,
gera mais instalações,
principalmente em mercados emergentes,
e faz com que mais pessoas

Japanese: 
こんにちは
R8圧縮の講演にようこそ
ソレン ゲシーです
ソフトウェアエンジニアで
R8プロジェクトの技術リーダーです
今日のトークの議題です
R8の観点から
圧縮の意味を説明し
R8で保存できる可能性のあるものの
アイデアを説明します
次に圧縮プロセスの仕組みと
Android Studioでの構成方法の
概要を説明します
後はクリストファーアダムセンが
高度な圧縮アルゴリズムについて
説明します
R8圧縮とは何でしょう
R8では圧縮は
コードのサイズの最適化です
アプリのコード量を
できるだけ減らすことです
Androidの場合 アプリ内の
dexファイルのサイズの話です
小さなアプリはユーザーとエコシステムの
双方にメリットがあります
特に新興市場でのインストールが増え
多くの人が携帯アプリを

Portuguese: 
mantenham o app nos smartphones.
De modo geral,
temos três técnicas de redução.
A primeira é o tree-shaking,
que remove
códigos e estruturas não usados.
Ela usa análises estáticas
para eliminar código não acessível
e remove objetos não instanciados.
A segunda é o uso
de técnicas de compilador tradicionais
para otimizar o tamanho.
A terceira é
a identificação de renomeações,
também chamadas de ofuscações,
o que pode reduzir
os nomes de classes, métodos e campos,
diminuindo o tamanho.
Ela também pode compactar
o namespace do pacote até a raiz.
Além dessas técnicas de redução de código,
temos recursos para reduzir
a quantidade de informações de depuração,
que também se encontram nos arquivos dex.
Qual é o benefício de usar o R8?
Ao escrever um app,
todo o código tem um propósito,
representa algum recurso do app.
Quanto é possível remover?
A resposta é: muito.
Isso ocorre por dois motivos principais.

Chinese: 
保留您的应用
总体上，我们有三种压缩方法
第一种是摇树优化，即去除未使用的代码
和结构
这种方法使用静态分析
去除无用代码
并去掉未实例化对象
第二种使用传统编译器技巧
优化大小
第三种是标识重命名
有时也称为混淆处理
这可缩短类、方法和字段的名称
从而削减大小
它还能将程序包命名空间缩减至根
除了这些代码压缩方法之外
我们还能减少
调试信息数量
这些信息保存在文本文件中
那么使用R8能给我带来什么？
编写应用时，其中所有代码
都各有目的，实现应用的各种功能
那有什么可以移除的呢？
答案是很多
原因主要有两个

Korean: 
계속 사용하게 될 것입니다
모두 3가지의 서로 다른
코드축소 기술이 있습니다
첫 번째 기술은 Tree Shaking으로
미사용 코드와 구조를 삭제합니다
통계 분석을 활용하여
접근 불가능한 코드를 제거하고
인스턴스화되지
않은 객체를 삭제합니다
두 번째 기술은 기존의
컴파일러 기법을 사용하여
크기에 맞추어 최적화하는 것입니다
세 번째 기술은
리네이밍을 식별하는 것으로
종종 코드 난독화라고도 합니다
클래스, 메서드, 입력란의
이름을 줄여서
크기를 축소하는 방식입니다
또한 패키지 네임스페이스를
루트로 압축해 넣기도 합니다
이러한 코드축소 기법 외에도
텍스트 파일 내에 존재하는
디버그 정보의 양을 
줄일 수 있는 방법들도 있습니다
그렇다면 R8을
사용할 때의 이점은 뭔가요?
앱을 작성하실 때
앱에 들어가는 모든 코드는
앱의 특정 기능을
지원할 하나의 목적에 종사합니다
그렇다면 삭제
대상의 양은 얼마나 될까요?
답변하기 간단치 않은 이유는
주로 다음의 2가지입니다

English: 
your app on their phone.
So overall, we have three
different shrinking techniques.
The first is tree shaking,
which removes unused code
and structure.
It use static analysis to
get rid of unreachable code
and remove
uninstantiated objects.
The second is using
traditional compiler techniques
for optimizing for size.
The third is identify
renaming, which is also
sometimes referred to as
obfuscation, which can shorten
names of classes,
methods, and fields,
and thereby reducing size.
It can also squash the package
namespace down to the root.
In addition to these code
shrinking techniques,
we also have ways
to reduce the amount
of debug information,
which is also
resident inside the text files.
So why would I gain
anything from using R8?
When you write an app,
all the code in the app
is there to serve a purpose,
some feature of the app.
So how much is there
actually to remove?
Well, the answer is quite a lot.
And there are two
main reasons for that.

Indonesian: 
menggunakannya di ponsel mereka.
Kami punya tiga teknik penyusutan.
Pertama adalah tree shaking,
yaitu menghapus
kode dan struktur
yang tidak dipakai.
Teknik ini memanfaatkan
analisis statis untuk menghapus kode
yang tak bisa dieksekusi dan
objek tidak dipakai.
Kedua adalah teknik
compiler konvensional
untuk mengoptimalkan ukuran.
Ketiga adalah
identifier renaming, yang
kadang disebut sebagai
obfuscation, yang dapat memangkas
nama class, metode, dan kolom
sehingga menyusutkan ukuran,
juga bisa menekan namespace
paket sampai ke root.
Selain itu, ada cara lain untuk
mengurangi jumlah informasi debug,
yang juga ada di dalam file teks.
Jadi, apa manfaat
menggunakan R8?
Ketika membuat
aplikasi, setiap kode
memiliki suatu fungsi,
yaitu fitur dalam aplikasi.
Jadi, berapa banyak
yang harus dihapus?
Jawabannya: banyak.
Ada dua alasan utamanya.

Japanese: 
保持するでしょう
３つの圧縮手法があります
１つ目はツリーシェイキングで
未使用のコードと構造を削除します
静的分析で到達不能なコードを削除し
非インスタンス化オブジェクトを
削除します
２つ目は従来のコンパイラ手法による
サイズの最適化です
３つ目は識別名の変更です
難読化とも言い
クラス メソッド フィールドの名前を
短縮してサイズを縮小できます
パッケージの名前空間をルートまで
圧縮することもできます
これらのコード圧縮手法のほか
dexファイル内にある
デバッグ情報の量を
減らす方法もあります
なぜR8を使用するのでしょうか
作成するアプリのコードはアプリの機能を
提供するためにあります
実際にどれだけ削除するのでしょう
答えはたくさんありますが
その理由は主に２つです

Spanish: 
También significa
que es más probable que más personas
conserven su app en el teléfono.
En general,
hay tres técnicas de reducción.
La primera
es la eliminación de código obsoleto
que descarta el código
y las estructuras que no se usan.
Aplica el análisis estático
para eliminar código inaccesible
y quitar objetos sin instancias.
La segunda técnica consiste en usar
métodos de compilación tradicionales
para optimizar el tamaño.
La tercera,
que suele denominarse ofuscación,
es cambiar el nombre de identificadores.
Acorta los nombres
de clases, métodos y campos
para reducir el tamaño.
También puede achicar el espacio
del nombre del paquete hasta la raíz.
Además de estas técnicas
de reducción de código,
hay formas de reducir la cantidad
de información de depuración,
que se encuentra en los archivos de texto.
¿Qué ganan por usar R8?
Cuando diseñan una app, todo su código
cumple una función
y atañe a alguna característica de la app.
Entonces, ¿cuánto se puede quitar?
La respuesta es "mucho".
Los motivos principales son dos.

Korean: 
첫째, 모든 앱이 제3자
라이브러리를 사용하기 때문입니다
즉, 여러분의 앱에는 타인이
작성한 수많은 코드가 존재합니다
또한 제3자 라이브러리를 이용할 때
대개 제3자 라이브러리의 극히 일부만이
특정 앱에서 사용됩니다
둘째, 사용되지 않는
코드를 삭제한 후에도
다른 최적화 기법을 통해
남은 코드를
최적화할 수 있는
여지가 있다는 것입니다
따라서 말씀드린 대로
라이브러리 코드가 관건입니다
코드축소 없이
모든 라이브러리 코드를
앱에 남겨둘 수 있습니다
지금 화면에 Jetpack 라이브러리 또는
AndroidX 라이브러리와 같이
널리 사용되는 제3자 라이브러리의 목록이
보이고 있습니다
모든 애플리케이션에서 꽤
많이 사용되는 라이브러리들입니다
죄송합니다
이전 슬라이드로
갈 수 있을까요?
OkHttp은 매우 널리
사용되는 네트워킹 앱입니다
Guava, Gson, 그리고
Google Play 서비스는
자주 사용되는
Google의 라이브러리입니다
Kotlin Standard Library도
여기에
포함된 이유는
Kotlin에서 앱을 작성할 경우
Kotlin Standard Library가
애플리케이션의 일부가 되기 때문입니다
이제 더 자세히
살펴보기 전에 여러분의 앱에서

Japanese: 
第１にすべてのアプリはサードパーティ
ライブラリを使います
そのためアプリには
自分で書かないコードがたくさん含まれます
サードパーティライブラリを使う場合
特定のアプリではサードパーティ
ライブラリのごく一部のみが使われます
第２に未使用コードを削除した後でも
他の最適化手法を使用して残りのコードの
サイズを最適化できます
ライブラリコードは重要です
すべてのライブラリコードが
圧縮せずアプリに保持されます
次の一覧でJetpackまたは
AndroidXライブラリなど
人気のサードパーティ
ライブラリをご紹介します
こうしたライブラリは多くの
アプリケーションで使用されています
すみません
前のスライドに戻ってください
OkHttpは非常に人気の
ネットワーキングアプリです
Guava Gson Google Play Servicesは
Google提供のライブラリとして
よく使われます
Kotlinでアプリを作成している場合
Kotlin Standard 
Libraryがアプリケーションの
一部になるため
Kotlin StandardLibraryも
この一覧リストに記載しています

Portuguese: 
Primeiro, todos os apps
usam bibliotecas de terceiros.
Portanto, seu app tem muito código
que não foi escrito por você.
Além disso, ao usar essas bibliotecas,
geralmente só uma pequena parte delas
é usada no app.
Em segundo lugar,
mesmo após remover o código não usado,
o restante ainda pode ter
o tamanho otimizado
com outras técnicas de otimização.
Como mencionei,
o código de bibliotecas é relevante.
Sem a redução,
todo o código das bibliotecas
é retido pelo app.
Veja uma lista das bibliotecas
de terceiros mais famosas,
como as do Jackpack
ou do AndroidX.
Elas são usadas
em praticamente todos os apps.
Desculpe.
Você pode voltar um slide?
O OkHttp é um app de rede muito famoso.
Guava, Gson e Google Play Services
são bibliotecas
fornecidas pelo Google muito usadas.
Veja que a Kotlin Standard Library
também está nesta lista,
porque, ao escrever um app em Kotlin,
a Kotlin Standard Library
se torna parte do app.
Antes de vermos mais detalhes,

Spanish: 
En primer lugar, todas las apps
usan bibliotecas de terceros.
Por ende, su app contiene
mucho código que ustedes no escribieron.
Además, solo suele usarse
una pequeña parte
de esas bibliotecas
en una app específica.
En segundo lugar, incluso después
de quitar el código que no se usa,
puede optimizarse
el tamaño del código restante
con otras técnicas.
Como vimos,
el código de la biblioteca es importante.
Sin ninguna reducción,
todo su código permanece en la app.
Aquí tenemos una lista de algunas
bibliotecas de terceros más populares
como las de Jetpack y AndroidX.
Casi todas las apps las usan.
¿Podemos volver a la diapositiva anterior?
OkHttp es una app de redes muy popular.
Guava, Gson y los Servicios de Google Play
suelen usar bibliotecas de Google.
Observen que la biblioteca
estándar de Kotlin también está en la lista
porque, si diseñan una app con Kotlin,
esa biblioteca
formará parte de su app.
Antes de entrar en mayores detalles,

English: 
First of all, all apps
use third-party libraries.
So there's a lot of code in your
app that you have not written.
And also, when you use
a third-party library,
typically only a very small
part of a third-party library
is used in a particular app.
And second, even after removing
the code that's not used,
the remaining code can
still be optimized for size
using the other
optimization techniques.
So as mentioned,
library code counts.
So without any shrinking,
all library code
is retained in your app.
Here's a list of some
of the more popular
third-party libraries, like the
Jetpack libraries or AndroidX
libraries.
They're used by pretty
much all applications.
Oh, sorry.
Could I go back
one slide, please?
OkHttp is a very
popular networking app.
Guava, Gson, and the
Google Play Services
are frequently used
Google-provided libraries.
And note that the Kotlin
Standard Library is also
on this list, because if
you're writing a app in Kotlin,
the Kotlin Standard
Library becomes
part of your application.
Now, before I go
into more details,

Indonesian: 
Pertama, semua aplikasi
menggunakan library pihak ketiga.
Ada banyak kode yang tidak
dibuat oleh Anda di dalam aplikasi.
Saat Anda memakai
library pihak ketiga pun,
biasanya hanya sebagian kecil
yang digunakan dalam aplikasi itu.
Kedua, meski kode yang
tidak dipakai sudah dihapus,
ukuran kode yang ada pun
masih bisa dioptimalkan
dengan teknik pengoptimalan lain.
Dengan demikian,
kode library jelas berpengaruh.
Tanpa adanya penyusutan,
semua kode library
tersimpan di aplikasi Anda.
Berikut sejumlah library pihak ketiga
yang paling populer,
seperti library Jetpack atau
AndroidX.
Semua aplikasi menggunakan library ini.
Oh, maaf.
Bisa tolong
mundur satu slide?
OkHttp adalah aplikasi
jaringan yang sangat populer.
Guava, Gson, dan
Google Play Services
adalah library dari Google
yang paling sering dipakai.
Kotlin Standard Library juga
termasuk karena jika
Anda membuat aplikasi di Kotlin,
Kotlin Standard
Library menjadi
bagian dari aplikasi Anda.
Sebelum membahas lebih jauh,

Chinese: 
首先，所有应用都使用第三方库
所以在你的应用中
许多代码并不是你编写的
另外，只要使用第三方库
通常一个应用只能用到
第三方库中的
一小部分
第二，即便移除了无用代码
我们还能使用其他优化方法
继续优化剩余代码的大小
如上所述，库代码占比重大
如果不压缩，所有库代码
都将保留在应用中
这里列出了一些较为流行的
第三方库，比如Jetpack库或AndroidX
库
几乎所有应用都使用这些库
抱歉
我能回到刚才的幻灯片吗？
OkHttp是一款非常流行的网络应用
Guava、Gson和
Google Play Services
是常用的Google提供的库
请注意Kotlin标准库
也在名单上，因为如果使用Kotlin编写应用
Kotlin标准库
就是应用的一部分
现在，详细介绍之前

English: 
I'll just tell you how to
enable R8 shrinking in your app.
In your app's main build.gradle
file, set minifyEnable to true.
So now it's turned on.
Don't let the minifyEnable
name confuse you.
It is actually turning
on R8 shrinking.
So now that R8 has
been turned on,
how much can you
expect to reduce
the size of your application?
Well, just to give
you an idea, I'll
try to create a simple
one activity app.
I'll build it in two
versions, one using
Kotlin and one using Java.
Both versions use the
Jetpack libraries,
but no other libraries.
Note that before shrinking,
the size of the Kotlin app
is considerably larger
than the Java app.
The main reason for this
is that the Kotlin Standard
Library is part
of the Kotlin app,
but not part of the Java app.
However, after
shrinking, you can
see that the size
of the two apps
are at a comparable
and much smaller size.
So now I try to add the OkHttp
4.2 library to both projects.

Spanish: 
les contaré
cómo habilitar la reducción con R8.
En el archivo build.gradle principal
de la app, establezcan minifyEnable
como verdadero para activarlo.
No se dejen confundir
por el nombre minifyEnable.
Lo que hace, en realidad,
es activar la reducción con R8.
Habiendo activado R8,
¿cuánto se puede reducir
el tamaño de una app?
Para que tengan una idea,
intenté crear
una app que hiciera una actividad.
La creé en dos versiones,
una con Kotlin y otra con Java.
Ambas usan la biblioteca Jetpack
y ninguna otra.
Observen que antes de la reducción,
la app de Kotlin
era mucho más grande que la de Java.
El motivo principal
es que la biblioteca estándar de Kotlin
forma parte de la app de Kotlin,
pero no está incluida en la app de Java.
Sin embargo, tras la reducción,
el tamaño de ambas apps
es parecido y más pequeño.
Luego intenté agregar la biblioteca
OkHttp 4.2 a ambos proyectos.
Aquí pueden ver que el tamaño

Portuguese: 
mostrarei como ativar
a redução com o R8 nos seus apps.
No arquivo build.gradle principal do app,
defina minifyEnable como true.
Agora o recurso está ativado.
Não se confunda com o nome minifyEnable.
Isso ativa a redução do R8.
Agora que o R8 está ativado,
qual é a redução de tamanho
esperada para seu app?
Para dar uma ideia,
criarei um app simples,
com só uma atividade.
Farei duas versões dele,
uma usando Kotlin e a outra, Java.
As duas versões
usam as bibliotecas do Jetpack,
e nenhuma outra.
Antes da redução, o tamanho do app Kotlin
é consideravelmente maior que o Java.
O motivo principal disso
é que a Kotlin Standard Library
é parte do app Kotlin,
mas não do Java.
No entanto, após a redução,
os tamanhos dos dois apps
são mais próximos e muito menores.
Agora, incluí
a biblioteca OkHttp 4.2 aos dois projetos.

Japanese: 
詳細を説明する前にアプリで
R8圧縮を有効にする方法を説明します
アプリのメインのbuild.gradle
ファイルで minifyEnableを
trueに設定します
これで有効になりました
minifyEnableの名前に
惑わされないでください
実際はR8圧縮を有効するものです
R8が有効になったので
アプリケーションのサイズをどれだけ
縮小できるか考えてみましょう
参考までに簡単な
単機能アプリを作成してみます
KotlinとJavaを使って
２バージョン作ります
どちらもJetpackライブラリを
使用しますが
他のライブラリは使用しません
圧縮前のKotlinアプリのサイズは
Javaアプリよりもかなり大きいです
これはKotlin Standard Libraryが
Javaアプリの一部ではなく
Kotlinアプリの一部であるためです
圧縮後は２つのアプリのサイズが
同等でかなり小さくなった
ことがわかります
現在両方のプロジェクトにOkHttp 4.2
ライブラリを追加しようとしています
Kotlinアプリがたった21%
増大したのに対し

Chinese: 
我来说说如何在应用中开启R8压缩
在应用主要build.gradle文件中
设置minifyEnable为true
这样就开启了
不要被minifyEnable这个名字迷惑
它其实可以开启R8压缩
现在R8已经开启
应用的大小
能压缩多少？
为了更加直观
我首先尝试创建一个简单的单一活动应用
我构建两个版本
一个使用Kotlin，一个用Java
两个版本都使用Jetpack库
都不用其他库
请注意，压缩前
Kotlin应用的大小
明显大于Java应用
主要原因是Kotlin应用
包含了Kotlin标准库
而Java应用不包括
然而，经过压缩
可以看到两个应用的大小
具有可比性，而且缩小许多
现在我试着给两个项目添加OkHttp 4.2库

Indonesian: 
akan saya beri tahu cara mengaktifkan
penyusutan R8 di aplikasi Anda.
Pada file build.gradle utama aplikasi
Anda, atur minifyEnable menjadi true.
Sekarang sudah aktif.
Jangan sampai terkecoh
dengan nama minifyEnable.
Ini adalah nama fungsi untuk
mengaktifkan penyusutan R8.
Setelah R8 diaktifkan,
berapa besar ukuran
yang bisa dikurangi
pada aplikasi Anda?
Sebagai gambaran,
saya akan
coba membuat satu aplikasi
aktivitas sederhana.
Saya akan buat dua versi,
satu dengan
Kotlin dan satunya dengan Java.
Keduanya menggunakan
library Jetpack,
tanpa library lain.
Sebelum penyusutan, ukuran aplikasi Kotlin
lebih besar daripada aplikasi Java.
Alasan utamanya karena
Kotlin Standard Library
adalah bagian
dari aplikasi Kotlin,
tapi bukan bagian dari aplikasi Java.
Namun, setelah
penyusutan,
ukuran kedua aplikasi
jauh lebih kecil.
Sekarang saya tambahkan
library OkHttp 4.2 pada keduanya.

Korean: 
R8 코드축소를
활성화하는 방법을 말씀드리겠습니다
앱의 메인 build.gradle 파일에서
minifyEnable을 true로 설정합니다
이제 활성화되었습니다
minifyEnable이라는 이름과
혼동하지 마십시오
이는 R8 코드축소를
켜는 명령입니다
R8을 활성화한 후에는
애플리케이션의 크기를
얼마나 줄일 수 있을까요?
한 가지 아이디어를 떠올려 보시죠
간단한 액티비티 앱 하나를
2개 버전으로 만들어 볼 건데
각각 Kotlin과
Java로 만들겁니다
두 버전 모두
Jetpack 이외에는
다른 라이브러리를 사용하지 않습니다
코드축소를 실행하기
전에는 Kotlin 앱의 크기가
Java 앱보다 상당히 컸습니다
그랬던 주요 이유는
Kotlin Standard Library가
Kotlin 앱의 일부이지
Java 앱의 일부가 아니기 때문입니다
그러나 코드축소를 실행한 후
두 앱의 크기가 비슷해지면서
훨씬 작아진 것을 알 수 있습니다
이제 OkHttp 4.2 라이브러리를
양쪽 프로젝트에 추가하겠습니다

Japanese: 
Javaアプリのサイズは急に２倍以上に
なっていることが
わかります
それはOkHttp 4.2ライブラリが
Kotlinに記述されているためです
JavaアプリはKotlin
Standard Libraryを
推移従属性としても取得します
この例ではコードでOkHttpを
使用していないため
圧縮後もサイズは同じです
私はコードにOkHttpを
使用したことはありません
空のアプリの数字を見せて
ごまかしていると言われるかもしれませんね
参考のために実際のアプリの
効果を検証してみました
今年のGoogle I/Oアプリを
採用しました
実際にR8がコードを
半分以下に削減していることがわかります
またメソッドとDEXファイル
の数を見ると
アプリの圧縮には他にも多くの
プラス効果があると
おわかりいただけるでしょう
圧縮アルゴリズムはプログラムの
既知のエントリポイントから
到達可能なすべてのコードを
トレースします

English: 
And here you can see that
the Java version of the app
suddenly doubles in size--
more than doubles
in size, actually--
whereas the Kotlin
app only grows up 21%.
And the reason for that
is the OkHttp 4.2 library
is written in Kotlin.
So suddenly, the Java app gets
the Kotlin Standard Library
s a transitive
dependency as well.
Now note, after
shrinking, the size
is still the same,
because in this example,
I haven't actually used
OkHttp in the code.
Now you might say that
this is cheating to show
numbers for an empty app.
So to give you an
idea, I have tried
to take the effect
of a real app.
So it took the Google
I/O app from this year.
And here you can see that
R8 actually reduces the code
to less than half.
And if you look at the number
of methods and DEX files,
you can see that
shrinking the app
has a lot of other
positive side effects.
Now let me just take you
through the basic process of how
the shrinking algorithm works.
So the shrinking algorithm
traces all reachable code
from the well-known entry
points of the program.
So R8 starts with
these well-known entry

Spanish: 
de la app de Java aumentó el doble
o más del doble, en realidad,
mientras que la app
de Kotlin solo creció un 21 %.
La razón es que la biblioteca OkHttp 4.2
está en Kotlin.
Entonces, de repente, la app de Java
recibe la biblioteca estándar de Kotlin
como dependencia transitiva.
Después de la reducción, el tamaño
es el mismo porque, en este ejemplo,
no usé OkHttp en el código.
Podrían pensar que eso es hacer trampa
a fin de generar números para una app vacía.
Por lo tanto, traté de mostrar los efectos
sobre una app real.
Trabajé con la app de Google I/O de este año.
Aquí pueden ver que R8 reduce el código
a menos de la mitad.
Si observan el número
de métodos y archivos .dex,
verán que la reducción de la app
tiene otros beneficios.
Ahora les explicaré el proceso básico
del algoritmo de reducción.
Este algoritmo rastrea
todo el código accesible
de los puntos de entrada
conocidos del programa.
Por lo tanto, R8 comienza

Portuguese: 
Observe que a versão Java
duplica de tamanho,
mais que duplica, na verdade,
enquanto o app Kotlin aumenta 21%.
O motivo disso
é que a biblioteca OkHttp 4.2
é escrita em Kotlin.
Assim, o app Java também
recebe a Kotlin Standard Library
como dependência transitiva.
Observe que, após a redução,
o tamanho ainda é o mesmo,
porque, neste exemplo,
não usei o OkHttp no código.
Você poderia dizer que estamos trapaceando
ao mostrar os números de um app vazio.
Para você ter uma ideia,
tentei avaliar o efeito em um app real.
Usei o app do Google I/O deste ano.
Veja que o R8 reduz o código
para menos da metade.
Se você observar
o número de métodos e arquivos dex,
verá que a redução do app
tem muitos outros efeitos positivos.
Vejamos como funciona o processo básico
do algoritmo de redução.
O algoritmo de redução
rastreia todo o código alcançável
de pontos de entradas
conhecidos do programa.
O R8 começa com esses pontos

Chinese: 
此处可以看到应用的Java版本
大小突然翻倍
其实不止翻一倍
而Kotlin应用只增加了21%
这是因为OkHttp 4.2库
由Kotlin编写
Java应用突然多出了
Kotlin标准库
成为其传递依赖
请注意，经过压缩
大小没有变化，因为此案例中
我没有在代码中使用OkHttp
可能有人会说，使用空应用演示
是作弊
所以为了直观展示
我来试试
真实的应用
这里使用了今年的
Google I/O应用
可以看到，R8将代码缩减至
不及原先的一半
如果看到方法数量和DEX文件
可以看到压缩应用
还有许多其他积极影响
现在我来给大家讲解
压缩算法的
基本工作流程
压缩算法从程序所有知名进入点中
追踪所有可及代码
R8以这些程序的知名进入点

Korean: 
화면을 통해
앱의 Java 버전 크기가
갑자기 2배로
커진 것을 알 수 있습니다
사실 2배 이상이죠
반면 Kotlin 앱은
불과 21%밖에 커지지 않았습니다
OkHttp 4.2 라이브러리가
Kotlin으로
작성되었기 때문입니다
갑자기 Java 앱이
Kotlin Standard Library의
추이 종속성도 사용했습니다
코드축소 후에도 크기가 동일한데요
이 예에서는 코드에 OkHttp를
사용하지 않았기 때문입니다
빈 앱의 숫자를
표시하는 것은 잘못이라고
생각하실 수 있습니다
한 가지 아이디어를 제공하기 위해
실제 앱에 대한
효과를 확인해 봤습니다
금년도 Google I/O
앱에 대한 효과를 확인했습니다
이제 화면에서 R8을
통해 코드가 절반 이하로
작아졌음을 알 수 있습니다
또한 메소드와
DEX 파일의 수를 보시면
앱의 코드를
축소하면 다른 부수적 이점이
있음을 알 수 있습니다
이제 코드축소 알고리즘이 기능하는
기본적인 과정을 살펴보겠습니다
코드축소 알고리즘은
프로그램의 모든 잘 알려진
진입점에서 모든
접근 가능한 코드를 추적합니다

Indonesian: 
Bisa dilihat pada 
aplikasi versi Java
ukurannya membengkak,
bahkan lebih dari
dua kali lipat,
sedangkan aplikasi
Kotlin hanya bertambah 21%.
Alasannya karena
library OkHttp 4.2
ditulis dalam Kotlin.
Jadi, mendadak aplikasi Java
mendapat Kotlin Standard Library
sebagai dependensi transitif juga.
Setelah penyusutan, ukuran
masih tetap sama,
karena pada contoh ini,
saya belum menggunakan
OkHttp dalam kodenya.
Mungkin ada yang bilang
ini kurang objektif
karena aplikasi masih kosong.
Sebagai gambaran,
saya sudah coba
efeknya pada
aplikasi sungguhan,
yaitu aplikasi Google
I/O tahun ini.
Bisa dilihat
R8 mengurangi kode
lebih dari setengahnya.
Jika dilihat dari jumlah
metode dan file DEX,
penyusutan aplikasi punya
banyak dampak positif lain.
Sekarang saya jelaskan
proses dasar cara kerja
algoritme penyusutan.
Algoritme penyusutan melacak
semua kode yang dapat dieksekusi
dari titik entri yang
dikenali pada program.

Portuguese: 
de entrada conhecidos.
Ele percorre todo o código alcançável.
Para definir
esses pontos de entrada conhecidos,
usamos as chamadas regras keep.
Acabou a bateria.
Veja este exemplo simples
de "Hello, world!" em Java.
O ponto de entrada
conhecido de um app Java
é o static void main
da classe Application.
Isso é definido por esta regra keep.
Este é o ponto de entrada.
Quando a redução começa,
ela rastreia o código nesses pontos.
Aqui ela passa pelo ponto de entrada,
descobre que greeting é chamado,
vai para greeting
e faz o rastreamento.
Greeting é chamado em tempo de execução,
então aqui o rastreamento é interrompido.
O rastreamento
do código todo foi concluído.
Agora o tree-shaking
pode remover o código não usado.
Aqui está.
Depois, a renomeação de identificador
altera o nome
do método greeting para algo menor.
Por último, a fase de otimização

Indonesian: 
Setelah mulai dari
titik ini,
R8 menelusuri semua kode
yang dapat dieksekusi.
Untuk menentukan
titik entri ini,
kami menggunakan
aturan keep.
Baterainya mungkin habis.
Oh, sudah bisa.
Nah.
Lihat contoh
sederhana "Hello, world!"
ini dalam Java.
Titik entri yang dikenali
dalam aplikasi Java
adalah static void main
pada class aplikasi,
dan ditentukan menggunakan
aturan keep ini.
Ini adalah titik entrinya.
Ketika dimulai, penyusutan berawal
dengan melacak kode
di titik entri.
Di sini masuk ke titik entri,
berlanjut ke greeting,
masuk ke greeting,
lalu melacak greeting,
Dari greeting lalu ke runtime,
dan di sini pelacakan berhenti.
Sekarang pelacakan sudah
selesai melacak semua kode
sehingga tree shaking bisa
menghapus kode yang tak terpakai.
Seperti itu.
Kemudian identifier renaming bisa
mengubah nama metode
greeting jadi lebih pendek.
Dan terakhir, tahap
pengoptimalan dapat

Korean: 
즉 R8은 프로그램의 이런 잘 알려진
진입점에서 시작합니다
접근 가능한 모든 코드를 검사합니다
이러한 잘 알려진 진입점을 정의하기 위해
우리는 유지 규칙이라는 개념을 사용합니다
노트북의 배터리가 부족하군요
뭐, 괜찮습니다
이제 Java의 "Hello, world!" 
사례를 살펴보겠습니다
Java 애플리케이션의
잘 알려진 진입점은
애플리케이션 클래스의
정적 [INAUDIBLE]입니다
이 유지 규칙을
사용해 정의됩니다
녹색 글씨 부분이
진입점입니다
코드축소를 개시하면
진입점에서 코드를
추적하는 것으로 시작합니다
지금 진입점을 지나고 있는데요
그리팅 호출을 확인하자
그리팅으로 향하고
그리팅을 추적합니다
그리팅은 런타임을 호출하고
여기서 추적은 끝납니다
모든 코드에 대한 추적을 마쳤습니다
이제 Tree Shaking으로
미사용 코드를 제거할 수 있습니다
말씀드린 대로입니다
그런 후 식별자 이름변경을 통해
그리팅 메소드의 이름을
좀 더 짧게 변경할 수 있습니다
마지막으로 최적화 단계에서

Japanese: 
R8はこうしたプログラムの既知の
エントリポイントから始まります
到達可能なすべてのコードが対象です
既知のエントリポイントを
定義するためにkeepルールというものを使います
電池がないです
これで大丈夫
はい
このJavaの”Hello, world!”
の例を見てください
Javaアプリケーションの
既知のエントリポイントは
アプリケーションクラスの
static void mainです
そしてこれはkeepルールを使って
定義されています
これがエントリポイントです
圧縮を始めるにはまずエントリポイントの
コードをトレースします
エントリポイントを見ると
グリーティングが呼ばれたのを検知し
グリーティングに行き
グリーティングをトレースします
グリーティングが実行されます
ここでトレースは終了です
すべてのコードのトレースが終わりました
これでツリーシェイキングが
未使用コードを削除できます
ここですね
次に識別名を変更して
greetingメソッドを少し短くします
最後に最適化フェーズで

Chinese: 
为起点
分析所有可及代码
为定义这些知名进入点
我们使用了所谓的保持规则
没电了
好了，可以了
对
请看Java编写的简单案例
"Hello, world!"
Java应用的知名进入点
为应用类的静态[INAUDIBLE]
使用保持规则对其定义
这就是进入点
压缩开始后，首先
追踪进入点代码
此时通过进入点
发现调用了问候语
然后转向问候语
追踪问候语
问候语调用进入运行时
此时追踪停止
现在所有代码追踪完毕
摇树可以清除未使用的代码
就是这样
然后标识符重命名
能够将问候语方法命名为较简短的形式
最后，优化阶段能够

Spanish: 
con esos puntos
y revisa todo el código accesible.
Para definir
los puntos de entrada conocidos,
usamos reglas de conservación.
Se agotó la batería.
Ahora funciona.
Observen este ejemplo sencillo
de "Hola, mundo" en Java.
Los puntos de entrada
conocidos de una app de Java
son los [inaudible]
estáticos de la clase de app,
que se definen
con esta regla de conservación.
Este es el punto de entrada.
Cuando la reducción comienza,
lo primero que hace
es buscar el código en los puntos de entrada.
Aquí lo vemos.
Descubre que se llama al saludo,
así que va al saludo
y hace un seguimiento de este.
El saludo llama al tiempo de ejecución
y culmina el seguimiento.
Ya se terminó de rastrear todo el código.
Por lo tanto, el método de eliminación
de código obsoleto borra
todo el código sin usar. Aquí lo ven.
Luego, el identificador que queda
puede cambiar el nombre
del método de saludo por algo más corto.
Finalmente, en la etapa de optimización,

English: 
points of the program.
It walks through all the
code that is reachable.
And to define these
well-known entry points,
we use what we call keep rules.
And there's no battery.
Well, maybe-- there we go.
Yes.
So take a look at this
simple "Hello, world!"
example in Java.
The well-known entry points
of a Java application
is the static [INAUDIBLE]
of the Application class.
And this is defined
using this keep rule.
So this is the entry point.
And when shrinking
starts, it starts
by tracing the code
at the entry points.
So here we go through
the entry point.
It find that greeting is called.
So it goes to greeting.
It traces greeting.
Greeting calls into the runtime.
So here the tracing stops.
And now the tracing has
finished tracing all code.
So now the tree shaking
can remove the unused code.
There it goes.
And then the
identifier renaming can
rename the greeting method
to something shorter.
And finally, the optimization
phase can actually

Japanese: 
このメソッドをインライン化
することで圧縮の結果は
始めよりかなり小さくなります
ツリーシェイキング 最適化 識別名変更という
３つの手法をお見せしました
単独のJavaプログラムと同様
Androidアプリケーションにも多くの
既知のエントリポイントがあります
これらはアクティビティ サービス
コンテンツプロバイダー
ブロードキャストレシーバです
AATPツールはこうしたエントリポイントの
処理を行います
これがマニフェストファイルで
メインアクティビティを定義しています
AATPツールはエントリポイントを
存続させるために
keepルールを生成します
現在はAATPツールで生成される
既知のエントリポイントのほか
この構成ファイルで
Android Studioによって
提供されるAndroidプラットフォームに
必要な他のものも多くあります
アプリのエントリポイントは
すべて配置されましたが
R8による圧縮後にアプリが機能するために

Korean: 
이 메소드를 인라이닝해서
코드축소를 통해
처음 크기보다 훨씬 
작아지게 만들 수 있습니다
세 가지 기법을 보여드렸습니다
Tree Shaking, 최적화 그리고
식별자 이름변경을 살펴봤습니다
독립형 Java 프로그램처럼
Android 애플리케이션에도
잘 알려진 진입점이 많습니다
그 예로는 액티비티, 서비스, 
콘텐츠 제공업체와
방송 수신자가 있습니다
그리고 AATP 툴에서
이런 진입점을 관리하는데
여기 매니페스트 파일이 있습니다
이를 통해 주요 액티비티를 정의합니다
ATTP 툴이 이 진입점을 남겨두기 위해
이 유지 규칙을 생성합니다
AATP 툴이 생성하는
이런 잘 알려진 진입점 외에도
이 구성 파일의
Android 스튜디오가 제공하는
Android 플랫폼에 필요한
다른 진입점이 많이 있습니다
앱 내에 존재하는 모든 진입점 외에도

Portuguese: 
faz a reestruturação in-line desse método.
Assim o resultado da redução é muito menor
que o código inicial.
Isso demonstra as três técnicas:
tree-shaking, otimização
e renomeação de identificador.
Assim como um programa Java individual,
um app Android também
tem pontos de entrada conhecidos,
que são as atividades, os serviços,
os provedores de conteúdo
e os broadcast receivers
A ferramenta AAPT gerencia
esses pontos de entrada.
Veja o arquivo de manifesto.
Ele define a atividade principal,
e a ferramenta AAPT gerará esta regra keep
para manter
esses pontos de entrada ativos.
Além desses pontos de entrada conhecidos
gerados pela ferramenta AAPT,
há vários outros elementos
exigidos pela plataforma Android
que são fornecidos pelo Android Studio
neste arquivo de configuração.
Com todos os pontos de entrada
do app preparados,

Spanish: 
se puede intercalar este método
para que el resultado
de la reducción sea mucho más chico
que el tamaño inicial.
Ya vimos las tres técnicas:
eliminación de código obsoleto,
optimización
y cambio de nombre de identificadores.
Al igual que
un programa Java independiente,
una app de Android también
cuenta con cierto número
de puntos de entrada conocidos.
Son sus actividades,
servicios, proveedores
de contenido y receptores de emisiones.
La AAPT se encargará de esos puntos.
Aquí tenemos un archivo de manifiesto,
que define la actividad principal.
La AAPT genera la regla de conservación
para preservar
los puntos de entrada conocidos.
Además de los puntos
generados por la AAPT, hay otros elementos
requeridos para la plataforma Android,
que Android Studio
proporciona en este archivo de configuración.
Con todos los puntos
de entrada de la app en su lugar,
debemos configurar un área más

English: 
inline this method,
so that you have
the resulting of the shrinking
is quite a lot smaller
than what we started with.
So this demonstrates
the three techniques--
tree shaking, optimization,
and identifier renaming.
Now just like a
standalone Java program,
an Android application
also have a number
of well-known entry points.
So these are your
activities, your services,
your content providers, and
your broadcast receivers.
And the AATP tool will take care
of handling these entry points.
So here is a manifest file.
It defines the main activity.
And AATP tool will
generate this keep rule
to have this entry
points survive.
Now, besides these
well-known entry points
generated by AATP tool, there's
a number of other things
that is required for the
Android platform, which
is provided by Android Studio
in this configuration file.
Now, with all the entry
points in the app in place,

Indonesian: 
merapikan metode ini sehingga
hasil penyusutan
jauh lebih ringkas
daripada awalnya.
Jadi, ada tiga teknik
yang telah dijelaskan:
tree shaking, pengoptimalan,
dan identifier renaming.
Sama halnya dengan
program Java mandiri,
aplikasi Android juga
punya sejumlah
titik entri yang dikenali,
meliputi aktivitas, layanan,
penyedia konten, dan
penerima siaran Anda.
Alat aapt2 akan menangani
semua titik entri ini.
Berikut adalah file manifes
yang berisi aktivitas utama,
dan aapt2 akan membuat aturan keep ini
agar titik entri ini tetap ada.
Sekarang, selain titik
entri yang dikenal
yang dibuat oleh alat aapt2 ini,
ada sejumlah hal lain
yang diperlukan untuk
platform Android,
yang disediakan oleh Android Studio
pada file konfigurasi ini.
Sekarang, setelah titik entri
di aplikasi ditentukan,

Chinese: 
内嵌该方法
这样压缩结果
相比于初始代码
要小得多
这里展示了三个技巧
摇树、优化和标识符重命名
类似于独立Java程序
Android应用也有许多
知名进入点
包括活动、服务
内容提供商和
广播接收器
AATP工具可以处理这些进入点
这是清单文件
用来定义主活动
AATP工具将生成保持规则
保留这些进入点
除了AATP工具生成的知名进入点
Android平台还需要
许多其他东西
由此配置文件中的Android Studio提供
现在，应用中的进入点已经就位

Japanese: 
構成が必要な領域がもう1つあります
アプリケーションコードのリフレクションです
リフレクションはコードへの
エントリポイントで
確認でき コードのトレースだけでは
R8で認識されません
ここで留意すべきことはサードパーティ
ライブラリで
リフレクションが発生する可能性があることです
サードパーティライブラリは
実質アプリの一部であるため
アプリケーションで行われる
リフレクションも担うことになります
これらのライブラリには独自のルールが
含まれている場合があります
しかしライブラリーの多くは実際には
Androidでも書かれず圧縮も
されていないため
追加の構成が必要になる場合があります
これがプログラムでどう現れるかを示すために
この簡単なコードを見てください
フィールド名の名前のクラスがあります
インスタンスを作成しそれをJSONに
シリアル化するメインメソッドがあります

English: 
there's one more area that
which needs configuration
for the app to work
after shrinking with R8,
and that is reflection
in application code.
So reflection can be
seen as a entry point
into the code, which is
not really recognized
by R8 by just tracing the code.
And one thing to
keep in mind here
is that reflection can happen
in third-party libraries.
And as third-party libraries
are now effectively
part of your app,
you also become
responsible for the reflection
performed in these applications
as well.
So some of these
libraries might come
with their own rules included.
But also keep in mind that quite
a few libraries are actually
not written neither with
Android nor shrinking in mind,
so they might need
additional configuration.
Just to show how this can
actually manifest itself
in your program, take a
look at this simple code.
We have a class with
a field name name.
And we have a main method that
will just create an instance
and serialize that to JSON.

Indonesian: 
ada satu bagian lagi yang
memerlukan konfigurasi
agar aplikasi tetap berfungsi
setelah penyusutan R8,
yaitu refleksi
pada kode aplikasi.
Refleksi bisa dianggap
sebagai titik entri
ke dalam kode yang
tidak dikenali
oleh R8 melalui pelacakan kode.
Satu hal yang perlu diingat,
refleksi bisa jadi sudah berjalan
di library pihak ketiga,
dan karena library pihak
ketiga sekarang sudah
menjadi bagian
aplikasi, Anda pun turut
berperan dalam
refleksi yang dijalankan di aplikasi ini.
Beberapa library ini
mungkin sudah punya
aturannya sendiri.
Tapi, perhatikan bahwa
ada library yang dibuat
tanpa mempertimbangkan
Android atau penyusutan
sehingga butuh
konfigurasi tambahan.
Untuk menunjukkan
cara menerapkannya
pada program Anda, perhatikan
kode sederhana berikut ini.
Ada class dengan nama kolom name,
dan ada metode utama
yang langsung membuat instance
dan menderetkannya ke JSON.

Korean: 
R8을 통한 코드축소
이후에 앱을 작동시키기 위해
구성이 필요한
또 다른 영역이 있습니다
애플리케이션 코드의 리플렉션이 그것입니다
리플렉션을 코드 안으로 향하는
진입점으로 볼 수 있습니다
이것은 R8의 코드
추적만으로는 실제로 인식되지 않습니다
여기서 기억하실 점은
리플렉션이 제3자 라이브러리에서
일어날 수 있다는 사실입니다
제3자 라이브러리는
사실상 앱의 일부이기 때문에
여러분은 그러한 애플리케이션 내에서
이루어지는 리플렉션에도
신경쓰셔야 합니다
이러한 라이브러리 중 일부에는
자체적인 규칙이 포함될 수 있습니다
하지만 Android
또는 코드축소를 이용해
라이브러리를 작성하지
않는 경우도 상당히 많습니다
따라서 추가적인
구성이 필요할 수 있습니다
여러분의 프로그램에서 어떻게 
그런 일이 발생하는지 확인하기 위해
name이란 이름의 입력란을 가진
클래스가 있습니다
그리고 인스턴스를 생성해
JSON으로 직렬화하는
메인 메소드가 있습니다

Chinese: 
还需要再配置一个区域
才能让经过R8压缩的应用
正常运行
那就是应用代码中的反射
反射可看作代码的
一个进入点
通常仅通过追踪代码
R8无法识别反射
这里有件事需要注意
那就是第三方库
也可能出现反射
由于第三方库已经成为
应用的一部分
因此您也需要
处理对这些应用中出现的
反射
其中一些库
可能已经包含自己的规则
但还需要注意
许多库编写时
即没有考虑Android
也没有考虑压缩
所以可能还需额外配置
为了展示这如何在程序中显现
来看一下这段简单的代码
此处有一个字段名为name的类
还有一个仅用于创建实例
并将其序列化为JSON的主方法

Spanish: 
para que la app funcione
luego de la reducción con R8.
Estoy hablando de la reflexión
del código de la app.
La reflexión
puede considerarse un punto de entrada
al código, que R8 no reconoce
con un simple seguimiento del código.
Tengan en cuenta que la reflexión
puede ocurrir
en las bibliotecas de terceros.
Dado que ahora
esas bibliotecas son parte de su app,
ustedes también son responsables
de la reflexión realizada en ellas.
Algunas de estas bibliotecas
pueden incluir sus propias reglas.
También recuerden
que la mayoría de las bibliotecas
se crean para hacer
reducciones en Android.
Por ende, es posible
que requieran configuración adicional.
Para ver cómo podría manifestarse esto
en su programa,
observen este código simple.
Hay una clase con un campo llamado "name".
También hay un método
principal que creará una instancia
y la serializará en JSON.

Portuguese: 
há mais uma área
que precisa ser configurada
para o app funcionar
após a redução com o R8,
que é a reflexão no código do app.
A reflexão pode ser vista
como um ponto de entrada
no código que não é reconhecido
pelo R8 só com o rastreamento.
É importante notar
que a reflexão
pode ocorrer em bibliotecas de terceiros,
e como elas são efetivamente
parte do seu app, você se torna
responsável pela reflexão realizada
nesses apps também.
Algumas dessas bibliotecas podem ter
regras próprias incluídas,
mas lembre-se de que muitas bibliotecas
não são escritas
com o Android ou a redução em mente.
Por isso, configurações adicionais
podem ser necessárias.
Para mostrar como isso pode se manifestar
no seu programa, veja este código simples.
Temos uma classe
com o nome de campo "name"
e um método principal
que criará uma instância
e fará a serialização para JSON.

Spanish: 
Entonces,
reducimos el código y lo ejecutamos.
El resultado es un objeto JSON vacío.
¿Por qué sucedió eso?
El nombre del campo
estaba escrito, pero no se leyó.
En consecuencia, R8 lo eliminó.
En realidad,
el serializador Gson debe leer el campo,
pero usa técnicas de reflexión,
por lo cual R8
no detecta la lectura del campo.
Ahora intentamos
agregar un método para leer el campo.
¿Qué sucede cuando ejecutamos el código?
Este es el resultado.
Tenemos un JSON
con un campo llamado A. ¿Por qué?
Se escribió y leyó el campo,
así que no se [inaudible] por R8,
pero aún se puede cambiar el nombre
por uno más corto.
Dado que Gson aplica reflexión,
busca el nombre
que se encuentra en el campo
en vez del nombre corto original
de la fuente.
¿Cómo podemos corregir esto?
Agregamos esta regla de conservación,

Korean: 
코드를 축소하고
실행한 후의 결과가
빈 JSON 객체임을
알 수 있습니다
왜 그럴까요?
입력란 이름을 작성했지만
읽히지 않은 것으로 확인되었습니다
그래서 R8에서 제거한 것입니다
이 입력란을 Gson
직렬 변환기가 읽어야 하는데
Gson은 리플렉션 기법을 사용하므로
R8은 이 입력란이
읽혔다는 사실을 모릅니다
입력란을 읽는 메소드를 추가해 보겠습니다
이 메소드가
입력란을 읽게 됩니다
코드를 실행하면 어떻게 될까요?
이제 결과가 나왔습니다
A란 이름의 입력란이
있는 JSON이 생겼는데요
왜일까요?
이 입력란에 입력하고
읽을 수 있는데요
R8이 삭제하지 않지만
이름 변경 기능으로 이름을 더 짧게
줄일 수 있습니다
Gson은 리플렉션을 사용하므로
현재 입력란에 있는
이름을 인식하겠지만
소스의 더 짧은 원래 이름은 아닙니다
이 문제를 어떻게 해결해야 할까요?
저는 이 규칙 준수를 추가하겠습니다
즉 Person 클래스에

Chinese: 
压缩代码，然后运行
可以看到输出为空JSON对象
为什么呢？
原来是字段名已写入，但没有读取
所以R8将其移除
实际上，该字段应由Gson
序列化器读取，但Gson
使用反射技术
所以R8无法识别该字段已经读取
好
现在我们准备加入方法读取字段
此方法将读取本字段
运行代码后会出现什么情况？
现在输出为此值
我们得到字段名为A的JSON
为什么会这样？
现在字段已写入并读取
所以R8没有将其移除
但重命名仍然
将名称缩短
由于Gson使用反射
它会寻找字段当前名称
而不会使用源文件中的
原始名称
如何修正此问题？
我把它加入保持规则

English: 
So we shrink the code,
and we run, and then
you see the output is
an empty JSON object.
Now, why is that?
It turns out that the field
name is written, but never read,
so R8 removes it.
Actually, this field is
supposed to be read by the Gson
serializer, but Gson uses
reflection techniques,
so R8 does not see that
this field is actually read.
OK.
Now we try to add a
method to read the field.
So this method will
somehow read the field.
What happens when
we run the code?
Now the output is this.
We have a JSON with a field
named A. And why is that?
Well, now the field is
both written and read,
so it's not [INAUDIBLE] by R8,
but renaming can still change
the name to a shorter name.
And as Gson uses
reflection, it'll
just find the name
that's currently
on the field and not the
original shorter name
from source.
Now, how do I fix this?
I add this keep rule.

Japanese: 
コードを圧縮して実行すると
出力が空のJSONオブジェクト
であることがわかります
これはなぜでしょう
フィールド名は書き込まれますが
読み取られないため
R8が削除したのです
このフィールドはGsonシリアライザによる
読み取り対象ですが
Gsonはリフレクション手法を使用するため
R8はこのフィールドが読み取られることが
分かりません
OK
ここでフィールドを読み取るメソッドを
追加してみましょう
このメソッドはフィールドを読み取ります
コードを実行すると何が起こるでしょう
これが出力されます
Aというフィールド名のJSONがあります
なぜでしょう
フィールドの書き込みと読み込みが
行われました
R8によって命令されてはいませんが
名前変更によって名前を短く変更できます
Gsonはリフレクションを使用するため
ソースの元の短い名前ではなく
現在のフィールドの名前を
見つけます
さて これをどうやって修正しましょう
このkeepルールを追加します

Portuguese: 
Após fazer a redução e executar o código,
vemos que a saída é um objeto JSON vazio.
Por que isso acontece?
O campo "name" foi gravado,
mas não foi lido,
por isso o R8 o remove.
Na verdade, esse campo
será lido pelo serializador Gson,
mas ele usa técnicas de reflexão.
Por isso, o R8 não detecta
a leitura do campo.
Agora incluímos
um método para ler o campo.
Ele lerá o campo de alguma forma.
O que acontece quando o executamos?
Esta é a resposta.
Temos um JSON
com um campo chamado "a". Por quê?
Agora o campo é gravado e lido,
por isso não é removido pelo R8,
mas a renomeação de identificador
ainda pode encurtar o nome dele.
Como o Gson usa reflexão,
ele encontrará o nome
atualmente no campo, e não o original
mais curto na fonte.
Como corrigimos isso?
Adicionamos esta regra keep.

Indonesian: 
Jadi kami menyusutkan kode ini,
lalu menjalankannya, dan seperti
yang Anda lihat, hasilnya
berupa objek JSON kosong.
Mengapa begitu?
Ternyata ada kolom name,
tapi tidak pernah dibaca,
jadi R8 menghapusnya.
Kolom ini sebenarnya
terbaca oleh penderet Gson
tapi Gson memakai teknik refleksi
sehingga R8 mendeteksinya tidak dibaca.
Baiklah.
Sekarang kita coba tambahkan
metode untuk membaca kolom ini.
Jadi metode ini akan
membaca kolom itu.
Apa yang terjadi
saat kode dijalankan?
Inilah hasilnya.
Kita memiliki JSON dengan
kolom bernama A. Mengapa?
Karena kolom ini
ditulis dan dibaca,
jadi tidak dihapus oleh R8,
tapi namanya tetap
diubah jadi lebih pendek.
Karena menerapkan refleksi, Gson akan
mencari nama yang sedang digunakan
di kolom dan bukan
nama asli yang lebih pendek
dari sumber.
Sekarang, bagaimana cara
memperbaikinya?
Saya tambahkan
aturan keep berikut.

Chinese: 
命令Person类中
保持字段命名的名称
然后再运行代码
输出为预期中的JSON对象
之所以成功，是因为R8
收到指令
不要动字段命名的名称
是的
这些额外的保持规则
进入一个新增加的文件
通过应用的build.gradle file
进行引用
我说完了
现在请Christoffer继续
谢谢Soren
现在我们来进一步了解
R8执行的一些优化
R8由许多不同的优化构成
我们发现少数几个优化功能
就可以完成绝大多数代码缩减任务
其中一个重要优化是缩减
Soren刚才已经提到
这能缩短类名称等
标识符的名称
另一个重要的优化是方法内嵌
该优化能够移除许多
应用中的方法定义
因为许多方法仅在

Japanese: 
Personクラスでnameという
フィールドを保持します
コードを実行しましょう
出力は予想通りのJSONオブジェクトです
R8はnameというフィールドに
触れないよう命令されているため保持されます
はい
これらのkeepルールはアプリケーションの
build.gradleファイルから参照する
追加ファイルに追加されます
さて ここからはクリスファーさんに
お願いします
ありがとう ソレンさん
では R8が実行する最適化について
詳しく見てみましょう
R8はさまざまな
最適化で構成されています
これらの最適化のいくつかは
コードサイズ削減の大部分を担っています
重要な最適化の１つは縮小化です
ソレンさんが述べたようにクラス名などの
識別名を短くすることです
もう１つはメソッドのインライン化です
多くのメソッドは
限られた場所でのみ使用されるため
アプリのメソッド定義は

Portuguese: 
Ela diz: na classe Person,
mantenha o campo chamado "name".
Ao executar o código,
a resposta será o objeto JSON esperado.
Isso funciona
porque o R8 é instruído
a não alterar o campo "name".
Essas outras regras keep
são incluídas em um arquivo adicional
que é inserido como referência
no arquivo build.gradle do seu app.
Agora passarei para o Christoffer.
Obrigado, Soren.
Agora vamos ver em mais detalhes
algumas otimizações realizadas pelo R8.
O R8 é composto
por uma série de otimizações diferentes.
Algumas delas são responsáveis
pela maioria
das reduções de tamanho do código.
Uma das otimizações importantes é
a minificação, que o Soren mencionou.
Ela dá nomes mais curtos
aos identificadores,
como nomes de classes.
Outra otimização importante é
a reestruturação in-line de métodos,
que muitas vezes remove
várias definições de métodos dos apps,
porque muitos deles
são usados em poucos locais.

Spanish: 
que indica que se debe conservar el campo
llamado name de la clase Person.
Cuando ejecutamos el código,
el resultado es el objeto JSON esperado.
Funciona porque R8 tiene instrucciones
de no tocar el campo llamado "name".
Estas reglas de conservación adicionales
se encuentran en un archivo extra
al que se hace referencia
mediante el archivo build.gradle
de su app.
Ahora los dejaré con Christoffer.
Gracias, Soren.
Ahora veremos más detenidamente
las optimizaciones que hace R8.
R8 hace muchas optimizaciones diferentes.
Algunas de ellas son responsables
de la mayoría
de las reducciones de tamaño de código.
Una optimización importante
(que Soren ya la mencionó)
es la reducción, que asigna
nombres más cortos a identificadores,
como los nombres de clases.
Otra optimización importante
es la intercalación de métodos,
que suele quitar
numerosas definiciones de métodos
de las apps porque muchos ellos
solo se usan en pocos lugares.

Indonesian: 
Isinya, pada class Person,
tetap gunakan kolom bernama name.
Lalu jalankan kodenya,
dan outputnya adalah
objek JSON yang diinginkan.
Kode berfungsi karena R8
diperintahkan tidak menyentuh
kolom bernama name.
Ya.
Dan aturan keep tambahan
dipakai untuk file tambahan
yang Anda ambil
dari file build.gradle
dalam aplikasi.
Dari sini, Christoffer akan melanjutkan.
CHRISTOFFER ADAMSEN:
Terima kasih, Soren.
Sekarang mari kita bahas lebih dalam
beberapa pengoptimalan
yang dijalankan R8.
Ada beragam pengoptimalan dalam R8.
Ternyata beberapa dari
pengoptimalan ini
berperan besar dalam menekan ukuran kode.
Salah satunya adalah minifikasi,
yang juga disebutkan Soren tadi,
yang memendekkan nama pengidentifikasi,
seperti nama class.
Pengoptimalan penting lainnya
adalah penataan metode
yaitu umumnya penghapusan
banyak definisi metode
pada aplikasi karena ternyata
ada banyak metode yang hanya

English: 
It says that in
the class Person,
keep the field named name.
So we're running the code.
The output is the
expectated JSON object.
It works because R8 is
instructed to not touch
the field named name.
Yes.
And these additional keep rules
goes into an additional file
that you reference
from your application's
build.gradle file.
And with that, I'll
give it to Christoffer.
CHRISTOFFER ADAMSEN:
Thank you, Soren.
So now let's try to
take a closer look
at some of the optimizations
that R8 performs.
R8 consists of a lot of
different optimizations.
It turns out that a few
of these optimizations
are responsible for the majority
of code size reductions.
So one important optimization is
minification, which Soren also
mentioned, which gives
shorter names to identifiers
such as class names.
Another important optimization
is method inlining,
which often ends up removing
a lot of method definitions
in apps, because it turns out
that many methods are only

Korean: 
name이라는 이름의
입력란을 두는 것입니다
이제 코드를 실행한 후의 결과는
예상했던 JSON 객체입니다
R8이 name이라는 입력란을
건드리지 말도록 지시했기 때문에
가능한 일입니다
이러한 추가적인 유지 규칙은
여러분의 애플리케이션의
build.gradle 파일에서 참조하는
추가 파일에 삽입됩니다
이제 크리스토퍼가 진행할 순서입니다
수고하셨습니다
지금부터 R8에서 실행하는
최적화에 대해
자세히 살펴보겠습니다
R8에는 다양한 최적화 기능이 있습니다
대부분의 코드 크기 축소에
이러한 최적화 기능 중
몇 가지가 관련되어 있음이 밝혀졌습니다
이러한 최적화 기능 중
중요한 하나가 소렌이 설명한
Minification인데요
클래스 이름과 같은 식별자의 이름을
짧게 줄이는 방식입니다
또 다른 중요한 최적화
기능은 메소드 인라이닝으로
종종 앱 내의 많은
메소드를 제거하기도 합니다
많은 메소드가 몇몇 공간에서만
사용되기 때문입니다

Spanish: 
También
existe la eliminación de código obsoleto,
que borra el código sin uso.
R8 también
cuenta con optimizaciones especializadas,
las cuales son útiles
para eliminar estructuras de código
que las técnicas estándares no borran.
Un ejemplo es la intercalación de clases.
Esta optimización
intenta eliminar las clases
que solo se usan localmente.
Los programadores
solemos introducir abstracciones,
utilidades,
métodos auxiliares y otros elementos
para que el código
sea más fácil de mantener y de leer.
Un buen ejemplo de ello
son las clases de Builder.
Por lo general, se crean instancias nuevas
de un compilador,
se invocan varios métodos
para modificar su estado
y, luego, se invoca un método
para crear un objeto nuevo
basado en el estado del compilador.
Sin embargo,
en la ejecución, estos compiladores
no son estrictamente necesarios
porque sería posible

English: 
used in a few places.
And then there's
tree shaking, which
is responsible for
removing unused code.
R8 also has more
specialized optimizations
that are important for removing
code structure that would not
be removed by standard
techniques as these ones.
So one example of that is
what we call class inlining.
Class inlining is
an optimization
that attempts to remove classes
that are only used locally.
So as programmers,
we often introduce
abstractions and
utilities, helper methods,
and so on, in order to make the
code more maintainable and also
easier to read.
So one good example of
that is Builder classes.
So with builders,
you would typically
create a new instance
of a builder,
invoke a few methods
on that to modify
the state of the
builder, and then invoke
a method to create
a new object based
on the state of the builder.
However, at runtime,
these builders
are not strictly needed, because
it would be possible just

Japanese: 
よく削除されることになります
そしてツリーシェイキングです
未使用コードを削除する役割があります
R8にはこうした標準的な手法では
削除されないコード構造を削除するために重要な
特殊な最適化もあります
その一例がクラスのインライン化です
クラスのインライン化による最適化は
ローカルのみで使用されるクラスを
削除する方法です
プログラマーはコードを保守しやすく
読みやすくするために
抽象化やユーティリティ
ヘルパーメソッドなどを導入
することがよくあります
その良い例がBuilderクラスです
Builterでは通常ビルダーの新しい
インスタンスを作成し
そのメソッドのいくつかを呼び出して
ビルダーの状態を変更し
メソッドを呼び出してビルダーの
状態に基づいて新しいオブジェクトを作成します
ただし実際はBuilderを使用せずにコードを
記述することが可能なため 実行時には

Chinese: 
少数几处使用
还有摇树
它可以移除未使用的代码
R8还有许多专门优化功能
这些功能对于移除代码结构非常重要
因为上述标准方法
无法移除此类结构
其中一个案例
我们称为类内嵌
类内嵌是一种优化功能
可移除仅在本地使用的类
作为程序员，我们经常使用
抽象、实用工具、辅助方法等
这样能让代码更加易于维护
易于读取
Builder类就是其中很好的例子
使用构建器时
通常会创建构建器新实例
调用几个方法更改
构建器状态，然后调用
方法，基于构建器状态
创建新对象
然而，在运行时中
并不特别需要这些构建器
因为完全可以

Korean: 
다음으로 미사용 코드의 삭제와 관련된 
Tree Shaking이 있습니다
R8에는 말씀드린 표준적인 기법으로는
삭제되지 않는
코드 구조를 삭제하기 위해
중요한 역할을 하는
특별한 최적화 기능도 있습니다
일례로 클래스
인라이닝을 들 수 있습니다
클래스 인라이닝은
로컬로만 사용되는
클래스의 삭제를 시도할 수 있는
최적화 기능입니다
우리 프로그래머들은
코드 관리를
용이하게 하고
가독성을 높이기 위해
종종 추상 및 유틸리티,
도우미 메소드 등을 도입합니다
좋은 예로
빌더 클래스가 있습니다
빌더를 사용해 일반적으로
빌더의 새로운 인스턴스를 만들어
이를 토대로
몇 가지 메소드를 호출하고
빌더 상태를 수정한 후
메소드를 호출해
빌더 상태에 기반한
새로운 객체를 만듭니다
그러나 런타임에서
이러한 빌더가
크게 필요하지 않은 이유는
빌더를 사용하지 않고도

Portuguese: 
Depois, temos o tree-shaking,
que é responsável
por remover código não usado.
O R8 também tem
otimizações mais especializadas
usadas para remover estruturas de código
que não seriam removidas
pelas técnicas padrão.
Um exemplo disso é
a reestruturação in-line de classes,
Essa otimização tenta remover classes
que só são usadas localmente.
Os programadores geralmente introduzem
abstrações e utilitários,
métodos auxiliares etc.
para facilitar a manutenção
e simplificar a leitura do código.
Um bom exemplo disso
são as classes de construtores.
Nesse caso, geralmente criamos
uma nova instância do construtor,
invocamos alguns métodos
para modificar o estado dele
e depois invocamos
um método para criar um novo objeto
com base no estado do construtor.
No entanto,
no tempo de execução, esses construtores
não são necessários, porque seria possível

Indonesian: 
dipakai di sedikit tempat.
Lalu ada tree shaking, yaitu
proses menghapus
kode yang tidak terpakai.
R8 juga memiliki
pengoptimalan khusus
yang berguna untuk
menghapus struktur kode
yang tidak terhapus
dengan teknik standar itu.
Salah satu contohnya
adalah class inlining.
Class inlining
adalah pengoptimalan
melalui penghapusan
class yang digunakan secara lokal.
Sebagai programmer,
kita sering memasukkan
abstraksi dan
utilitas, metode pembantu,
dan sebagainya agar kode
lebih mudah dikelola dan
mudah dibaca.
Salah satu contohnya
adalah class Builder.
Dengan builder,
Anda biasanya
membuat instance builder baru,
menyisipkan beberapa
metode untuk mengubah
status builder, kemudian
menyisipkan lagi
metode untuk membuat
objek baru berdasarkan
status itu.
Namun, di runtime,
builder ini
tidak terlalu dibutuhkan
karena kemungkinan

English: 
to write the code without
actually using the Builder.
So it's mostly there for the
maintainability of the code.
So class inlining
will actually try
to rewrite the
code in such a way
that the Builder
ends up being unused,
so that it can be removed by
[INAUDIBLE] optimizations.
So let's try to
look at an example.
So here's a few lines of code
taken from the Google I/O app
from this year.
So I should mention
that I've slightly
simplified the code here.
So if you go and
look in the I/O app,
it will be slightly
different from this.
So here on the first
line, we invoke
a method called
databaseBuilder, which
will basically just return
a new instance of a builder.
Then we invoke two
methods on that.
And the build method
here is going to return
a new instance of a database.
So the issue, so to speak,
with this piece of code
is that it uses
this builder here,
which has last time I checked
around 15 or 17 fields
and a bunch of methods.
And these few lines
of code actually

Japanese: 
Builderは厳密には必要ありません
これは主にコードの保守性のためです
クラスのインライン化は最適化によって
コードを削除できるように
Builderが使用されない方法で
コードを書き換えます
例を見てみましょう
今年のGoogle I/Oアプリから抜粋した
数行のコードです
ここではコードを少し
簡略化してあります
I/Oアプリを見ると
これとは少し異なると思います
最初の行では
databaseBuilderという
メソッドを呼び出します
このメソッドは
基本的にビルダーの新しいインスタンスを
返すだけです
そして２つのメソッドを呼び出します
このbuildメソッドは
データベースの新しいインスタンスを返します
このコードの問題はこのビルダーを
使用していることです
このビルダーでは15または17のフィールドと
多くのメソッドを確認しています
これらの数行のコードは

Indonesian: 
kode dibuat tanpa
menggunakan Builder.
Jadi, builder itu ada hanya
untuk mengelola kode.
Intinya, dengan class inlining
kode akan dibuat ulang sedemikian rupa
sehingga Builder
tidak jadi digunakan
agar kode itu bisa dihapus
melalui pengoptimalan.
Berikut contohnya.
Ada beberapa baris
kode diambil dari
aplikasi Google I/O tahun ini.
Saya sedikit menyederhanakan kode ini.
Jika Anda
lihat di aplikasi I/O,
kodenya akan sedikit
berbeda dengan yang ini.
Pada baris pertama,
kami menyisipkan
metode databaseBuilder yang
intinya akan memberikan
instance builder baru.
Lalu kami sisipkan
dua metode pada builder itu,
dan metode build
ini akan memberikan
instance database baru.
Jadi, masalah pada kode ini adalah
pada pemakaian builder ini,
yang terakhir saya periksa
punya sekitar 15 atau 17 kolom
dan sejumlah metode.
Dalam barisan kode ini,

Chinese: 
不使用构建器编写代码
运行时的存在主要出于代码维护性考虑
类内嵌将尝试
在不使用构建器的情况下
重新编写代码
这样R8优化就可以移除构建器
我们来看个例子
这里有几行代码
取自今年的Google I/O
应用
我需要说明的是
我这里稍稍
对代码进行了一些简化
如果你去看I/O应用的代码
与这里会有些许不同
这里的第一行，我们调用
名为databaseBuilder的方法
其功能基本上就是返回构建器新实例
然后我们对其调用两个方法
之后此处的构建器方法
将返回数据库新实例
这段代码的问题是
它使用了这个构建器
上次我查看时
其中包含15到17个字段
还有一堆方法
简单的几行代码

Korean: 
코드를 작성할 수 있기 때문입니다
코드 관리의 용이성은
주로 그러한 점과 관련됩니다
클래스 인라이닝은
코드 재작성을
시도하는데, 그 목적은
빌더가 사용되지 않게 하여
[INAUDIBLE] 최적화에 의해
삭제되도록 하는 것입니다
예를 하나 살펴보겠습니다
여기 올해 작성된 Google I/O 앱의 
코드가 몇 줄 있습니다
제가 약간 단순화해 놓은 코드인데요
I/O 앱을 살펴보면
이 코드와는 약간 다를 겁니다
여기 첫 줄에서
databaseBuilder라는
메소드를 호출하면
기본적으로
빌더의 새로운 인스턴스를
반환하게 됩니다
그러면 우리는 이를 토대로
2개의 메소드를 호출합니다
그러면 여기 빌더 메소드가
데이터베이스의 새로운 인스턴스를
반환할 것입니다
이 코드 조각의 문제는
여기 이 빌더를
사용한다는 것입니다
최근 제가 확인했을 때
이 빌더에는 15~17개 입력란과
다량의 메소드가 있었습니다

Spanish: 
escribir el código sin usarlos.
El compilador está allí, más que nada,
para el mantenimiento del código.
La intercalación de clases
intenta rescribir el código de tal manera
que no se use el compilador
para que las optimizaciones
puedan eliminarlo.
Veamos un ejemplo.
Estas son algunas líneas de código
de la app de Google I/O de este año.
Yo las simplifiqué un poco.
Por lo tanto, si revisan la app de I/O,
encontrarán algunas diferencias.
En la primera línea, invocamos un método
llamado databaseBuilder,
que mostrará
una nueva instancia del compilador.
Luego, invocamos dos métodos sobre este.
Este método de compilación
mostrará una nueva instancia
de la base de datos.
El problema con este fragmento de código
es que usa este compilador,
que, la última vez que lo vi,
tenía 15 o 17 campos
y varios métodos.
Estas pocas líneas de código

Portuguese: 
escrever o código sem usar o construtor.
Ele serve só para facilitar
a manutenção do código.
A reestruturação in-line de classes
tenta reescrever o código
de modo que o construtor não seja usado.
Dessa forma,
ele pode ser removido pelas otimizações.
Vamos ver um exemplo.
Estas linhas de código foram tiradas
do app do Google I/O deste ano.
É importante mencionar
que eu simplifiquei um pouco o código.
Se você observar o app do I/O,
ele estará um pouco diferente.
Nesta primeira linha,
invocamos um método
chamado databaseBuilder,
que basicamente retorna
uma nova instância de um construtor.
Depois, invocamos dois métodos,
e o método do construtor retornará
uma nova instância de um banco de dados.
O problema com esse código
é que ele usa este construtor
que tem entre 15 e 17 campos
e vários métodos,
e essas linhas de código

Korean: 
결국 이 몇 줄의 코드가
빌더 전체를 사용하게 되는 거죠
이것이 삭제되지 않으므로
R8이 이 코드를
최적화하는 방식을 살펴보겠습니다
R8은 우선 이 입력란 내의
내용을 인식합니다
이 입력란 내의 값이 상수임을
R8이 인식하게 됩니다
R8이 입력란의 값을
인라이닝하게 됩니다
이제 입력란 내에
읽을 값이 없으므로
입력란을 완전히
삭제해도 됩니다
그 다음 R8은 이 databaseBuilder 
메소드를 인라이닝합니다
말씀드린 대로 이 메소드가
빌더의 새로운 인스턴스를 반환한 후
데이터베이스 이름 인수에 대해
몇 가지 건전성 검사를
실시합니다
코드 안으로
인라이닝할 경우
해당 코드가
바깥 문맥으로 이동됩니다
여기 if 조건문에 대해서는
이름이 명확히 null은 아님을
R8이 인식하게 됩니다
이 부분을 제거하고
길이를 살펴보면
확인된 값은 0입니다
이 조건문은 항상 false이므로
R8이 해당 코드를 삭제합니다

English: 
end up using the entire builder.
So we can't get rid of it.
So let's try to look at
how R8 optimizes this code.
So the first thing
that R8 will do
is to look at this
field read here.
And R8 will recognize that this
field has a constant value.
So R8 will inline the
value of the field.
And now since the field
is never read anymore,
we can just get rid
of the field entirely.
The next thing R8 will do is
to inline this databaseBuilder
method.
So this method here just returns
a new instance of a builder
as I mentioned
before, and then it
performs a few sanity checks
on the database name argument.
So if we inline
that into the code,
then we'll just move the code
out into the outer context.
And now if we look at
the if condition here,
then R8 will recognize that the
name is definitely not null.
And if you trim that
and take the length,
then you don't get zero.
So since this condition
here is always false,
R8 will just remove the code.

Portuguese: 
acabam usando o construtor inteiro.
Por isso, não podemos descartá-lo.
Vejamos como o R8 otimiza esse código.
A primeira coisa que o R8 fará
é observar a leitura deste campo.
Ele reconhecerá
que este campo tem um valor constante
e fará a reestruturação
in-line do valor do campo.
Agora, como o campo não é mais lido,
podemos descartá-lo completamente.
A próxima ação do R8
será fazer a reestruturação in-line
do método databaseBuilder.
Esse método só retorna
uma nova instância de um construtor,
como já disse.
Em seguida, ele realiza
verificações de integridade
no argumento "name" do banco de dados.
Se reestruturarmos isso in-line no código,
moveremos o código
para o contexto externo.
Agora, se observarmos a condição "if",
o R8 reconhecerá que "name" não é nulo.
Se aplicarmos "trim"
e extrairmos o comprimento,
não recebemos zero.
Como essa condição é sempre falsa,
o R8 removerá o código.

Indonesian: 
seluruh builder dipakai
sehingga tidak bisa dihapus.
Mari kita lihat proses
pengoptimalan R8 pada kode ini.
Pertama-tama, R8 akan
melihat kolom yang ini.
untuk mengenali bahwa
kolom ini punya nilai konstan
sehingga R8 akan menata
nilai kolom tersebut.
Karena kolom tidak lagi diperlukan,
kita bisa menghapus
kolom ini semuanya.
Selanjutnya, R8 akan
menata metode
databaseBuilder ini.
Jadi, metode ini hanya
memberikan instance baru builder
seperti yang
sudah dijelaskan, lalu
melakukan pemeriksaan
pada argumen nama database.
Jika kita menatanya
ke dalam kode,
kita tinggal memindahkan
kode itu ke konteks luar.
Dan jika dilihat
pada ketentuan if,
R8 akan mengenali bahwa
name di sini jelas bukan null.
Dan dengan kode trim dan length,
hasilnya bukan nol.
Jadi, karena ketentuan
ini selalu false,
R8 akan menghapus kodenya.

Japanese: 
ビルダー全体を使用することになります
そのためそれを削除することはできません
R8がこのコードをどのように最適化するかを
見てみましょう
R8が最初に行うのは
この読み取ったフィールドを確認することです
R8はこのフィールドが定数値を
保持していることを認識します
R8はフィールド値をインライン化します
フィールドはもう読み取りされないので
フィールドを完全に削除することができます
R8が次に行うのは
databaseBuilderメソッドの
インライン化です
このメソッドはビルダーの
新しいインスタンスを返し
データベース名の引数に対して
サニティチェックを行います
それをコードにインライン化
する場合はコードを
外側のコンテキストに移動するだけです
このif条件を見ると R8は名前が確実に
nullでないことを認識するでしょう
それをトリムして長さを取ると
ゼロではありません
この条件は常にfalseであるため
R8はコードを
削除することになります

Spanish: 
usan todo el compilador,
así que no podemos eliminarlo.
Veamos cómo R8 optimiza este código.
Lo primero que hace R8
es mirar esta lectura de campo
y reconocer que tiene un valor constante.
Por lo tanto, intercala el valor del campo.
Como el campo nunca se lee,
podemos eliminarlo por completo.
Después, R8 intercala el método
databaseBuilder.
Como dije antes, este método que ven aquí
muestra una nueva instancia del compilador
y, después, hace algunos controles
de funcionalidad al argumento
del nombre de la base de datos.
Si lo intercalamos en el código,
el código pasa al contexto exterior.
Si observamos esta condición,
vemos que R8
detectará que el nombre no es nulo.
Además, si lo acortamos,
el resultado no será cero.
Por ende,
como esta condición es siempre falsa,
R8 eliminará el código.

Chinese: 
结果却使用了整个构建器
所以没法将其简化
我们来看看R8如何优化这段代码
R8首先要做的
就是查看此处的字段读取
R8会识别出此字段有常量值
因此R8会内嵌字段值
由于此时字段不会再次读取
可以将其彻底移除
接下来，R8将内嵌该databaseBuilder
方法
如上所述，此方法只能
返回构建器的新实例
然后它还会
对数据库名称参数执行几次健全性检查
如果将其内嵌入代码中
就能将代码移动至外部语境
如果观察此处的if条件
R8可识别出名称不可能为空
如果进行修剪并取其长度
则结果不为零
由于此条件始终为false
R8会清除这段代码

Indonesian: 
Jadi kodenya tinggal yang ini.
Saat inilah pengoptimalan
class inlining berjalan.
Ada empat tahap dalam
pengoptimalan ini.
Tahap pertama adalah
menjalankan escape analysis
untuk builder ini.
Langkah ini secara intuitif
berupaya menentukan
bahwa builder hanya
digunakan secara lokal pada kode ini,
katakanlah builder
dibuat ke dalam kolom,
maka kita tidak akan bisa
menghapus instance
secara menyeluruh
karena kita butuh instance
dan menyimpannya ke dalam kolom.
Dalam hal ini, R8
akan menganalisis kode
dan memastikan
builder benar-benar lokal.
Berikutnya adalah tahap yang
akan menata tiap metode
yang digunakan pada builder.
Saya mulai dengan
konstruksi ini.
Kode ini menetapkan peran sejumlah
kolom di instance builder.
Ketika ditata, peran
kolom ini dipindah ke
konteks luar agar peran itu

Spanish: 
Entonces, nos queda este fragmento.
Aquí entra en juego
la intercalación de clases.
Esta optimización consta de cuatro etapas.
En la primera,
se hace un análisis
de escape sobre el compilador.
Se intenta determinar
de manera intuitiva que este solo se usa
localmente en nuestro fragmento de código.
Por ejemplo, si el compilador
se incluyera en un campo,
no tendríamos ninguna esperanza
de deshacernos
de la instancia por completo
porque necesitaríamos
obtener una instancia
y guardarla en un campo.
Por ende, en este caso,
R8 analizará el código
y determinará que el compilador es local.
Después, sigue la segunda etapa,
en la que R8 trata de intercalar
cada uno de los métodos usados
en el compilador.
Aquí comenzamos con el constructor,
que asigna varios campos
a la instancia del compilador.
Al intercalar eso,
se traslada la asignación de campos
al contexto exterior,

Korean: 
결국 이런 코드 조각이 남게 되는데
바로 여기에서 클래스
인라이닝 최적화가 수행됩니다
이 최적화는
4개 단계로 진행됩니다
첫 번째 단계로 이 빌더에
이스케이프 분석을 실행합니다
분석 과정을 통해
문제되는 부분이 이 코드 조각에서
로컬로만 사용된다고
직관적인 판단을
내리려 할 것입니다
문제되는 부분이
입력란에 작성되었다면
우리가 인스턴스 전체를
삭제할 수는 없습니다
왜냐하면 인스턴스를 확보하고
입력란에 저장해야 하기 때문입니다
이 경우, R8이 코드를 분석하여
빌더가 사실상
로컬이라고 판단합니다
그런 후 다음 단계로 진행해
빌더에서 사용 중인
각 메소드에 대한
인라이닝을 시도합니다
이 생성자로 시작해 보겠습니다
이 생성자는 빌더 인스턴스에
다수의 입력란을 할당합니다
인라이닝할 경우 이 입력란 할당이
바깥 문맥으로 옮겨져
할당분이 빌더 인스턴스에
존재하게 됩니다

Chinese: 
此时只剩这些代码
类内嵌优化也在此时启动
优化分为四个阶段
首先做的是
对这里的构建器运行逃逸分析
R8凭借直觉判断
确定该段代码中
构建器仅在本地使用
如果说构建器已经写入字段
那么我们就没有机会
完全去除实例
因为我们需要获取实例
并将其储存于字段中
本案例中，R8将分析代码
判断构建器是否确实在本地
然后进入下一个阶段
尝试内嵌构建器使用的
每一个方法
我们先来看这里的构造函数
它为构建器实例分配了许多字段
对其进行内嵌时
我们会将这些字段任务
移动至外部语境
这时任务会

Portuguese: 
Assim, ficamos com este código.
Aqui entra a otimização
de reestruturação in-line de classe.
Ela funciona em quatro fases.
A primeira ação
é executar
uma análise de escape do construtor.
Ela tentará, intuitivamente,
determinar se o construtor
só é usado localmente
nesta parte do código.
Se o construtor fosse gravado em um campo,
não haveria como remover
a instância completamente,
porque precisamos receber uma instância
e armazená-la em um campo.
Neste caso, o R8 analisará o código
e determinará se o construtor é local.
Depois, ele avançará para a próxima fase,
em que tentará reestruturar in-line
todos os métodos usados no construtor.
Começaremos com este construtor.
Ele só atribui alguns campos
na instância do construtor.
Ao reestruturar de modo in-line,
moveremos essas atribuições de campo
para o contexto externo,
onde as atribuições
estarão na instância do construtor.

English: 
So this leaves us with
this piece of code here.
And that's where the class
inlining optimization kicks in.
So this optimization
works in four phases.
And the first thing
that it's going to do
is to run an escape analysis
for the builder here.
So it will basically
try intuitively
to determine that the
responsible is only locally
used in this piece of code.
So say that the responsible
was being written into a field,
well, then there would
be no hope for us
that we could get
rid of the instance
entirely, because we actually
need to get an instance
and store it into a field.
So in this case, R8
will analyze the code
and determine that the
builder is in fact local.
And then it will move on
to the next phase, where
it will try to inline
each of the methods that
are being used on the builder.
So we will start with
the constructor here.
It just assigns a bunch of
fields on the builder instance.
So when we inline that, we'll
move these field assignments
into the outer context, where
the assignments will now

Japanese: 
コードはこうなります
クラスのインライン化による最適化が
始まったところです
この最適化は４つのフェーズで実行されます
最初に行うのはビルダーの
エスケープ分析を実行することです
それによりこのコードでビルダーが
ローカルでのみ使用されていることが
直観的に判断されます
ビルダーはフィールドに書き込まれていたため
インスタンスを完全に
削除できる可能性はなくなりました
インスタンスを取得してフィールドに
保存する必要があるためです
このケースではR8はコードを分析し
ビルダーが実際にローカルであると判定します
そして次のフェーズに進み
ビルダーで使用されている
各メソッドをインライン化します
コンストラクタを見てみましょう
これは多くのフィールドを
builderインスタンスに割り当てます
それをインライン化するとき
これらのフィールドの
割り当てを外側のコンテキストに移動します
割り当てはビルダーインスタンスに行われます

Portuguese: 
Em seguida,
o R8 avança para o método seguinte.
Ele somente define um campo como "true".
Ao reestruturar de modo in-line,
moveremos essa atribuição de campo
para o contexto externo também.
Por último, temos o método build.
Não é relevante para esta apresentação
o que esse método faz.
É importante notar
que ele lê vários campos no construtor.
Assim, ao reestruturar
esse código de modo in-line,
os acessos a este campo
estarão no construtor, e não aqui.
Assim, ficamos com este código.
Lembre-se de que queremos
remover a instância do construtor,
mas ainda temos alguns acessos a ele.
Se você observar
o código com atenção aqui,
verá que temos uma leitura
logo após uma gravação de campo.
Portanto, basta usar
o valor armazenado no campo,
em vez de fazer a leitura dele.
Se também fizermos isso
nas outras leituras de campos,

Japanese: 
R8は次のメソッドのインライン化に進みます
これはフィールドをtrueに設定するために
発生します
インライン化すると
そのフィールド割り当ても
外側のコンテキストに移動されます
最後にbuildメソッドがあります
buildメソッドが行っていることは
このプレゼンテーションでは
特に重要ではありません
注目すべきはビルダーの
フィールドの束が読み取られることです
そのため
このコードをインライン化すると
これらのフィールドアクセスは
代わりにbuilderで行われます
OK
コードはこうなります
builderインスタンスを
削除したいのですが
まだbuilderへのアクセスが
かなりあります
コードを詳しく見ると
フィールドの書き込みの直後に
フィールドの読み取りがあることがわかります
このようにフィールドを読み取る代わりに
フィールドに格納された値を使用できます
他のフィールド読み取りにも同様に行う場合

Korean: 
그런 다음 R8은 다음 메소드를
인라이닝하게 됩니다
그 결과 입력란은 true가 됩니다
인라이닝하면 입력란 할당이
바깥 문맥으로도 옮겨집니다
마지막 살펴볼 것은
빌드 메소드입니다
빌드 메소드의 역할은
오늘 프리젠테이션의 목적에 비추어
중요하지 않습니다
한 가지 살펴볼 사항은
빌드 메소드가
수 많은 입력란을
읽는다는 것입니다
빌더이기 때문에
이 코드를 인라이닝하면
이러한 입력란 액세스는
빌드 메소드가 아니라
빌더를 대상으로 하게 됩니다
이제 이 코드 조작을
살펴봐야 합니다
우리가 원하는 것은
빌더 인스턴스의 삭제이지만
빌더에 대한 몇몇 액세스가 존재합니다
이 코드를 자세히 살펴보면
입력란 쓰기 바로 뒤에
입력란 읽기가 있습니다
입력란을 읽는 대신에
이처럼 입력란에 저장된 값을
가져와 사용하면 됩니다
이렇게요
다른 입력란 읽기에도
동일하게 할 경우

Indonesian: 
berada di instance builder.
Lalu, R8 akan menata
metode selanjutnya.
Dalam contoh ini,
kolom diubah ke true.
Jadi, ketika ditata,
peran kolom akan pindah
ke konteks luar juga.
Kemudian metode build.
Sebenarnya fungsinya tidak terlalu perlu
dibahas pada presentasi ini.
Yang penting adalah
metode build
membaca kolom-kolom
di sini, yaitu builder,
jadi ketika kode ini ditata,
akses kolom ini akan
berada di builder.
Berarti tinggal kode yang ini.
Tujuan kita adalah
menghapus instance builder,
tapi masih ada sedikit akses ke builder.
Jika dilihat dengan
cermat pada kode ini,
ada kolom read setelah kolom write.
Kita bisa ambil nilai
yang ada di kolom ini
dan memakainya ketimbang
membaca kolomnya, seperti ini.
Lakukan langkah yang sama
untuk kolom read lainnya,

English: 
be on the builder instance.
Then R8 moves on to
inlining the next method.
This just happens to
set a field to true.
So when we inline, that will
move that field assignment out
in the outer context as well.
And then, finally,
there's the build method.
So it's not particularly
important for the purpose
of this presentation what this
build method is actually doing.
One thing that's
worth noting here
is that it reads
a bunch of fields
on this, which is the builder,
so when we inline this code,
then these field
accesses will be
on the builder instead of this.
OK, so that leaves us with
this piece of code here.
So remember that we want to get
rid of the builder instance,
but we still have quite a
few accesses to the builder.
If we look more closely
at the code here,
you'll see that we have a field
read right after a field write.
So we can just take the value
that was stored into the field
and use that instead of
reading the field, like this.
And if we do that for the
other field reads as well,

Chinese: 
出现在构建器实例中
之后R8继续内嵌下一个方法
这碰巧能将字段设置为true
进行内嵌时，字段任务也将移出
至外部语境
最后，进入构建方法
本次展示的重点
不在于讲解构建方法的工作原理
这里需要注意的是
它读取构建器中的许多字段
当我们内嵌此代码时
这些字段的访问
将在构建器，而不在构建方法
好，现在只剩这些代码
注意，我们希望去除构建器实例
但还是对构建器进行了许多次访问
如果进一步观察这里的代码
可以发现字段写入后
紧跟着一次字段读取
因此我们可以直接提取字段中存储的值
直接使用，而无需读取字段，像这样
如果其他字段读取也这样操作

Spanish: 
es decir, a la instancia del compilador.
Luego,
R8 pasa a intercalar el método siguiente.
Se establece un campo como verdadero,
de modo que,
al intercalar, la asignación de campos
se hace también en el contexto exterior.
Por último,
se aplica el método de compilación.
Para esta presentación, no importa
qué hace este método exactamente.
Lo que sí deben tener en cuenta
es que lee varios campos
del compilador. Por lo tanto,
cuando intercalamos el código,
los accesos a campos
están en el compilador en vez de aquí.
Por consiguiente,
nos queda este fragmento de código.
Recuerden que queremos deshacernos
de la instancia del compilador,
pero aún hay varios accesos a él.
Si observamos detenidamente el código,
veremos que hay una lectura
de campo después de una escritura.
Podemos tomar
el valor almacenado en el campo
y usarlo en vez de leerlo.
Si hacemos lo mismo
con las demás lecturas de campos,

Korean: 
이러한 값을
적용하게 됩니다
이러한 입력란 할당을 살펴볼 때
필드의 읽은 값을
모두 삭제했기 때문에
이제 입력란 할당분을
모두 제거할 수 있습니다
이제 이 코드 조각을
살펴봐야 합니다
이제 이 코드 부분에서 빌더가
더 이상 사용되지 않으므로
보여드리고자 했던
과정은 완료되었습니다
이제 삭제해도 됩니다
코드를 기본적으로 최적화하고
빌더를 완전히 제거한 것입니다
이제 Tree Shaking을 실행하면
빌더가 삭제됩니다
Google I/O 앱에서
이 최적화 기능 하나만으로
정확히 170개 클래스와
350개 메소드가 삭제되어
앱의 DEX 크기를
약 38K 축소했습니다
이는 매우 특별한
최적화 사례로서
인상적인 케이스라고
할 수 있습니다
수많은 사례 중에서도 단연 독보적이고 
특별한 최적화 결과입니다

Spanish: 
también se propagarán estos valores.
Si observamos estas asignaciones de campo,
vemos que quitamos todas las lecturas.
En consecuencia, podemos
deshacernos de todas las asignaciones.
El código que queda es este.
Logramos lo que queríamos
porque ya no se usa el compilador
en esta parte del código;
de modo que también podemos quitarla.
El resultado es un código optimizado
que no incluye el compilador.
Ahora,
cuando eliminemos el código obsoleto,
se quitará el compilador.
En la app de Google I/O, esta optimización
es responsable
de eliminar exactamente 170 clases
y unos 350 métodos, y de reducir
el tamaño del archivo .dex de la app
en alrededor de 38 000.
Creo que es algo impresionante
para una optimización muy especializada.
Recuerden que esta es solo una
de muchas optimizaciones especializadas.

Japanese: 
これらの値も下方に伝播します
フィールド割り当てを見ると
これらのフィールドの
読み取りがすべて削除されています
これでフィールド割り当てを
すべて削除できるようになりました
コードはこうなります
コードのこの部分でbuilderが
使用されなくなったため
目的はほぼ達成されたと言えます
こちらも削除できます
つまりコードが
根本的に最適化され builderが
完全に削除されたということです
ツリーシェイキングを実行すると
builderは削除されます
Google I/Oアプリでは
この最適化だけで170クラス
約350メソッドが削除され
アプリのDEXサイズが
約38K削減されます
これは非常に特殊化された最適化としては
大変素晴らしいと思います
これは多くの特殊化された
最適化の１つに過ぎません

Portuguese: 
precisaremos propagar esses valores.
Se observarmos estas atribuições de campo,
removemos todas as leituras desses campos.
Agora podemos remover
todas as atribuições de campo.
Assim, ficamos com este código.
Agora praticamente alcançamos
o que queríamos, porque o construtor
não está mais sendo usado no código.
Portanto, podemos remover isto.
Com isso, otimizamos o código
e descartamos totalmente o construtor.
Agora,
quando o tree-shaking for executado,
o construtor será removido.
No app do Google I/O, só essa otimização
é responsável por remover 170 classes
e em torno de 350 métodos,
reduzindo o tamanho
dos arquivos dex do app em 38 K.
Acho isso muito impressionante
para uma otimização tão especializada.
Lembre-se de que esta
é só uma otimização especializada
entre muitas outras.

Indonesian: 
dan kita juga akan
menyebarkan nilai ini.
Jika kita lihat peran 
kolom di sini,
semua read pada kolom
ini sudah dihapus,
jadi kita bisa hapus
semua peran kolom ini,
jadi tinggal kode ini.
Sekarang kita
sudah berhasil
mendapat yang kita mau
karena builder tidak lagi
digunakan dalam kode ini.
Jadi sekarang
bisa kita hapus.
Artinya, kita sudah
mengoptimalkan kode
dan menghapus
builder seutuhnya.
Jadi ketika kita
jalankan tree shaking,
builder akan dihapus.
Pada aplikasi Google I/O,
pengoptimalan ini saja
sudah menghapus 170 class,
hampir 350 metode, dan
menekan ukuran DEX aplikasi
nyaris 38 ribu.
Saya rasa cukup
bagus untuk suatu
pengoptimalan khusus.
Perlu diingat bahwa ini baru
satu pengoptimalan khusus
dari sekian banyak lainnya.

English: 
then we would also
propagate these values down.
Now if we look at these
field assignments here,
we just removed all of
the reads of these fields,
so now we can get rid of all
of these field assignments.
And that leaves us with
this piece of code.
So now we've pretty
much achieved
what we were hoping for, because
the builder is no longer being
used in this part of the code.
So now we can also
remove that one.
And that means that we've now
basically optimized the code
and gotten completely
rid of the builder.
So now when we run tree
shaking, the builder
will actually just be removed.
So on the Google I/O app,
so this optimization alone
is responsible for removing
exactly 170 classes, around
350 methods, and then it
reduces the DEX size of the app
by around 38K.
So I think that's quite
impressive for a very
specialized optimization.
And remember that this is just
one specialized optimization
out of many [INAUDIBLE].

Chinese: 
那么就能继续向下沿用这些值
现在来看这里的字段任务
我们去除了这些字段的所有读取
因此我们能够移除所有这些字段任务
此时就只剩余这些代码
我们现在基本上实现了
自己的期望，因为这段代码
不再使用构建器
此时我们也能去掉它
这也意味着，我们已经基本实现了代码优化
完全去除了构建器
这时再次运行摇树
将直接清除构建器
在Google I/O应用中，仅这一项优化
就能移除170个类
约350种方法，将应用的DEX
减少约38K
我认为，对于一项非常有针对性的优化而言
这非常了不起
而且请注意，这只是众多专项优化
当中的一个

Portuguese: 
Isso conclui o exemplo.
Vou passar a palavra ao Soren novamente.
Obrigado.
A moral disso tudo é:
use o R8 para reduzir seus apps.
O tamanho do app é muito importante.
Ele é fácil de ativar.
Todos os pontos de entrada
do Android são gerenciados.
Você só precisa
tomar cuidado com a reflexão
e com algumas bibliotecas que normalmente
usam reflexão,
como frameworks de serialização
ou mapeadores objeto-relacionais.
Agora gostaria de falar sobre algo
completamente diferente.
Você sente falta das APIs
do Java 8 e do java.util.streams
no Android?
Você tem interesse
em usar mais APIs do Java 8
em versões menores do SDK?
Muitos desenvolvedores pediram isso.
No Google I/O deste ano,
prometemos trabalhar nisso.
Nossa equipe
não é só responsável pela redução,

English: 
So with that, that
concludes the example.
And I'll give the [INAUDIBLE]
back to you, Soren.
SOREN GJESSE: Thank you.
So the takeaway from
this should be use R8
to make your apps smaller,
as app size does matter.
It's easy to turn on.
All the Android entry
points are handled.
You only need to worry
about reflection.
And some of the libraries
which are normally
used for [INAUDIBLE] things
like serialization frameworks
or maybe
object-relational mappers.
Yes.
And now I actually want
to talk about something
completely different.
So are you missing the Java
8 APIs and java.util.streams
in Android?
Are you interested in
using more Java 8 APIs
on lower SDK versions?
Well, many developers
have asked.
And at Google I/O
earlier this year,
we promised to work on this.
So our team is not only
responsible for shrinking,

Korean: 
이로써 예제 설명을 마치겠습니다
이제 다시 소렌이 진행할 순서입니다
감사합니다
앱의 크기가 관건이므로
결론은 앱을 축소하기 위해
R8을 사용하는 것입니다
R8은 활성화가 쉽고
모든 Android 진입점을
처리할 수 있으므로
리플렉션만 신경쓰시면 됩니다
그리고 직렬화
프레임워크와 같이 일반적으로
리플렉션 등에 사용되는
일부 라이브러리나 경우에 따라서는
객체 관계형 매퍼만
신경쓰시면 됩니다
이제 완전히 다른 주제를
다루려고 합니다
Android의 Java 8 API와
java.util.streams를 원하십니까?
낮은 SDK 버전의
Java 8 API를 더 많이
사용하고 싶으십니까?
이는 많은 개발자들이
요청하는 것들입니다
올해 초 Google I/O에서
우리는 이러한 요청에
화답할 것을 약속했습니다
따라서 우리 팀은
코드축소뿐 아니라

Japanese: 
さて これで説明は終了です
ではソレンさん マイクをお返ししますね
ありがとう
アプリのサイズは重要なので
R8を使用してアプリを小さくする
必要があります
これは簡単に実行できます
すべてのAndroidエントリポイントに
対応できます
気を付けるべきはリフレクションだけです
そして通常シリアル化フレームワークや
オブジェクト関係マッパーなどの
リフレクション関連に
使用される一部のライブラリです
はい
さて今度は全く別なものについて
お話させてください
AndroidでJava 8 APIや
java.util.streamが
なくなっていませんか？
下位SDKバージョンで
さらに多くのJava 8 APIを
使ってみたくありませんか？
多くの開発者が必要としています
Google I/Oでは今年初めに
この件に取り組むことを約束しました
私たちのチームは圧縮だけではなく

Chinese: 
好，案例讲解到此结束
再次把讲台交还给Soren
谢谢
本节演讲的重点是
使用R8缩小应用大小
因为应用大小非常重要
R8很容易开启
所有Android进入点都得到处理
只需要留意反射
某些库通常
用于[INAUDIBLE]，如序列化框架
或用于对象关系映射
是的
现在我想谈谈另一个
完全不同的话题
大家是否怀念Android中的Java 8 API和
java.util.streams？
有没有兴趣在较低SDK版本中
使用更多Java 8 API？
许多开发者有这种需求
今年早些时候的Google I/O中
我们承诺努力攻关
我们团队不仅负责压缩

Indonesian: 
Sekian penjelasan tentang contohnya.
Saya kembalikan ke Soren.
SOREN GJESSE: Terima kasih.
Kesimpulannya, gunakan R8
untuk memperkecil ukuran aplikasi,
karena ukuran memang penting.
Itu membuat aplikasi mudah diaktifkan.
Semua titik entri Android ditangani.
Anda hanya perlu
memikirkan refleksi
dan sejumlah
library yang biasanya
digunakan untuk [TIDAK TERDENGAR]
seperti framework serialisasi
atau mungkin pemetaan terkait objek.
Ya.
Sekarang saya ingin
membahas sesuatu yang
benar-benar berbeda.
Apakah Anda ingin
kembali ke API Java 8 dan
java.util.streams di Android?
Ingin menggunakan API Java 8
pada SDK versi lama?
Banyak developer yang bertanya-tanya.
Pada Google I/O tahun ini,
kami berjanji menggarapnya.
Jadi tim kami tidak hanya
mengerjakan penyusutan,

Spanish: 
Así concluye el ejemplo.
Los dejo nuevamente con Soren.
Gracias.
Las conclusiones
de todo esto son las siguientes:
Usen R8 para reducir el tamaño de su app,
ya que el tamaño es importante.
Es fácil de activar.
Se abordan
todos los puntos de entrada de Android.
Solo deben preocuparse por la reflexión.
Algunas de las bibliotecas
suelen usarse para [inaudible],
como marcos de serialización
o, quizás, el mapeo objeto-relacional.
Ahora quiero hablarles de algo
completamente diferente.
¿Extrañan las API
de Java 8 y java.util.streams en Android?
¿Quieren usar más API de Java 8
en versiones anteriores de SDK?
Muchos desarrolladores las pidieron,
y, este año en Google I/O,
prometimos poner manos a la obra.
Nuestro equipo
no solo es responsable de la reducción,
también estamos a cargo

Japanese: 
Java 8のdesugarにも対応します
私たちはこの件に既に取り組んでいます
昨日お聞きいただいたかもしれませんが
この機能はまもなく公開されます
昨日リリースされたAndroid
Studio 4.0アルファ1で
そのプレビュー版が
利用可能であることを
お知らせいたします
最後になりましたが 
R8をまだ使用されていない方は
ぜひお使いいただき
新しいJava 8のdesugarを
お試しください
バグは遠慮なくご連絡ください
皆さんのご意見を大切にします
バグはぜひ教えてください
機能のご要望 特に新しいdesugarに関する
ご要望をお聞かせください
これで私たちの講演は終了です
今日は講演にご参加いただき
ありがとうございました

Indonesian: 
tapi juga Java 8 desugaring.
Kami telah mengerjakannya.
dan mungkin ada yang
sudah dengar kemarin,
fitur ini sekarang
sudah hadir.
Dengan bangga
saya umumkan
pratinjaunya sudah tersedia di
Android Studio 4.0 alpha 1
yang dirilis kemarin.
Demikian presentasi kami.
Silakan coba R8
jika belum pernah memakainya,
coba juga Java 8
desugaring yang baru.
Jangan ragu melaporkan bug.
Masukan Anda sangat berharga.
Kami ingin menemukan bug.
Juga permintaan fitur,
terutama tentang
desugaring yang baru.
Itu saja dari kami.
Terima kasih atas kehadirannya.

Chinese: 
还负责Java 8的精简
我们也在努力这样做
昨天大家可能已经听说
该功能即将面世
我很高兴地宣布
Android Studio 4.0 alpha 1版本
已经拥有该功能，昨天已经发布
[掌声]
我的演讲也进入尾声，最后我要说
如果还没使用R8，请抓紧尝试
还有尝试一下全新的Java 8
精简
请随时提交遇到的问题
我们很重视大家的反馈
希望看到大家提交的错误报告
希望看到大家的功能请求
尤其是新的精简工具
我们的内容就是这些
非常感谢大家聆听此次演讲
[掌声]
[音乐]

Spanish: 
de la desazucarización de Java 8.
Estamos trabajando en ello.
Quizás hayan escuchado ayer
que pronto habrá novedades.
Además, me complace anunciar
que pueden ver un adelanto
en Android Studio 4.0 alfa 1,
que se lanzó ayer.
Para terminar, solo les diré que usen R8
y, si aún no lo hicieron,
prueben la desazucarización
de Java 8.
No duden en informar errores.
Valoramos sus comentarios.
Queremos conocer los errores.
Queremos que soliciten funciones,
en especial
para la nueva desazucarización.
Eso es todo.
Gracias por asistir a esta presentación.

Korean: 
Java 8 desugaring을 위한
노력도 기울여야 했고
실제로 그렇게 해왔습니다
어제 이미 들으셨겠지만
그 성과를 이제 곧
확인할 수 있으실 겁니다
바로 어제 출시된
Android 스튜디오 4.0 알파 1으로
미리 체험하실 수 있다는
기쁜 소식을 알려 드립니다
이로써 오늘 회의를 마무리하며
R8을 사용하시고
새로운 Java 8 desugaring을
사용하지 않으셨다면 체험해 볼 것을
당부드립니다
또한 버그는 적극적으로
보고해 주십시오
여러분의 피드백이 필요합니다
버그 신고를 환영합니다
기능 관련 요청, 특히 새로운 
desugaring에 대한 요청을 환영합니다
저희가 준비한 내용은 여기까지입니다
참석해 주셔서 대단히 감사합니다

Portuguese: 
mas também pela simplificação do Java 8.
Estamos trabalhando nisso.
Como você já deve ter ouvido ontem,
chegou o momento.
Gostaria de anunciar
que já temos
uma versão inicial no Android Studio
4.0 Alfa 1, lançada ontem.
Com isso, encerramos a apresentação.
Use o R8, caso ainda não tenha feito isso,
teste a nova
versão simplificada do Java 8.
Comunique os bugs.
Seu feedback é muito importante.
Queremos receber os bugs.
Queremos solicitações de recursos,
principalmente em relação
à nova versão simplificada.
Isso é tudo.
Muito obrigado pela sua presença.

English: 
but we're also responsible
for Java 8 desugaring.
And we've been working on this.
And as you maybe have
heard already yesterday,
this is now coming.
And I'm happy to
announce there's
a preview of this available
already in Android Studio
4.0 alpha 1, which was
released yesterday.
[APPLAUSE]
So with that, I'll just
close and say, please use R8
if you're not already doing
so, try out the new Java 8
desugaring.
Don't hesitate to file bugs.
We actually value your feedback.
We want to have bugs.
We want to have feature
requests, especially around
the new desugaring.
And that was all we had for you.
Thank you very much for
attending this talk.
[APPLAUSE]
[MUSIC PLAYING]
