【ecplise如何导入源码】【权益包源码下载】【镜像站源码下载】findview源码

时间:2024-12-24 07:24:46 编辑:新宝5源码 来源:围堵神经猫 源码

1.JD-GUI的基础知识:
2.Android UI绘制之View绘制的工作原理
3.butterknife源码详解

findview源码

JD-GUI的基础知识:

        大家都知道,将源代码转换成二进制执行代码的过程叫“编译”,比如将C源代码编译成exe可执行文件;那么把二进制执行代码的过程就叫“反编译”,比如把exe转换为C源代码就叫“反编译”。

       ç”±äºŽä¸»æµçš„C的编译器都进行了代码的优化,因此把C编译生成的exe文件反编译成C代码非常困难。但是像Java、.net这样基于虚拟机技术的编程语言则反编译非常容易,Java平台下有Jad、Jode、JD等反编译器,.net平台下则有Reflector等反编译器,反编译质量非常高,甚至和源代码几乎没什么差别。 反编译得到的代码是非常接近于源代码,但是或多或少与源代码有一些差异的,比如一些表达式被优化掉了,比如:

       ä¸‹é¢çš„源代码:

       int i=1+1;

       å­¦è¿‡ã€Šç¼–译原理》的同学知道有“常量优化”这个编译优化算法,因此上边的源代码一般会被优化为:int i=2;

       ç”±äºŽåœ¨ç¼–译过程中已经进行了优化,把“1+1”这个原始的信息丢掉了,因此反编译出来的代码只能是:

       int i=2;

       å¯ä»¥çœ‹åˆ°åç¼–译得到的代码和源代码是有区别的。

       æ¯”如:andriod中

       download = (Button)findViewById(R.id.xiaz);

       è¢«ä¼˜åŒ–成了download = (Button)findViewById(0x7f); 由于Java、.net这样的基于虚拟机技术的语言都是采用了ByteCode的二进制结构,因此很容易将ByteCode转化为“抽象语法树”(简称AST,《编译原理》这门课中的概念),然后采用反编译器就可以将AST转换为代码了。

       æœ¬è¯æ¡èµ„料来源于soso网友此处参考资料无法引用对于作者表示抱歉!!!

       è¿˜æœ‰æœ€é‡è¦çš„,那就是jd-gui只能查看,不能够将那些文件转换成.java文件。

Android UI绘制之View绘制的工作原理

        这是AndroidUI绘制流程分析的第二篇文章,主要分析界面中View是如何绘制到界面上的具体过程。

        ViewRoot 对应于 ViewRootImpl 类,它是连接 WindowManager 和 DecorView 的纽带,View的三大流程均是通过 ViewRoot 来完成的。在 ActivityThread 中,当 Activity 对象被创建完毕后,会将 DecorView 添加到 Window 中,源码同时会创建 ViewRootImpl 对象,并将 ViewRootImpl 对象和 DecorView 建立关联。

        measure 过程决定了 View 的宽/高, Measure 完成以后,可以通过 getMeasuredWidth 和 getMeasuredHeight 方法来获取 View 测量后的宽/高,在几乎所有的情况下,它等同于View的最终的宽/高,但是特殊情况除外。 Layout 过程决定了 View 的四个顶点的坐标和实际的宽/高,完成以后,可以通过 getTop、getBottom、getLeft 和 getRight 来拿到View的四个顶点的位置,可以通过 getWidth 和 getHeight 方法拿到View的最终宽/高。 Draw 过程决定了 View 的显示,只有 draw 方法完成后 View 的内容才能呈现在屏幕上。

        DecorView 作为顶级 View ,一般情况下,它内部会包含一个竖直方向的 LinearLayout ,在这个 LinearLayout 里面有上下两个部分,上面是标题栏,下面是内容栏。在Activity中,我们通过 setContentView 所设置的布局文件其实就是被加到内容栏中的,而内容栏id为 content 。可以通过下面方法得到 content:ViewGroup content = findViewById(R.android.id.content) 。通过 content.getChildAt(0) 可以得到设置的 view 。 DecorView 其实是一个 FrameLayout , View 层的事件都先经过 DecorView ,然后才传递给我们的 View 。

        MeasureSpec 代表一个位的int值,高2位代表 SpecMode ,低位代表 SpecSize , SpecMode 是指测量模式,而 SpecSize 是指在某种测量模式下的规格大小。

        SpecMode 有三类,如下所示:

        UNSPECIFIED

        EXACTLY

        AT_MOST

        LayoutParams需要和父容器一起才能决定View的MeasureSpec,从而进一步决定View的宽/高。

        对于顶级View,即DecorView和普通View来说,MeasureSpec的转换过程略有不同。对于DecorView,其MeasureSpec由窗口的尺寸和其自身的LayoutParams共同确定;

        对于普通View,其MeasureSpec由父容器的MeasureSpec和自身的Layoutparams共同决定;

        MeasureSpec一旦确定,onMeasure就可以确定View的测量宽/高。

        小结一下

        当子 View 的宽高采用 wrap_content 时,不管父容器的模式是精确模式还是最大模式,子 View 的模式总是最大模式+父容器的剩余空间。

        View 的工作流程主要是指 measure 、 layout 、 draw 三大流程,即测量、布局、绘制。其中 measure 确定 View 的测量宽/高, layout 确定 view 的最终宽/高和四个顶点的位置,而 draw 则将 View 绘制在屏幕上。

        measure 过程要分情况,如果只是一个原始的 view ,则通过 measure 方法就完成了其测量过程,如果是一个 ViewGroup ,除了完成自己的测量过程外,还会遍历调用所有子元素的 measure 方法,各个子元素再递归去执行这个流程。

        如果是一个原始的 View,那么通过 measure 方法就完成了测量过程,在 measure 方法中会去调用 View 的 onMeasure 方法,View 类里面定义了 onMeasure 方法的默认实现:

        先看一下 getSuggestedMinimumWidth 和 getSuggestedMinimumHeight 方法的源码:

        可以看到, getMinimumWidth 方法获取的是 Drawable 的原始宽度。如果存在原始宽度(即满足 intrinsicWidth > 0),那么直接返回原始宽度即可;如果不存在原始宽度(即不满足 intrinsicWidth > 0),那么就返回 0。

        接着看最重要的 getDefaultSize 方法:

        如果 specMode 为 MeasureSpec.UNSPECIFIED 即未指定模式,那么返回由方法参数传递过来的尺寸作为 View 的测量宽度和高度;

        如果 specMode 不是 MeasureSpec.UNSPECIFIED 即是最大模式或者精确模式,那么返回从 measureSpec 中取出的 specSize 作为 View 测量后的宽度和高度。

        看一下刚才的表格:

        当 specMode 为 EXACTLY 或者 AT_MOST 时,View 的布局参数为 wrap_content 或者 match_parent 时,给 View 的 specSize 都是 parentSize 。这会比建议的最小宽高要大。这是不符合我们的预期的。因为我们给 View 设置 wrap_content 是希望View的大小刚好可以包裹它的内容。

        因此:

        如果是一个 ViewGroup,除了完成自己的 measure 过程以外,还会遍历去调用所有子元素的 measure 方法,各个子元素再递归去执行 measure 过程。

        ViewGroup 并没有重写 View 的 onMeasure 方法,但是它提供了 measureChildren、measureChild、measureChildWithMargins 这几个方法专门用于测量子元素。

        如果是 View 的话,那么在它的 layout 方法中就确定了自身的位置(具体来说是通过 setFrame 方法来设定 View 的四个顶点的位置,即初始化 mLeft , mRight , mTop , mBottom 这四个值), layout 过程就结束了。

        如果是 ViewGroup 的话,那么在它的 layout 方法中只是确定了 ViewGroup 自身的位置,要确定子元素的位置,就需要重写 onLayout 方法;在 onLayout 方法中,会调用子元素的 layout 方法,子元素在它的 layout 方法中确定自己的位置,这样一层一层地传递下去完成整个 View 树的 layout 过程。

        layout 方法的作用是确定 View 本身的位置,即设定 View 的四个顶点的位置,这样就确定了 View 在父容器中的位置;

        onLayout 方法的作用是父容器确定子元素的位置,这个方法在 View 中是空实现,因为 View 没有子元素了,在 ViewGroup 中则进行抽象化,它的子类必须实现这个方法。

        1.绘制背景( background.draw(canvas); );

        2.绘制自己( onDraw );

        3.绘制 children( dispatchDraw(canvas) );

        4.绘制装饰( onDrawScrollBars )。

        dispatchDraw 方法的调用是在 onDraw 方法之后,也就是说,总是先绘制自己再绘制子 View 。

        对于 View 类来说, dispatchDraw 方法是空实现的,对于 ViewGroup 类来说, dispatchDraw 方法是有具体实现的。

        通过 dispatchDraw 来传递的。 dispatchDraw 会遍历调用子元素的 draw 方法,如此 draw 事件就一层一层传递了下去。dispatchDraw 在 View 类中是空实现的,在 ViewGroup 类中是真正实现的。

        如果一个 View 不需要绘制任何内容,那么就设置这个标记为 true,系统会进行进一步的优化。

        当创建的自定义控件继承于 ViewGroup 并且不具备绘制功能时,就可以开启这个标记,便于系统进行后续的优化;当明确知道一个 ViewGroup 需要通过 onDraw 绘制内容时,需要关闭这个标记。

        参考:《Android开发艺术探索》

butterknife源码详解

       深入剖析butterknife源码,以揭示其实现机制和效率优化。源码作为Android开发者,源码butterknife无疑提升了开发效率,源码ecplise如何导入源码但其内部工作原理往往被忽视。源码本文将通过运行时注解的源码学习,系统解析butterknife的源码实现原理。

       若之前对注解使用了解不足,源码强烈建议先学习注解基础知识。源码

       通过直观示意图,源码可以清晰看到butterknife的源码权益包源码下载模块结构及其示例代码应用。

       模块划分如下:

       app : butterknife

       api : butterknife-annotations

       compiler : butterknife-compiler

       作用于变量的源码BindView注解,通过指定的源码资源id调用findViewById()方法,并将找到的源码控件赋值给相应变量。同时,源码onClick注解通过指定id设置onClickListener,镜像站源码下载并触发相关方法。

       使用Butterfield.bind(this);方法是关键,它通过自定义处理器解析注解并生成对应代码。

       但butterknife功能强大,本文仅聚焦于BindView和onClick注解。计数制的源码BindView注解通过IdRes注解限定资源id,而onClick注解结合ListenerClass注解,实现事件监听。

       运行时注解ListenerClass实现解析,通过自定义处理器解析编译时注解。互助盘源码网重点在于ButterknifeProcessor.process()方法,其中findAndParseTargets()查找并解析所有注解,bindingClass.brewJava()生成代码。

       findAndParseTargets()解析BindView等注解,生成BindingClass实例存储初始化信息。bindingClass.brewJava()生成对应ViewBinder类,实现view初始化。

       生成的ViewBinder实例通过Butterfield.bind(this);方法调用,该方法通过反射实例化ViewBinder并调用其bind()方法。

       ViewBinder类内部封装了findViewById()、setOnClickListener()等方法,将注解信息对应到具体操作,简化控件初始化和事件处理。

       总结,butterknife通过编译时注解解析和运行时动态生成ViewBinder类,实现高效、便捷的控件绑定和事件监听。这种机制虽然引入了反射,但在内存缓存优化下,整体性能优势显著。

       关键点在于合理使用注解,避免将变量声明为private,以确保butterknife能够正确绑定和初始化控件。