序文
この一連の記事：
1、理解しやすい説明として、技術の実用的な値説明により
2、詳細に記述されたソースの追跡、ソースコードの構成図ショットを、クラスを描く、詳細に探査法の原則を説明しようと
3をGitHubのを実行することができます提供デモプロジェクトが、私は適切で、CVとして、、より多くのアイデアを提供し、より良いアイデアをコードしてください提供してきた
4、いくつかのピットを探索する過程で一連の原則を終え、またはデモで動作中の注意事項
5、最も直感的とGIFマップ業績は、デモを表示します
あなたは詳細が薄すぎると思われる場合は、結論を見てスキップすることができます。限られた容量は、説明が不適切、歓迎メッセージの批判を見つけなければなりません。
そして、古い、長い道路補修に生きることを学ぶはるかに来ます。そして、手動で面白いCVエンジニアとして私との相互励まし！のすべての王も、
ボディ概要
- JVMのメモリ管理の知識
- ジッタメモリの検出と処理
- そして、処理メモリリーク検出
テキスト
JVMのメモリ管理の知識
LMK（LowMemoryKill）機構システムがメモリを使い果たしたときにアンドロイド底は、他のプロセスのメモリのニーズを満たすためにいくつかのプロセスを殺すために、特定の規則によれば、あろう。どのレベルの指標であるので、アプリのメモリフットプリントの最適化、効果的に殺されたアプリのシステムであることの確率を減らすことができ、メモリを消費します。
GC STW機構 GC、ガベージコレクションプロセスは、時にGCタスク実行スレッドの時間があるでしょうSTW (stop the world)メカニズム、彼は他のすべてのスレッドが中断されて配置されます。場合はGC非常に頻繁に呼び出し、それがメインスレッドにつながるユーザーに感じているカトンを与え、滑らかされていません。
メモリー・ジッタ多い原因OOMのメモリジッタがあまりにも頻繁に、頻繁に作成され、破壊された多数のオブジェクトで、その結果、大きなオブジェクトのメモリを適用する必要がある場合は、この時点で、につながる、失敗適用することが可能である、連続したメモリ空間を大量に生産することができないOOMメモリオーバーフロー
文説明メモリリーク長いとオブジェクトへの強い参照の短いライフサイクルに保持されたオブジェクトのライフサイクルは、それを回収すること、リサイクルされたオブジェクトの短いライフサイクルの時に漏れとみなすことができない見出さ
GC回復到達可能性分析
、オブジェクトが回収されているか否かを判断することができるGCスレッドを算出した到達可能性解析アルゴリズム、であるGcRootからGcRoot検索ダウンは、GcRootオブジェクト全体を直接ガベージコレクションとは関係ありません。
4つの仮想強い弱い参照言わず強いと想像。最も一般的に強いが、特別な治療法はありません（匿名内部クラスが外部クラスへの強い参照を保持します含む）強参照されています。役に立たないファントム参照は、議論されることはありません。ソフト参照、だけでなく、いくつかの使用を定義するために、そのオブジェクトを持っていない、使用することは、SoftRefrence<T>GCは、使用後のリサイクル、メモリストレスの多い時間に、修正しましたSoftRefrence<T>十分なシステムメモリがあれば、オブジェクトの変更は、その後、関連するソフト参照が回収されることはありません、利用可能です。不十分な場合は、関連するオブジェクト参照のソフト回復。弱参照（WeakRefrence<T>）、限り、弱参照に関連付けられたGCトリガオブジェクトが回収されるように、軟らかい基準数よりも弱いです。
注：使用して、軟質および弱参照は、関連するオブジェクトが空であるかどうかを決定します。
ジッタ検出と治療メモリの
我々の使用の発展、我々は通常、アプリを実行し、通常のポイントRunAppが、別の選択肢は、そこにあるprofileApp、あなたがアプリケーションを実行した後などは、プロファイルの下に表示されます、としてそれは、ウィンドウプロファイルの下部にクリックしたときに表示されます図は、ネットワーク内のメモリおよびCPUの使用を表示しました
フィギュアシェイクのメモリは、このようなECGとして、非常に明白である場合：
それは治療の緊急の必要性におけるジッタの非常に明確なメモリがあることを示しています。メモリのグラフィックス領域をクリックした後、あなたは、詳細なメモリの変化、およびメモリの割り当てを見ることができます：
ここでのピットは、次のとおりです。
あなたはトレンドメモリを滑らかに描画し、その誇張ジッタフィギュアの完全なシミュレーションに表示されないから見れば、何のメモリジッタはそれではないんですが？そうではありません。メモリの場合は私たちのGCは、アプリが取る場合は、メモリを解放するために使用できなくなりますので、メモリは比較的小さかった、臨界値GCには触れませんでした、そして、彼らは崖スタイルのダウンを表示されません。これは、メモリを観察しないようにジッタは、どのようにそれを行うには？
解决方法 在8.0以下的安卓手机上，在下方的位置上会出现一个Record按钮(如果是8.0以上，你可以直接用拖拽的方式来截取一段内存record)：
点击它，一段时间之后，再点一下：你就能在下方发现一张表格：
这张表格代表的是，你Record这段时间之内创建的对象,点击一下第二列 Allocations,对创建的数量进行排序，找出创建次数最多的对象:
然后，点击排行第一的String之后，会在右方看到
然后点击其中的一个，又会看到一个新的窗口:
此为止，就找到了 创建对象 的 元凶，以这个为线索，找到你们自己包名下的类和方法，确定是我们自己的代码在不合理地创建对象.
再往后，就是根据各自的业务代码去做优化了，记住一个宗旨：不要让代码干多余的事。 如果是我们调用了系统的api导致了不合理地大量对象的创建，那么就要考虑这个系统API为什么会这样创建对象，有没有其他方法避免吗，从业务代码层来合理使用这个api，实在不行再考虑自定义api或者换个系统api。
在我们做了一次优化之后，再profile运行一次app，再重复上面的过程。以此类推，直到内存抖动达到理想状态。
总结
优化内存抖动，核心就是防止频繁创建对象。常见的反面教材就是：循环中创建对象，大量调用的api中创建对象。而优化的主要手段，就是对象复用，常见的手段是：对象池，像是 Handler的Message 单链表池，Glide的bitmap池等。
检测以及处理内存泄漏
经典案例： 处理 handler异步任务导致的内存泄漏方法
- 在Activity的
onDestroy中移除所有的任务@Override protected void onDestroy() { super.onDestroy(); handler.removeCallbacksAndMessages(null);//移除所有任务 } - 使用静态内部类 + Activity弱引用的方式
MyHandler handler = new MyHandler(this); private static class MyHandler extends Handler { WeakReference<Activity> activityWeakReference; MyHandler(Activity activity) { activityWeakReference = new WeakReference<>(activity); } @Override public void handleMessage(Message msg) { //在执行任务的时候，判断弱引用所关联的对象是否为空，能在对象已经被回收的情况下 switch (msg.what) { case 1: if (activityWeakReference.get() !=null) { //T0D0 } } } }
工具的使用
依然是 profileApp,先用 profile看出内存的变化情况。
问：如何判断内存泄漏？
答：内存泄漏是精细功夫，不能全盘观察，只能凭借profile的内存变化来推测。比如，打开app之后内存一路飙升，直到超出app能够使用的最大内存，app崩溃,，这是最明显的。又比如，你反复打开关闭某一个界面，发现内存的稳定线( 内存稳定之后，内存占用值)随着每一次的打开关闭，都在提高，这说明，这一个界面上存在泄漏，有对象无法被回收。
上一章节使用 profile 最多是了解到 哪些对象的创建和回收引起了内存抖动，但是，涉及到泄漏，只通过profile尚且 不能知道是 哪个类持有了希望被回收的对象的强引用. 这里就要借助另外一款工具,他的名字叫做 EclipseMat (自行百度)
先回到刚才的 profile
点一下，然后再点一下，界面会自动跳转：
点击上面的保存按钮，将文件存到本地;
然后：
但是这个文件是无法直接在mat打开的
找到SDK目录下的要 hprof-conv.exe：
使用cmd命令，对文件进行转换，命令为：hprof-conv[源文件名][目标文件名]如 hprof-conv1.hprof2.hprof回车
将得到的 2.hprof利用刚才下载的Mat工具打开：
这里有很多指标，但是检查内存泄漏，我们只需要关注这个直方图按钮即可：
这个图中会列出你dump的这一段内存中的所有对象，包括framework层的，也包括我们自己代码创建的对象
案例模拟
我模拟了一个经典案例，也就是前面提到的 Handler延时任务导致 Activity不能被释放，核心代码如下
public class SecondActivity extends AppComatActivity {
Handler handler = new Handler();
//创建一个强引用Activity的handler对象
@Override
protected void onCreate (Bundle savedInstancestate) {
super.onCreate(saveInstanceState);
setContentView(R.layout.activity_second);
handler.postDelayed(new Runnable() {
@Override
public void run() {
}
}, Integer.MAX_VALUE);
//我让任务永远在这里
}我就用一个非常普通的方式创建了一个 handler对象，并且用它来执行一段延时任务，只不过，延时任务的延时时间是 Integer的最大值，也就是说，任务要很久以后才会执行。之后，我反复进出这一个 Activity，然后按照上面的方式 dump了一段 hprof，经过 hprof-conv 转化，然后用 Mat打开：结果如下
我填写过滤信息: SecondActivity 回车
在我们最终退出SecondActivity之后，内存中依然保留了 18个无用的对象。
那么是不是我们这18个都是泄漏的呢？
不一定
前文讲过，只有不合理的强引用，才会导致内存泄漏，所以我们要按照上面的方式排除软弱虚引用。之后我们能看到下面的界面,把能展开的信息尽数展开
了解 Handler源码的同志们应该一眼就看明白了， handler引起了内存泄漏，是因为存在不合理地强引用链， 上图中可以看出，最终是callback对象持有了 SecondActivity对象。
如何优化内存泄漏
我们刚才已经看到了Handler的不合理使用导致了内存泄漏，那么如果在 onDestroy中移除所有的任务
@Override
protected void onDestroy() {
super.onDestroy();
handler.removeCallbacksAndMessages(token.null):
}
}执行同样的任务，dump下来的hprof 在mat触发了GC之后， SecondActivity数量变为了0，内存泄漏解决。
当然还有另一种做法，静态内部类+弱引用。
ps： 静态内部类是为了防止内部类持有外部类的引用，弱引用是为了在
GC触发之时，回收掉WeakRefrence中的对象。public class secondActivity extends AppCompatActivity { Handler handler = new Handler(): @Override protected void onCreate(Bundle saveInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_second)； handler.postDelayed(runnable, Integer.MAX_VALUE); //依旧是那个延时很久的任务 } Runnable runnable = new MyRunnable(this); private static class MyRunnable implements Runnable { //静态内部类 WeakReference<activity> activityWeakReference //弱引用 MyRunnable(Activity activity) { activityWeakReference = new WeakReference<>(activity); } @Override public void run() { } }
但是排除之后，一个都没有了。
小技巧
多くのページがリークのトラブルシューティングを行う必要がある場合は、上記の手順は、実現可能な一方で、しかし、我々は、全体のプロセスは非常に長く不快になります閉じたページを開くには、ポイントを行きます。実際には、解決策があります。バックの前にヒストグラム：
あなたが操作をしたい場合は、各操作の前と後のあなたはダンプ：使用であるhprof前と後に命名をし、その後hprof-conv、それを変換する前に`の後と ，用のEclipse MATを同时打开这两个文件，然后切换到クリックして、after.hprof`上記のボタン画像
それはあなたが、比較したいファイルを選択する前に、次に濾過し、クリックできるようになるSecondActivity
処理の前に漏れることがあり、このように、トラブルシューティングコード領域と前が漏洩する可能性。私たちの最適化の作業を簡素化します。
エピローグ
メモリリークとJVMは、私が以前に記載されたポイントに加えて、多くの知識を必要とするジッタを最適化するには、特徴点がたくさんあります。メモリの最適化を行うには、JVMは、確かな知識ベースを必要とします。