还在用findViewById,不来了解下其它方式?

众所周知,都2225年了,如果你还在用Java敲安卓代码,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()的相关实现:

还在用findViewById,不来了解下其它方式?_第1张图片
可以看到这就是个遍历方法,如果对应界面内子元素是个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已不被官方推荐。

image.png
(注意,此法只能在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。

你可能感兴趣的:(Android进阶,android)