How to fix leakcanary report leakcanary ? 1.5 megabyte leakage. A photo:

enter image description here enter image description here

mainView - link to the ClickListener activation interface in the adapter:

 private class OnItemClickListener implements View.OnClickListener { private String songId; private OnItemClickListener(String songId) { this.songId = songId; } @Override public void onClick(View view) { mainView.showSelectedSong(songId, listPhotoLoaded); } }

ClickListener one of View:

 private class OnItemToneClickListener implements View.OnClickListener { private int clickPosition; private OnItemToneClickListener(int clickPosition) { this.clickPosition = clickPosition; } @Override public void onClick(View view) { if (clickPosition != currentCheckedRadioButton) { radioButtonsTones.get(currentCheckedRadioButton).setChecked(false); radioButtonsTones.get(clickPosition).setChecked(true); currentCheckedRadioButton = clickPosition; } } }

Listener by clicking favorites:

 @OnClick(R.id.imageButtonFavorite) void favoriteClick() { currentSongPresenter.setFavoriteState(); }

Still:

 @Override public void showFavoriteDialog(boolean addFavorite) { final Dialog dialog = new Dialog(mainActivity); if (addFavorite) { dialog.setContentView(R.layout.dialog_favorite_add); } else { dialog.setContentView(R.layout.dialog_favorite_delete); } dialog.findViewById(R.id.parentLayout).setOnClickListener(v -> dialog.dismiss()); dialog.show(); final Handler handler = new Handler(); handler.postDelayed(dialog::dismiss, 3000); setFavoriteImageState(addFavorite); }
  • one
    Attach a photo to the question, not the link - Vladimir Parfenov
  • @VladimirParfenov Very long photo, for this I made a link - iamtihonov
  • It is necessary to break into 2 photos, compress so that they do not weigh several megabytes and apply. We must respect the rules of registration. - Vladimir Parfenov
  • So it is not clear. It is necessary to analyze the memory dump and watch the code completely. Try in the studio to do all the actions that lead to a leak, then call GC, and then immediately take a dump and look there in the dump - Vladimir Parfenov

2 answers 2

It's simple: the bottom line says that the CurrentSongFragment hangs in memory,
The line above indicates where the link holding it is created.
A quick look at the stack and this is what we see.
In the CurrentBaseFragment class CurrentBaseFragment you hang a handler on a button in the toolbar, in the code of which you refer to the fragment instance (most likely implicitly - refer to fields and methods). But the toolbar lives longer than the fragment and keeps it in memory by reference to the button handler.

    Judging by the chain, the sDefaultWindowManager link contains direct and / or indirect references to the Context . Memory leaks occur because references are stored (in this case, indirect) on the Context in a static field.

    Arrange the code so that sDefaultWindowManager not static and the leak should disappear.

    • Links I do not have sDefaultWindowManager - iamtihonov
    • Do you support screen rotation? Can you send the code, where you hang up the clicker in CurrentSongFragment? - Vladimir Parfenov
    • Rotate do not support. Added touch processing. - iamtihonov