Android：抽象自定义视图和通用布局膨胀

Question

abstract class Foo @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyleAttr: Int = 0
) : FrameLayout(context, attrs, defStyleAttr) {

    private val myView: View

    init {
        // todo@patches fix leaking "this"
        View.inflate(context, R.layout.view_foo, this)
        myView = requireNotNull(findViewById(R.id.my_view))
    }
}

class Bar @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyleAttr: Int = 0
) : Foo(context, attrs, defStyleAttr) 

还有人觉得这有点令人沮丧或有什么建议吗？从基类中膨胀相同的布局似乎并不罕见。

Answer 1

在构造函数中泄漏此是危险的，因为您泄漏到的对象可能在构造函数完成之前就开始访问其成员，因此它可能还没有准备好。即使对于不可空的Kotlin属性或其他奇怪的行为，也可以获得NPEs。

对于layoutinflator.inflate，这似乎不是一个问题，因为Android的内置视图经常将这个作为inflate()方法的父级传递给inflate()。例如，DatePicker的构造函数实例化一个DatePickerSpinnerDelegate，它将该DatePicker实例传递给invlate()，所有这些都发生在DatePicker的构造函数返回之前。

当您将视图作为父视图传递给invulate()时，通过遵循调用链，我看到父视图发生了两件事。它对父级调用getcontext()，如果addtoroot为true，则对父级调用addview()。因此，我认为泄漏这个是安全的，只要您不重写addview()来执行额外的工作，这些工作依赖于调用invalate（）后设置的成员。但是addview()也在内部调用requestlayout()和invalidate()`，所以同样的问题也适用于它们。

在大多数情况下，您的自定义ViewGroup将是现有Android ViewGroup类的子类，因此您不需要重写这些方法。

不幸的是，我们只能通过检查代码来推断这种行为。文档没有保证它是安全的，这并不令人放心，但据我所知，我们只能接受它可能是安全的。也许应该在AOSP上打开一个问题。如果您用Java编写相同的代码，甚至不会出现此警告，但风险是相同的。

禁止警告并不意味着您忽略了警告或只是在代码上进行黑客攻击。它的意思是，“我承认失败模式，并已经检查了我的代码不会以这种方式失败。”如果不是这样，那将是编译器错误，而不是警告。在Kotlin中，可以使用的抑制注释是@suppress（“leakingthis”）。