android关联符号,聊一聊Android中View的绑定

今天初步认识一下Android中实现View绑定的两种方案：ViewBinding 和 kotlin-android-extension

一、ViewBinding

1.1 配置build.gradle

android{

viewBinding {

enabled = true // 开启。默认关闭

}

}

1.2 使用

以SecondActivity为例，其布局文件为：activity_second_new.xml，只有一个TextView android:id="@+id/textView"

class SecondActivity : AppCompatActivity() {

override fun onCreate(savedInstanceState: Bundle?) {

super.onCreate(savedInstanceState)

// 注意 ActivitySecondNewBinding

val mBinding = ActivitySecondNewBinding.inflate(layoutInflater)

setContentView(mBinding.root)

// 使用textView

mBinding.textView.text = "这是一个通过ViewBinding 实现的view绑定"

}

}

ViewBinding会根据 layout的名称创建相关的Binding类，如本例的：ActivitySecondNewBinding。想看一下ActivitySecondNewBinding具体实现，点击会直接导航到对应的xml文件。这怎么回事，难道不让看具体代码吗？莫急，我们先来编一下项目。查看 build/generated/data_binding_base_class_source_out 这里会生成ViewBinding相关的辅助类，这里就有我们的ActivitySecondNewBinding，我们们来看一下具体实现吧。

public final class ActivitySecondNewBinding implements ViewBinding {

@NonNull

private final RelativeLayout rootView; // xml 根布局容器

@NonNull

public final TextView textView; // xml中对应的View，以id作为变量名

//私有构造函数

private ActivitySecondNewBinding(@NonNull RelativeLayout rootView, @NonNull TextView textView) {

this.rootView = rootView;

this.textView = textView;

}

@Override

@NonNull

public RelativeLayout getRoot() {

return rootView;

}

@NonNull

public static ActivitySecondNewBinding inflate(@NonNull LayoutInflater inflater) {

return inflate(inflater, null, false);

}

@NonNull

public static ActivitySecondNewBinding inflate(@NonNull LayoutInflater inflater,

@Nullable ViewGroup parent, boolean attachToParent) {

View root = inflater.inflate(R.layout.activity_second_new, parent, false);

if (attachToParent) {

parent.addView(root);

}

return bind(root);

}

@NonNull

public static ActivitySecondNewBinding bind(@NonNull View rootView) {

// The body of this method is generated in a way you would not otherwise write.

// This is done to optimize the compiled bytecode for size and performance.

String missingId;

missingId: {

//注意这里：findViewById

TextView textView = rootView.findViewById(R.id.textView);

if (textView == null) {

missingId = "textView";

break missingId;

}

// 注意这里创建 ActivitySecondNewBinding 实例

return new ActivitySecondNewBinding((RelativeLayout) rootView, textView);

}

throw new NullPointerException("Missing required view with ID: ".concat(missingId));

}

}

通过查看ActivitySecondNewBinding 发现其实逻辑很简单。它会帮助我们通过findViewById实例化view，调用 inflate方法最终把整个ActivitySecondNewBinding 对象返回。

这里有一个有意思的东西。在项目没有编译之前。我们就可以在coding时使用 ActivitySecondNewBinding，而且IDE不会报错，点击跳转对应xml布局文件，这依赖的是 IDE的能力(通过AS 插件应该也可以实现)。真正进行打包编译的时候，会在构建过程中去创建真正的 ActivitySecondNewBinding.java类 。这个跟 R 文件的处理类似。那其实ButterKnife R2 也能像这样处理，在coding阶段更友好，不至于在没编译时一片爆红，也能更智能提示开发者。这点可以参考 lombok 插件的实现，虽然lombok是在javac的阶段对生成的 .class进行干预，但在coding阶段，我们就可以利用 lombok 插件 正常使用相关扩展的实体类的功能。

题外话：lombok 中的 @Data 可以帮助我们生成java实体类中的辅助方法(编译期间：javac，原理操纵AST)：set、get、equals、hashCode、toString 等。 在coding阶段利用lombok 插件功能，可以直接使用这些 未来 生成的方法，并且IDE不会报错：

lombok plugin

1.3 其它

只要此Moudle开启了viewBinding功能，那么就会给此Moudle下所有xml都生成一个Binding辅助类。但是有时候我们不想这样干，比如有可能我们已经在使用其他的View绑定的形式了，那么这时候 有些Binding辅助类 可能永远不会给使用到，这时候就会生成一下无用的辅助类，而这些辅助类也将最终打到apk中去。

解决办法，把下边的配置添加到想忽略的xml布局文件中，在编译时就不会生成对应的辅助类。

tools:viewBindingIgnore="true"

二、kotlin-android-extension

如果恰好项目是用kotlin开发，kotlin通过一些gradle插件 kotlin-android 、kotlin-android-extensions 可以帮助我们实现View的绑定。

以 MainActivity 为例，layout布局：activity_main.xml，其中只有一个TextView(android:id="@+id/txt")

import kotlinx.android.synthetic.main.activity_main.*

class MainActivity : AppCompatActivity() {

override fun onCreate(savedInstanceState: Bundle?) {

super.onCreate(savedInstanceState)

setContentView(R.layout.activity_main)

txt.text = "这是一个 kotlin-android-extension 实现的viewBinding"

}

}

我们通过字节码看一下最终生成的类的内容：

public final class MainActivity extends AppCompatActivity {

private HashMap _$_findViewCache; //缓存

protected void onCreate(@Nullable Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

this.setContentView(1300010);

TextView var10000 = (TextView)this._$_findCachedViewById(id.txt);

Intrinsics.checkExpressionValueIsNotNull(var10000, "txt");

var10000.setText((CharSequence)"这是一个 kotlin-android-extension 实现的viewBinding");

}

// View从缓存中获取，如果命中直接返回，否则通过findViewById初始化

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;

}

//清空缓存

public void _$_clearFindViewByIdCache() {

if (this._$_findViewCache != null) {

this._$_findViewCache.clear();

}

}

}

通过观察 最终的MainActivity 可知，它的实现方式时利用了HashMap对View进行缓存，第一次访问view的话，会调用findViewById进行初始化，之后都会拿缓存里的View。

无论你有没有使用，所有kotlin编写的Activity生成的字节码上最终都会添加 _$_findCachedViewById、_$_clearFindViewByIdCache 这些方法。那么有没有办法去掉呢？答案是有的。

使用 @ContainerOptions 可以控制，默认是使用CacheImplementation.HASH_MAP去处理的。我们可以手动设置为 CacheImplementation.NO_CACHE；

public annotation class ContainerOptions(

/** A cache implementation for the container. */

public val cache: CacheImplementation = HASH_MAP

)

public enum class CacheImplementation {

/** Use [android.util.SparseArray] as a backing store for the resolved views. */

SPARSE_ARRAY,

/** Use [HashMap] as a backing store for the resolved views (default). */

HASH_MAP,

/** Do not cache views for this layout. */

NO_CACHE;

companion object {

/** The default cache implementation is [HASH_MAP]. */

val DEFAULT = HASH_MAP

}

}

我们以 ThirdActivity举例

import kotlinx.android.synthetic.main.activity_third.*

@ContainerOptions(CacheImplementation.NO_CACHE) //注意注解

class ThirdActivity : AppCompatActivity() {

override fun onCreate(savedInstanceState: Bundle?) {

super.onCreate(savedInstanceState)

setContentView(R.layout.activity_third)

thirdTv.text = "Third textView"

thirdTv.text = "Third textView2"

}

}

最终生成的代码：

public final class ThirdActivity extends AppCompatActivity {

protected void onCreate(@Nullable Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

this.setContentView(layout.activity_third);

//每次用到的地方都会使用 findViewById进行替换

TextView var10000 = (TextView)this.findViewById(id.thirdTv);

Intrinsics.checkExpressionValueIsNotNull(var10000, "thirdTv");

var10000.setText((CharSequence)"Third textView");

//每次用到的地方都会使用 findViewById进行替换

var10000 = (TextView)this.findViewById(id.thirdTv);

Intrinsics.checkExpressionValueIsNotNull(var10000, "thirdTv");

var10000.setText((CharSequence)"Third textView2");

}

}

三、总结

本次就这样了，简单认识了一下它们的使用，以及辅助类的逻辑处理。对它们有了一个初步的认识。 这里突然想到一个问题，lombok 是通过APT影响最终的字节码生成，那么为什么在javac的前期阶段(语法分析、词法分析)的时候不会直接报错呢？比如此时所访的实体类中还没有那些方法，例如set/get，怎么会编译通过呢？

想要解释上述的这个问题需要了解javac的相关理论。

深入理解JVM

javac 编译过程大致可以分为3个过程：

解析与填充符号表过程

插入式注解处理器的注解过程

分析与字节码生成过程

3.1 解析与填充符号表

3.1.1. 词法、语法分析

词法分析是将源代码的字符流转变为标记(Token)的集合，标记是编译过程中的最小元素，关键字、变量名、字面量、运算符都可以成为标记。

语法分析是根据Token序列构造抽象语法树的过程。抽象语法树(Abstract Syntax Tree。 AST)是一种用来描述程序代码语法结构的树形表示形式。语法树的每一个节点都代表着程序代码中的一个语法结构，例如包，类型、修饰符、运算符、接口、返回值等

3.1.2. 填充符号表

完成了词法分析和语法分析后，下一步就是填充符号表的过程。符号表中所登记的信息在编译的不同阶段都要用到。在语义分析中，符号表所登记的内容将用于语义检查和产生中间代码。

3.2 注解处理器

在这个过程中，我们可以通过提供的API，对抽象语法树中的任意元素进行读取、修改、添加。如果处理器在注解处理期间对语法树进行了修改，编译器将回到解析及符号表的过程重新处理，知道所有注解处理器都没有再对语法树进行修改为止。每一次循环称为一个Round。

3.3 语义分析与字节码生成

语法分析之后，我们获得了程序代码的抽象语法树表示，语法树能表示一个 结构正确 的源程序的抽象，但是无法表示源程序是否符合逻辑。而语义分析的主要任务是对结构上正确的源程序进行上下文有关性质的检查。举个例子：

int a = 1;

boolean b = false;

char c = 2;

后续可能出现的赋值运算：

int d = a + c;

int d = b + c;

char d = a + c;

上边示例代码中，后续代码中如果出现了如上3中赋值运算的话，那他们都能构成结构正确的语法树，但是只有第一种写法在语义上是没问题的。其余两种在Java语言中是不合逻辑的，无法编译通过。

了解了编译过程，就能想通了，使用lombok生成的方法，只要IDE不报错，在词法、语法分析上也都能通过，可以生成一个结构正确的语法树。之后通过APT，按照一定规则，动态修改语法树结构，保证在语义分析阶段，我们的程序没有问题，从而编译通过。