最近遇到一个内存泄露, 代码非常简单 :
先打开一个 FragmentA, 然后通过 replace 替换成 FragmentB, 并且加入回退栈, 因为 FragmentB 关闭后还要回到 FragmentA. 伪代码如下
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
FragmentA fragmentA = new FragmentA();
replaceFragment(R.id.frame, fragmentA);
}
//replaceFragment 并加入回退栈
public void replaceFragment(int containerID, Fragment fragment) {
FragmentManager fm = getSupportFragmentManager();
FragmentTransaction transaction = fm.beginTransaction();
transaction.replace(containerID, fragment);
transaction.addToBackStack(null);
transaction.commit();
}
}
public class FragmentA extends Fragment {
private Button mButton;
@Nullable
@Override
public View onCreateView(@NonNull LayoutInflater inflater, @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
View view = inflater.inflate(R.layout.fragmenta, container, false);
mButton = view.findViewById(R.id.btn_a);
mButton.setText(MessageFormat.format("{0}{1}", mButton.getText().toString(), getArguments().getInt("index")));
return view;
}
@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
//将 FragmentA 替换成 FragmentB,并且加入回退栈
mButton.setOnClickListener(v -> {
if (getActivity() != null) {
FragmentB fragmentB = new FragmentB();
((MainActivity) getActivity()).replaceFragment(R.id.frame, fragmentB);
}
});
}
}
这时 LeakCanary 会提示发生了内存泄露 :
├─ androidx.appcompat.widget.AppCompatButton
│ Leaking: YES (View detached and has parent)
│ mContext instance of com.james.myapplication.MainActivity with mDestroyed = false
│ View#mParent is set
│ View#mAttachInfo is null (view detached)
│ View.mWindowAttachCount = 1
│ ↓ AppCompatButton.mParent
╰→ androidx.constraintlayout.widget.ConstraintLayout
Leaking: YES (AppCompatButton↑ is leaking and ObjectWatcher was watching this)
mContext instance of com.james.myapplication.MainActivity with mDestroyed = false
View#mParent is null
View#mAttachInfo is null (view detached)
View.mWindowAttachCount = 1
key = b1205e98-e894-4cd1-a702-ef2f06a55ab9
watchDurationMillis = 6853
retainedDurationMillis = 1848
key = ca1cfff1-c424-4273-b6fb-90f9e3d44c96
通过 view detahced and has parent提示, FragmentA 中的 mButton 引起了泄露.
分析
参考官方的生命周期图, Fragment 的生命周期
- 直接Replace : onDestroyView() -- onDestroy() -- onDetach()
- Replace 并且 addToBackStack : onDestroyView()
后者的 Fragment 只是视图被销毁了, 实例没有被销毁, 在使用回退栈回退后, 会重新通过 onCreateView 创建一个新的视图.
这就意味着, 在 onDestroyView() 之后, 当前的视图View已经没有任何价值, 在源码里也做了处理 f.mView = null
f.mContainer = null;
f.mView = null;
// Set here to ensure that Observers are called after
// the Fragment's view is set to null
f.mViewLifecycleOwner = null;
f.mViewLifecycleOwnerLiveData.setValue(null);
f.mInnerView = null;
f.mInLayout = false;
然而此时 Fragment 实例 f 是没有被销毁的, 我们自己 findViewById 查找的 View 是可以作为成员变量保存的.
打开AS的profiler, dump内存后, 证实了 mButton 不为null, 并且通过 mParent 持有了父布局的引用. (Fragment$1是 mButton 持有的clickListener内部类.)
显然, 此时的 mButton 应当被回收, 因为下次进入页面还会通过 onCreateView() 查找一个新的 mButton. 我们手动把引用置为null.
FragmentA.java
@Override
public void onDestroyView() {
super.onDestroyView();
mButton = null; //置为null
}
再次进行以下操作 :
- replace FragmentA()
- replace FragmentB() 并加入回退栈
此时leakCanary无泄漏提示. dump内存, mButton = null , 并且此时 mButton 持有的内部类 clickListener 也被回收了.
有人会说, Fragment 对象并没有销毁, 即使在 onDestroyView() 之后 view 依然占用内存, 在 onDestroy() 时依然能被正确回收. 但是 onDestroyView 到 onDestroy 这段时间内, view 的存在会使得onDestroyView()行为失效.
因为在下次 onCreateView 时, view又会被分配新的内存. 当前的 View 的生命周期已经结束了, 应当被立即回收掉.
另一种常见的情况是 ViewPager 使用 FragmentPagerAdapter 时.
FragmentPagerAdapter
使用 FragmentPagerAdapter 时超过缓存 pageLimit 的 Fragment 会进行 FragmentTransaction.detach()。此时 Fragment 的实例同样没有被销毁. 当页面数量很多时, 即使超出 pageLimit 的 Fragment 中, view 也会占用大量的内存.
public class ViewPagerTest extends AppCompatActivity {
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_viewpager);
ViewPager viewPager = findViewById(R.id.viewpager);
List<Fragment> fragments = new ArrayList<>();
fragments.add(FragmentA.newInstance(0));
fragments.add(FragmentA.newInstance(1));
fragments.add(FragmentA.newInstance(2));
fragments.add(FragmentA.newInstance(3));
fragments.add(FragmentA.newInstance(4));
//在使用FragmentPagerAdapter的情况下, 超出 pageLimit 的Fragment只会走onDestroyView(), 也就是实例仍然存在于内存中
//此时Fragment如果有View的强引用, 仍然会继续占有内存
viewPager.setOffscreenPageLimit(1);
viewPager.setAdapter(new FragmentPagerAdapter(getSupportFragmentManager()) {
@NonNull
@Override
public Fragment getItem(int position) {
return fragments.get(position);
}
@Override
public int getCount() {
return fragments.size();
}
});
}
}
同样, 我们在 onDestroyView() 中把使用到的 View 手动置为 null , 这在图片较多的 ViewPager 中尤其明显, 能节约大量内存.
框架中的处理
1. SDK中ListFragment中的处理
SDK 中的 ListFragment 中, 也在 OnDestroyView 时手动把使用到的View置空.
ListAdapter mAdapter;
ListView mList;
View mEmptyView;
TextView mStandardEmptyView;
View mProgressContainer;
View mListContainer;
CharSequence mEmptyText;
boolean mListShown;
/**
* Detach from list view.
*/
@Override
public void onDestroyView() {
mHandler.removeCallbacks(mRequestFocus);
mList = null;
mListShown = false;
mEmptyView = mProgressContainer = mListContainer = null;
mStandardEmptyView = null;
super.onDestroyView();
}
2. ButterKnife中的处理
ButterKnife 提供了一个 unBind() 方法, 供我们在 Fragment#onDestroyView() 时调用.
查看apt生成的 XX_ViewBinding 文件的 unBind() 方法
public class FragmentA_ViewBinding implements Unbinder {
private FragmentA target;
@UiThread
public FragmentA_ViewBinding(FragmentA target, View source) {
this.target = target;
target.editText = Utils.findRequiredViewAsType(source, R.id.et, "field 'editText'", EditText.class);
}
@Override
@CallSuper
public void unbind() {
FragmentA target = this.target;
if (target == null) throw new IllegalStateException("Bindings already cleared.");
this.target = null;
target.editText = null;
}
}
You only need to call
unbind()in fragments inonDestroyViewbecause it can cause a leak if the fragment is re-used. For activities you do not need to call the method because the references form a cycle which will be correctly GC'd.
3. Kotlin Android Extention中的处理
同样, 在 onDestroyView() 的时候清空保存 view 的容器.
// $FF: synthetic method
public void onDestroyView() {
super.onDestroyView();
this._$_clearFindViewByIdCache();
}
总结:
通常的内存泄露都是对象由于被强引用指向导致不能回收, 在安卓中最多的就是 Activity, Fragment 关闭时出现的泄露. 移动开发中内存比较吃紧, 频繁使用的对象要做持久化缓存, 超出生命周期的对象应当及时回收.
在上面的场景中, Fragment 并没有销毁, 只是因为 view 超出了他应当存在的生命周期(因为在onCreateView中会被重新分配), 在 onDestroyView() 后他仍然存在, LeakCanry 也把这种判定为内存泄露.
