1.suricata中的源码线程管理分析
2.谈谈RecyclerView中的缓存
3.Android 大厂面试常见客：RecyclerView 缓存机制
4.RecyclerView详解

suricata中的线程管理分析

       梳理suricata中线程管理

       在《suricata中DPDK收发包源码分析2》和《suricata中command的实现分析和自定义命令方法》中，suricata多线程处理已经涉及。解析关注DPDK的源码workers模式收包，我们聚焦关键线程：收包线程、解析FlowManager和FlowRecycler线程、源码StatsMgmtThread和StatsWakeupThread线程、解析源码安装 jdkUnixManager线程。源码线程启动流程包括创建线程变量、解析指定线程类型与入口函数、源码调用TmThreadCreate、解析TmThreadSetSlots等函数。源码各线程处理逻辑围绕调用slot上的解析Module，先初始化后执行逻辑处理。源码通过top工具可查看suricata创建线程，解析与理论线程对应。源码kernel源码怎么安装自定义命令threads-list与slots-list可分别查看线程列表与指定线程的slots。至此，suricata线程管理分析完成。欢迎有问题或需自定义命令源码的朋友加入网络技术开发交流群提问。对文章内容感兴趣的读者，记得关注哦。

谈谈RecyclerView中的缓存

       Android深入理解RecyclerView的缓存机制

        RecyclerView在项目中的使用已经很普遍了，可以说是项目中最高频使用的一个控件了。除了布局灵活性、丰富的动画，RecyclerView还有优秀的缓存机制，本文尝试通过源码深入了解一下RecyclerView中的缓存机制。

        RecyclerView做性能优化要说复杂也复杂，比如说布局优化，缓存，预加载等等。其优化的点很多，在这些看似独立的点之间，其实存在一个枢纽：Adapter。因为所有的ViewHolder的创建和内容的绑定都需要经过Adaper的两个函数onCreateViewHolder和onBindViewHolder。

        因此我们性能优化的本质就是要减少这两个函数的调用时间和调用的次数。如果我们想对RecyclerView做性能优化，必须清楚的了解到我们的每一步操作背后，onCreateViewHolder和onBindViewHolder调用了多少次。因此，了解RecyclerView的缓存机制是RecyclerView性能优化的基础。

        为了理解缓存的应用场景，本文首先会简单介绍一下RecyclerView的绘制原理，然后再分析其缓存实现原理。

        RecyclerView滑动时会触发onTouchEvent#onMove，回收及复用ViewHolder在这里就会开始。我们知道设置RecyclerView时需要设置LayoutManager,红包定制源码开发LayoutManager负责RecyclerView的布局，包含对ItemView的获取与复用。以LinearLayoutManager为例，当RecyclerView重新布局时会依次执行下面几个方法：

        上述的整个调用链：onLayoutChildren()->fill()->layoutChunk()->next()->getViewForPosition(),getViewForPosition()即是是从RecyclerView的回收机制实现类Recycler中获取合适的View，下面主要就来从看这个Recycler#getViewForPosition()的实现。

        上述逻辑用流程图表示：

        RecyclerView在Recyler里面实现ViewHolder的缓存，Recycler里面的实现缓存的主要包含以下5个对象：

        public final class Recycler {

        final ArrayList mAttachedScrap = new ArrayList<>();

        ArrayList mChangedScrap = null;

        RecyclerView在设计的时候讲上述5个缓存对象分为了3级。每次创建ViewHolder的时候，会按照优先级依次查询缓存创建ViewHolder。每次讲ViewHolder缓存到Recycler缓存的时候，也会按照优先级依次缓存进去。三级缓存分别是：

        使用自定义ViewCacheExtension后，view离屏后再回来不会走onBindViewHolder()方法。

        holder.setIsRecyclable(false)，这样的话每次都会走onCreateViewHolder()和onBindViewHolder()方法

        1.提前初始化viewHolder，放到缓存池中

        viewPool.putRecycledView(adapter.onCreateViewHolder(recyclerView, 1))

        2.提前初始化view，在onCreateViewHolder的时候去取view

        3.自定义ViewCacheExtension

        4.适当的增加cacheSize

        4.公用缓存池，比如多个viewPager+fragment场景使用，或者全局单利缓存池，感觉用户不大。

        有2中做法有值

        第一种

        第二种

        不会，因为prefetch（GapWorker中的一个方法）之后mViewCacheMax会变成mRequestedCacheMax + extraCache

        有2种方式可以让缓存失效

        第一种

        recyclerView.setItemViewCacheSize(-1)

        第二种

        recyclerView.setItemViewCacheSize(0)

        layoutManager.isItemPrefetchEnabled = false

        设置不缓存后，来回滑动让view进入屏幕离开屏幕，viewHolder的item时会多次走onBindViewHolder()方法。

Android 大厂面试常见客：RecyclerView 缓存机制

       RecyclerView的缓存机制在面试中经常被提及，掌握它有助于提高开发效率。

       我们将通过具体场景来解析RecyclerView的缓存机制，主要包括两个场景：滑动RecyclerView的缓存机制和RecyclerView首次加载的缓存机制。

       本文主要讲解滑动RecyclerView下的缓存机制。

       1.缓存层级

       背景知识：Recycler类负责回收和复用ViewHolder，其主要成员变量负责缓存。下面展示部分源码，fusionappjs脚本源码请注意注释（认真阅读注释很重要）。

       关于缓存层级的问题，其实并不重要。有人说有三层，有人说有四层。有人说有三层，因为认为自定义层不是设计框架源码书RecyclerView实现的，所以不算；也有人认为Scrap不是真正的缓存，所以不算。

       从源码来看，我更同意后者，Scrap不算一层缓存。因为在源码中，mCachedViews被称为first-level。至于为什么Scrap不算一层，我的理解是：因为这层的只是detach了，并没有remove，所以这层也没有缓存大小的概念，只要符合规则就会加入进去。

       2.场景分析：滑动中的RecyclerView缓存机制

       通过Android Studio的Profiles工具，我们可以看到调用流程。入口是ouTouchEvent。

       以下表格简要说明上图的流程都在做什么？

       通过上述表格，我们知道了最重要的东西就是scrollBy中调用了fill的方法。那么我们来看看fill在做什么？滑出去的View最后去哪里了呢？滑进来的View是怎么来的？（带着这个问题，我们一起来读源码！一定要带着），源码只留下了核心部分。

       3.总结

       做一个总结，在分析源码前，我们提出了三个问题，现在来看看答案是什么吧。

       这里针对以往面试中常见的题，做了些整理归档，该学习手册的内容还在持续更新中，有需要的可以直接点击此处↓↓↓或私信回复：进行获取参考学习！！！

RecyclerView详解

       RecyclerView作为ListView和GridView的替代，但是和ListView不一样的是，RecyclerView不再负责Item的摆放等显示方面的功能，所有和布局、绘制等方面的工作都拆分成不同的类进行管理。

        RecyclerView与ListView的不同点，主要在于以下几个特性：

        如果你想使用RecyclerView，需要做以下操作：

        我们可以从下图更直观的了解到RecyclerView的基本结构：

        RecyclerView不再负责Item视图的布局及显示，所以RecyclerView也没有为Item开放OnItemClick等点击事件。可以通过以下方式进行：因为在ViewHolder我们可以拿到每个Item的根布局，所以如果我们为根布局设置单独的OnClick监听并将其开放给Adapter，那么就可以在组装RecyclerView时就能够设置ItemClickListener，只不过这个Listener不是设置到RecyclerView上而是设置到Adapter。

        多Item布局，getItemViewType方法，用法和ListView没有任何区别，这里要注意的是函数onCreateViewHolder(ViewGroup parent, int viewType)的第二个参数就是View的类型，可以根据这个类型判断去创建不同item的ViewHolder，从而完成多Item布局。

        在RecylerView中，Adapter扮演着两个角色：一是根据不同viewType创建与之相应的的itemView，二是访问数据集合并将数据绑定到正确的View上。这就需要我们实现以下两个函数：

        另外我们还需要重写另一个方法，像ListView-Adapter那样，同样地告诉RecyclerView-Adapter列表Items的总数：

        ViewHolder描述RecylerView中某个位置的itemView和元数据信息，属于Adapter的一部分，其实现类通常用于保存findViewById的结果。 主要元素组成有：

        关于ViewHolder，这里主要介绍mFlags：

        FLAG_BOUND——ViewHolder已经绑定到某个位置，mPosition、mItemId、mItemViewType都有效

        FLAG_UPDATE——ViewHolder绑定的View对应的数据过时需要重新绑定，mPosition、mItemId还是一致的

        FLAG_INVALID——ViewHolder绑定的View对应的数据无效，需要完全重新绑定不同的数据

        FLAG_REMOVED——ViewHolder对应的数据已经从数据集移除

        FLAG_NOT_RECYCLABLE——ViewHolder不能复用

        FLAG_RETURNED_FROM_SCRAP——这个状态的ViewHolder会加到scrap list被复用。

        FLAG_CHANGED——ViewHolder内容发生变化，通常用于表明有ItemAnimator动画

        FLAG_IGNORE——ViewHolder完全由LayoutManager管理，不能复用

        FLAG_TMP_DETACHED——ViewHolder从父RecyclerView临时分离的标志，便于后续移除或添加回来

        FLAG_ADAPTER_POSITION_UNKNOWN——ViewHolder不知道对应的Adapter的位置，直到绑定到一个新位置

        FLAG_ADAPTER_FULLUPDATE——方法addChangePayload(null)调用时设置

        LayoutManager主要作用是，测量和摆放RecyclerView中itemView，以及当itemView对用户不可见时循环复用处理。

        当我们想在某些item上加一些特殊的UI时，往往都是在itemView中先布局好，然后通过设置可见性来决定哪些位置显示不显示。RecyclerView将itemView和装饰UI分隔开来，装饰UI即ItemDecoration，主要用于绘制item间的分割线、高亮或者margin等。其源码如下：

        过去AdapterView的item项操作往往是没有动画的。现在RecyclerView的ItemAnimator使得item的动画实现变得简单而样式丰富，我们可以自定义item项不同操作（如添加，删除）的动画效果。

        Recycler用于管理已经废弃或与RecyclerView分离的（scrapped or detached）item view，便于重用。Scrapped view指依附于RecyclerView，但被标记为可移除或可复用的view。

        LayoutManager获取Adapter某一项的View时会使用Recycler。当复用的View有效（clean）时，View能直接被复用，反之若View失效（dirty）时，需要重新绑定View。对于有效的View，如果不主动调用request layout，则不需要重新测量大小就能复用。在分析Recycler的复用原理之前，我们先了解下如下两个类：

        RecyclerViewPool用于多个RecyclerView之间共享View。只需要创建一个RecyclerViewPool实例，然后调用RecyclerView的setRecycledViewPool(RecycledViewPool)方法即可。RecyclerView默认会创建一个RecyclerViewPool实例。

        通过源码我们可以看出mScrap是一个<viewType, List>的映射， mMaxScrap 是一个<viewType, maxNum>的映射，这两个成员变量代表可复用View池的基本信息。调用 setMaxRecycledViews(int viewType, int max) 时，当用于复用的 mScrap 中viewType对应的ViewHolder个数超过maxNum时，会从列表末尾开始丢弃超过的部分。调用 getRecycledView(int viewType) 方法时从 mScrap 中移除并返回viewType对应的List的末尾项。

        ViewCacheExtension是一个由开发者控制的可以作为View缓存的帮助类。调用Recycler.getViewForPosition(int)方法获取View时，Recycler先检查attached scrap和一级缓存，如果没有则检查ViewCacheExtension.getViewForPositionAndType(Recycler, int, int)，如果没有则检查RecyclerViewPool。注意：Recycler不会在这个类中做缓存View的操作，是否缓存View完全由开发者控制。

        现在大家熟悉了RecyclerViewPool和ViewCacheExtension的作用后，下面开始介绍Recycler。 如下是Recycler的几个关键成员变量和方法：

        获取某个位置需要展示的View，先检查是否有可复用的View，没有则创建新View并返回。具体过程为：

        注：以上每步匹配过程都可以匹配position或itemId（如果有stableId）。