手记

你入门了吗?--findViewById背后的逻辑

你入门了吗?--findViewByID背后的逻辑

安卓开发千千万,是否还是门外汉。

没有逻辑懒分析,猿路漫漫满荆棘。

析始于问,有问方有析;析生暗门,门内藏疑。门现而有启闭,启之极理,闭之极情。

情理内斗而乱神,不辩则不知事之真假,不通关联之物,不能处世仁人。

得到控件的函数名为何会叫findViewByID?

在此开始浅析findViewByID背后的逻辑,让我为你开启逻辑的门窗!

为什么叫find而不是create?  连续或不连续两句find同一个控件id,两个控件内存地址是否会是一样?会一样!我们知道,setContentView时会加载xml布局文件,pull解析xml文件,及生成控件。--控件已先存在,故此时findViewByID的目的应该是去找到一个控件而不是生成一个控件!反之推论,找一个人时,此人必先存在,创造一个人时,此人必先不存在。由反推也可知,多次findViewByID同一个id得到的都是同一个控件。题外话深入---找一个人时,此人必先存在。此逻辑充分正确吗?不充分!"找"与"找到"概念不同,找person前,person可以不存在,找到person前,person才必先存在!我们说,"找"就是findViewByID的入口执行,"找到"就是findViewByID的返回结果,找的过程就是findViewByID的函数体。findViewByID开始调用时,不能确定此时控件是否存在,譬如有这样的两条逻辑线,findViewByID-->不存在则创建再返回/存在则返回。所以究其本质,根据以上分析首次探索以下现象,即连续的两句findViewByID同一个id,微观上是不能断定两个控件内存是否一致,但宏观预测上,可推测其在大概率上应该是会产生"控件一致"这样的结果的。以上为研究一个未知现象答案前的分析过程,并非是答案后的分析,在此强调。后析长于强化既定知识,前析长于锻炼逻辑技巧,联通万物,以应未知。   再归正题,宏观预测为何会取"控件一致"之结果而非反?"控件不一致"若成立的话,则说明每次查找都会重新创建,则不会发生。控件之间存在着父子的单级或跨级的关系,故而每一个控件必须唯一,否则关系破裂,getChildAt与getParent等皆会存在漏洞。控件唯一之必然反推了控件只能创建一次的结果。find前创造控件还是第一次find时创造控件呢?由父子关系可推,只能在find前创建,否则会发生不调find不生成控件的情况,则此时父子关系链一样会断。总论:所有控件必须在framework层pull解析xml文件时创建,"find"就非常合乎架构设计的原理了,正确地命名反映了架构的内部原理!--反映了架构设计的精巧

为什么叫"View"而不是"Widget","ViewGroup","Layout"等?   很简单---继承结构关系。控件之祖就是顶层容器View。--反映了Java继承特性,继承结构无处不在!

为什么叫"By"而不是"To","With","Under"等其它介词?  by,译为"通过......的方式"。by bicycle时还有by car,by bus等,由此可知,by id很有可能还有by x,by y,by z等等其它找到控件的方式。有吗?通过我们的查找,自然可以发现还有with tag,getChildAt,getParent等等找到控件的方式。方式不同,利弊不同,用处不同。比如:

id快,向下,可跨级;

tag慢,向下,可跨级,数据灵活;

getChildAt最快,向下,单级;

getParent最快,向上,单级。

通过对by一个很简陋的单词的逆向思考,我们可以学到四种找到控件的方式并区分利弊使用场景。如果你一开始就抱着by两个字母还有什么需要思考的心态的时候,自然也会反向受到"丑陋"的by的高能伤害---错失具备优化控件查找速度,tag妙用的基础技巧。

为什么叫"Id"而不是叫"Tag"或其它的名字?  问题就交由学友们自己去发散思维开启询问分析之旅了。

从被代码牵着鼻子走,到牵着代码的鼻子走,在这入门的极短道路中,我们付出的思考及分析若不能让自己头痛欲裂,那你终将会被越来越多的人俯视!

问题的解答,都会伴随着个人头脑内理与情的相争。对个人学习者而言,理与情需要辩度,辩度的好,情可融于理并促进之;辩度的不好,情会摧击理,让人得到错误的结论,辩错真伪,或者只看到其中的一条逻辑线,无法发现潜藏的其它逻辑线!

原文链接:http://www.apkbus.com/blog-784139-68348.html

0人推荐
随时随地看视频
慕课网APP