这次记录的是图形编程awt,本来应该是放到后面看的，但是由于后面的学习的对这块的知识要求的比较迫切。怕以后没有机会看便提前看了一下，事实上也不可能全部看完，因为 内容实在是太多，因此还是按照惯例，以时间线的方式进行笔记的记录。。 

   在awt包下中的类下面稍加分析，应该能发现哪个是老大，嘿嘿，就是Component。

       上两张图是它的一些依赖关系。。 

    之前看的时候并不太理解所谓的轻量级容器和重量级的容器，事实上它们显示出来的可能大差不差，但是它们的意义差别还是挺大的。。  具体的可以百度下又十分详尽的解释。    另外需要注意一点就是这个容器是针对图形的，背景（一种逻辑上的背景）。

    这是第一遍看的时候的理解，与前辈们的看法有一些出入。。 不出意外的话我肯定是错的，但是这种求知的精神值得肯定哈哈哈。  事实上性能的理解大牛们的解释是：   针对于重量级组件，它们的渲染依赖于本地操作系统，导致移植性不强。。至于代码空间的优化嘛，这倒不是很清楚，虽然编译优化的时候又空间优化这一说，但是通常是要让位于时间优化的。。  所以或许也有影响。。

   这是自己的一些想法，请大家参考，同时提供给将来的自己回味。

    这里当时在记录的时候出了点小意外，导致原本十分精彩的内容和思维碰撞的火花都丢了，之后只能凭着回忆写一点点，有一点小情绪是可以被理解的。

    这里只是看了下皮毛，后面会具体分析这个模式。 

    上图是一些小感想请大家参考嘿嘿。

    这里当时看的时候并没有理解到一个重绘的概念，并且由于是为了查看一个渲染的实现的目的，忽略了很多的其它外在因素，这使得理解可能是错误的，但是没办法，对于学习应该是有积极作用的，因此就将错就错吧。 

    这里的论调我认为还是颇有点意思的，对以后多媒体文件的理解应该有一些自己的见解。。 

      到这里，中途已经省去了很多的类，接口，跳转等等，因为是为了某一个目的而去追踪的，因此逻辑很乱。

    自从在实践中用了设计模式，体会到了它的强大之处后，总会在不知不觉间用设计模式去套很多的东西，尽管有时候反而降低了效率。我想这也是有些人说滥用设计模式，或者说为设计模式而设计模式吧。。 但是没办法我空寂布局我寄几啊！   

      这里当时被我认为是最终绘制的支撑实现，现在看来有待商榷。

    也算自己的一些猜想，但是有可能是错误的。  不过对于我自己而言认为意义还是蛮大的。

     图形渲染与流的移动（也就是数据的移动）联合起来，我认为还是比较有意思的。。   反思一下，计算机从被书籍之初用于支撑计算，数学运算，到后来的逻辑处理。。   现在逻辑处理的功能应该是要远大于数学处理的需求的。。 但是没有数学处理的话，逻辑处理就很难走下去，因此它们并非对立关系。。      

     现在这样一个发达的互联网体系，做的最多的不就是数据的传输吗？  不论数据的类型是什么，对数据做了一些怎样的处理，它们本质上就是数据的移动，或者说流动。。  很难理解，也很难想象如此丰富的网络本质上就是一些物体（bit）移动中构成的。

    这里的理解抛开对错不说，我还是比较喜欢的额。 就再敲一遍吧：

        渲染的本质就是：    将一堆流转移倒合适的位置，然后相关的硬件隐式翻译，或者说： 只是读取，他自己不知道它在干什么，它只是在快速的读取，读取，读取。。。。运动 这个流存在的全部意义。。。  正如现代哲学所说，运动时绝对的，静止时相对的。 

    这便是某一个时间结点的一次调试的精力。。 晚安，好梦！！  虽然我可能还要看一部电影。。