Kotlin干掉了findViewById，但用不好也会有性能问题

击上方的终端研发部，右上角选择“设为星标”

每日早9点半，技术文章准时送上

公众号后台回复“学习”，获取作者独家秘制精品资料

往期文章

5G时代，程序员会失业还是会继续吃香？

刚好在搞测试规范，顺便谈谈单元测试...

是时候摒弃掉Notepad++ ，因为你还有更多的选择...

浅谈：聊聊“全栈工程师”

程序员：待过头条、阿里和微软，只想说微软是世界上最好的公司

转载自：承香墨影

一.前言

自从 Google 宣布 Kotlin 为 Android 一等公民的身份后，大量的 Android 开发开始接触和使用 Kotlin，也体会到 Kotlin 在编码过程中的便捷和高效。

在 Kotlin 中，有个非常便捷的特性，就是无需再使用 findViewById() 方法，Kotlin 可以直接通过 View 的 ID 来访问 View 并进行操作，该特性被称为「静态布局引入」。

findViewById() 这个方法，会通过遍历 View Tree 的方式，来找到我们指定 ID 的 View，正因为如此，该方法被认定为是一个「较重」的方法。在一些需要后续变动的 View，都会使用一个变量将 View 存起来，就是为了避免每次都调用findViewById()。

这一切在 Kotlin 中就被简化了，只需要利用 View ID 就可以直接访问到这个 View。如果你对其原理有所了解，应该知道它其实是使用了「懒加载」，并不是每次调用 View ID，Kotlin 都帮我们去自动 findViewById()，而是用时获取，取到后就缓存下来，方便下次再用。

看似没有任何问题，我们可以放心使用，但是实际上还有一些场景，可能会导致频繁的调用 findViewById()，引发效率问题。

本文就这个问题，展开讨论 Kotlin 通过 View ID 访问 View 的原理，以及频繁调用 findViewById() 的问题。

二. Kotlin 干掉了 findViewById

2.1 如何使用？

想使用这个特性，还需要一些简单的配置，不过在 Android Studio 中，我们支持 Kotlin 的时候就已经自动配置完成。

如果无法使用，可以检查在 build.gradle 中是否添加了 extensions。

apply plugin:'kotlin-android-extensions'

之后在访问的 Activity 或者 Fragment 中，还需要对布局进行 import，通常我们在首次使用该布局下的「View ID」访问 View 时，Android Studio 就会给我们提示需要 import 布局。总之，跟着 AS 的提示走。

例如我们在布局中有一个 TextView。

<TextView
    android:id="@+id/tvName"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content" />

此时我们可以直接在 Activity 中通过 View ID 访问它，注意 import Layout。

import kotlinx.android.synthetic.main.act_findview_layout.*

class FindViewActivity:FragmentActivity(){
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.act_findview_layout)
    tvName.text = "承香墨影（ID:cxmyDev）"
    tvName.setOnClickListener {}
  }
}

省去了大段重复的 findViewById() 代码，非常的方便，而且不存在性能问题。

以前在 Kotlin 写法还很混乱的时候，我甚至看到过这样的代码。

val mTvName by lazy { tvName }
// or
val nTvName2 by lazy { findViewById(R.id.tvName) as TextView }

但是不得不说，在这里使用 「by lazy」是完全没有必要的，正如前面说到的，Kotlin 的静态布局引入特性，其原理已经帮我们实现了类似「懒加载」的效果。

此特性在 Activity 和 Fragment 中的实现还略微有些差异，接下来具体看看。

2.2 在 Activity 中的实现

我们知道，无论 Kotlin 干了什么，最好的办法是直接查看 Bytecode 来分析其原理。

正好 AS 也提供了非常好的转换工具，Tools → Kotlin → Show Kotlin Bytecode，再点击 Decompole，就可以得到我们熟悉的 Java 代码了。

就前面举例的 Kotlin 代码，可以看到它的产物。

private HashMap _$_findViewCache;
protected void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    this.setContentView(2130968608);
    TextView var10000 = (TextView)this._$_findCachedViewById(id.tvName);
    Intrinsics.checkExpressionValueIsNotNull(var10000, "tvName");
    var10000.setText((CharSequence)"承香墨影（ID:cxmyDev）");
}
public View _$_findCachedViewById(int var1) {
    if (this._$_findViewCache == null) {
    this._$_findViewCache = new HashMap();
    }

    View var2 = (View)this._$_findViewCache.get(var1);
    if (var2 == null) {
        var2 = this.findViewById(var1);
        this._$_findViewCache.put(var1, var2);
    }
    return var2;
}

可以看到这里最关键的就是 _$_findCachedViewById() 方法，在其内利用一个 HashMap 结构，存储我们使用过的 View，避免重复的调用 findViewById() 方法。

这很简单，没什么好说的。

2.3 在 Fragment 中的实现

在 Fragment 当然也可以这么使用，但是有稍许不同。

override fun onCreateView(/**...*/): View? {
  val view = inflater.inflate(R.layout.act_findview_layout,container,false)
  tvName.text = "承香墨影（ID:cxmyDev）"
  return view;
}

在 Fragment 中需要利用 onCreateView() 方法设置布局，但是此时我们并不能直接去操作 View，上面是一个错误的示例，它会报错。

原因在于 Fragment 生成的 _$_findCachedViewById() 方法，使用的是getView().findViewById()，在 onCreateView() 中获取 getView() 会返回 null，导致获取控件失败。

public View _$_findCachedViewById(int var1) {
    if (this._$_findViewCache == null) {
        this._$_findViewCache = new HashMap();
    }

    View var2 = (View)this._$_findViewCache.get(var1);
    if (var2 == null) {
        View var10000 = this.getView(); // 注意此处
        if (var10000 == null) {
            return null;
        }

        var2 = var10000.findViewById(var1);
        this._$_findViewCache.put(var1, var2);
    }

    return var2;
}

这也很好解决，问题就是 getView() 拿空了，那把逻辑换到 View 被创建之后就好了， onViewCreated() 是一个不错的时机，逻辑很简单，就不再给出代码示例了。

2.4 问题隐患

到这里基本上都是优势，好用且高效。但是 Kotlin 在提供了高效的编码体验的同时，也隐藏了一些问题。

我们知道 Android 的布局就是一个大的 View Tree，而在 Kotlin 下，我们可以利用父 View，通过「.」操作符，直接访问到该父 View 的子 View。这一步，也不需要显式的调用 findViewById()。

这有什么用呢？

例如在 Fragment 的 onCreateView() 中，一定不能操作布局内的控件吗？并不是，借助 inflate 的 View 对象就可以做到。

view.tvName.text = "承香墨影（ID:cxmyDev）"

好像这也不是必须的，那再换个场景。

一个布局文件中，通过 include 引入了多个重复的布局，我们就无法再通过 View ID 访问到它们了，必须通过 include 布局的根布局 View 来间接访问到它们。

总有一些场景，需要我们这么使用它，那它到底存在什么问题呢？

@Nullable
public View onCreateView(//**...*/) {
  Intrinsics.checkParameterIsNotNull(inflater, "inflater");
  View view = inflater.inflate(2130968608, container, false);
  Intrinsics.checkExpressionValueIsNotNull(view, "view");
  TextView var10000 = (TextView)view.findViewById(id.tvName);
  Intrinsics.checkExpressionValueIsNotNull(var10000, "view.tvName");
  var10000.setText((CharSequence)"承香墨影（ID:cxmyDev）");
  return view;
}

看看编译后的产物吧，它实际上也会被转化成 findViewById() 代码，但是注意，这里并没有用到 _$_findViewCache 这个 HashMap 来做缓存。

那如果我们不仅仅想改变 TextView 的 Text，还想改变它的 textSize、textColor，甚至还想再加一个 Click 事件，会出现什么情况呢？

@Nullable
public View onCreateView(@NotNull LayoutInflater inflater, @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
  Intrinsics.checkParameterIsNotNull(inflater, "inflater");
  View view = inflater.inflate(2130968608, container, false);
  Intrinsics.checkExpressionValueIsNotNull(view, "view");
  TextView var10000 = (TextView)view.findViewById(id.tvName);
  Intrinsics.checkExpressionValueIsNotNull(var10000, "view.tvName");
  var10000.setText((CharSequence)"承香墨影（ID:cxmyDev）");
  ((TextView)view.findViewById(id.tvName)).setTextColor(2131624090);
  ((TextView)view.findViewById(id.tvName)).setTextSize(10.0F);
  ((TextView)view.findViewById(id.tvName)).setOnClickListener((OnClickListener)null.INSTANCE);
  return view;
}

这样的使用方式，你将得不到任何优化，直接很简单粗暴的每次调用都会去findViewById() 一遍，实际上这是一个比较重的操作。也是我们今天要说到的问题。

Kotlin 虽然干掉了 findViewById()，并且实现上还有一些优化，但是使用 view.view 的操作方式，依然会回归到原始的 findViewById()，从而对性能造成影响。

既然知道了问题所在，那么如何避免就显而易见了。

三. 小结时刻

在本文中，我们聊到了 Kotlin 中一个非常好的特性，直接通过 View ID 访问布局内的 View 对象。以及它内部是如何实现的，它会利用一个 HashMap 结构，实现了缓存，避免 findViewById() 被重复调用。

最后还聊到了，当我们使用 view.view 这种连续调用的方式，其实是得不到任何优化的，就是很直接的每次利用 findViewById() 拿 ID 指定的 View 进行操作，所以我们要尽量避免这样的使用方式。

就到这里吧，有任何问题欢迎留言。

本文对你有帮助吗？留言、转发、点好看是最大的支持，谢谢！

程序员接私活经验总结

为什么阿里巴巴禁止static修饰SimpleDateFormat？

程序员10101：一个需求引发的血案

刚好在搞测试规范，顺便谈谈单元测试...

是时候摒弃掉Notepad++ ，因为你还有更多的选择...

相信自己，没有做不到的，只有想不到的

在这里获得的不仅仅是技术！

喜欢就给个“在看”