每日一问:不一样的角度吐槽下 DataBinding
我们项目采用的是 kotlin && DataBinding 处理的,可能你会疑问,既然用的是 kotlin,为啥没有用 kotlinx?新的页面当然是用的 kotlinx 啦,但我们有相当庞大的历史代码,并且我们的通用 adapter 其实也是基于 DataBinding 来封装的。所以,我们还是不得不来讨(吐)论(槽)一下这个 DataBinding 的坑。事实上,这个问题在我当年面试字节跳动的时候就被问及过。 这是一个非常开放性的问题,所以看到这篇文章的小伙伴一定得带一个有色眼镜进行审视,下面会尽可能地列举中笔者遇到过的坑,当然能力有限,有可能不少东西并不是 DataBinding 的问题,需要大家一起来甄别并进行补充。 DataBinding 是早些时候 Google 推出来的一个支持库,只要勇于解决我们代码中频繁出现的 但我们今天不对 Butterknife 进行过多的评论,而转移到我们的主角 DataBinding。 对于 DataBinding 的使用和介绍这里就不做讲述了,建议大家还是直接到 官方文档 极难进行错误定位oh,这应该是使用 DataBinding 的小伙伴们最最最大的坑点了,你甚至一定在各种技术轮胎和开发交流群中见过一些小伙伴对它的深恶痛绝。不管你代码中有了什么错误,你一定收到的错误日志是一大堆 DataBinding 生成的类找不到。 可能非常多的小伙伴会对此保持疑问,这不,真正的错误都在 build 日志的最后能看到么?实在没有看到,你也可以在控制台输入 但事实真的如此么?有没有小伙伴经历过不管你怎么查看日志都找不到真正的错误代码的。 我想一定有!虽然我们一般都要求对 commit 保持「少量多次」的原则,但这并不能保证我们时刻都得严格遵守,在部分业务非常紊乱的时候,我们并不希望经常做 commit,因为每一次 commit,我们也得做一次编译确认当前的代码没有任何语法问题。而对于代码量庞大、尤其是还受各种历史原因组件化不够彻底的项目,一次编译基本就可以让你去吃一个饭了。我司的项目就是如此,受限于历史原因,组件化做的并不彻底,导致本地编译在没有命中缓存的情况下至少得 10 分钟,这还是在 16G 的 mac pro 上。而且大多数人的电脑可能配置还更低,在编译的时候很难做其他和工作相关的事情。 为了处理这个编译问题,我司不得不编写一个编译脚本,把编译操作都在服务器上进行处理,在做了一系列优化操作后,在没命中缓存的情况下编译 debug 包还是需要 4.5 分钟,当然现在在编译中我们可以做其他有意思的事情了。 好像前面这两段说了很多无关紧要的东西,但是!我真正想要表达的是,这时候出现了错误,并且日志无法对错误进行定位,你会发现非常痛苦,你可能已经改动了数十个文件,新建了不少 XML,因为无法定位到日志,你不得不一行一行的进行语法检查。 我在这个问题上体验过编码两小时,查编译失败问题花费时间更多的尴尬情况,通常来说,这样的错误都不容易发现,我深深的记住我有一次因为组件化历史问题,不得不把一个组件代码 move 到另外一个组件,然后就发生了不可预料的错误的悲痛场景。当你 OK,目前对于这样的情况,还是有所总结,这种情况 95% 是 XML 代码的问题,你可以直接检查 XML 了。 代码极难维护我们使用 DataBinding 的时候,必然会喜欢它的双向绑定操作。在 XML 里面直接做一些简单的逻辑处理,这样的操作让我们的代码变得非常简洁,并且可以省去 我们的代码里面就有相当部分的这样的代码,部分页面逻辑非常复杂,比如一个商品详情页,会牵扯到非常大量的信息展示和各种促销秒杀状态,还有不少的动效,这时候不少逻辑放在 XML 里面后,后续维护的同事在处理产品改动的时候,一定在心中暗自谩骂。 通常来说,我习惯于把这些复杂的逻辑放置在我们的 Java 代码中。就目前来看,在代码中查看这些复杂的交互逻辑得心应手不少。 @{} 不会去做检查早些时候,我连续犯过两次低级错误,所以对这个问题记忆深刻。我们可以发现,XML 里面支持我们用类似 根据控件 ID 在代码里面找一个东西很难在我们项目的早期代码中,XML 里面的命名规范基本是 xxx_xxx_xxx 这样的格式,但在 DataBinding 里面为我们生成的变量却采用的是驼峰命名法,这导致我们根据一个控件 id 去对应 class 里面寻找的时候,还得自己更改为驼峰命名法命名的名字,这一度让我们感到非常不适,所以我们后面的代码 XML 命名规范就跟着变成驼峰命名法了。这可能和命名规范有些许出入,不过我们坚信适合自己的,才是最好的理念。 部分 XML 中的表达式在不同 gradle 版本上表现有所不同前面说到,我们平时会采用服务器编译,所以此前有出现过 XML 文件里面的某个属性设置在本地编译不过,但在服务器上甚至其他同事的电脑上可以编译的问题。老实说,目前我并没有找到真正的原因,我姑且把这个问题甩锅给了此前做这个的同事。我后续更改了他的实现方式才让这个问题得到妥善处理,但至今没有明白问题出在哪里,因为那样的方式我认为本身代码是没有什么问题的。可惜我现在没有时间去寻找这个代码,大概是设置一个公用的 BindingAdapter 不好维护我们通常会用到 @BindingAdapter 方式来做一些公用逻辑,而不是直接去把逻辑放在页面通过设置属性来使用它,这样就会出现这些公用逻辑比较难维护,当然,这极有可能是我们项目的历史问题,但我觉得这算是一个坑点了。不知道有没有人出现这样的属性在 XML 里面没有提示的情况。就像你自定义 View Styleable 名字不唯一一样。 多模块依赖问题这个问题我之前还没有发现,因为我们每个模块都用到了 DataBinding,所以认为每个模块的
哎,个人能力有限,就想到哪儿说到哪儿了。可能有不少其实并不是 databinding 的坑,是个人使用问题,还往明白的人能直接指出。PS:再给我一个机会,我不想在用 Databinding。 希望有其他槽点或者认为上面的东西是有更好的处理方式的小伙伴一定要在下面留言,盼复盼复~ (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |