【译】Android泄漏模式：View中的订阅
【译】Android泄漏模式：View中的订阅
- 原文链接： Android leak pattern: subscriptions in views
- 原文出自： Pierre-Yves Ricau
- 译文出自： 小鄧子的简书
- 译者： 小鄧子
- 状态： 完成
我们通过一些自定义的view来构建Square register模块。有时候这些view需要监听一个比他们自身声明周期还要长的对象。
例如，一个HeaderView(译者注:类似于头像控件)可能需要监听用户名的改变，而这个用户名来自于一个Authentic单例。
public class HeaderView extends FrameLayout {
private final Authenticator authenticator;
public HeaderView(Context context, AttributeSet attrs) {...}
@Override protected void onFinishInflate() {
final TextView usernameView = (TextView) findViewById(R.id.username);
authenticator.username().subscribe(new Action1<String>() {
@Override public void call(String username) {
usernameView.setText(username);
}
});
}
}onFinishInflate()是一个用来填充自定义view，并试图找到其子view的绝佳时机。所以我们决定在这个地方处理绑定视图的逻辑，并订阅用户名的变化。
上面的代码存在一个非常严重的bug：没有解除订阅。当尝试回收view时，Action1始终处于订阅状态。因为Action1是一个匿名内部类，它持有外部类的引用，也就是持有对HeaderView的引用。现在整个视图层级结构都发生了泄露，无法被回收。
修复这个bug，我们可以在view从window中分离的时候取消订阅：
public class HeaderView extends FrameLayout {
private final Authenticator authenticator;
private Subscription usernameSubscription;
public HeaderView(Context context, AttributeSet attrs) {...}
@Override protected void onFinishInflate() {
final TextView usernameView = (TextView) findViewById(R.id.username);
usernameSubscription = authenticator.username().subscribe(new Action1<String>() {
@Override public void call(String username) {...}
});
}
@Override protected void onDetachedFromWindow() {
super.onDetachedFromWindow();
usernameSubscription.unsubscribe();
}
}问题被修复了吗？不完全是！我最近看了LeakCanary的报告，由一段类似代码所引发的内存泄露：
让我们再看一遍代码：
public class HeaderView extends FrameLayout {
private final Authenticator authenticator;
private Subscription usernameSubscription;
public HeaderView(Context context, AttributeSet attrs) {...}
@Override protected void onFinishInflate() {...}
@Override protected void onDetachedFromWindow() {
super.onDetachedFromWindow();
usernameSubscription.unsubscribe();
}
}不知为什么View.onDetachedFromWindow()没有被调用，这就是造成泄露的原因。
在调试的过程中，我发现View.onAttachedToWindow()同样没有被调用。如果一个View没有被Attach过，那么理所应当的也不会发生Detach。所以，View.onFinishInflate()被调用了，而View.onAttachedToWindow()则没有。
让我们多了解一些这个View.onAttachedToWindow()：
- 当view被添加到一个已经加载到window的父view中时，
addView()的内部会立即调用onAttachedToWindow()。 - 当View被添加到一个还没有加载至window的父view中时，
onAttachedToWindow()将会在父view被加载到window后执行。
我们用Android中的惯用方式来填充view层级：
public class MyActivity {
@Override protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.my_activity);
}
}这时，视图层级中的每一个view都会收到View.onFinishInflate()的回调通知，而不是View.onAttachedToWindow()，而原因是：
View.onAttachedToWindow()只在第一次view遍历时被调用，将发生在Activity.onStart()之后。
<u>ViewRootImpl</u>执行了onAttachedToWindow()的分发操作：
public class ViewRootImpl {
private void performTraversals() {
// ...
if (mFirst) {
host.dispatchAttachedToWindow(mAttachInfo, 0);
}
// ...
}
}所以说，我们不能在onCreated()中得到Attach结果，那么在onStart()之后就一定能吗？它总是在onCreated()之后被调用吗？
不一定！<u>Activity.onCreate()</u>的文档给出了答案：
你可以在这个函数内直接调用
finish()，这种情况下onDestroy()会被立即调用，那么将不再执行剩余的生命周期回调(onStart(),onResume(),onPause()等等）。
我终于顿悟了！
我们在onCreated()中判断intent，如果intent的内容失效了，则立即调用finish()并返回一个代表错误信息的结果。
public class MyActivity {
@Override protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.my_activity);
if (!intentValid(getIntent()) {
setResult(Activity.RESULT_CANCELED, null);
finish();
}
}
}虽然整个层级视图都被填充了，但是Attach至window还没有发生，因此Detach的动作也不会发生。
那么根据这种情况，这里有一张更新后的Activity生命周期图表：
因此，有了这些认识之后，我们应该将订阅的代码移至onAttachedToWindow()中：
public class HeaderView extends FrameLayout {
private final Authenticator authenticator;
private Subscription usernameSubscription;
public HeaderView(Context context, AttributeSet attrs) {...}
@Override protected void onAttachedToWindow() {
final TextView usernameView = (TextView) findViewById(R.id.username);
usernameSubscription = authenticator.username().subscribe(new Action1<String>() {
@Override public void call(String username) {...}
});
}
@Override protected void onDetachedFromWindow() {
super.onDetachedFromWindow();
usernameSubscription.unsubscribe();
}
}这是为了更好的解决问题：保证对称访问是好的。与之前的实现方式不同，现在我们可以任意次数的添加或者移除那个view了。