【dede地方门户源码】【quick select c 源码】【his调用医保源码】view标签源码_view 标签

来源:微源码3.15.

1.scrollto和scrollby的区别
2.View 绘制流程源码分析
3.ParaView 源码编译教程
4.Android UI绘制之View绘制的工作原理
5.Android 14 HWUI 源码研究 View Canvas RenderThread ViewRootImpl skia
6.setContentView()及LayoutInflater布局加载源码分析

view标签源码_view 标签

scrollto和scrollby的区别

       View类的源代码如下所示,mScrollX记录的是当前View针对屏幕坐标在水平方向上的偏移量,而mScrollY则是记录的时当前View针对屏幕在竖值方向上的偏移量。

        从以下代码我们可以得知,scrollTo就是把View移动到屏幕的X和Y位置,也就是绝对位置。而scrollBy其实就是调用的scrollTo,但是参数是当前mScrollX和mScrollY加上X和Y的位置,所以ScrollBy调用的是相对于mScrollX和mScrollY的位置。我们在上面的代码中可以看到当我们手指不放移动屏幕时,就会调用scrollBy来移动一段相对的距离。而当我们手指松开后,会调用mScroller.startScroll(mUnboundedScrollX,标签标签 0, delta, 0, duration);来产生一段动画来移动到相应的页面,在这个过程中系统回不断调用computeScroll(),我们再使用scrollTo来把View移动到当前Scroller所在的绝对位置。

        /

**

        * Set the scrolled position of your view. This will cause a call to

        * { @link #onScrollChanged(int, int, int, int)} and the view will be

        * invalidated.

        * @param x the x position to scroll to

        * @param y the y position to scroll to

        */

        public void scrollTo(int x, int y) {

        if (mScrollX != x || mScrollY != y) {

        int oldX = mScrollX;

        int oldY = mScrollY;

        mScrollX = x;

        mScrollY = y;

        invalidateParentCaches();

        onScrollChanged(mScrollX, mScrollY, oldX, oldY);

        if (!awakenScrollBars()) {

        invalidate(true);

        }

        }

        }

        /

**

        * Move the scrolled position of your view. This will cause a call to

        * { @link #onScrollChanged(int, int, int, int)} and the view will be

        * invalidated.

        * @param x the amount of pixels to scroll by horizontally

        * @param y the amount of pixels to scroll by vertically

        */

        public void scrollBy(int x, int y) {

        scrollTo(mScrollX + x, mScrollY + y);

        }

View 绘制流程源码分析

       在View的绘制流程中,ViewRootImpl的源码setView主流程涉及的关键步骤包括设置PFLAG_FORCE_LAYOUT和PFLAG_INVALIDATED。这一步骤在执行时,标签标签触发了View的源码重绘逻辑。

       接下来,标签标签当View收到需要重绘的源码dede地方门户源码信号后,会执行invalidate方法。标签标签这个方法首先计算出需要重绘的源码dirty区域,然后从下向上,标签标签最终调用到ViewRootImpl的源码scheduleTraversals方法。这个过程中,标签标签脏区域的源码范围逐步扩大,直至整个View需要进行重绘。标签标签

       在View的源码绘制流程中,PFLAG_FORCE_LAYOUT和PFLAG_INVALIDATED的标签标签使用至关重要。它们的设置触发了视图的重绘和布局过程,保证了UI在用户操作或其他事件触发时能够及时响应和更新。通过这种方式,系统确保了用户界面的实时性和交互性。

       具体来说,当View收到布局或尺寸变化的信号时,会调用requestLayout方法,同时设置PFLAG_FORCE_LAYOUT标志。这个标志告诉系统,quick select c 源码当前布局需要强制执行,即使布局尚未完成,也应立即进行更新。同时,invalidate方法的调用,会触发PFLAG_INVALIDATED标志的设置,表明视图需要重绘。

       在ViewRootImpl中,scheduleTraversals方法是负责组织和执行视图层级中所有视图的重绘和布局的。它会根据脏区域和布局标志的设置,合理安排视图的更新顺序,确保系统的性能和用户体验。

       总结整个流程,View的绘制和布局机制通过一系列的标志(如PFLAG_FORCE_LAYOUT和PFLAG_INVALIDATED)和方法(如requestLayout和invalidate)来协调和控制。这些机制使得系统能够高效地响应用户操作,实现流畅的UI交互。通过深入理解这些源码细节,开发者能够更好地优化UI性能,提高用户体验。

ParaView 源码编译教程

       ParaView-5..0的源码在年月日,由作者陌尘分享了一个Windows H2平台下的编译教程,使用了Visual Studio 、CMake 3..1 x版本,his调用医保源码以及Qt 5..、Python 3..8和Microsoft MPI v.1.2作为依赖。请注意,编译过程和环境设置可能需要根据个人的设备和需求进行调整,参考链接为Building ParaView。

       步骤1:首先,确保从ParaView官网下载最新源码,GitHub上的版本可能缺少VTK模块,因此直接从官方获取是必要的。

       步骤2:接着,进行CMake配置,这是编译过程的关键步骤,通过CMake工具将源代码与编译器和依赖项连接起来,生成可编译的项目文件。

       步骤3:配置完毕后,使用Visual Studio 打开生成的项目文件,开始VS编译过程。确保所有依赖项已经正确安装并配置,然后启动编译,生成ParaView的可执行文件。

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开发艺术探索》

Android HWUI 源码研究 View Canvas RenderThread ViewRootImpl skia

       HUWUI是Android系统中负责应用可视化元素绘制的核心组件,其架构主要在C++层实现,从Java层接收View绘制信息,电影 小程序 源码通过唯一的渲染线程使用skia技术完成渲染任务。整体上,从应用程序到UI线程,再到渲染线程,形成了清晰的层级关系。

       HUWUI的构建主要包括三个核心类,它们分别是:RecordingCanvas、Canvas、RenderNode、RenderProxy、RenderThread、CanvasContext、IRenderPipeline。在Java层,主要涉及两类Canvas,RecordingCanvas用于记录绘制指令,Canvas则是直接用于渲染。RecordingCanvas在构造时创建,而Canvas在调用时创建。这两个类在C++层分别对应SkiaRecordingCanvas和SkiaCanvas,后者直接引用SkCanvas。

       在全局循环中,UI线程与渲染线程之间的电商源码销售协同操作至关重要。具体流程包括:新创建Activity后,附着到对应的PhoneWindow,然后调用PhoneWindow的setContentView方法,将View添加到DecorView作为子节点。接着,DecorView与ViewRootImpl对接,完成View的更新与渲染。整个过程包含了measure、layout和draw等复杂子流程。

       渲染线程创建与核心对象紧密关联,主要包括RenderProxy、RenderThread和DrawFrameTask。RenderProxy负责Java层信息的衔接,RenderThread作为进程唯一的渲染线程,持有DrawFrameTask和CanvasContext,完成一帧的绘制任务。指令记录流程的核心在于使用C++层的RecordingCanvas将View属性和绘制信息记录到DisplayList中,进而完成指令的渲染。

       Surface、ANativeWindow、EGLSurface的创建流程在ViewRootImpl的performTraversals函数中初始化。ReliableSurface的封装和EGL与Skia环境的创建主要在RenderThread的requireGlContext函数中实现。从源码分析,这一过程通常在三个地方调用。

       View树与RenderNode树之间的协作关系明确,一个Application进程对应多个Activity,每个Activity与一个PhoneWindow绑定,PhoneWindow持有DecorView,DecorView对应一个ViewRootImpl,而ViewRootImpl与ThreadedRender模块对接。ThreadedRender与C++层的RenderProxy一一对应,RenderProxy持有关键对象,如RenderThread、CanvasContext、DrawFrameTask等。RenderThread是单例模式,进程唯一,负责一帧绘制的逻辑。

       在RenderPipeline模块中,关键操作包括makeCurrent、draw和swapBuffers。Native Canvas在这一过程中扮演了桥梁角色,接收Java API调用,而RecordingCanvas完成Op记录,最终DisplayListData存储这些Op。

       skia的核心资源主要在三个使用场景中发挥作用,具体细节需深入分析,这些资源对于实现高效、稳定的渲染效果至关重要。

setContentView()及LayoutInflater布局加载源码分析

       setContentView()和LayoutInflater布局加载源码深度解析

       当我们在Android应用中调用setContentView()时,其实涉及到了一系列复杂的流程。这个过程主要分为三个步骤:系统布局加载、LayoutInflater初始化以及LayoutInflater布局加载。

       首先,setContentView()方法通过Activity的PhoneWindow对象加载布局。在判断mContentParent是否为空后,会创建DecorView,然后将自定义的activity_main_layout加载到mContentParent,这个mContentParent对应id为R.id.content的Layout。接着,系统会加载一个包含R.id.content的系统布局到DecorView中。

       LayoutInflater的初始化过程关键在于其作为系统服务注册在SystemServiceRegistry中。当我们通过LayoutInflater.from(this)获取实例时,实际上是通过SystemServiceRegistry获取并初始化LayoutInflater的。

       LayoutInflater的布局加载流程则涉及xml预编译、View的反射创建以及递归解析子布局。在inflate方法中,会先检查根节点标签是否为"merge",然后决定是否递归加载子布局并决定是否添加到父布局中。View的创建则可能通过自定义的Factory进行拦截和定制。

       总结来说,setContentView()和LayoutInflater的交互使得我们能够灵活地加载和定制Activity的布局。通过理解这些源码细节,开发者可以更好地控制和优化应用的界面显示。

跑马灯带你深入浅出TextView的源码世界

       本文将深入浅出地解析Android系统中TextView的跑马灯动画源码,以解决开发者在实际开发中遇到的问题。文章将通过一个具体问题作为出发点,引导读者从源码的角度分析和解决问题。

       首先,面临的问题是Android 6.0及以上系统中点击“添加购物车”按钮时,TextView的跑马灯动画会出现跳动现象(动画重置,滚动从头开始)。面对这一现象,开发者往往需要从源码层面进行深入分析。

       为了解决问题,文章建议采用以下步骤进行源码分析:

       搜索“Android TextView 跑马灯原理”,找到关键代码实现,特别是与跑马灯启动相关的startMarquee()方法。

       使用Android Studio搜索TextView并查看类接口图,找到startMarquee()方法的实现,对其进行初步分析。

       确定找到的方法正确后,继续了解整个框架的实现流程,绘制主流程图。

       接下来,文章将深入分析跑马灯动画的实现机制,包括TextView、Marquee内部类以及Choreographer系统。

       在分析中,文章指出Choreographer是一个用于管理动画、输入和绘制的系统类,它通过监听DisplayEventReceiver来接收系统信号,并在每一帧中回调以确保动画的平滑性。在Choreographer中,Marquee会计算偏向值,然后触发TextView的刷新来实现动画效果。

       文章进一步解析了Choreographer的实现原理以及Marquee在postFrameCallback中的具体操作,包括计算时间差、移动位移以及触发TextView刷新的过程。

       最后,文章对问题进行了详细分析,揭示了导致跑马灯动画重置的根源在于“购物车”按钮的setText方法触发了requestLayout,从而导致了视图重绘。通过修改按钮的布局属性,问题得以解决。

       总结而言,文章通过问题分析和源码解析,为开发者提供了一条清晰的路径,从现象出发,深入源码,最终找到问题的根本原因并解决,从而提升对Android系统内核的理解和应用能力。

怎么查看手机浏览器的源代码

       支持查看网页源码的手机浏览器有以下几种:

       1、火狐Firefox浏览器手机版,可以通过于地址栏中的原URL之前输入view-source指令,单击后方的箭头按钮即可查看该网页的源代码;

       2、谷歌浏览器手机版,可以通过打开浏览器右上角的菜单按钮,在菜单列表中的更多工具选项中找到开发者工具按钮,点击其中的Elements按钮即可查看该网页的源代码;

       3、UC浏览器手机版,可以通过长按UC浏览器地址栏中的原URL,在弹出的选项中选择查看源代码按钮,即可查看该网页的源代码。

文章所属分类:百科频道,点击进入>>