
Korean: 
[음악 재생중]
안녕하세요, 여러분
저는 '슈강'이고
Android Studio 팀의
소프트웨어 엔지니어입니다
안녕하세요
저는 '이'입니다
저도 Android Studio 팀
소프트웨어 엔지니어예요
오늘 저희는
Android 스튜디오의 프로파일러에
대해 말씀드릴 거예요
여러분도 아시겠지만
프로파일러는
개발자에게
CPU, 메모리, 네트워크
에너지 사용 정보를 
제공하기 때문에
앱을 더 간단하고
빠르게 최적화할 수 있어요
오늘은 메모리 프로파일러에
집중하려고 합니다.
많은 개발자들이
메모리 프로파일러를 사용하는 이유는
메모리 누수를
찾고 있기 때문이에요
메모리 누수란 뭘까요?
기존의 정의에서
메모리 누수는 객체입니다
작동 중인 프로그램에
액세스할 수 없게 되지만
여전히 메모리를 차지합니다
C 또는 C++의
포인터로 작업한 적이 있다면
이 개념에
익숙하실 겁니다
하지만 Kotlin과
자바의 세계에서는

Portuguese: 
Olá a todos!
Meu nome é Shukang.
Sou engenheiro de software
da equipe do Android Studio.
Olá, meu nome é Yi.
Também sou engenheiro de software
da equipe do Android Studio.
Hoje falaremos sobre
sobre criadores de perfil
no Android Studio.
Como é possível que vocês saibam,
os criadores de perfil
fornecem aos desenvolvedores
informações sobre CPU,
memória, rede e uso de energia.
Assim, é possível otimizar os apps,
tornando-os mais enxutos e rápidos.
Hoje focarei no Memory Profiler.
Muitos desenvolvedores
usam o Memory Profiler
quando procuram
por um vazamento de memória.
Mas o que é isso?
Na definição convencional,
um vazamento de memória é um objeto.
Ele fica inacessível
ao programa em execução,
mas ainda ocupa a memória.
Se você já trabalhou
com ponteiros no C ou C++,
é possível que conheça esse conceito.

Indonesian: 
-Halo semuanya.
Nama saya Shukang.
Saya software engineer dari
tim Android Studio.
-Hai, nama saya Yi.
Saya juga software engineer
dari tim Android Studio.
-Jadi hari ini
kami akan berbicara
tentang Profiler
di Android Studio.
Seperti yang telah Anda ketahui,
Profiler kami menyediakan informasi 
penggunaan CPU, memori, jaringan,
dan energi bagi developer
sehingga mereka bisa mengoptimalkan
aplikasi menjadi lebih ramping dan cepat.
Hari ini, saya akan
fokus pada Profiler Memori.
Banyak developer
menggunakan Profiler Memori
untuk mencari
kebocoran memori.
Jadi apa itu
kebocoran memori?
Dalam definisi konvensional,
kebocoran memori adalah objek.
Objek tersebut tidak dapat diakses
oleh program yang sedang berjalan,
tetapi masih menggunakan memori.
Jika Anda pernah bekerja
dengan pointer di C atau C++,
Anda mungkin akrab
dengan konsep ini.
Tetapi
di platform Kotlin dan Java,

Chinese: 
大家好 我是 Shukang 
是来自 Android Studio 团队的软件工程师
大家好 我是 Yi
也是来自 Android Studio 团队的软件工程师
今天我们想谈的是 Android Studio 中的分析工具 (Profiler)
大家可能已经知道了 我们的 Profiler
可以为开发者提供 CPU 内存 网络 能耗等信息
方便他们优化应用 让应用更加精干 高速
今天我重点来谈谈内存分析工具 (Memory Profiler)
很多开发者使用 Memory Profiler 
是因为他们想排查内存泄漏问题
那么 内存泄漏是什么？
按照传统定义 内存泄漏属于对象
正在运行的程序无法访问这个对象
但这个对象仍然占据着内存 这就叫内存泄漏
如果你曾经用过 C 或 C++ 语言下的指针
那么你可能会比较熟悉这个概念
不过 在 Kotlin 和 Java 的世界里

Spanish: 
[MÚSICA SONANDO]
SHUKANG ZHOU: Hola a todos.
Mi nombre es Shukang.
Soy ingeniero en sistemas 
del equipo de Android Studio.
YI YANG: Hola, me llamo Yi.
También soy ingeniero en sistemas
del equipo de Android Studio.
SHUKANG ZHOU:
Hoy vamos a hablar
de los Profilers en Android Studio.
Como saben, nuestros Profilers
brindan información sobre
el CPU, la memoria, la red
y el uso de energía a los desarrolladores
para que puedan optimizar
la app y que sea más liviana y rápida.
Hoy me enfocaré
en Memory Profiler.
Muchos desarrolladores
llegan a Memory Profiler
porque están buscando
una fuga de memoria.
¿Qué es una fuga de memoria?
Según la definición tradicional,
una fuga de memoria es un objeto.
Se vuelve inaccesible
para el programa en ejecución,
pero igual ocupa la memoria.
Si alguna vez han trabajado
con punteros en C o C++,
este concepto
puede serles familiar.
Pero en el mundo 
de Kotlin y Java,

Japanese: 
こんにちは
Android Studioチームの
Shukangです
私はYiです
私も同じチームに
所属しています
今日のテーマは
Android Studioの
プロファイラです
プロファイラでは
アプリの
最適化および
高速化に役立つ
メモリ、CPU、
ネットワーク
エネルギーの使用状況を
知ることができます
まず メモリプロファイラを
ご紹介します
このプロファイラは
主に
メモリリークの調査に
使います
メモリリークとは
何でしょうか？
従来の定義では
メモリリークとは
アクセス不能なまま
メモリを占有している
オブジェクトのことです
CやC++のポインタを
ご存知の方には
この概念は
おなじみかもしれません
しかし
Kotlinや

English: 
[MUSIC PLAYING]
SHUKANG ZHOU: Hello everyone.
My name is Shukang.
I'm a software engineer from
the Android Studio team.
YI YANG: Hi, my name's Yi.
I'm also a software engineer
from the Android Studio team.
SHUKANG ZHOU: So
today we are going
to talk about Profilers
in Android Studio.
As you may have
known, our Profilers
provide the CPU,
memory, network,
and energy usage
information for developers
so they can optimize their
app to be leaner and faster.
Today, I'm going to be
focused on Memory Profiler.
A lot of developers
come to Memory Profiler
because they are looking
for a memory leak.
So what is a memory leak?
In the conventional definition,
a memory leak is a object.
It becomes inaccessible
to the running program,
but still occupies the memory.
If you have ever worked
with pointers in C or C++,
you may be familiar
with this concept.
But in the world
of Kotlin and Java,

Spanish: 
las cosas son
un poco diferentes
porque sus programas
usan la Máquina Virtual Java (JVM).
Y en JVM, hay
un concepto conocido como
recolección
de elementos no utilizados (GC).
Cuando esto ocurre, la máquina virtual
identifica primero las raíces GC.
Una raíz GC es un objeto
que es accesible
desde afuera del montón.
Por ejemplo, las variables locales,
el subproceso de ejecución, etc.
Luego, la máquina virtual 
va a identificar
todos los objetos
accesibles desde estas raíces GC.
Ellos van a ser retenidos.
El resto de los objetos
a los que no se puede acceder
desde ninguna de las raíces 
se considerarán no utilizados
y se reciclarán.
Por lo tanto, la definición
convencional de fuga de memoria
no existe en JVM.
Entonces, ¿a qué nos referimos
cuando hablamos de fuga de memoria en JVM?
Generalmente, a objetos abandonados.
El programa nunca más
volverá a usarlos,

Indonesian: 
hal ini akan sedikit berbeda
karena programnya
berjalan di Java Virtual Machine.
Dan di JVM, ada
konsep penting
yang disebut pembersihan sampah memori.
Saat pembersihan sampah memori
berjalan, mesin virtual pertama-tama
akan mengidentifikasi 
root Pembersih Sampah Memori (GC).
Root GC adalah objek
yang dapat diakses
dari luar heap.
Contohnya termasuk
variabel lokal, thread yang berjalan,
dan lain-lain.
Lalu mesin virtual
akan mengidentifikasi
semua objek yang
dapat diakses dari root GC ini.
Semua objek akan dipertahankan.
Untuk objek lainnya yang tidak dapat 
diakses dari root GC ini,
akan dianggap 
sampah memori
dan akan didaur ulang.
Oleh karena itu, definisi
konvensional kebocoran memori
tidak ada di JVM.
Jadi apa yang kami maksud
dengan kebocoran memori di JVM?
Kami biasa
menyebutnya sebagai objek yang diabaikan.
Objek itu
tidak akan pernah digunakan oleh program,

Korean: 
약간의 차이가 있습니다
프로그램이
자바 가상 머신(JVM)에서
실행되고 있기 때문이죠
JVM에는
가비지 컬렉션이라는
중요한 개념이 있습니다
가비지 컬렉션이 발생하면
가상 머신은 먼저
가비지 컬렉션(GC) 루트를 식별합니다
GC 루트는 힙 외부에서
액세스할 수 있는
객체입니다
로컬 변수와
실행 중인 스레드 등을
예로 들 수 있습니다
가상 머신은
GC 루트에서 액세스할 수 있는
모든 객체를 식별합니다
이 객체는 유지됩니다
GC 루트 중
어느 것에서도 액세스할 수 없는
나머지 객체는
가비지로 간주되고
재활용됩니다
따라서 메모리 누수의
기존 정의는
JVM에 존재하지 않습니다
JVM에서는 메모리 누수가
어떤 의미일까요?
보통은 버려진 객체를
의미합니다
프로그램이 절대
다시 사용하지는 않지만

Japanese: 
Javaは
JVM上で
実行されるので
この概念が
少し異なります
JVMには
ガベージコレクション
略してGCという
概念があります
これが発生すると
JVMは
まずGCルートという
ヒープ外からアクセス可能な
オブジェクトの
特定を行います
GCルートの例には
ローカル変数や
スレッドなどがあります
GCルートの特定後
JVMは
GCルートからアクセス可能な
全オブジェクトを特定し
それらを保持します
残りのオブジェクトのうち
GCルートから
アクセスできない
オブジェクトは
リサイクルされます
したがって
従来の定義のようなメモリリークは
JVMでは発生しません
そのため JVMにおける
メモリリークとは
使用されなくなった
オブジェクトです
再使用する
予定はないものの

Chinese: 
情况有些不同
因为这些程序是在 Java 虚拟机 (JVM) 里运行的
在 JVM 中 “垃圾回收 (GC)”是个重要概念
虚拟机会在垃圾回收时首先确认 GC Root
GC Root 是一种对象 可以从堆外访问
例子包括本地变量 运行线程 等等
随后 虚拟机会辨别所有
可以通过 GC Root 访问的对象
它们将会被保留
其余无法通过任何 GC Root 访问的变量 
将会被认为是垃圾并予以回收
因此 传统定义中的“内存泄漏”
在 JVM 中并不存在
那么 我们在提到 JVM 中的内存泄露的时候
又是在指什么呢？
我们所指的一般是被放弃的对象
程序将永不再次使用它

English: 
things are a little
bit different
because their programs are
running in Java Virtual
Machines.
And in JVM, there is
an important concept
called garbage collection.
When garbage collection
happens, the virtual machine
will first identify
Garbage Collection roots.
A GC root is an object
that is accessible
from outside the heap.
Examples include local
variables, and the running
thread, and et cetera.
Then the virtual
machine will identify
all the objects that are
accessible from these GC roots.
They will be retained.
For the rest of the objects that
cannot be accessible from any
of these GC roots, they will be
considered garbage and will be
recycled.
So therefore, the conventional
definition of memory leak
does not exist in JVM.
So what we mean when we
say memory leak in JVM?
We usually mean
abandoned objects.
The program is never
going to use it again,

Portuguese: 
Mas as coisas são um pouco diferentes
no mundo do Kotlin e do Java,
uma vez que os programas deles
operam em máquinas virtuais do Java.
Na JVM, há um conceito importante
chamado coleta de lixo.
Quando a coleta de lixo ocorre,
a máquina virtual primeiro identifica
as raízes dessa coleta.
Uma raiz da coleta de lixo é
um objeto acessível fora do heap.
Os exemplos incluem variáveis locais,
o thread em execução etc.
Em seguida, a máquina virtual identifica
todos os objetos acessíveis
a partir dessas raízes de coleta de lixo.
Eles são mantidos.
Quanto ao restante dos objetos,
não acessíveis de nenhuma raiz,
são considerados como lixo
e vão para a reciclagem.
Portanto, a definição convencional
de vazamento de memória
não existe na JVM.
Então, o que significa
vazamento de memória na JVM?
Geralmente, significa objetos abandonados.
O programa nunca os usará novamente,

Indonesian: 
tetapi masih dapat diakses.
Jadi di Android,
ada dua jenis objek
yang memang tidak ingin Anda bocorkan,
yaitu fragmen dan aktivitas.
Karena objek itu sering
menggunakan banyak memori.
Berita baiknya,
mulai Android Studio 3.6
Profiler Memori
secara otomatis
bisa mendeteksi kebocoran, 
aktivitas, dan fragmen.
Untuk melakukan itu, 
pertama ambil dulu heap dump
dengan menekan
tombol ini di Profiler Memori.
Lalu setelah heap
dump dimuat,
centang kotak ini.
Lalu penyedia akan menampilkan
aktivitas dan fragmen
yang mungkin bocor.
Bagaimana Profiler
mengidentifikasinya?
Karena kedua class ini memiliki
perilaku yang ditentukan dengan jelas.
Jadi untuk aktivitas, 
jika telah dihancurkan,
kita tahu program
tidak akan menggunakannya lagi.
Jika aktivitas masih dirujuk,
artinya terjadi kebocoran.

Japanese: 
アクセス可能な
プログラムのことです
Androidの
フラグメントと
アクティビティは
メモリ消費量が大きいので
これら2つを
リークさせないように
特に気をつける
必要があります
バージョン3.6の
プロファイラでは
アクティビティと
フラグメントの
リーク自動検出が可能になります
手順としては
メモリプロファイラで
ボタンを押して
ヒープダンプを取得し
チェックボックスを
選択すると
リークの
可能性がある
アクティビティと
フラグメントが
表示されます
このような検出が
可能な理由は
これらのクラスの動作が
明確に定義されているからです
まず 破棄済みの
アクティビティは
プログラムで
再使用されることはないので
参照されていれば
リークと言えます

English: 
but it's still accessible.
So in Android,
there are two types
of objects that you really
don't want to leak them--
fragments and activities.
Because they often
consume a lot of memory.
We are happy to say that
from Android Studio 3.6,
Memory Profiler
can automatically
detect leaks, activities,
and fragments.
In order to do that, the first
thing you do to capture heap
dump by pressing this button
in the Memory Profiler.
Then after the heap
dump is loaded,
you select this checkbox.
Then the provider will show
possibly leaked activities
and fragments.
So how can the
Profiler tell that?
Because these two classes
have real defined behavior.
So for activity-- if
it has been destroyed--
then we know the program is
not going to use it again.
So if it's still
referenced, it's a leak.

Spanish: 
pero todavía son accesibles.
En Android, hay dos tipos de objetos
que en verdad 
no quieres que tengan una fuga.
Los fragmentos y las actividades.
Porque a menudo
consumen mucha memoria.
Nos complace decir
que desde Android Studio 3.6
el Memory Profiler
puede detectar automáticamente
fugas, actividades y fragmentos.
Para hacer esto, el primer paso
para capturar un volcado de pila
es presionar este botón
en el Memory Profiler.
Después de que se cargue
el volcado de pila,
seleccionamos esta casilla.
El Profiler mostrará
posibles actividades
y fragmentos con fugas.
Entonces, ¿cómo puede el Profiler
decir esto?
Porque estas dos clases
tienen un comportamiento definido real.
Para las actividades,
si han sido destruidas,
sabemos que el programa
no las usará de nuevo.
Si todavía tiene referencia,
es una fuga.

Chinese: 
但它仍然是可访问的
在 Android 中 有两种对象是绝对不能泄露的
Fragment 和 Activity
因为这两者通常会占用大量的内存
很高兴地告诉大家 自 Android Studio 3.6 以来
Memory Profiler 可以自动检测
泄露的 Activity 和 Fragment 想要做到这一点
首先就要在 Memory Profiler 中点击这个按钮
抓取 Heap Dump 文件
在 dump 加载完毕后
勾选这里 
然后分析器就会显示可能的 Activity 和 Fragment 泄露
那么 Profiler 是如何发现这个情况的？
因为这两个类拥有明确的行为
对于 Activity 如果它被销毁了
那么我们就知道 程序不会再使用它了
这时如果它再被引用 就表示有泄露了

Korean: 
여전히 액세스할 수 있죠
Android에는 여러분이
절대 누수되지 않기를 바랄
두 가지 유형의 객체가 있는데요
fragment와 activity입니다
흔히 많은 메모리를
소모하기 때문이죠
Android 스튜디오 3.6의 경우
메모리 프로파일러가
누수 및 activity, fragment를
자동으로 감지할 수 있습니다
그렇게 하기 위해서는
먼저 힙 덤프를 캡처해야 합니다
메모리 프로파일러의
이 버튼을 눌러서 실행합니다
힙 덤프를
로딩한 후에는
이 체크 박스를 선택하세요
그러면 메모리 프로파일러가
누수 가능성이 있는
activity와 fragment를
보여줄 거예요
Profiler는 어떻게
누수 가능성을 알 수 있을까요?
두 클래스에는
정의된 실제 동작이 있기 때문입니다
만약 activity가 파괴되었다면
우리는 프로그램이 다시는 이 클래스를
사용하지 않을 걸 알고 있습니다
여전히 참조되면
그건 누수인 거죠

Portuguese: 
mas eles permanecem disponíveis.
No Android,
há dois tipos de objetos
que não podem vazar:
fragmentos e atividades.
Eles costumam consumir muita memória.
É uma alegria informar
que, a partir do Android 3.6,
o Memory Profiler
pode detectar automaticamente
vazamentos, atividades e fragmentos.
Para isso, primeiro pressione
este botão no Memory Profiler
para capturar o despejo de heap.
Após o carregamento do despejo de heap,
marque esta caixa de seleção.
O provedor mostrará as atividades
e os fragmentos vazados.
Como o criador de perfis
consegue informar isso?
Estas duas classes têm
comportamento real definido.
Se a atividade foi destruída,
sabemos que o programa
não a usará novamente.
Se ainda for referenciada,
ela é um vazamento.

Indonesian: 
Sedangkan fragmen harus dikaitkan
dengan pengelola
fragmen untuk digunakan.
Jika kita tidak melihat pengelola fragmen
dengan fragmen yang terkait,
dan jika fragmen masih dirujuk,
artinya terjadi kebocoran.
Tapi ada yang perlu diperhatikan.
Jika heap dump
ditemukan di titik yang menarik
setelah fragmen dibuat
tapi sebelum digunakan,
Profiler Memori akan
melaporkan positif palsu.
Memang benar bahwa fragmen disimpan 
dalam cache tapi belum digunakan lagi.
Saya telah berbicara 
tentang aktivitas dalam fragmen.
Lalu bagaimana dengan
project atau objek lain?
Selanjutnya, saya akan membahas
data dalam Profiler Memori
yang didesain untuk membantu
Anda mengidentifikasi kebocoran.
Jadi, hal pertama setelah
Anda mendapatkan heap dump,
Anda akan melihat daftar class.
Untuk setiap class, 
ditampilkan jumlah instance,
yaitu di kolom alokasi pada tabel.
Selanjutnya, 
kami akan tampilkan native size,

Japanese: 
次に
フラグメントには
使用する
フラグメントマネージャーへの
関連付けが必須なので
関連付けがないのに参照されていれば
そのフラグメントは
リークです
注意点があります
ヒープダンプを取得した時点で
まだ使用されていない
作成済みの
フラグメントと
キャッシュ化後に
再使用されていない
フラグメントも
リークとして検出されてしまいます
次に
アクティビティと
フラグメント以外も
見てみましょう
ここからは
リークの特定に役立つ
メモリプロファイラ内の
データを紹介します
ヒープダンプを
取得すると
クラスが
一覧表示されます
[Allocations]列に
各クラスの
インスタンス数
右3列に
ネイティブサイズ
シャローサイズ
保持サイズが

Chinese: 
对于 Fragment 它必须与 FragmentManager 搭配才可用
如果我们发现 Fragment 没和 FragmentManager 一起出现
而这时如果它被引用 就表示有泄露了
但是有一个注意点：
如果你正好在 Fragment 被创建后但被使用前的某个点获取 Heap Dump
Memory Profiler 会报告一个错误的诊断结果
如果 Fragment 被缓存 但仍未被复用 也是一样
我已经讨论了 Fragment 及 Activity
那么 其他对象呢？
下面我来讲讲 Memory Profiler 中的数据
它是专门设计用来帮你识别泄露的
在获取了 Heap Dump 之后 
你首先会看到的 是一个类列表
我们会显示每个类中的实例
也就是这个表中的分配 (Allocations) 列
接下来 我们还会显示 Native Size

Spanish: 
Para los fragmentos,
un fragmento tiene que estar asociado
a un administrador 
de fragmentos para ser usado.
Si no vemos que un administrador
de fragmentos está con los fragmentos,
y si todavía tiene
referencia, es una fuga.
Pero hay una salvedad.
Si se produce un volcado de pila
en el punto de interés
después de que se crea el fragmento
pero antes de que se use,
el Memory Profiler informará
sobre un falso positivo.
Es verdadero si el fragmento está en caché
pero todavía no es reutilizado.
He hablado sobre
la actividad en los fragmentos.
¿Qué hay de otros proyectos
y otros objetos?
Ahora me voy a referir
a los datos en Memory Profiler
que están diseñados para ayudarnos
a identificar las fugas.
Lo primero que veremos
después de un volcado de pila
es una lista de clases.
Para cada una de las clases
tenemos el número de instancias
que es la columna
de asignaciones en la tabla.
Después tenemos el Native Size,
el Shallow Size,

English: 
So for fragments, a
fragment has to be
associated with a fragment
manager to be used.
So if we don't see a fragment
manager is with the fragments,
and if it's still
referenced, it's a leak.
But there is a caveat.
If you get your heap dump
at the interesting point
after the fragment is created
but before it's getting used,
the Memory Profiler will
report a false positive.
And so it's true if the fragment
is cached but not yet reused.
So I have talked about
activity in fragments.
So how about other
projects or other objects?
Next, I'm going over the
data in Memory Profiler
that are designed to help
you identify the leaks.
So the first thing after
you get a heap dump,
you will see a list of classes.
So for each of the
classes, we show the number
of instances, which
is the allocations
column in the table.
Next we show native
size, shallow size,

Korean: 
fragment의 경우
사용될 fragmentmanager와
연결되어야 해요
fragmentmanager가
fragment와 연결되지 않았지만
여전히 참조되고 있다면
누수입니다
하지만 주의해야 할 점이 있습니다
fragment가 생성되었지만
아직 사용되기 전에
흥미로운 지점에
힙 덤프가 생기는 경우
메모리 프로파일러는
긍정 오류를 보고합니다
fragment가 캐싱되었지만
아직 재사용되지 않았다면 참이죠
fragment와 activity에
대해 이야기했는데요
다른 프로젝트나
다른 객체는 어떨까요?
다음으로, 누수를
식별하기 위해 설계된
메모리 프로파일러를
살펴보겠습니다
힙 덤프를 얻은 후에
가장 먼저 보게 되는 것은
클래스 목록일 겁니다
각각의 클래스에 대해
인스턴스의 수가 표시됩니다
이것은 표에 있는
할당 열입니다
다음으로 Native 사이즈와
Shallow 사이즈, Retained 사이즈를

Portuguese: 
Um fragmento 
precisa estar associado
a um gerenciador de fragmentos
para ser usado.
Se um gerenciador não for
exibido com o fragmento
e ainda estiver referenciado,
ele é um vazamento.
Mas há uma ressalva.
Se você receber
o despejo de heap no ponto de interesse
depois da criação do fragmento,
mas antes da utilização,
o Memory Profiler
relatará um falso positivo.
Isso também ocorrerá se o fragmento
estiver armazenado no cache,
mas ainda não foi reutilizado.
Falei sobre atividade nos fragmentos.
Mas e os outros projetos e objetos?
Falarei sobre os dados no Memory Profiler,
projetados para ajudar
a identificar os vazamentos.
Logo após você receber um despejo de heap,
será exibida uma lista de classes.
Para cada classe,
mostraremos a quantidade de instâncias.
Ou seja, a coluna de alocações na tabela.
Em seguida, exibiremos o tamanho nativo,

Chinese: 
Shallow Size 和 Retained Size
这些数据很重要 因为它可以让你明白
内存被消耗在了哪里
接下来 我会使用这个例子
来详细讲讲它们的含义
希望大家关注一下这个红色节点
在本例中 它引用了我们在 native 堆 (C/C++) 中的对象
这种情况不是很常见 但也确实会出现
例如 在 Android 8.0 后
位图会将像素数据保留在本地堆中
以减少 JVM 上的内存压力
我们先从 Shallow Size 说起 这个很简单
对象本身消耗内存
Native Size 也很简单
它是由红色节点引用的本地对象的尺寸
Retained Size 就很有意思了
它代表着被这些橙色节点消耗的内存
为什么？因为 如果你删除红色节点
那么所有的橙色节点都会被删除 

Korean: 
표시합니다
이러한 데이터는
메모리가 소모되는 위치를
정확히 찾을 수 있기 때문에 중요합니다
다음으로, 이 예시를 이용해서
이들이 정확히
무엇을 의미하는가를
확장해서 설명하려고 합니다
이 빨간색 부분에
주의해 주시기를 바랍니다
이 예시에서
네이티브 힙에 있는
객체를 지칭하기도 합니다
아주 흔한 것은 아니지만
실제로 일어나는 일이죠
예를 들어
Android 8.0 이후
비트맵은 JVM에 대한
메모리 압력을 줄이기 위해
네이티브 힙에
픽셀 데이터를 저장합니다
Shallow 사이즈부터
시작해봅시다
아주 간단해요
객체 자체에서
소비되는 메모리입니다
Native 사이즈도 간단합니다
빨간색 부분에서 참조되는
네이티브 객체의 크기입니다
Retained 사이즈는 흥미롭습니다
이 모든 주황색 부분이
소비하는 메모리입니다
왜 그럴까요?
빨간색 부분을 삭제하면
주황색 부분도 모두 삭제됩니다

Portuguese: 
superficial e retido.
Esses dados são importantes
porque permitem que você identifique
o local de consumo da memória.
Usarei este exemplo
para destacar exatamente
o significado desses valores.
Observem a anotação em vermelho.
Neste exemplo, também houve referência
ao nosso objeto no heap nativo.
Isso não é muito comum,
mas pode acontecer.
Por exemplo, após o Android 8.0,
o bitmap salva os dados de pixel
no heap nativo para reduzir
a pressão de memória na JVM
Começaremos
com o tamanho superficial.
É muito simples.
É a memória consumida pelo próprio objeto.
O tamanho nativo também é simples.
É o tamanho dos objetos nativos
referenciados pela anotação em vermelho.
O tamanho retido é interessante.
É a memória consumida
por todas estas anotações em laranja.
Por quê?
Se você excluir a anotação em vermelho,
todas estas anotações em laranja

Spanish: 
y el Retained Size.
Estos datos son importantes
porque nos dejan identificar
dónde se consume la memoria.
Luego, usaré este ejemplo
para explicar exactamente
lo que significan.
Quiero que le presten atención
a esta nota roja.
Este ejemplo, también hace referencia
a nuestro objeto
en el montón nativo.
Esto no es muy común,
pero puede pasar.
Por ejemplo, después
de Android 8.0, el bitmap
guardará los datos
de píxeles en los montones nativos
para reducir la presión
en la memoria de la JVM.
Comencemos con el Shallow Size.
Es muy simple.
Es la memoria consumida
por el objeto mismo.
El Native Size también es simple.
Es el tamaño de los objetos
nativos a los que se refiere la nota roja.
El Retained Size es interesante.
Es la memoria consumida
por todas estas notas anaranjadas.
¿Por qué?
Porque si suprimes la nota roja,
todas estas notas anaranjadas

Japanese: 
示されます
これらのデータは
メモリが消費されている箇所を
特定する上で重要です
各データの意味を
こちらの例を基に
説明していきます
この赤いノードに
注目してください
これはネイティブヒープの
オブジェクトも
参照しています
このような
ノードの例は
JVMのメモリ負荷を抑えるために
ピクセルデータを
ネイティブヒープ内に
保存する
Android 8.0以降の
ビットマップです
さて
シャローサイズは
単純であり
オブジェクト自体により
消費されているメモリを表します
ネイティブサイズは
ネイティブ
オブジェクトの
サイズを表します
保持サイズは
すべてのオレンジノードで
消費されている
メモリの合計を表します
この名前の意味を説明します
赤ノードが削除されると

English: 
and retained size.
These data are important
because they let you pinpoint
where the memory is consumed.
Next, I'm going to
use this example
to expand exactly
what they mean.
I want you to pay
attention to this red note.
In this example, it also
referenced to our object
in the native heap.
This is not very common,
but it does happen.
For example, after
Android 8.0, the bitmap
will save the pixel
data in the native heap
to reduce the memory
pressure on the JVM.
So let's start with
the shallow size.
It's very simple.
It's the memory consumed
by the object itself.
Native size is also simple.
It's the size of the
native objects referenced
by the red note.
Retained size is interesting.
It's the memory consumed by
all of these orange notes.
Why?
Because if you delete the red
note, all of these orange notes

Indonesian: 
shallow size, dan retained size.
Data ini penting karena
memungkinkan Anda menentukan
tempat memori digunakan.
Selanjutnya, saya akan 
menggunakan contoh ini
untuk menjelaskannya lebih terperinci.
Mari perhatikan tanda merah ini.
Di contoh ini, tanda merah juga
merujuk ke project kita
di heap native.
Hal ini tidak terlalu umum,
tetapi bisa terjadi.
Misalnya, setelah 
Android 8.0,
bitmap akan menghemat 
data piksel di heap native
untuk mengurangi
tekanan memori pada JVM.
Mari mulai dengan shallow size.
Hal ini sangat sederhana.
Ini adalah memori
yang digunakan oleh objek itu sendiri.
Native size juga sederhana.
Ini adalah ukuran objek native
yang ditunjukkan dengan warna merah.
Retained size cukup menarik.
Ini adalah memori yang digunakan
oleh semua warna oranye ini.
Mengapa?
Karena jika tanda merah dihapus, 
semua tanda oranye juga terhapus

Korean: 
액세스할 수 없게 되기 때문이죠
따라서 어떤 의미로는
이 빨간색 부분에 의해 유지되는 거죠
그렇기 때문에
Retained 사이즈라고 부릅니다
오른쪽의 이 객체를 보세요
Retained 사이즈에
포함되지 않습니다
빨간색 부분이 없어졌어도
아직 액세스할 수 있기 때문이죠
이 데이터를 사용해서
관심을 가질 가치가 있는
클래스를 식별할 수 있습니다
클래스 이름을 클릭하면
메모리 프로파일러가
이 클래스 인스턴스의
목록을 표시하는
인스턴스 뷰를 엽니다
새로운 종류의
데이터인 depth가 있어요
depth는 GC 루트에서
이 인스턴스까지의
최단 경로의 길이입니다
그래프의 숫자는 이들 객체의
depth입니다
이 depth를 왜 표시할까요?
왜냐하면 객체가
GC 루트에 더 가까울수록
GC 루트에서
이 객체까지 여러 경로가

Chinese: 
因为它们会变得无法访问
所以 在某种意义上讲 它们是被这个红色节点所保留的
所以它才叫保留尺寸 Retained Size
注意右边这个对象
它没有被包含在 Retained Size 里面
因为 即使红色节点不见了 它仍然可以访问
你可以通过使用这些数据识别出值得注意的类
只需点击类名 内存分析器会打开一个实例视图
显示出属于这个类的实例列表
这里有一种新的数据：深度数据
深度是从 GC Root 到这个实例的最短距离
图表上的数字代表着这些对象的深度
我们为什么要把它们显示出来？
因为 对象距离 GC Root 越近
它拥有从 GC Root 到这个实例的多条路径的可能性就越高

Spanish: 
también serán suprimidas
porque se hacen inaccesibles.
En cierto modo,
esta nota roja las retiene.
Por eso se llama Retained Size,
tamaño retenido.
Miren este objeto en la derecha.
No está incluido
en el Retained Size
porque todavía es accesible,
aunque la nota roja ya no esté.
Al usar estos datos,
podemos identificar las clases
a las que vale la pena
prestarles atención.
Haces clic en el nombre de la clase,
el Memory Profiler
abrirá una vista de instancias
que muestra una lista
de esta clase.
Hay un nuevo tipo
de información aquí: la profundidad.
La profundidad es la distancia
de la ruta más corta de la raíz GC
a esta instancia.
Los números en el gráfico
son la profundidad de estos objetos.
¿Por qué los mostramos?
Porque cuanto más cerca
está un objeto de las raíces GC,
mayor será la posibilidad
de que existan

English: 
will also be deleted because
they become inaccessible.
So in a sense, they are
retained by this red note.
That's why it's
called retained size.
Note this object to the right.
It's not included
in the retained size
because it's still accessible
even if the red note is gone.
So by using this data, you
can identify the classes
that are worth attention.
You click on the class
name, the memory provider
will open a instance view
showing a list of instances
of this class.
There is new kind of
data here-- depth.
The depth is the length of
the shortest path from the GC
root to this instance.
So the numbers on the graph
are the depth of these objects.
Why do we show them?
Because the closer an
object is to the GC roots,
it has a higher chance
that multiple paths

Indonesian: 
karena menjadi tidak dapat diakses.
Jadi sebenarnya, tanda oranye
dipertahankan oleh tanda merah.
Itu sebabnya
disebut retained size.
Perhatikan objek di sebelah kanan.
Ini tidak termasuk retained size
karena masih dapat diakses
meskipun tanda merah dihapus.
Jadi dengan menggunakan data ini, 
Anda bisa mengidentifikasi
class yang perlu diperhatikan.
Anda dapat mengklik nama class,
penyedia memori akan 
membuka tampilan instance
yang menampilkan 
daftar instance class ini.
Ada jenis data baru
yaitu kedalaman.
Kedalaman adalah 
panjang jalur terpendek
dari root GC ke instance ini.
Jadi angka pada grafik
adalah kedalaman objek-objek ini.
Mengapa kami menampilkannya?
Karena semakin dekat suatu
objek dengan root GC,
kemungkinan adanya beberapa jalur

Portuguese: 
também serão excluídas,
já que ficarão inacessíveis.
De certa forma, elas são retidas
pela anotação em vermelho.
Por isso, são chamadas de tamanho retido.
Observe este objeto à direita.
Ele não está incluso no tamanho retido
porque ainda está acessível,
mesmo após a exclusão
da anotação em vermelho.
Ao usar esses dados,
é possível identificar as classes
que merecem atenção.
Quando você clicar no nome da classe,
o Memory Provider
exibirá uma visualização da instância
com uma lista de instâncias dessa classe.
Aqui há
um novo tipo de dados: a profundidade.
Ela é a duração do caminho mais curto
da raiz da coleta de lixo
para essa instância.
Assim, os números no gráfico
são as profundidades desses objetos.
Por que eles são exibidos?
Isso ocorre porque,
quanto mais perto um objeto estiver
das raízes da coleta de lixo, maior será
a chance de que vários caminhos existam

Japanese: 
オレンジノードも
アクセス不能になり削除されます
このように 保持されている
ノードのサイズを表すので
保持サイズと
呼ばれています
右側にあるオブジェクトは
保持サイズに
含まれません
赤ノードの削除後も
これにはアクセスできるからです
保持サイズに基づいて
注意が必要なクラスを
特定できます
クラス名を
クリックすると
インスタンスビューが開き
クラスのインスタンスが
一覧表示されます
このビューには新しく
深さも表示されます
深さとは GCルートから
インスタンスまでの
最短パスの長さです
つまり この図上の数字が
各オブジェクトの深さです
深さは重要です
オブジェクトが
GCルートに近いほど
そのオブジェクトから
GCルートまでのパスは

Spanish: 
múltiples rutas de acceso
desde la raíz GC a este objeto.
Como resultado, tiene menos posibilidad
de ser recolectado como no utilizado.
Tomemos la nota roja como ejemplo.
Si alguna de las referencias
a la derecha se rompe,
la nota roja
se volverá inaccesible
y los elementos no deseados
se recolectarán.
Ahora las notas azules
a la derecha.
Si desean hacerlos
elementos no deseados,
deben romper
la ruta de acceso de la izquierda
y la de la derecha.
Si ven que cualquier instancia
tiene una profundiad de 1,
es una señal muy fuerte.
Porque significa que
esa instancia
tiene una referencia directa
a una raíz GC.
Les mostraré un ejemplo de código.
Aquí tenemos una actividad.
Implementa la interfaz
LocationListener.
Y el método resaltado,
requestLocationUpdates,
registrará esta actividad
en locationManager.
Si olvidas desregistrarte,
esta actividad
se volverá una fuga.
Se quedará en el montón
para siempre, porque locationManager
es una raíz GC 
y se quedará siempre ahí.

Indonesian: 
dari root GC ke objek ini
akan semakin tinggi.
Akibatnya, kemungkinan sampah memori
dibersihkan akan lebih kecil.
Jadi, ambil tanda merah sebagai contoh.
Jika ada referensi 
di sebelah kiri yang rusak,
tanda merah menjadi
tidak dapat diakses
dan sampah memori dibersihkan.
Untuk tanda biru
di sebelah kanan,
jika Anda ingin
menjadikannya sampah memori,
Anda harus memutus jalur
dari kiri dan kanan.
Jika Anda melihat instance
memiliki depth satu,
itu adalah sinyal yang sangat kuat.
Karena itu berarti instance
secara langsung dirujuk
oleh suatu root GC.
Ini adalah contoh kode.
Di sini ada aktivitas
yang mengimplementasikan
antarmuka LocationListener.
Dan metode yang disorot,
requestLocationUpdates,
akan mendaftarkan aktivitas ini
ke locationManager.
Jika Anda lupa membatalkan pendaftaran,
aktivitas ini akan menjadi kebocoran
dan akan jadi heap seterusnya

Korean: 
존재할 가능성이
더 높기 때문이고
그 결과 가비지가
수집될 가능성이 작아집니다
빨간색 부분을 예로 들어봅시다
왼쪽의 기준 중에서
어느 것이든 깨진 경우
빨간색 부분은
액세스할 수 없게 되고
가비지가 수집됩니다
오른쪽의 파란색 부분의 경우
가비지로
만들고자 하는 경우
왼쪽에서의 경로와
오른쪽에서의 경로를
깨뜨려야 합니다
depth가 1인
인스턴스를 보면
아주 강력한 신호인데요
일부 GC 루트가
인스턴스를 직접 참조한다는
뜻이기 때문입니다
여기에서 코드 예를 보여드릴게요
여기에 activity가 있습니다
LocationListener 
인터페이스를 구현하죠
하이라이트된 메서드인
requestLocationUpdates가
이 activity를
locationManager에 등록합니다
등록 해제를 잊어버리면
이 activity가
누수가 될 겁니다
locationManager가 
GC 루트이기 때문에

English: 
exists from the GC
root to this object.
And as a result, it has a lower
chance to be garbage collected.
So take the red note as example.
If any of the reference
to the left is broken,
the red note will
become inaccessible
and the garbage collected.
For the blue notes
on the right--
if you want to
make it a garbage,
you have to break the path
from the left and the path
from the right.
If you see any instance
has a depth of 1,
that's a very strong signal.
Because it means that
instance is directly
referenced by some GC root.
Here I'm showing a code example.
Here we have activity.
It implements
LocationListener interface.
And the highlighted method--
requestLocationUpdates--
will register this activity
to locationManager.
If you forget to
unregister, this activity
will become a leak.
It will stay in the heap
forever because location manager

Chinese: 
结果是 它比较不可能会被当作垃圾回收
就以红色节点作为例子吧
如果左侧的任意引用被破坏
红色节点就会变得无法访问 并被当作垃圾回收
至于右侧的蓝色节点 如果你想把它当作垃圾
就必须打断从左侧和右侧出发的引用
如果你看到有任何深度为1的实例
这就是很强烈的信号
因为这意味着这个实例是直接被某些 GC Root 所引用的
下面我来展示一个代码范例
这里有一个 Activity
它实现了 LocationListener 接口
高亮的方法 requestLocationUpdates 
将把这个 Activity 注册到 LocationManager
如果你忘记取消注册 这个 Activity 就会成为内存泄漏点
它会永远存在于堆中 
因为 LocationManager 是 GC Root 
它会永远待在那儿

Portuguese: 
da raiz da coleta de lixo
para esse objeto.
Desta forma, há uma chance menor
de coleta de lixo.
Veja a anotação em vermelho como exemplo.
Se alguma referência
à esquerda estiver corrompida,
a anotação em vermelho ficará inacessível
e o lixo será coletado.
Quanto às anotações em azul,
do lado direito, se quiser torná-las lixo,
será necessário dividir
os caminhos da esquerda e da direita.
Caso você perceba alguma instância
com valor 1 de profundidade,
é um sinal muito importante.
Isso significa que a instância
está referenciada diretamente
por alguma raiz de coleta de lixo.
Este é um exemplo de código.
Aqui temos a atividade.
Ela implementa
a interface LocationListener.
O método destacado,
requestLocationUpdates,
registrará essa atividade
no locationManager.
Se você esquecer de cancelar o registro,
a atividade se tornará um vazamento.
Ela ficará sempre no heap,
porque o gerenciador de localização é

Japanese: 
複数存在する可能性が
高くなるために
ガベージコレクションの対象になる
可能性が低くなるからです
赤ノードを例に考えてみましょう
左側の参照の
いずれかが壊れると
赤ノードは
アクセス不能になり
GCで回収されます
右側にある
青ノードの場合は
左からのパスと
右からのパスが
壊れると
ガベージになります
深さが1の
インスタンスは
GCルートから
直接参照されているので
特に注意が必要です
コードの例を示します
アクティビティで
インターフェースを実装し
ハイライトされている
メソッドにより
アクティビティを
LocationManagerに
登録しています
登録解除を忘れた場合
このアクティビティは
リークになります
LocationManagerは
GCルートなので

English: 
is a GC root and will
stay there forever.
You can verify this in
the Memory Profiler.
If you click an instance
in the instance view,
Memory Profiler will
open a reference panel.
And here we can show who is
referencing to that instance.
And here we can
see the mListener
field in location manager is
referencing this activity.
And actually, you can
navigate the reference graph
of the heap using the
reference panel so
that you can verify if those
reference chains is expected.
That can help you to
understand if there's a leak
and where is the leak.
So I have talked enough
about the Memory Profiler.
Now, let us please
switch to the demo.
So here I have a
Android Studio opening
a sample app called
Displaying Bitmap.
It's a very simple
app, not a real one,
but it serves the
purpose for today's talk.

Spanish: 
Pueden verificar esto
en Memory Profiler.
Si haces clic en una instancia
en la vista de instancias,
Memory Profiler abrirá
un panel de referencia.
Aquí podemos ver
quién hace referencia a esa instancia.
Aquí podemos ver que
el campo mListener
en LocationManager
está haciendo referencia a esta actividad.
En realidad, pueden moverse
en el gráfico de referencia
del montón usando
el panel de referencia
para poder verificar
si se esperan esas cadenas de referencia.
Eso puede ayudarles
a entender si hay una fuga
y dónde está ubicada.
Ya hablé suficiente
del Memory Profiler.
Ahora pasemos
a la demostración.
Aquí tengo un Android Studio
que está abriendo
una app de muestra
llamada Displaying Bitmap.
Es una app muy simple,
no es verdadera,
pero sirve para el propósito
de la charla de hoy.

Portuguese: 
uma raiz de coleta de lixo
e permanecerá ali indefinidamente.
É possível verificar
isso no Memory Profiler.
Se você clicar em uma instância
na visualização da instância,
o Memory Profiler exibirá
um painel de referência.
Aqui podemos mostrar
quem está referenciando a instância.
Podemos ver que o campo mListener
no gerenciador de localização
está referenciando essa atividade.
É possível navegar
pelo gráfico de referência do heap
usando o painel de referência.
Assim, você pode verificar
se essas cadeias
de referência são esperadas.
Isso pode ajudar
a entender se há vazamento
e onde ele está.
Falei bastante sobre o
Memory Profiler.
Agora passaremos à demonstração.
Aqui temos o Android Studio
abrindo um app de amostra
chamado Displaying Bitmap.
É um app muito simples.
Ele não é real, mas serve 
para a apresentação de hoje.

Korean: 
힙에 영원히
있을 거예요
메모리 프로파일러에서
이것을 확인할 수 있어요
인스턴스 뷰에서
인스턴스를 클릭하면
메모리 프로파일러가
레퍼런스 패널을 열 겁니다
누가 그 인스턴스를
참조하는지 표시할 수 있습니다
여기에서 locationManager의
mListener 필드가
이 activity를 참조한다는
것을 알 수 있습니다
여러분은 레퍼런스
패널을 이용해서
힙의 레퍼런스 그래프를
탐색할 수 있기 때문에
그러한 레퍼런스 체인이
예상되는 경우 확인할 수 있어요
그래서 누수가 있는지
어디에 있는지
이해하는 데 도움이 될 수 있죠
메모리 프로파일러에 대해
충분히 설명해 드렸습니다
이제 데모로
전환해봅시다
여기 Displaying Bitmap이라는
샘플 앱을 열고 있는
Android 스튜디오가 있습니다
가상으로 만든
아주 단순한 앱이에요
오늘 설명에 유용하게 
사용될 거예요

Japanese: 
アクティビティも
ヒープに残るからです
プロファイラで
確かめましょう
インスタンスビューで
インスタンスをクリックし
参照パネルを開くと
インスタンスを参照している
オブジェクトを確認できます
LocationManagerの
mListenerフィールドが
このアクティビティを参照しています
さらに
参照パネルを使用すると
ヒープの参照グラフを
たどって
参照チェーンが
適切かどうかを検証できます
こうすることで
リークの発生の有無と
リーク発生場所を
特定できます
メモリプロファイラ
に関する説明は以上です
ここからは
実演に移ります
Android Studioで
Displaying Bitmapを
開きます
これは
サンプルアプリですが
本日のテーマには十分です

Chinese: 
你可以在 Memory Profiler 中验证它
如果你在实例视图中点击实例
Memory Profiler 就会开启一个引用面板
这里 我们可以展示 谁在引用那个实例
我们可以看到 是 LocationManager 中的 mListener 
实际上 你可以使用引用面板来在引用节点图中浏览
这样你就可以验证 那些引用链是否符合你的猜测
这有助于你理解 泄露是否存在 如果是的话 在哪里
我已经讲了很多关于 Memory Profiler 的内容
现在我们转换到演示机上来看看
这里的 Android Studio 正在打开一个
样本应用 名叫 Displaying Bitmap
这是个非常简单的应用 并没有真的上架
但它用来充当今天演讲的道具也够用了

Indonesian: 
karena pengelola lokasi adalah root GC 
dan akan ada di sana seterusnya.
Anda bisa memverifikasi
di Profiler Memori.
Jika Anda mengklik suatu instance
pada tampilan instance,
Profiler Memori akan
membuka panel referensi.
Dan di sini kita bisa menunjukkan 
siapa yang merujuk ke instance itu.
Dan di sini kita bisa
melihat bidang mListener
di pengelola lokasi
merujuk aktivitas ini.
Dan sebenarnya, Anda bisa
menavigasi grafik referensi dari heap
menggunakan panel referensi 
sehingga Anda bisa memverifikasi
apakah referensi itu diharapkan.
Cara ini bisa membantu Anda
memahami jika ada kebocoran
dan lokasi kebocoran itu.
Saya sudah jelaskan cukup banyak
tentang Profiler Memori.
Sekarang, mari kita beralih ke demo.
Jadi, ini adalah Android Studio
yang membuka aplikasi sampel 
yang disebut Displaying Bitmap.
Ini adalah aplikasi yang sangat
sederhana dan bukan sungguhan,
tetapi memenuhi
tujuan diskusi hari ini.

Korean: 
제일 먼저 할 일은
이 'profile' 버튼을 클릭해서
이 앱을 배포하고
프로파일링을 시작하는 겁니다
이 앱에는 두 개의 activity가 있어요
첫 번째 activity는
이미지의 등급을 표시해요
하나를 클릭하면
형태 이미지를 표시하는
두 번째 activity로 이동해요
이제 첫 번째
activity로 돌아갑니다
이 지점에서
두 번째 activity는
재활용되는 가비지가 됩니다
메모리 프로파일러에서
맞는지 확인할 수 있어요
메모리 프로파일러로 이동해서
힙 덤프를 얻습니다
지금은 공개하려고 합니다
이 단순한 앱에서는
메모리 누수를 찾지 못했어요
그래서 Profiler에서는
누수가 어떻게 보이는지
보여주기 위해 하나를 추가했어요
이제 이 체크박스를 선택합니다
이제 메모리 프로파일러가 이미지
세부사항 activity가 누수라고
보고하는 것을 볼 수 있습니다
클래스 이름을
클릭하면 인스턴스가 보이고
인스턴스를 클릭하면
레퍼런스가 보입니다
locationManager가
이 activity를
참조하고 있는 것을
볼 수 있어요

Spanish: 
Lo primero que hago
es hacer clic en el botón de Profile
para usar esta app
y comenzar la generación de perfil.
Esta app tiene dos actividades.
La primera muestra
un grado de imágenes.
Si hago clic en uno,
pasamos a la segunda actividad
que muestra la imagen de forma.
Ahora vuelvo
a la primera actividad.
En este punto,
la segunda actividad
debería ser reciclada como no utilizada.
Y podemos examinar si pasa así
en el Memory Profiler.
Voy a Memory Profiler.
Tengo un volcado de pila.
Ahora quiero hacer una revelación.
No encontré ninguna fuga de memoria
en esta app simple,
así que le agregué una
para mostrarles
cómo se ve una fuga
en el Profiler.
Ahora selecciono esta casilla.
Podemos ver
que Memory Profiler informa
que la actividad de detalle
de la imagen es una fuga.
Si hago clic en el nombre
de la clase, veo la instancia.
Hago clic en la instancia
y veo la referencia.
Y podemos ver 
que el locationManager
está haciendo referencia
a esta actividad,

Chinese: 
首先 我要点击这个 profile 按钮
部署这个应用 并开始分析它
这个应用有两个 Activity 
第一个 Activity 用网格布局展示图像
如果我点击一个小图 就会前往第二个 Activity
也就是展示出完整图片
现在 我返回第一个 Activity
这时 第二个 Activity 应该已经被垃圾回收了
我们可以查看 在 Memory Profiler 中是不是这样
我前往 Memory Profiler
获取 Heap Dump
我想要说明一下
这个简单的应用之前并不存在任何内存泄露
所以 我刻意添加了一个 
让大家看看它在 Profiler 中是什么样子的
现在我勾选这个 我们可以看到
Memory Profiler 报告 imageDetailActivity 出现泄露
所以 我点击类名 看到了实例
点击实例 看到了引用
我们可以看到 是 LocationManager 
正在引用这个活动 正如我们之前介绍的那样

Portuguese: 
Primeiro eu clico neste botão
de perfil para implantar esse app
e começar a criar o perfil dele.
Esse app tem duas atividades.
A primeira atividade
mostra uma categoria de imagens.
Se eu clicar sobre uma delas,
acessaremos a segunda atividade,
que mostra a imagem completa.
Agora eu volto para a primeira atividade.
Neste momento, a segunda atividade
será reciclada como lixo.
Podemos analisar se esse é
o caso no Memory Profiler.
Basta acessá-lo.
Eu recebo um despejo de heap.
Quero fazer uma revelação.
Não encontrei nenhum vazamento
de memória neste app de amostra,
então adicionei um para mostrar
como é um vazamento no criador de perfis.
Agora eu marco esta caixa de seleção.
Podemos ver que o Memory Profiler relata
que a atividade do detalhe 
da imagem é um vazamento.
Eu clico no nome da classe
e visualizo a instância.
Clico na instância e vejo a referência.
Podemos perceber que o locationManager
está referenciando esta atividade,

English: 
The first thing I do is I
click this profile button
to deploy this app and
start profiling it.
So this app has two activities.
The first activity
shows a grade of images.
If I click one, we go
to the second activity
showing the form image.
Now I return to
the first activity.
At this point, the
second activity
should be garbage recycled.
And we can examine if that's
the case in the Memory Profiler.
I go to the Memory Profiler.
I get a heap dump.
Now I want to make a disclosure.
I didn't find any memory
leaks in this simple app,
so I added one to show
you what a leak looks
like in the Profiler.
So now I select this checkbox.
And we can see the Memory
Profiler reports image detail
activity is a leak.
So I click the class
name, I see the instance.
I click the instance,
I see the reference.
And we can see it's
the locationManager
is referencing
this activity, just

Indonesian: 
Hal pertama yang saya lakukan
adalah mengklik tombol profil ini
untuk men-deploy aplikasi ini
dan mulai membuat profil.
Jadi, aplikasi ini memiliki dua aktivitas.
Aktivitas pertama 
menunjukkan tingkat image.
Jika saya mengklik satu, 
kita pindah ke aktivitas kedua
yang menampilkan image formulir.
Sekarang saya kembalikan ke
aktivitas pertama.
Saat ini, aktivitas kedua
harusnya menjadi sampah daur ulang.
Dan kita bisa memeriksanya
di Profiler Memori.
Saya buka Profiler Memori.
Saya mendapatkan heap dump.
Sekarang saya ingin buat pengungkapan.
Saya tidak menemukan
kebocoran memori
di aplikasi sederhana ini,
jadi, saya tambahkan satu aplikasi lagi
untuk menunjukkan 
seperti apa kebocoran di Profiler.
Lalu saya pilih kotak centang ini.
Dan kita bisa lihat Profiler Memori
melaporkan 
aktivitas detail image yang bocor.
Jadi saya mengklik nama class,
lalu menemukan instance.
Saya klik instance itu,
lalu menemukan referensi.
Dan kita bisa melihat bahwa
locationManager
merujuk ke aktivitas ini,

Japanese: 
このボタンを
クリックして
アプリをデプロイし
プロファイリングを開始します
このアプリには
画像を一覧表示する
アクティビティと
一覧の画像をクリックすると
拡大表示するアクティビティが
含まれています
最初の画面に戻ると
2つ目の
アクティビティは
回収されるはずです
メモリプロファイラで
確認してみましょう
メモリプロファイラを開いて
ヒープダンプを取得します
実は
このアプリでは
リークは
発生しなかったため
プロファイラでの
例を示すために
リークを
追加しています
チェックボックスを
選択すると
リークとして
ImageDetailActvityが
検出されます
クラス名
インスタンスの順に
クリックして
参照を確認すると
LocationManagerが
このアクティビティを

Spanish: 
como lo discutimos
hace un momento.
Esto es lo que veremos
sobre el Memory Profiler hoy.
Ahora dejaré que Yi
continúe con la presentación.
[APLAUSOS]
YI YANG: Gracias, Shukang.
Hablaremos del CPU Profiler.
Como el Memory Profiler,
el CPU Profiler también brinda
una forma de capturar datos
de ejecución críticos
para ayudarte
a generar el perfil de tu app.
La función se llama 
CPU Recording.
Para capturar un registro,
dirígete al CPU Profiler
y, luego, presiona 
el botón Record.
Realiza alguna acción
en tu app, vuelve al Profiler,
y presiona el botón de Stop.
Ahora tenemos un registro
de seguimiento aquí.
Lo primero que quiero señalar
es esta lista de subprocesos.
Debido a que el registro de seguimientos
está organizado en subprocesos,
debes asegurarte
de seleccionar
el subproceso correcto antes de ver
los datos de seguimiento.
En la parte de abajo,
tenemos cuatro pestañas que muestran

Chinese: 
这就是我想向大家介绍的 Memory Profiler 内容
接下来 我会把话筒交给 Yi
谢谢 Shukang
现在我们来看看 CPU Profiler
CPU Profiler 有点像是 Memory Profiler
它同样可以让你抓取关键性能表现数据
帮助你分析应用
这个功能名为 CPU Recording
想要抓取录制结果 请到 CPU Profiler
点击“录制”按钮
在应用中进行一些操作 然后回到 Profiler
再点击“停止”按钮
现在我们有了一个录制结果
首先我想指出的就是这个线程列表
因为录制的轨迹是根据线程来组织的
在开始仔细分析录制的数据之前
你需要确保选取了正确的线程

Indonesian: 
seperti yang telah kita bahas tadi.
Jadi, itulah yang ingin kami sampaikan
tentang Profiler Memori hari ini.
Selanjutnya, saya persilakan Yi
untuk melanjutkan.
-Terima kasih, Shukang.
Sekarang mari kita pindah topik
ke Profiler CPU.
Seperti halnya Profiler Memori,
Profiler CPU juga menyediakan cara 
untuk mengambil data performa penting
untuk membantu 
membuat profil aplikasi Anda.
Fitur ini disebut CPU Recording.
Untuk merekam,
buka Profiler CPU
lalu tekan tombol Record ini.
Lakukan beberapa tindakan 
di aplikasi, lalu
kembali ke Profiler,
dan tekan tombol Stop.
Sekarang kita memiliki
jejak perekaman di sini.
Hal pertama yang ingin saya tunjukkan
adalah daftar thread di sini.
Karena jejak perekaman
diatur oleh thread,
pastikan Anda
memilih thread yang benar
sebelum melihat ke data jejak.
Di bawah ini ada empat tab

Japanese: 
参照していることが
わかります
メモリプロファイラ
に関する講演は
以上です
後半はYiの方から
お話します
ここからは
CPUプロファイラを
紹介します
CPUプロファイラには
CPUレコーディングという
アプリ分析に役立つデータを
取得する機能があります
この機能を使うには
CPUプロファイラで
[Record]ボタンを押し
アプリで操作を行ってから
CPUプロファイラに戻り
[Stop]ボタンを押します
トレースが
記録されました
初めに このスレッド一覧に
注目してください
トレースは
スレッド別に
まとめられるので
データ確認前に
適切なスレッドを選択してください
下部には
4つのタブがあり

Korean: 
조금 전에 얘기했던 것처럼요
오늘 메모리 프로파일러에 대해
여러분께 설명하려고 했던
내용이었습니다
다음으로 다음 발표는 이 님이 
진행해 주시겠습니다
[박수]
고마워요, 슈강
이제 CPU Profiler로
화제를 전환하겠습니다
메모리 프로파일러와
마찬가지로 CPU Profiler도
중요한 성능 데이터를 캡처하는
방법을 제공해서
여러분의 앱 프로파일링을 돕습니다
이 기능을
CPU 기록이라고 합니다
기록을 캡처하기 위해
CPU Profiler로 이동한 다음
이 'Record' 버튼을
누릅니다
앱에서 몇 가지 행동을 수행하고
Profiler로 돌아와서
'Stop' 버튼을 누릅니다
이제 여기에 기록된
트레이스가 있습니다
지적하고 싶은 첫 번째는
여기 있는 이 스레드 목록입니다
기록된 트레이스는
스레드별로 정리되기 때문에
트레이스 데이터를
들여다보기 전에
올바른 스레드를 선택했는지
확인하려고 합니다
여기 하단에는
네 가지의 차트를 보여주는

Portuguese: 
como conversarmos há alguns instantes.
É isso que temos para falar
sobre o Memory Profiler hoje.
Agora deixarei o restante 
da apresentação com o Yi.
Obrigado, Shukang!
Falaremos sobre o CPU Profiler.
Assim como o Memory Profiler,
o CPU Profiler também oferece uma forma
de capturar dados de desempenho essenciais
para ajudar na criação
do perfil para seu app.
O recurso se chama CPU Recording.
Para capturar uma gravação,
navegue até o CPU Profiler
e pressione o botão "Record".
Faça alguma ação no app,
volte ao criador de perfis
e pressione o botão "Stop".
Agora temos um rastro registrado.
Primeiro quero indicar 
esta lista de thread.
Como um rastro registrado
é organizado por threads,
é importante verificar
se você está selecionando
o thread correto antes de
analisar os dados do rastro.
Na parte inferior,
temos quatro guias que mostram

English: 
like we discussed a moment ago.
So this is what we are going to
tell you about Memory Profiler
today.
Next, I'm going to hand
over the rest of talk to Yi.
[APPLAUSE]
YI YANG: Thank you, Shukang.
Now let's switch gears
to the CPU Profiler.
Just like the Memory
Profiler, the CPU Profiler
also provides a way of capturing
critical performance data
to help you profile your app.
The feature is
called CPU Recording.
To capture a recording,
navigate to the CPU Profiler
and then press
this Record button.
Perform some action in your
app, come back to the Profiler,
and press the Stop button.
So now we have a
recorded trace here.
The first thing I want to point
out is this thread list here.
Because a recorded trace
is organized by threads,
you want to make sure
you are selecting
the correct thread before
looking into the trace data.
On the bottom here, we
have four tabs showing you

Portuguese: 
quatro gráficos diferentes.
"Call Chart", "Flame Chart",
"Top Down" e "Bottom Up".
O Call Chart pode ser simples,
mas o que é um Flame Chart?
Por que ele tem esse formato?
E quanto ao Top Down e o Bottom Up?
O que esses números significam?
Vejamos essas questões.
Podemos voltar ao site?
O CPU Recording é só
um conjunto de pilhas de chamadas.
No caso do System Trace,
trata-se de um conjunto
de pilhas de eventos.
Mas o comportamento é o mesmo.
No restante desta apresentação,
usarei somente pilhas de chamadas.
Um rastro registrado,
mesmo um rastro curto,
contém uma quantidade
enorme de dados não legíveis.
Por isso, precisamos
de algumas formas de visualizá-los.
Começaremos com o Call Chart.
Ele é provavelmente o mais simples.
Trata-se de uma representação visual
das pilhas de chamadas.

English: 
four different charts--
Call Chart, Flame Chart,
Top Down, and Bottom Up.
The Call Chart may
be straightforward,
but what is a Flame Chart?
Why does it have
a shape like this?
And what about Top
Down and Bottom Up?
What do these numbers mean?
Well, let's dive right in.
Can we switch back to the site?
So CPU Recording is
actually just a collection
of call stacks.
In the case of
System Trace, it's
a collection of event stacks.
But they behave the same.
So for the rest of the talk, I'm
just going to use call stacks.
So a recorded trace contains
a tremendous amount of data--
even for a short trace--
and is not human-readable.
That's why we need a few
ways to visualize them.
Let's start with the Call Chart.
A Call Chart is probably the
most straightforward one.
It's basically a
visual representation
of the call stacks.

Spanish: 
cuatro tablas diferentes:
Call Chart, Flame Chart,
Top Down y Bottom Up.
La Call Chart
pueder ser directa,
pero ¿qué es la Flame Chart?
¿Por qué tiene esta forma?
¿Y qué hay de
Top Down y Bottom Up?
¿Qué significan estos números?
Pasemos enseguida a esto.
¿Podemos volver al sitio?
CPU Recording 
es en verdad una recopilación
de pilas de llamadas.
En el caso de System Trace,
es una recopilación
de pilas de eventos.
Pero se comportan igual.
Durante el resto de la charla, 
solo usaré pilas de llamadas.
Un seguimiento grabado contiene
una tremenda cantidad de datos,
hasta para un seguimiento menor,
y no es legible por humanos.
Por eso necesitamos algunas
formas de visualizarlos.
Empecemos con la Call Chart.
Una Call Chart es quizás
la más directa.
Es básicamente
una representación visual
de una pila de llamadas.

Indonesian: 
yang menunjukkan empat diagram berbeda,
yaitu Call Chart, Flame Chart, 
Top Down, dan Bottom Up.
Call Chart lebih sederhana.
Lalu apa itu Flame Chart?
Kenapa bentuknya seperti ini?
Dan bagaimana dengan 
Top Down dan Bottom Up?
Apa artinya angka-angka ini?
Mari kita bahas.
Bisa tolong kembali ke situs?
Oke.
CPU Recording sebenarnya adalah
kumpulan stack panggilan.
Dalam kasus System Trace,
berupa stack peristiwa.
Tetapi perilakunya sama.
Jadi sampai akhir pembahasan,
saya akan menggunakan stack panggilan.
Jadi jejak yang tersimpan berisi 
jumlah data yang luar biasa,
bahkan untuk jejak pendek,
dan tidak bisa dibaca oleh manusia.
Itulah mengapa kita butuh 
cara untuk memvisualisasikannya.
Mari kita mulai dengan Call Chart.
Call Chart bisa jadi 
yang paling sederhana.
Pada dasarnya hal ini adalah
representasi visual dari stack panggilan.

Japanese: 
コールグラフ
フレイムグラフ
トップダウン、ボトムアップ
の4グラフが表示されます
コールグラフは
わかりやすいのですが
フレイムグラフの形状や
他2つの
グラフの数字の
意味は何でしょう？
1つずつ説明します
スライドをご覧ください
CPUレコーディングは
コールスタックを
集めたもので
イベントスタックを
集める
システム
トレースと
動作は同じです
今回はコールスタックを
見ていきましょう
短時間の記録でも
トレースには
データが大量にあり
判読できません
トレースを可視化する
手段が必要です
まず コールグラフを
見てみましょう
これは4つの中で
最も単純なグラフであり
簡単に言うと
コールスタックを視覚的に
表したものです

Korean: 
네 개의 탭이 있는데
Call Chart, Flame Chart,
Top Down, 그리고 Bottom Up입니다
Call Chart는 뭔지 
쉽게 알 것 같은데
Flame Chart는 무엇일까요?
왜 이런 모양을
하고 있을까요?
Top Down과
Bottom Up은 무엇일까요?
이들 숫자는 무엇을 의미할까요?
자, 바로 알아봅시다
사이트로 다시 돌아갈 수 있을까요?
CPU 기록은 사실
호출 스택의 컬렉션에
불과합니다
시스템 트레이스의 경우
이벤트 스택의 컬렉션이죠
하지만 똑같이 행동합니다
이후 내용에서는
호출 스택만 사용하려고 합니다
기록된 트레이스에는
엄청난 양의 데이터가 들어 있어요
짧은 트레이스도 그렇죠
그리고 사람이 읽을 수가 없습니다
그래서 이들을 시각화할
몇 가지 방법이 필요합니다
Call Chart부터 시작합시다
Call Chart는 아마도
가장 단순한 차트일 겁니다
기본적으로 호출 스택의
시각적 재현입니다

Chinese: 
在底部这里 有4个标签页 代表4个不同的表格 分别是
Call Chart、Flame Chart、Top Down 和 Bottom Up
Call Chart 很简单明了
但是 Flame Chart 是什么？
为什么它的形状是这样的？
Top Down 和 Bottom Up 又是怎么回事？
这些数字是什么意思？
好 下面我们就来具体讲解一下
我们切换回文稿
CPU Recording 其实就是一个调用栈的集合
在 System Trace 的例子中
它是事件栈的集合
但它们两个的行为模式是一致的
在剩余的时间里 我会使用调用栈
录制信息中包含有大量的数据
即使是短小的录制中也是如此 而且是人类无法读懂的
所以 我们需要采用一个新方式来让它们可视化
就先从 Call Chart 说起吧
Call Chart 可能是最简单明了的一个
它基本上就是调用栈的视觉展示

Portuguese: 
Pense nele como uma reconstrução
das pilhas de chamada em execução
do programa.
O eixo horizontal é
somente a linha do tempo
mostrando exatamente
o início e o término do método.
O eixo vertical mostra
os autores da chamada
na parte superior
e os recebedores na parte inferior.
Assim, o Call Chart
é muito mais fácil de analisar
do que os dados brutos.
No entanto, não é muito fácil
descobrir partes do código
de execução longa.
Por isso, precisamos de um Flame Chart.
Ele oferece
uma visualização agregada
das pilhas de chamadas.
Ao contrário do Call Chart,
o eixo horizontal exibe
a porcentagem da duração.
Ao descartar
a informação da linha do tempo,
é possível agregar os dados
e mostrar a porcentagem recebida
por cada chamada
em relação ao registro completo.
Além disso, o eixo vertical é invertido.
Ele mostra os recebedores de chamadas
na parte superior
e os autores na parte inferior.
O nome Flame Chart vem do formato dele.

English: 
Think of this as a
reconstruction of the program's
running call stacks.
The horizontal axis
is just the timeline
showing you exactly when the
method starts and when it ends.
The vertical axis shows
callers on the top
and callees on the bottom.
So the Call Chart is much easier
to parse than raw data already.
But it's not very
easy to discover
parts of the code
that's long-running.
That's why we need
a Flame Chart.
So the Flame Chart
provides an aggregated view
of the call stacks.
Unlike the Call Chart,
the horizontal axis
here shows duration percentage.
So by discarding the
timeline information,
we can now aggregate
the data and show
the percentage each
call takes relative
to the entire recording.
And also the vertical
axis is inverted,
showing callees on the top
and callers on the bottom.
So the name Flame Chart
comes from the shape.

Japanese: 
プログラム実行時の
コールスタックの再現
と考えてください
横軸は時系列であり
各メソッドの
開始時点と終了時点を
表しています
上から順に
呼び出し元と
呼び出し先が
置かれています
未加工データよりも
わかりやすくなっていますが
実行時間の長い
コード部分は
簡単には
特定できません
そこで
フレイムグラフの出番です
このグラフは
コールスタックを
集約したものです
コールグラフと異なり
横軸は
実行時間の
割合を示しています
時系列の情報を
取り除くことで
データを集約して
各コールの実行時間を
記録全体に対する
割合として確認できます
縦軸の向きは
逆転しており
呼び出し先が上側
呼び出し元が下側です
このように
上が細くなる形が

Indonesian: 
Anggaplah ini sebagai 
rekonstruksi stack panggilan
yang berjalan dari sebuah program.
Sumbu horizontal adalah linimasa
yang menunjukkan 
kapan tepatnya metode mulai dan berhenti.
Sumbu vertikal 
menunjukkan pemanggil di atas
dan yang dipanggil di bawah.
Call Chart bisa lebih mudah 
diurai daripada data mentah.
Tapi tidak mudah
untuk menemukan 
bagian kode yang berjalan lama.
Itu mengapa kita 
perlu Flame Chart.
Flame Chart
memberikan tampilan gabungan
dari semua stack panggilan.
Tidak seperti Call Chart, 
sumbu horizontal di sini
menunjukkan persentase durasi.
Jadi, dengan menghapus infomasi linimasa,
sekarang kita bisa menggabungkan data
dan menunjukkan
persentase setiap panggilan
relatif terhadap seluruh rekaman.
Dan juga sumbu vertikalnya dibalik,
menunjukkan yang dipanggil 
di atas dan pemanggil di bawah.
Jadi nama Flame Chart 
berasal dari bentuknya.

Korean: 
이것을 호출 스택을
실행하고 있는 프로그램의
재구성이라고 생각합시다
수평 축은
메서드가 정확히 언제 시작되고
언제 끝나는지 보여주는
타임라인입니다
수직 축은 상단에
호출자를 표시하고
하단에 피호출자를 표시합니다
Call Chart는 원시 데이터보다
파싱하기가 훨씬 쉬워요
하지만 장기 실행 중인
코드의 일부분을
찾는 것은 그다지
쉽지 않습니다
그렇기 때문에
Flame Chart가 필요하죠
Flame Chart는
호출 스택의 집계된 뷰를
제공합니다
Call Chart와 달리
수평 축은 기간 백분율을
표시합니다
타임라인 정보를
폐기함으로써
데이터의 총계를
집계할 수 있고
전체 기록에 대비하여
각 호출의 백분율을
표시할 수 있습니다
또한 수직 축이
도치되어
상단에 피호출자가 표시되고
호출자는 하단에 표시됩니다
Flame Chart라는 이름은
그 모양에서 나온 것이죠

Spanish: 
Piensen en esto como una
reconstrucción de una pila de llamadas
de un programa ejecutándose.
El eje horizontal
es el cronograma
que muestra exactamente cuándo
empieza el método y cuándo termina.
El eje vertical muestra
los emisores arriba
y los receptores abajo.
La Call Chart es más fácil
de analizar que los datos sin procesar.
Pero no es fácil descubrir
partes del código
que hace mucho se ejecutan.
Por eso necesitamos
la Flame Chart.
La Flame Chart brinda
una vista agregada
de la pila de llamadas.
A diferencia de la Call Chart,
el eje horizontal
muestra el porcentaje
de duración.
Al descartar la información
del cronograma,
ahora podemos agregar los datos
y ver el porcentaje
que cada llamada toma
en relación con la grabación total.
También el eje
vertical está invertido,
y muestra a los destinatarios arriba
y a los emisores abajo.
El nombre Flame Chart
proviene de esa forma de llama.

Chinese: 
你可以把它看作程序运行调用栈的重绘
横轴代表时间线
展示方法开始和结束的精确位置
纵轴代表顶端的调用者和底端的被调用者
所以 Call Chart 解析起来已经比原始数据容易多了
但是 并不是非常容易发现那些长期运行的代码
所以我们才需要 Flame Chart
Flame Chart 提供了一个调用栈的聚合视图
与 Call Chart 不同 Flame Chart 的横轴
是用来展示持续时间百分比的
在不使用 Call Chart 的时间轴后 我们可以聚合数据
展示出每次调用在整个录制中所占的时长百分比
纵轴上下对调了
将被调用者显示在顶端 调用者显示在底端
Flame Chart 得名于它的形状

Chinese: 
越往上就越窄 像一团燃烧着的火
那么我们是如何聚合调用栈的？
我们从 Call Chart 起步
把一致的调用栈合并进来 按照持续时间对其进行排序
然后就出现了 Flame Chart
我来给大家看一个例子
在这个 Call Chart 中 
方法 A 对 B 进行了多次调用
而 B 又对 C 进行了一次调用
所以现在存在着多个相同序列的实例
从 A 到 B 再到 C 也就是说 它们可以被聚合起来
我画了一个图 用来解释如何识别某个调用栈
我把这个 Call Chart 切开
现在我们可以把一致的调用栈合并起来 就这样
好 最后 我们把图表上下对调
然后我们就有了 Flame Chart
我们来比较一下这两者
左侧的 Call Chart 会保留时间线信息

Korean: 
위로 올라갈수록
점점 더 좁아집니다
불타는 불꽃처럼 말이죠
그런데 정확히 어떻게
호출 스택을 집계할 수 있을까요?
Call Chart에서
시작합니다
똑같은 호출 스택을 병합해서
기간별로 분류하고 나면
Flame Chart가 됩니다
예를 보여드릴게요
이 Call Chart에서 메서드 A가
메서드 B에 다중 호출을 하면
C에 하나의 호출을 합니다
같은 호출 시퀀스에 대해
A에서 B, C로
다중 인스턴스가 있고
이들을 집계할 수
있다는 뜻입니다
고유의 호출 스택을
식별하는 방법을 설명하기 위해
이 Call Chart를
얇게 잘랐습니다
이제 동일한 호출 스택을
병합할 수 있습니다
이렇게요
그리고 마지막으로 
차트를 수직으로 뒤집습니다
그러면 Flame Chart를 얻게 됩니다
잠시 두 차트를
비교해 봅시다
왼쪽에 있는
Call Chart는
무엇이 언제 일어났는지
정확히 보여주는

English: 
The higher you go,
the narrower it gets--
just like a burning flame.
But how exactly do we
aggregate the call stacks?
Well, we start
with a Call Chart,
merge identical calls stacks,
sort them by duration,
and then we have a Flame Chart.
I'll show you an example.
In this Call Chart here,
method A makes multiple calls
to B, which makes a call to C.
So there are multiple instances
of the same call
sequence, A to B
to C, which means they
can be aggregated.
To illustrate how to
identify unique call stacks,
I have sliced this
Call Chart for you.
And now we can start merging
identical call stacks, just
like this.
And then finally, we flip
the chart vertically.
And then we have a Flame Chart.
So let's compare the
two for a moment.
The Call Chart on
the left-hand side
retains timeline
information, where it shows

Japanese: 
炎(フレイム)に
似ているので
フレイムグラフと
名付けられました
コールスタックの集約方法は
次のとおりです
まず コールグラフを
用意して
同じコールスタックを合成し
実行時間で並べ替えると
フレイムグラフが
できあがります
実際に試してみましょう
このコールグラフで
メソッドAはBを複数回呼び出し
BはCを呼び出しています
A→B→Cという
同じ順序の
呼び出しが
複数あるので
これらを集約します
一意のスタックを
特定するため
コールグラフを
分割します
そして このように
同じコールスタックを統合します
最後にグラフの
上下を反転させます
フレイムグラフの完成です
2つのグラフを
比べると
左のコールグラフは
各コールの
時系列に関する

Spanish: 
Cuanto más alto vayas,
más angosta se hace,
justo como una llama.
Pero ¿cómo agregamos
las pilas de llamadas exactamente?
Empezamos con una Call Chart,
fusionamos pilas de llamadas idénticas,
las ordenamos por duración,
y luego tenemos una Flame Chart.
Les mostraré un ejemplo.
En esta Call Chart,
el método A hace llamadas múltiples a B,
que hace una llamada a C.
Hay instancias múltiples
de la misma secuencia
de llamadas, A a B a C.
Esto significa que
puden ser agregadas.
Para ilustrar cómo
identificar pilas de llamadas únicas,
dividí esta Call Chart
para ustedes.
Ahora podemos empezar
a fusionar pilas de llamadas idénticas,
de esta manera.
Y, al final,
giramos la tabla verticalmente.
Y ahora tenemos una Flame Chart.
Comparemos las dos
por un momento.
La Call Chart de la izquierda
retiene la información del cronograma,

Indonesian: 
Semakin tinggi maka akan semakin sempit,
seperti nyala api.
Tapi bagaimana sebenarnya cara
menggabungkan stack panggilan?
Kita mulai dengan Call Chart,
gabungkan stack panggilan
yang identik, urutkan berdasarkan durasi,
lalu jadilah Flame Chart.
Saya perlihatkan satu contoh.
Pada Call Chart di sini, metode A 
membuat panggilan multipel ke B,
yang juga membuat panggilan ke C.
Jadi ada berbagai instance 
dalam urutan panggilan yang sama,
A ke B ke C, 
yang artinya bisa digabungkan.
Untuk menunjukkan cara 
mengidentifikasi stack panggilan unik,
Saya telah mengiris 
Call Chart ini untuk Anda.
Sekarang kita bisa mulai
menggabungkan stack panggilan yang identik
seperti ini.
Lalu terakhir, kita balik 
diagramnya secara vertikal.
Lalu jadilah Flame Chart.
Mari kita bandingkan
keduanya.
Call Chart di sisi kiri
mempertahankan informasi linimasa,

Portuguese: 
Quanto mais alto você for,
mais estreito ficará.
Como uma chama.
Mas como exatamente
agregamos a pilha de chamadas?
Começaremos com um Call Chart.
Mesclamos as pilhas de chamadas idênticas,
as ordenamos por duração
e teremos um Flame Chart.
Mostrarei um exemplo.
Neste Call Chart,
o método A faz várias chamadas para B,
que faz uma chamada para C.
Assim, há diversas instâncias
da mesma sequência de chamadas:
A > B > C.
Ou seja, elas podem ser agregadas.
Para mostrar como identificar
pilhas de chamadas únicas,
eu dividi este Call Chart para vocês.
Agora podemos começar a mesclar
as pilhas de chamadas idênticas, assim.
Por fim, viramos o gráfico verticalmente.
Dessa forma, temos um Flame Chart.
Compararemos os dois por um instante.
O Call Chart, à esquerda,
retém as informações da linha do tempo,

Japanese: 
情報を示しています
一方 右側の
フレイムグラフには
実行時間の
集約情報が
示されているので
コード内で実行時間の長いパスを
簡単に特定できます
フレイムグラフは
全体像を見るのに役立ちますが
正確なタイミングを
知るには
トップダウンツリーが
必要になります
このツリーの
作成方法は
コールグラフ全体について
ツリー構造のように
呼び出し元と呼び出し先を
順番につなげるだけです
これでトップダウンツリーの完成です
ノードごとに
3種類の
タイミング情報を
知る必要があります
ノード自身の
コードの呼び出しに
かかった時間を表す
セルフ時間と
別メソッドの呼び出しに
かかった時間を表す子時間と
これら2つの合計時間です
トップダウンツリーを
使用すれば

Portuguese: 
onde é mostrado exatamente
o momento em que algo ocorre.
No entanto, o Flame Chart, à direita,
mostra as informações
de duração agregadas.
Isso facilita a descoberta
de caminhos de execução longa
no seu código.
Portanto, o Flame Chart é útil
para visualizar o panorama geral.
Mas às vezes você precisa encontrar
as informações exatas de tempo.
Por isso, precisamos
de uma árvore descendente.
A construção de uma
árvore desse tipo é simples.
Você começa pelo autor da chamada
e adiciona os recebedores
como nós da árvore,
até transferir o Call Chart inteiro.
Assim, você terá uma árvore descendente.
Para cada nó nessa árvore,
três informações temporais nos interessam.
O tempo próprio:
gasto na execução do próprio código.
O tempo filho:
gasto nas chamadas a outros métodos.
E o tempo total:
a soma dos dois valores anteriores.
Com essa árvore descendente,
podemos incorporar facilmente

Indonesian: 
tepat saat sesuatu sedang terjadi.
Tetapi Flame Chart pada sisi kanan
menunjukkan penggabungan informasi durasi,
yang mempermudah Anda menemukan
jalur yang berjalan lama di kode Anda.
Jadi flame chart berguna 
untuk melihat secara garis besar.
Tapi terkadang Anda ingin 
tahu informasi waktu yang presisi.
Dan itulah alasan kita 
membutuhkan struktur Top Down.
Struktur Top Down mudah dibuat.
Mulai dari pemanggil,
tambahkan yang dipanggil 
sebagai node struktur
sampai Anda selesai 
menjelajahi Call Chart seluruhnya.
Lalu jadilah struktur Top Down.
Untuk setiap node 
di struktur Top Down ini,
kami tertarik di tiga 
bagian informasi waktu.
Self Time yaitu waktu yang dihabiskan 
mengeksekusi kodenya sendiri,
Children Time yaitu waktu 
untuk memanggil
ke dalam metode lain,
dan Total Time 
yaitu penjumlahan dari keduanya.
Dengan struktur Top Down di sini,

Chinese: 
也就是说 它会记录下事件发生的确切时间
但是 右侧的 Flame Chart
会显示聚合持续时间信息
也就方便了你探索代码中长时间运行的路径
Flame Chart 有助于通览全局
但是有时候 你会想去找到精确的时间信息
所以我们才需要 Top Down 树
生成 Top Down 树没什么困难的
只需从调用者出发 持续将它的调用对象添加为树节点
直到你将整个 Call Chart 梳理完毕
这时你就有了一个 Top Down 树
对于 Top Down 树中的每个节点
我们都对它的3段时间信息感兴趣 分别是
Self Time 也就是它用来执行自身代码的时间
Children Time 也就是它用来调用其他方法的时间
Total Time 也就是前两者的总和
Top Down 树让我们能够轻松地

Spanish: 
donde muestra exactamente
cuándo pasa algo.
Pero la Flame Chart de la derecha
muestra información de duración agregada,
lo que hace más fácil descubrir
rutas de acceso largas en tu código.
De este modo, la Flame Chart es útil
para tener una visión general.
Pero a veces queremos encontrar
información precisa sobre el tiempo.
Por eso necesitamos
un árbol Top Down.
La construcción de un árbol
Top Down es simple.
Empezamos por el emisor,
agregamos a los receptores
como nodos en el árbol,
hasta que hayamos recorrido
toda la Call Chart.
Y también tenemos
el árbol Top Down.
Para cada nodo
en este Top Down tree,
nos interesan tres tipos
de información de tiempo.
Self Time: el tiempo que pasa
ejecutando su propio código.
ChildrenTime: el tiempo que pasa
integrando otros métodos.
Y Total Time, que es la suma
de los dos.
Con el árbol Top Down,
podemos fácilmente

English: 
exactly when something happens.
But the Flame Chart
on the right-hand side
shows you aggregate
duration information,
which makes it easy for you
to discover long-running paths
in your code.
So the flame chart is helpful
for looking at the big picture.
But sometimes you want to find
the precise timing information.
And that's why we
need a Top Down tree.
Constructing a Top
Down tree is trivial.
You just start from
the caller, keep
adding its callees as tree
nodes until you have traversed
the entire Call Chart.
And then you have
a Top Down tree.
For each node in
this Top Down tree,
we're interested in three
pieces of timing information.
Self Time-- the time
it spends executing
its own code, Children
Time-- the time
it spends calling into other
methods, and Total Time,
which is the sum of the two.
With the Top Down tree
here, we can easily

Korean: 
타임라인 정보를 보유하고 있어요
그러나 오른쪽의
Flame Chart는
코드에서 장기 실행 중인
경로를 쉽게
찾도록 해주는
기간별 집계 정보를
표시합니다
따라서 Flame Chart는
큰 그림을 살펴보는 데 유용합니다
그러나 가끔은 정확한
시간 정보를 찾고 싶을 때가 있어요
그렇기 때문에
Top Down 트리가 필요합니다
Top Down 트리를
구축하는 일은 간단해요
호출자부터 시작해서
전체 Call Chart를 횡단할 때까지
트리 노드로 피호출자를
계속 추가하면 됩니다
그러면 Top Down
트리를 얻게 됩니다
이 Top Down 트리의
각 노드에서
세 가지의
시간 정보에 관심이 있습니다
Self Time은
자체 코드 실행에 들이는 시간이고
Children Time은 다른 메서드를
호출하는 데 들이는 시간이며
Total Time은
이들 두 개의 합계입니다
이 Top Down 
트리를 통해

Chinese: 
把这三段时间信息纳入一个表格 就像这样
下面我来讲解一个例子
向大家展示时间信息是如何被运算的
位于左侧的还是我们一直使用的 Flame Chart
右侧则是一个 Top Down 树
我们先从根节点 A 开始
A 花了1秒钟来执行它自己的代码
所以它的 Self Time 是1秒
它总共花了9秒来调用 B 和 D 方法
也就是说 Children Time 是9秒
以上两者加起来是10秒 
还跟得上吗？下面我要加快节奏了
现在 如果我扩展节点 A
我们就会看到它的两个同类 B 和 D 
B 花了3秒钟来执行它自己的代码
花了4秒钟来调用其他方法
总和是7秒
D 比较有意思

English: 
incorporate all three
pieces of timing information
in one table just like this.
So I'm going to walk
through an example here
to show you how the
timing info is computed.
On the left-hand side is
the same Flame Chart example
we've been using.
On the right-hand side,
we have a Top Down tree.
Let's start with the root
node A. A spent one second
executing its own code.
So the Self Time is one second.
And then it spent a total
of nine seconds calling
into methods like B
and D, which means
the Children Time is nine.
That gives us a
total of 10 seconds.
Still with me?
I'm going to pick up the pace.
Now, if I expand
the node A, we're
going to see two
of its colleagues,
B and D. B spent three
seconds executing its own code
and four seconds calling
into other methods.
That makes a total
of seven seconds.
D here is a little
bit interesting.

Portuguese: 
as três informações temporais
em uma tabela, desta forma.
Mostrarei um exemplo de como
a informação temporal é calculada.
À esquerda, temos o mesmo
exemplo de Flame Chart
usado anteriormente.
À direita, há uma árvore descendente.
Começaremos com o nó da raiz A.
A passou um segundo
executando o próprio código.
O tempo próprio é de um segundo.
Em seguida, ele passou 
um total de nove segundos
chamando métodos como B e D.
Ou seja, o tempo filho é nove.
Com isso, temos um total de 10 segundos.
Está dando para acompanhar?
Acelerarei o ritmo.
Se eu expandir o nó A,
veremos dois parceiros dele: B e D.
B passou três segundos
executando o próprio código
e quatro segundos chamando outros métodos.
Ou seja, um total de sete segundos.
D é um caso interessante.

Japanese: 
3つのタイミング情報を
1つの表に
まとめられます
それでは
各タイミングの計算方法を
具体例とともに
説明します
左側は 先ほどの
フレイムグラフ
右側は
トップダウンツリーです
まずルートノードAです
Aは1秒で自コードを
実行したので
セルフ時間は1秒です
メソッドBとDの
呼び出しに
合計で9秒
かけているので
子時間は9秒です
合計時間は10秒です
ここまでは
いいですか？
次に進みましょう
ノードAの
呼び出し先は
BおよびDの
2つです
Bは3秒で自コードを実行し
別メソッドを
4秒で呼び出しているので
合計時間は
7秒になります
Dが実行しているのは

Spanish: 
incorporar los tres tipos
de información sobre el tiempo
en una tabla como esta.
Voy presentar un ejemplo
para mostrarles cómo se computa
la información sobre tiempo.
En el lado izquierdo,
está el mismo ejemplo de la Flame Chart
que he estado usando.
A la derecha,
tenemos el árbol Top Down.
Comencemos con el nodo raíz A.
A tardó un segundo
en ejecutar su propio código.
Así que el Selt Time tarda
un segundo.
Y tardó un total de nueve segundos
en integrar métodos como B y D,
lo que significa
que Children Time es de nueve.
Esto nos da un total
de 10 segundos.
¿Todavía me siguen?
Voy a acelerar el paso.
Si expando el nodo A,
veremos dos de sus colegas, B y D.
B tardó tres segundos
en ejecutar su código
y cuatro segundos
en integrar otros métodos.
Eso hace un total
de siete segundos.
D es un poco más interesante.

Indonesian: 
kita bisa dengan mudah 
menggabungkan tiga bagian informasi waktu
dalam satu tabel seperti ini.
Saya akan jelaskan contoh di sini
untuk menunjukkan cara 
informasi waktu terkomputasi.
Di sisi kiri ada contoh Flame Chart
yang sama dengan yang kita gunakan.
Di sisi kanan,
ada struktur Top Down.
Mari kita mulai dengan node root A.
A menghabiskan satu detik 
untuk mengeksekusi kodenya sendiri.
Jadi Self Time adalah satu detik.
Lalu ada total sembilan detik dihabiskan
memanggil ke dalam 
metode seperti B dan D,
artinya Children Time adalah sembilan.
Jadi total waktunya 10 detik.
Jelas ya?
Akan saya percepat.
Sekarang, jika saya perluas node A,
kita lihat dua rekannya, B dan D.
B menghabiskan tiga 
detik untuk mengeksekusi kodenya sendiri
dan empat detik untuk 
memanggil ke dalam metode lain,
Jadi totalnya tujuh detik.
D di sini sedikit menarik.

Korean: 
세 가지의 시간 정보
모두를 이렇게 하나의 표로
쉽게 통합할 수 있습니다
여기 있는 예시를
차례로 살펴보면서
시간 정보를 어떻게
산출하는지 보여드리겠습니다
왼쪽에 있는 것은
저희가 사용하고 있는 것과 같은
Flame Chart 예입니다
오른쪽에 있는 것은
Top Down 트리입니다
루트 노드 A부터 시작합시다
A는 자체 코드를
실행하는 데 1초를 들였습니다
따라서 Self Time은 1초입니다
그런 다음 B와 D 같은
메서드를 호출하기 위해
총 9초의 시간을 들였으며
Children Time이 9초라는 뜻입니다
총 10초의 시간을
들였다는 것을 알 수 있죠
이해하시죠?
속도를 올려보겠습니다
노드 A를
확장하는 경우
유사한 종류 중 B와 D 노드
두 개를 볼 수 있어요
B는 자체 코드를
실행하는 데 3초
다른 메서드를
호출하는 데 4초를 들였어요
이렇게 해서
총 7초가 됩니다
D는 조금
흥미롭습니다

Japanese: 
Cの呼び出しのみです
これは
ラッパーによくある動作です
セルフ時間は0秒で
子時間と合計時間は
ともに2秒になります
ここで Aの子時間は
当然のことながら
BとDの合計時間の
合計になっています
ツリーをすべて展開した表は
このようになります
実際には
プロファイラが
自動で計算します
この計算はみなさんに
それぞれの数字の意味を
わかりやすく
説明するためのものです
それでは 2つのグラフを
比較してみましょう
左のフレイムグラフは
実行時間の長いコードを
視覚的に示しており
右側にある
トップダウンツリーは
正確な数字を
知るのに適しています
ツリーは
表形式なので
各列を
並べ替えられるという
非常に大きなメリットもあります

Indonesian: 
Yang dilakukannya adalah 
memanggil ke dalam C,
yang umum dilakukan pada metode wrapper.
Jadi Self Time-nya adalah nol.
Children Time dan 
Total Time berjumlah dua.
Perhatikan bahwa Children Time A adalah
jumlah waktu total B dan D,
yang memang seharusnya.
Seperti inilah tabelnya 
saat ditampilkan seluruhnya.
Jangan khawatir, Profiler CPU akan 
mengkomputasi semuanya untuk Anda.
Saya hanya memberikan contoh ini
untuk memberitahu 
maksud dari angka-angka ini.
Jika kita perhatikan
dan bandingkan dua diagram ini,
Flame Chart di sisi kiri
bagus untuk memeriksa secara visual
di mana kode Anda 
banyak menghabiskan waktu,
sedangkan struktur Top Down di sisi kanan
bagus untuk melihat angka tepatnya.
Karena bentuknya tabel,
Anda bisa mengurutkan setiap kolom,
yang sangat berguna.

Korean: 
D가 한 일은
C를 호출한 게 다인데요
래퍼 메서드에서는 흔한 일입니다
따라서 Self Time은 0입니다
그리고 Children Time과
Total Time은 둘 다 2초입니다
A의 Children Time은
B와 D의 Total Time의
합계라는 것에 주목하세요
이해되시죠
이것은 표를 완전히
확장했을 때의 모습입니다
걱정하지 마세요
CPU Profiler가 모든 것을
컴퓨팅합니다
이들 숫자가 무엇을
의미하는지 보여드리기 위해
이 예를 사용하고 있어요
잠깐 멈추고
두 개의 차트를 비교하면
왼쪽의 Flame Chart는
코드가 어디에서 많은
시간을 들이는지
육안으로 확인하기에
적합한 반면에
오른쪽에 있는
Top Down 트리는
정확한 숫자를 살펴보는 데
적합하죠
또한 표로 만들면
개별 열에 따라
분류할 수 있고
이렇게 하면 굉장히
유용합니다

Chinese: 
它只是调用 C 
这种行为在封装方法中很常见
所以 它的 Self Time 是 0
Children Time 和 Total Time 都是2秒
请注意 A 的 Children Time 是 B 和 D Total 的总和 很合理
这个表格在完全展开后是这样的
别担心 CPU Profile 会处理一切
我只是用这个例子来让大家看看这些数字的含义
我们在这里暂停一下 比较一下这两个图表
左侧的 Flame Chart 非常适合用来目视检查
你的代码在哪些地方花费了大量时间
而右侧的 Top Down 树则适合用来观察精确数字
此外 你可以通过这个图表来按照单列进行排序
这个功能非常有用

Spanish: 
Todo lo que hace
es integrar a C,
que es común en métodos wrapper.
Así que el Self Time es cero.
Y el total
de Children y Total Time es dos.
Fíjense en que Children Time de A
es la suma del tiempo total de B y D,
lo que tiene sentido.
Así es cómo se verá
la tabla totalmente expandida.
No se preocupen, el CPU Profiler
computará todo por ustedes.
Estoy usando
este ejemplo para mostrarles
qué significan estos números.
Si nos detenemos un momento
y comparamos estas dos tablas,
la Flame Chart de la izquierda
es buena para controlar visualmente
dónde tu código tarda mucho tiempo
mientras que el árbol Top Down
de la izquierda
es bueno para ver los números precisos.
Y, al ser también una tabla, nos permite
ordenar en columnas individuales.
Esto lo hace extremadamente útil.

English: 
All it does is
call in to C, which
is common in wrapper methods.
So the Self Time is zero.
And then both Children
and Total Time are two.
So notice A's Children
Time is the sum of B
and D's total time,
which makes sense.
Now, this is what the table will
look like when fully expanded.
Don't worry, the CPU Profiler
will compute everything
for you.
I'm just using this
example to show you
what these numbers mean.
So if we pause for a moment
and compare these two charts,
the Flame Chart on
the left-hand side
is good for visually checking
where your code is spending
a lot of time on,
while the Top Down
tree on the right-hand
side is good for looking
at the precise numbers.
And also being a
table, this allows
you to sort by
individual columns, which
makes it extremely useful.

Portuguese: 
Ele somente chama C.
Isso é comum em métodos de wrapper.
Então, o tempo próprio é igual a zero.
Os tempos filho e total são iguais a dois.
O tempo filho de A é a soma
do tempo total de B e D.
O que faz sentido.
A tabela ficará assim
ao ser totalmente expandida.
Não se preocupem, o CPU Profiler
fará todos os cálculos para vocês.
Só estou usando este exemplo
para mostrar o significado destes números.
Se pararmos um instante
e compararmos os dois gráficos,
o Flame Chart, à esquerda,
é bom para verificar visualmente
onde o código está demorando muito.
Já a árvore descendente, à direita,
serve para analisar os números exatos.
Além disso, por ser uma tabela,
é possível organizar
por colunas individuais,
o que é extremamente útil.

Portuguese: 
Assim, uma árvore descendente
é muito interessante, mas às vezes
você precisa descer
por toda a pilha de chamadas
até encontrar um método em particular.
É aí que entra a árvore ascendente.
Como o nome sugere,
ela começa pela parte inferior.
É possível construir essa árvore
fazendo o método inverso
e adicionando os autores
de chamadas do nó à árvore, desta forma.
Ainda tem mais.
Para cada nó único, podemos construir
uma árvore ascendente.
Sim, eu menti.
É uma floresta.
Faremos mais um problema matemático
e descobriremos as informações temporais.
Primeiro, do lado direito,
podemos perceber quatro linhas,
já que temos
quatro árvores nesta floresta.
Começaremos com o nó C.
O tempo próprio é o que foi gasto
executando o próprio código.
4 + 2, um total de 6 segundos.

Japanese: 
トップダウンツリーは有用ですが
目的のメソッドが
見つかるまで
コールスタックを
たどる必要があるので
場合によっては
ボトムアップツリーが有用です
ボトムアップツリーの始点は
その名前のとおり
最下部(ボトム)です
ボトムアップツリーを
作成するには
呼び出し先から呼び出し元に向かって
ツリーをつなげていきます
そして
この手順を
すべての一意のノードで
行います
ツリーではなく
フォレスト(森)ですね
それでは
先ほどと同じように
タイミング情報を
計算しましょう
まず このフォレストには
ツリーが4つあるので
表の行も4つであることに
注意してください
ノードCから始めます
セルフ時間は
自コードの実行に
かかった時間です
4 + 2 = 6秒です
別のメソッドは

Spanish: 
Así que un árbol Top Tree
está muy bueno
pero a veces te encuentras
bajando en la pila de llamadas
hasta que encuentras 
un método particular.
Ahí es cuando el árbol
Bottom Up gana importancia.
Como su nombre sugiere,
el árbol Bottom Up
comienza desde abajo.
Podemos construir
este árbol yendo al revés
y agregar nodos de emisores
al árbol de esta forma.
Pero esperen, hay más.
Para cada nodo, podemos
construir un árbol BottomUp.
Sí, les mentí.
Es un bosque.
Hagamos un problema
de mátemáticas más
para resolver
la información de tiempo.
La primera cosa que vemos,
del lado derecho,
es que tenemos cuatro hileras
porque hay cuatro árboles en el bosque.
Empecemos con el nodo C.
Self Time es el tiempo que pasa
ejecutando su propio código.
Cuatro más dos son seis segundos.
C no integra ningún otro método.

Indonesian: 
Struktur Top Down sangatlah baik,
tapi terkadang Anda harus 
menelusuri banyak stack panggilan
untuk menemukan
metode tertentu.
Di sinilah gunanya Bottom Up.
Seperti namanya,
struktur Bottom Up dimulai dari bawah.
Jadi, kita dapat menyusun
struktur ini dengan berjalan ke belakang
dan terus menambahkan
pemanggil node ke struktur seperti ini.
Tunggu, masih ada lagi.
Untuk setiap node unik, kita dapat
menyusunnya dengan struktur Bottom Up.
Jadi ya, saya berbohong.
Ini adalah sekumpulan struktur.
Mari kita kerjakan 
satu soal matematika lagi
dan memperhitungkan informasi waktu.
Pertama, di sisi kanan
ada empat baris
karena ada empat struktur 
di kumpulan struktur ini.
Mari kita awali dengan node C.
Self Time hanyalah waktu yang terpakai
untuk menjalankan kodenya sendiri.
Empat ditambah dua adalah enam detik.
C tidak memanggil metode lain.

Chinese: 
Top Down 树很好 但是有时候
你会在调用栈中苦苦寻找 直到找到某个特定的方法
这就是 Bottom Up 树发挥作用的地方了
正如它的名称所示 Bottom Up 树始于底层
我们可以倒过来构建这个树
不断在树上添加调用者节点 就像这样
等等 还有更多
我们可以为每一个节点建立一个 Bottom Up 树
好吧 我撒谎了 应该叫它森林才对
下面我们再来做一道数学题 弄清楚时间信息
我们注意到的第一件事就是 在右侧
我们有4个行 因为这个森林里有4棵树
我们就从节点 C 起步吧
Self Time 也就是它用来执行自身代码的时间
4+2=6秒
C 没有调用任何方法

Korean: 
Top Down 트리는
굉장히 멋지지만 가끔은
특정 메서드를
찾을 때까지
호출 스택의 아래로
내려가야 합니다
Bottom Up 트리가
빛을 발하는 순간이죠
이름이 말해주듯이
Bottom Up 트리는
바닥에서부터 시작합니다
이 트리는 거꾸로 가면서
노드의 호출자를 트리에 계속
추가하며 구성할 수 있어요
바로 이렇게 말이죠
잠시만요
다른 내용이 더 있습니다
모든 고유 노드에 대해
Bottom UP 트리를 구성할 수 있어요
그래요, 제가 거짓말했어요
이건 숲이에요
수학 문제를 하나 
더 풀고
시간 정보를 계산해 봅시다
가장 먼저 주목할 것은
오른쪽에
네 개의 행이 있다는 건데
이 숲에 네 개의 트리가 있기 때문이에요
노드 C부터
시작합시다
Self Time은 자체 코드를
실행하는 데 들이는 시간이에요
4 더하기 2는 6초입니다
C는 다른 어떤 메서드도
호출하지 않아요

English: 
So a Top Down tree is very
cool, but sometimes you
find yourself
going down the call
stack until you find
a particular method.
That's where a Bottom
Up tree shines.
So as the names suggests,
the Bottom Up tree
starts from the bottom.
So we can construct this
tree by going backwards
and keep adding a node's callers
to the tree just like this.
But wait, there's more.
For every unique node, we can
construct a Bottom Up tree.
So yeah, I lied.
It's a forest.
Let's do one more math
problem and figure out
the timing information.
So first thing we notice
is, on the right-hand side,
we have four rows because we
have four trees in this forest.
Let's start with
node C. Self Time
is just time is spent
executing its own code.
4 plus 2 is 6 seconds.
C doesn't call any other method.

English: 
So Children Time is zero.
That gives us a total of 6.
When you expand C, its
callers, B and D, will show up.
What do these numbers show?
Is this what you expected?
No?
Remember, we're looking
at C's Bottom Up tree.
So all the timing information
in that Bottom Up tree
is time spent by C. So
what we are counting here
is not B's Self Time,
but C's Self Time
when called by B, which means
that's four seconds here.
And similarly for D,
that's two seconds.
And then since B and D are
the only methods calling C,
they should add up.
Now, let's move on
to the next tree,
which is B's Bottom Up tree.
The Self Time is
trivial-- three seconds.
The Children Time
is the time that's
spent on calling other
methods, which is just C here.

Indonesian: 
Jadi Children Time adalah nol.
Sehingga totalnya adalah enam.
Jika Anda membentangkan C,
pemanggilnya, B dan D, akan muncul.
Apa yang ditunjukkan angka ini?
Apakah ini yang diharapkan?
Tidak?
Ingat, kita sedang melihat
struktur Bottom Up C.
Jadi, seluruh informasi waktu
dalam struktur Bottom Up ini
adalah waktu yang dipakai oleh C.
Jadi, apa yang kita hitung di sini 
bukanlah Self Time B,
melainkan Self Time C 
saat dipanggil oleh B,
yang berarti
empat detik di sini.
Dan sama halnya untuk D,
yaitu dua detik.
Karena B dan D adalah
satu-satunya metode yang memanggil C,
keduanya harus ditambahkan.
Sekarang, mari beralih
ke struktur berikutnya,
yaitu struktur Bottom Up B.
Self Time-nya,
mudah, tiga detik.
Children Time adalah waktu yang 
dihabiskan untuk memanggil metode lain,
dalam hal ini hanya C,

Japanese: 
呼び出していないので
子時間は0です
これらをまとめた
合計時間は6秒です
Cを展開して
呼び出し元のBとDについて
それぞれの数字を求めましょう
計算結果はこのようになります
これは
Cのボトムアップツリーなので
Cが消費した時間だけを
考えます
つまり Bのセルフ時間は
計算に含めません
Bにより
呼び出された時の
Cのセルフ時間を考えるので
ここは4秒になります
Dも同様に
2秒になります
Cを呼び出しているメソッドは
BとDだけなので
これらを足し合わせます
次のツリーに
進みましょう
今度はBのツリーです
セルフ時間は
3秒です
子時間は
別のメソッド
つまり Cの呼び出しに
かかった時間なので

Portuguese: 
C não chamou nenhum outro método.
O tempo filho é igual a zero.
Então, temos um total de seis.
Ao expandir C,
os autores de chamadas dele,
B e D, serão exibidos.
O que estes números mostram?
Era o que você esperava?
Não?
Lembre-se de que estamos observando
a árvore ascendente de C.
Assim, toda a informação temporal
nesta árvore é o tempo gasto por C.
O que estamos contando aqui
não é o tempo próprio de B,
mas o tempo próprio de C
ao receber a chamada de B.
Ou seja, quatro segundos.
De forma semelhante,
para D, temos dois segundos.
Como B e D são
os únicos métodos que chamam C,
eles serão somados.
Agora avançaremos para a próxima árvore,
a árvore ascendente de B.
O tempo próprio é trivial: três segundos.
O tempo filho é o que foi gasto
na chamada a outros métodos,
que é C, neste caso.

Chinese: 
所以 Children Time 是0
共计6秒
将 C 扩展之后 它的调用者 B 和 D 会出现
这里的这些数字该是多少呢？
大家算对了吗？
请记住 我们在看的是 C 的 Bottom Up 树
所以 这个 Bottom Up 树中的所有时间信息
都是由 C 花费的时间
所以我们在这里计算的并不是 B 的 Self Time
而是 C 在被 B 调用时的 Self Time
也就是说 这里的用时应该是4秒
D 的情形类似 用时是2秒
B 和 D 是仅有的调用 C 的方法
所以它们加起来的值是匹配的
我们再来看下一个树
也就是 B 的 Bottom Up 树
Self Time 很简单 是3秒
Children Time 代表它调用其他方法的时间
它只调用了 C 所以是4秒

Spanish: 
Así que Children Time es cero.
Eso nos da un total de seis.
Cuando expandes C,
aparecen sus emisores, B y D.
¿Qué muestran estos números?
¿Es lo que esperaban?
¿No?
Recuerden, estamos viendo
el árbol Bottom Up de C.
Toda la información de tiempo
en ese árbol Bottom Up
es el tiempo que tarda C.
Lo que contamos aquí
no es el Self Time de B,
sino el Self Time de C cuando lo llama B
por eso tenemos
estos cuatro segundos aquí.
Y de manera similar para D,
son dos segundos.
Y como B y D son
los únicos métodos llamando a C,
debería dar la suma.
Vayamos al próximo árbol,
el árbol Bottom Up de B.
Self Time es mínimo: 
tres segundos.
Children Time es el tiempo
que pasa integrando otros métodos,
que es C.

Korean: 
따라서 Children Time은 0이에요
총 6초가 되었어요
C를 확장하면
호출자인 B와 D가 나타날 거예요
이 숫자는 무엇을 나타낼까요?
여러분이 예상했던 것인가요?
아닌가요?
지금 보고 있는 것은
C의 Bottom Up 트리라는 것을 기억하세요
이 Bottom Up 트리의
모든 시간 정보는
C가 들인 시간이에요
여기에서 세고 있는 것은
B의 Self Time이 아니라
B가 호출했을 때
C의 Self Time이고
여기가 4초라는 뜻이죠
D의 경우에도 마찬가지로
이건 2초가 됩니다
그리고 B와 D가
C를 호출하는 유일한 메서드이기 때문에
이들을 합산해야 해요
이제 다음 트리로
옮겨갑시다
B의 Bottom Up 트리예요
Self Time은 짧아요
3초군요
Children Time은
다른 메서드를 호출하는 데
들였던 시간이고
여기 있는 C입니다

Korean: 
그리고 4초입니다
Total Time은 쉬워요
항상 Self Time 더하기
Children Time입니다
완전히 확장했을 때
표의 모습은 이렇습니다
다시 말하지만 CPU Profiler가 
알아서 모두 처리할 거예요
이 숫자들을 이해하기 위해
예시를 이용하려고 합니다
Bottom Up 트리가
얼마나 유용할 수 있는가에 대한
실제 예시가 여기 있습니다
가끔 여러분은 메서드가
어떻게 호출되는지 알고 싶을 거예요
여기 있는 Nano Time 등의 경우
많은 메서드가
이것을 호출합니다
확장된 노드를
찾을 수 있는 곳에서
Bottom Up 트리를
사용하고 싶다면
호출자 목록을
살펴본 다음
관심이 가는 의심스러운
항목을 찾아보세요
기억해야 할 내용이 
너무 많죠?
계산식을
잊어버리셨어도 괜찮습니다
여러분을 위해
커닝 페이퍼를 준비했어요

Spanish: 
Esos son cuatro segundos.
Y Total es fácil.
Es siempre Self más Children.
Así se verá la tabla cuando esté
totalmente expandida.
El CPU Profiler se encargará de todo.
Estoy intentando usar este ejemplo
para encontrarle el sentido
a estos números.
Aquí tenemos un ejemplo real
de cómo un árbol Bottom Up puede ser útil.
A veces queremos encontrar
cómo se llama un método.
Para cosas como el Nano Time,
se llama con muchos métodos.
Si quieres usar
el árbol Bottom Up
donde puedas encontrar
cualquier nodo expandido,
revisa la lista de emisores,
y luego encuentra
al sospechoso en que puedas
estar interesado.
Sé que es mucha información.
Si te olvidas de las matemáticas,
no hay problema.
Aquí tenemos una hoja
de ayuda que preparé para ustedes.

Chinese: 
只需把 Self 和 Children 相加
即可得出 Total Time
这就是表格完全展开的样子
我们的 CPU Profiler 会处理好一切事情
我只是在使用这个例子来说明这些数字的含义
这是一个真实的例子 我们可以从中看到
Bottom Up 树的功能是怎样的
有时 你可能会想要知道某个方法是如何被调用的
比如这里的 nanoTime()
很多方法都调用了它
这时你就可以使用 Bottom Up 树
并从中找到任意展开的节点
查清它的调用者 并寻找你感兴趣的可疑目标
我知道 刚才这番话信息量很大
如果你忘了数学推导过程的话 没关系
我为大家准备了一个备忘单

Portuguese: 
O valor é quatro segundos.
O total é fácil.
É sempre o valor próprio somado ao filho.
A tabela ficará assim
ao ser completamente expandida.
Mais uma vez,
o CPU Profiler cuidará de tudo.
Só estou tentando usar este exemplo
para explicar esses números.
Este é um exemplo real
de como as árvores ascendentes
podem ser úteis.
Às vezes, você quer descobrir
como um método é chamado.
Para itens como o nanoTime,
chamado por muitos métodos.
Você usa a árvore ascendente,
onde é possível encontrar
qualquer nó expandido,
passa pelas listas
dos autores de chamadas
e encontra o suspeito
que possa interessar a você.
Sei que é muita informação.
Se você esquecer toda a
matemática, não tem problema.
Esta é uma folha de
referência que eu preparei.

Japanese: 
4秒になります
合計時間は
すぐにわかります
セルフ時間と子時間を
足し合わせるだけです
全ノードを展開すると
このようになります
すべて自動で計算されます
数字の意味だけ
理解してください
参考として 実際の
ボトムアップツリーの
例を見てみましょう
メソッドの呼び出し状況を
調べる場合を考えます
nanoTimeは
多くのメソッドに
呼び出されています
ボトムアップツリーで
各ノードを展開し
呼び出し元のリストを
たどっていくことで
問題のある呼び出し元を
見つけることが
できます
説明は以上です
計算方法を忘れても
問題ありません
早見表を
ご用意しています

Indonesian: 
berarti empat detik.
Mencari Total itu mudah.
Selalu Self Time ditambah Children Time.
Jadi seperti inilah tabelnya nanti
saat ditampilkan seluruhnya.
Sekali lgi, Profiler CPU
akan mengurus semuanya.
Saya menyampaikan contoh ini
hanya untuk memahami angkanya.
Berikut adalah contoh nyata
penggunaan struktur Bottom Up.
Terkadang Anda ingin 
mengetahui cara metode dipanggil.
Misalnya Nano Time di sini
dipanggil oleh banyak metode.
Jadi, gunakanlah
struktur Bottom Up
yang menampilkan node diperluas,
buka daftar pemanggilnya,
lalu cari yang Anda inginkan.
Saya tahu penjelasan
ini sangat panjang.
Jika Anda lupa
semua perhitungannya, tidak apa-apa.
Ini ada contekan
yang saya siapkan untuk Anda.

English: 
And that's four seconds.
And Total is easy.
It's always Self plus Children.
So this is what the table will
look like when fully expanded.
Again, our CPU Profiler will
take care of everything.
I'm just trying to
use this example
to make sense of these numbers.
So here's a real-world example
of how the Bottom Up trees
can be helpful.
Sometimes you want to find
how a method is called.
For things like the
Nano Time here, it's
called by many methods.
So you want to use the
Bottom Up tree where
you can find any
node expanded, go
through the list of its
callers, and then find
the suspicious one that
you may be interested in.
I know it's a lot
of information.
If you forgot about
all the math, it's OK.
Here's a cheat sheet
I prepared for you.

Spanish: 
Shukang y yo estaremos
en Android Studio Sandbox después de esto.
Si tienen alguna pregunta,
podrán encontrarnos ahí,
en el segundo piso.
Muchas gracias.
[MÚSICA SONANDO]

Portuguese: 
Eu e o Shukang estaremos
no sandbox do Android Studio.
Caso você tenha dúvidas,
fale com a gente no sandbox,
no segundo andar.
Muito obrigado!

Indonesian: 
Saya dan Shukang akan berada di
Android Studio Sandbox setelah ini.
Jika ada pertanyaan,
temui kami di Sandbox di lantai dua.
Terima kasih banyak.

English: 
So Shukang and I will be at
the Android Studio Sandbox
after this.
If you have any
questions, find us
at the Sandbox on
the second floor.
Thank you very much.
[MUSIC PLAYING]

Korean: 
슈강과 저는
이 시간 후에
Android 스튜디오
샌드박스에 있을 거예요
질문이 있으시면
2층에 있는
샌드박스에서 저희를
찾아주세요
대단히 감사합니다
[음악 재생중]

Chinese: 
Shukang 和我会在 Android Studio 互动体验区等着大家
欢迎大家前往2楼体验区找到我们并提问 非常感谢

Japanese: 
この後 私たちは
Sandboxにいますので
ご質問や不明点がある方は
2階の
Sandboxに
お越しください
ありがとうございました
