众所周知，都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 extends View> 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 extends View> T findViewById(@IdRes int id) {
return getDelegate().findViewById(id);
}
1⃣️和2⃣️最后都会调用Window（getWindow）里的findViewById()。
@Nullable
public <T extends View> T findViewById(@IdRes int id) {
return getDecorView().findViewById(id);
}
Window类中通过getDecorView()来得到View对象(实际上是一个ViewGroup对象)，
@Nullable
public final <T extends View> 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<MyAdapter.ViewHolder> {
、、、、、、
@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。
](https://img-blog.csdnimg.cn/direct/0e721eeb188c4634a424f19aa57a75fa.png)
