还在用findViewById，不来了解下其它方式？

众所周知，都2220年了，findViewById已经是一种非常繁琐的操作，如果要去获取的id数量多，则对开发更加不友好。如果一个页面id过多，经常会有如下场景：

TextView title = findViewById(R.id.*tv_title*);
TextView title2 = findViewById(R.id.tv_title2);
TextView title3 = findViewById(R.id.tv_title3);
TextView title4 = findViewById(R.id.tv_title4);
TextView title5 = findViewById(R.id.tv_title5);
TextView title6 = findViewById(R.id.tv_title6);
TextView title7 = findViewById(R.id.tv_title7);
TextView title8 = findViewById(R.id.tv_title8);
TextView title9 = findViewById(R.id.tv_title28);
TextView title10 = findViewById(R.id.tv_title9);
TextView title11 = findViewById(R.id.tv_title10);
TextView title12 = findViewById(R.id.tv_title11);
TextView title13 = findViewById(R.id.tv_title12);
TextView title14 = findViewById(R.id.tv_title13);
TextView title15 = findViewById(R.id.tv_title14);
TextView title16 = findViewById(R.id.tv_title15);
TextView title17 = findViewById(R.id.tv_title16);
TextView title18 = findViewById(R.id.tv_title17);
TextView title19 = findViewById(R.id.tv_title18);

...

数量一多，你会发现，这已经极其不友好。其实不光是不友好有问题，了解findViewById的原理后，你也会发现其内部实现在一定情况下对整体性能有轻微影响。

一 、 findViewById() 的原理

findViewById()的流程原理其实非常简单，以activity中的findViewById流程为例，activity要么继承自android.app.Activity，要么继承自androidx.appcompat.app.AppCompatActivity（你要是没适配AndroidX的话那就是support包）。这其中：

1⃣️、android.app.Activity继承类会通过getWindow得到Window对象来调用findViewById()；

@Nullable
public  T findViewById(@IdRes int id) {
    return getWindow().findViewById(id);
}

2⃣️、androidx.appcompat.app.AppCompatActivity继承类会通过getDelegate()得到AppCompatDelegate委派类的实例对象后调用其findViewByid()，这个对象实际是AppCompatDelegateImpl对象，创建其时传入了activity.getWindow得到的window对象。

@SuppressWarnings("TypeParameterUnusedInFormals")
@Override
public  T findViewById(@IdRes int id) {
    return getDelegate().findViewById(id);
}

1⃣️和2⃣️最后都会调用Window（getWindow）里的findViewById()。

@Nullable
public  T findViewById(@IdRes int id) {
    return getDecorView().findViewById(id);
}

Window类中通过getDecorView()来得到View对象(实际上是一个ViewGroup对象)，

@Nullable
public final  T findViewById(@IdRes int id) {
    if (id == NO_ID) {
        return null;
    }
    return findViewTraversal(id);
}

通过调用findViewById（）来调用ViewGroup中重写的findViewTraversal（）。下面源码图片是通过在线浏览网站获取到的ViewGroup类中findViewTraversal（）的相关实现：

可以看到这就是个遍历方法，如果对应界面内子元素是个View，只要id配对上可以直接返回，如果是一个ViewGroup则会调用子ViewGroup或子View的这个方法，依次遍历，直到找到目标id。很明显这是个深度优先搜索，时间复杂度为O(n)。

二 、 相关替代方案 ：

1、 ButterKnife

大名鼎鼎的黄油刀，使用方式极为简便，项目地址：

https://github.com/JakeWharton/butterknife

在gradle中依赖：

implementation 'com.jakewharton:butterknife:xxx'
annotationProcessor 'com.jakewharton:butterknife-compiler:xxx'

对应在activity中操作为（具体一键生成方式这里不表）:

public class MainActivity extends AppCompatActivity {
        @BindView(R.id.tv_title1)
        TextView tvTitle1;
	@BindView(R.id.tv_title2)
        TextView tvTitle1;
	@BindView(R.id.tv_title3)
        TextView tvTitle3;
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
            //绑定处理
            ButterKnife.bind(this);
        }
......
}

其实ButterKnife只是通过注解对findViewById的进行的一个取代，增加代码的可读性，而findViewById的各种缺点依然存在。当然，就这个开源框架而言，功能绝不仅仅是替代findViewById()。自从kt语言出来后，黄油刀的功效捉襟见肘，非Java版的老工程，不推荐。

2、kotlin-android-extensions

如果你项目可以使用kotlin，则可以使用kotlin-android-extensions。

在module的gradle中加入：

plugins {
    id 'kotlin-android-extensions'
}

可直接在对应类中通过其id的形式控制其控件，相当于已经获取了一遍控件id。

import androidx.appcompat.app.AppCompatActivity
import android.os.Bundle
import com.test.demo.main.activity_main.*

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        tv_hello.setOnClickListener {

        }
    }
}

这种方法其本质上依旧还是通过findViewById去实现，有兴趣的小伙伴可以反编译看看。虽然现在此法已不被官方推荐，但其便利性还是首屈一指。

3、ViewBinding

一曲新人笑，几度旧人哭。此法一出，kotlin-android-extensions已不被官方推荐。

(注意，此法只能在AndroidStudio3.6及更高版本上可用）

使用方式：在build.gradle中依赖:

android {
        ...
        buildFeatures {
        viewBinding true
    }
}

reload后，系统会为每个layout目录下 XML 布局文件生成一个绑定类。每个绑定类均包含对根视图以及具有 ID 的所有视图的引用。系统会通过以下方式生成绑定类的名称：将 XML 文件的名称转换为驼峰式大小写，并在末尾添加“Binding”一词。
例如：某个布局命名为activity_login，其所生成的绑定类的名称就为LoginActivityBinding，这个绑定类就会完成findViewById的工作。

不同布局会生成不同绑定类，他们所生成的路径在：在build/generated/data_binding_base_class_source_out/debug/out/com/xxx/yyy/databinding/目录下。

当然，如果不想xml文件生成 Binding 类，可以在 xml 布局文件中根 view 写入此属性：

tools:viewBindingIgnore="true"

其在代码中使用方式如下：（ViewBinding在Java和kotlin类中都可使用，这里仅是拿kotlin类举例）

· Activity：

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    ActivityMainBinding binding = ActivityMainBinding.inflate(getLayoutInflater());
    setContentView(binding.getRoot());
    binding.tvTest.setText("This is ViewBinding");
}

可见，setContentView（）中的参数改为了XXXbing.getroot（）。调用布局中的某控件，只需要XXXbing.viewID（驼峰原则）可直接拿到实例对象(上述代码中的binding.tvTest控件在xml中的id为tv_test)。例如：xml中TextView控件id为tv_demo，则在activity中对应实例为XXXbing.tvDemo。

· Fragment中:

public class MyFragment extends Fragment {

    private FragmentMyBinding binding;
    private Context context;

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container,
                             Bundle savedInstanceState) {
        binding = FragmentMyBinding.inflate(getLayoutInflater(), container, false);
        return binding.getRoot();
    }

    @Override
    public void onViewCreated(@NonNull View view, @Nullable Bundle savedInstanceState) {
        super.onViewCreated(view, savedInstanceState);
        binding.tvTitle.setText("Hello ViewBinding");
    }

    @Override
    public void onDestroyView() {
        super.onDestroyView();
        binding = null;
    }
}

可以看出，跟Activity的引用方式区别不大，这里需要稍微注意Fragment 的存在时间比其视图长。在 Fragment对应onDestroyView()时要清除对绑定类实例的所有引用。

·RecyclerView adapter中：

public class MyAdapter extends RecyclerView.Adapter {
、、、、、、
    @NonNull
    @Override
    public ViewHolder onCreateViewHolder(@NonNull ViewGroup parent, int viewType) {
        ItemLayoutBinding itemBinding = ItemLayoutBinding.inflate(inflater, parent, false);
        return new ViewHolder(itemBinding);
    }

    @Override
    public void onBindViewHolder(@NonNull ViewHolder holder, int position) {
        holder.textView.setText(mData.get(position));
    }

    static class ViewHolder extends RecyclerView.ViewHolder {
        TextView textView;

        public ViewHolder(@NonNull ItemLayoutBinding itemBinding) {
            super(itemBinding.getRoot());
            textView = itemBinding.textView;
        }
    }
}

可见，应用方式无大致区别。

总结

1、findViewById兼容性好，适用所有场景，且灵活；

2、findViewById性能略差，底层就是个深度优先搜索，且id过多情况下容易造成可读性极差的情况，从上述的原理流程中不难看出，在Activity中调用findViewById，实际上是调用Window中的findViewById，但是Fragment中并没有单独的Window，Fragment中调用findViewById的效果和Activity中调用的效果一模一样。所以如果一个Activity中有多个Fragment，Fragment中的控件名称又有重复的，直接使用findViewById会爆错。

3、ButterKnife可一键生成，方便至极，但缺点跟findViewById一样。如果不是老工程，此法已不推荐使用。

4、Google官方表示，与使用 findViewById 相比，ViewBinding具有一些很显著的优点：

· 空指针安全：由于视图绑定（ViewBinding）会创建对视图的直接引用，因此不存在因视图 ID 无效而引发 Null 指针异常的风险。此外，如果视图仅出现在布局的某些配置中，则绑定类中包含其引用的字段会使用 @Nullable 标记。（说白了就是让你丫代码少爆空指针）

· 类型安全：每个绑定类中的字段均具有与它们在 XML 文件中引用的视图相匹配的类型。这意味着不存在发生类转换异常的风险。

这些差异意味着布局和代码之间的不兼容将会导致构建在编译时（而非运行时）失败。

下篇预告：第四种方式：DataBinding。