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

Kotlin干掉了findViewById 1041 阅读 0 评论 0 点赞

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

题图 @Skitterphoto

一. 序

自从 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 funonCreate(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(@able Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
this.setContentView(2130968608);
TextView var10000 = (TextView)this._$_findCachedViewById(id.tvName);
Intrinsics.checkExpressionValueIsNot(var10000, "tvName");
var10000.setText((CharSequence)"承香墨影（ID:cxmyDev）");
}
public View _$_findCachedViewById(int var1) {
if (this._$_findViewCache == ) {
this._$_findViewCache = new HashMap;
}

View var2 = (View)this._$_findViewCache.get(var1);
if (var2 == ) {
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会返回，导致获取控件失败。

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

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

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 来间接访问到它们。

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

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

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

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

@able
public View onCreateView(@Not LayoutInflater inflater, @able ViewGroup container, @able Bundle savedInstanceState) {
Intrinsics.checkParameterIsNot(inflater, "inflater");
View view = inflater.inflate(2130968608, container, false);
Intrinsics.checkExpressionValueIsNot(view, "view");
TextView var10000 = (TextView)view.findViewById(id.tvName);
Intrinsics.checkExpressionValueIsNot(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).INSTANCE);
return view;
}

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

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

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