android实训已经过去好几天，随着一天天的深入，在学到需多新知识的同时，有很多的知识容易产生模糊，有必要规整一下，同时也算是一个小阶段的总结。。
看一个新项目的过程，可以从android项目的AndroidManifest.xml进行梳理，需注意有些项目可能有多个模块，每个模块都有一个AndroidManifest.xml，需要定位到含有main的那个Intent拦截的那个。
何谓application?
众所周知，我们有关app的所有的组件都必须在这个里面申请，但是很少有人去关注这个标签本身。。。我也是在一次错误偶然发现，这个标签竟然要去加载一个一个上下文。。 而这个恰恰也是我们在后面开发中多次用到的那个上下文。
需要注意，这个application默认应该是由android的application提供实例化。 但是，可以在它里面加一个name属性，这样就指定了Application的一个子类来用作实例化。。 它的意义在于，我么在集成其它第三方sdk时候，通常都需要在application实例化的时候进行实例上下文。
这里顺便记录一下自己碰到的一个坑，在集成第三方框架的时候总是报错，一个activity也启动不了。 它的原因在于： 一是没有正确的指定app的上下文。 二是 没有导入jniLibs依赖。 同时，这个jniLibs位于src/main/java的同级目录，这个文件夹是默认识别的，所以不用额外配置。
这里顺便查看一下它的结构：
可以看到它是继承了一个Contest(上下文）的抽象类。 同时它位于android.app包下，继承了一个容器回调的接口。 通过之前的一些源码查看经验，可以知道在设计是包名对类的作用或者说地位 有启示意义。
接着来看一下这个上下文于四大组件的关系：
通过类的继承结构，可以看到： Activity的直接父类ContextThemeWrapper,是继承了ContextWrapper,也就是说，从逻辑上看，Application与ContextThemeWrapper处于同等设计高度。 或者说，Activity组件与 Application共享一个Context上下文（当然前提是一个进程）。 同时，它们都位于android.app包下。
接着来看看Service:
接着来看看ContentProvider:
ContentProvider位于android.content包中，它与Context位于同一个包。 从他的作用来看，它可以将本应用程序的一些内容提供给其它应用，也就是说它超越了上下文（嘿嘿，不知道这样理解对不）。 此外，它本身就是一个抽象类，并且没有父类，但是实现了一个容器回调的接口。
最后看看BroadCastReceiver：
同ContentProvider位于android.content包中。抽象类，么有父类以及接口实现。
四大组件看完了，可以发现有三个组件都是实现了容器回调的接口。
---------------------------------------------------------------------------------
接着来看看Fragment,Dialog,Activity，View,以及 布局文件的相互关系以及区别： View 与ViewGroup的主要内容已在前面总结过了，包括一些基本的视图控件和布局（不是布局文件，可以成一个视图集合，或者一个特殊的View）。还有一些特殊的View,如AdapterView,也再前面总结过。
下面来看看Fragment:
可以看到它是由v4支持包提供的。总所周知，支持包是为了兼容性而生的。 通过它的类结构关系，可以看到它并没有与Activity 和 View发生什么结构上的联系。 但是可以明确的知道，它继承了容器回调接口，具有生命周期。 同时官方包中给出了它的两个子类： ListFragment,以及DialogFragment.
紧接着看看它的主要方法以及构成：
主要的方法：onCreate,onCreateView，instantiate。
理解： 这里有个onCreate，这是大概是它生命周期的一个方法，被创建的时候调用。
onCreateView返回一个视图，应该是它执行核心的方法对用户来说。（它跟AdapterView的getView有些相似，但又有区别，相似是它们都是返回一个控件视图，区别是Adapter通常是递归调用，这里是用户调用）。
instantiate静态方法，用于规范的实例对象。
Fragment可以具有自己的布局文件，通过onCreateView绑定实例。
Activity指定Fragment替换的方法： getFragmentManager().replace().commit(), 从这个方法的使用以及结果来看，Fragment就是一个View。
此外，android包有有提供一个Fragment，不过被废弃了。见图
接着看看Dialog:
它位于android.app包中。 与View,Activity，Fragment没有多大关系。具有回调。
它的典型的一个实例对象：AletrtDialog。
这个方法可以联想一下，View 与 Activity是分离的。
核心方法为setContentView,配合上面的方法使用。
----------------------------------------------------------------------------------------------------------------------------
接着再看布局文件的时候，有必要再看一看View,以及ViewGroup的一些方法，以形成更深的认识。
先看看View:
与这个方法有点像的一个类： LayoutInflater,
inflate有道释意：充气。 它的对象是 xml配置文件。 未充气前，所有关于视图，或者布局的配置文件都是普通文件。 充气之后，所有的配置文件都被转化为了类。 具有了“生命”的实体。
从这个思路理解：
1.所有的配置文件可以单独存在，但是没有意义。如果不被充气的话。
2.外部控件被充气了之后，内部控件被自动充气，但是它相对于开发人员来说，是匿名的。 所以要求它们必需严格遵循类规范和要求，如果有些必需的属性没写，或者多写了属性，都会报错。
3.View,ViewGroup,Fragment通常都是通过给 配置 文件充气，来达到想要的效果。。 这样做是为了解耦，转化阶段应该再构建过程完成的，而不是在执行时通过反射注入，那样的话估计手机得卡死。
4.View,ViewGroup,Fragment等代表视图的内容既然可以给配置 文件充气来达到需求，那么必然可以不通过配置文件达到效果。 也就是说我们可以一直实例对象就行了，指定相应对象的属性就是一毛一样的。 只是那种代码冗余度会让很多开发人员望而却步。 现在冗余度也还是挺高，但是由于android studio神器的存在，轻松了很多，况且这个对执行过程没有很大影响，所以是OK的。
5.四大组件与View的区别，一在于线程的区别，组件获取线程后根据自己的生命周期进行连贯的执行，长期持有线程资源。 View系列的资源持有线程资源是暂时的，当有视图需要渲染的时候，实例一个线程，渲染完成，线程回收。 下次渲染时候，再次生成新的线程。 尽管是同一个View对象，它的两次渲染操纵有很大的几率已经不是同一个线程。 当然，事件的监听线程则另算。 二在于实现接口的不同，四大组件中除BroadcastReceiver以外，都实现了容器回调的接口，而视图则主要实现渲染回调，或者键盘，鼠标事件的回调。
结合实践再看看ViewGroup的一些方法：
针对这些方法有这样一些理解：
1.虽然ViewGroup继承自View, 但是 inflate方法是静态类方法，所以不会被ViewGroup继承。 因此，它不能自己通过充气来实例化自己。
2.addView，removeView 可以为它添加或者删除视图。 需要主要，删除的是视图对象。。。 切记切记切记。 在理解上总是会模糊，对象本身就具有唯一性。。。 此外，这个删除视图和增加视图，会触发渲染线程，也就是说对用户来说，这个类似开关了。 相当于系统自动调用了一个repaint()方法。 (awt编程的概念）。
3.虽然一个ViewGroup在实例化的时候不能自己充气，也就是无形的，但是它可以通过被setContentView() 生成的匿名（或者带有id的）对象，然后绑定。 这样的话，就好像自己一实例化的时候就有了很多的可视属性，但是实际情况是非也。。
---------------------------------------
注释： 本文有很多的观点都是属于自己的猜测，并没有实际验证过，仅供自己思索之用，如有错误，概不负责！嘻嘻