你入门了吗？--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"或其它的名字？ 问题就交由学友们自己去发散思维开启询问分析之旅了。
从被代码牵着鼻子走，到牵着代码的鼻子走，在这入门的极短道路中，我们付出的思考及分析若不能让自己头痛欲裂，那你终将会被越来越多的人俯视！
问题的解答，都会伴随着个人头脑内理与情的相争。对个人学习者而言，理与情需要辩度，辩度的好，情可融于理并促进之；辩度的不好，情会摧击理，让人得到错误的结论，辩错真伪，或者只看到其中的一条逻辑线，无法发现潜藏的其它逻辑线！