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

2023-11-07 03:20

本文主要是介绍Kotlin干掉了findViewById,但用不好也会有性能问题,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

击上方的终端研发部,右上角选择“设为星标

每日早9点半,技术文章准时送上

公众号后台回复“学习”,获取作者独家秘制精品资料

往期文章

5G时代,程序员会失业还是会继续吃香?

刚好在搞测试规范,顺便谈谈单元测试...

是时候摒弃掉Notepad++ ,因为你还有更多的选择...

浅谈:聊聊“全栈工程师”

程序员:待过头条、阿里和微软,只想说微软是世界上最好的公司

转载自:承香墨影

一.前言

自从 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 fun onCreate(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(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    this.setContentView(2130968608);
    TextView var10000 = (TextView)this._$_findCachedViewById(id.tvName);
    Intrinsics.checkExpressionValueIsNotNull(var10000, "tvName");
    var10000.setText((CharSequence)"承香墨影(ID:cxmyDev)");
}
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;
}

可以看到这里最关键的就是 _$_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() 会返回 null,导致获取控件失败。

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

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

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

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

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

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

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

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

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

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

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

三. 小结时刻

在本文中,我们聊到了 Kotlin 中一个非常好的特性,直接通过 View ID 访问布局内的 View 对象。以及它内部是如何实现的,它会利用一个 HashMap 结构,实现了缓存,避免 findViewById() 被重复调用。

最后还聊到了,当我们使用 view.view 这种连续调用的方式,其实是得不到任何优化的,就是很直接的每次利用 findViewById() 拿 ID 指定的 View 进行操作,所以我们要尽量避免这样的使用方式。

就到这里吧,有任何问题欢迎留言。

本文对你有帮助吗?留言、转发、点好看是最大的支持,谢谢!

程序员接私活经验总结

为什么阿里巴巴禁止static修饰SimpleDateFormat?

程序员10101:一个需求引发的血案

刚好在搞测试规范,顺便谈谈单元测试...

是时候摒弃掉Notepad++ ,因为你还有更多的选择...

相信自己,没有做不到的,只有想不到的

在这里获得的不仅仅是技术!

喜欢就给个“在看” 

这篇关于Kotlin干掉了findViewById,但用不好也会有性能问题的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/360918

相关文章

Vue3 的 shallowRef 和 shallowReactive:优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉,那么对 shallowRef 和 shallowReactive 是否了解呢? 在编程和数据结构中,“shallow”(浅层)通常指对数据结构的最外层进行操作,而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素,而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层(Shallow) 定义

性能测试介绍

性能测试是一种测试方法,旨在评估系统、应用程序或组件在现实场景中的性能表现和可靠性。它通常用于衡量系统在不同负载条件下的响应时间、吞吐量、资源利用率、稳定性和可扩展性等关键指标。 为什么要进行性能测试 通过性能测试,可以确定系统是否能够满足预期的性能要求,找出性能瓶颈和潜在的问题,并进行优化和调整。 发现性能瓶颈:性能测试可以帮助发现系统的性能瓶颈,即系统在高负载或高并发情况下可能出现的问题

好题——hdu2522(小数问题:求1/n的第一个循环节)

好喜欢这题,第一次做小数问题,一开始真心没思路,然后参考了网上的一些资料。 知识点***********************************无限不循环小数即无理数,不能写作两整数之比*****************************(一开始没想到,小学没学好) 此题1/n肯定是一个有限循环小数,了解这些后就能做此题了。 按照除法的机制,用一个函数表示出来就可以了,代码如下

hdu1043(八数码问题,广搜 + hash(实现状态压缩) )

利用康拓展开将一个排列映射成一个自然数,然后就变成了普通的广搜题。 #include<iostream>#include<algorithm>#include<string>#include<stack>#include<queue>#include<map>#include<stdio.h>#include<stdlib.h>#include<ctype.h>#inclu

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

购买磨轮平衡机时应该注意什么问题和技巧

在购买磨轮平衡机时,您应该注意以下几个关键点: 平衡精度 平衡精度是衡量平衡机性能的核心指标,直接影响到不平衡量的检测与校准的准确性,从而决定磨轮的振动和噪声水平。高精度的平衡机能显著减少振动和噪声,提高磨削加工的精度。 转速范围 宽广的转速范围意味着平衡机能够处理更多种类的磨轮,适应不同的工作条件和规格要求。 振动监测能力 振动监测能力是评估平衡机性能的重要因素。通过传感器实时监

黑神话,XSKY 星飞全闪单卷性能突破310万

当下,云计算仍然是企业主要的基础架构,随着关键业务的逐步虚拟化和云化,对于块存储的性能要求也日益提高。企业对于低延迟、高稳定性的存储解决方案的需求日益迫切。为了满足这些日益增长的 IO 密集型应用场景,众多云服务提供商正在不断推陈出新,推出具有更低时延和更高 IOPS 性能的云硬盘产品。 8 月 22 日 2024 DTCC 大会上(第十五届中国数据库技术大会),XSKY星辰天合正式公布了基于星

缓存雪崩问题

缓存雪崩是缓存中大量key失效后当高并发到来时导致大量请求到数据库,瞬间耗尽数据库资源,导致数据库无法使用。 解决方案: 1、使用锁进行控制 2、对同一类型信息的key设置不同的过期时间 3、缓存预热 1. 什么是缓存雪崩 缓存雪崩是指在短时间内,大量缓存数据同时失效,导致所有请求直接涌向数据库,瞬间增加数据库的负载压力,可能导致数据库性能下降甚至崩溃。这种情况往往发生在缓存中大量 k

6.1.数据结构-c/c++堆详解下篇(堆排序,TopK问题)

上篇:6.1.数据结构-c/c++模拟实现堆上篇(向下,上调整算法,建堆,增删数据)-CSDN博客 本章重点 1.使用堆来完成堆排序 2.使用堆解决TopK问题 目录 一.堆排序 1.1 思路 1.2 代码 1.3 简单测试 二.TopK问题 2.1 思路(求最小): 2.2 C语言代码(手写堆) 2.3 C++代码(使用优先级队列 priority_queue)

【VUE】跨域问题的概念,以及解决方法。

目录 1.跨域概念 2.解决方法 2.1 配置网络请求代理 2.2 使用@CrossOrigin 注解 2.3 通过配置文件实现跨域 2.4 添加 CorsWebFilter 来解决跨域问题 1.跨域概念 跨域问题是由于浏览器实施了同源策略,该策略要求请求的域名、协议和端口必须与提供资源的服务相同。如果不相同,则需要服务器显式地允许这种跨域请求。一般在springbo