BaseRecyclerViewAdapterHelper 源码分析(1)

本贴最后更新于 2816 天前,其中的信息可能已经水流花落

BaseViewHolder 源码学习

接下来假设一个场景来分析,假设我们要给一个 TextView 控件设置一段文字进行显示,一般我们会使用该方法:

holder.setText(R.id.xxx,"hello world");
```java

源码:
```java
public BaseViewHolder setText(int viewId, CharSequence value) {
    TextView view = getView(viewId);
  view.setText(value);
 return this;}

可以看到,源码里第一步会调用 getView(viewId)方法,我们来看下该方法的代码

@SuppressWarnings("unchecked")
public <T extends View> T getView(int viewId) {
    View view = views.get(viewId);
 if (view == null) {
        view = convertView.findViewById(viewId);
  views.put(viewId, view);
  }
    return (T) view;
}

代码中,他会先到 views 中根据 view 的 id 进行查找,看是否前面已经实时化该 view,如果实例化来,就直接拿来用就好。

如果 view==null 我们会通过 convertView 去调用我们再熟悉不过的 findViewById 进行创建,然后把创建的 view 实例缓存到 views 中方便下次使用,上面我们说到 convertView 是 viewholder 的 ItemView,也就是每个 item 的总布局。其实是在初始化 BaseViewHolder 的时候传进来的,源码所示:

public BaseViewHolder(final View view) {
    super(view);
 this.views = new SparseArray();
 this.childClickViewIds = new LinkedHashSet<>();
 this.itemChildLongClickViewIds = new LinkedHashSet<>();
 this.nestViews = new HashSet<>();
  convertView = view;

}

而 BseVIewHolder 的创建又是从我们的 BaseQuickAdapter 里面执行的,下一篇会分析 BaseQuickAdapter 的代码。

剩下的事情就相当简单了,如果从 views 缓存队列中找到了我们需要的 view,直接调用 setText 设置文字,没找到就先创建,然后压入缓存,然后再调用。其余的 api 调用方法执行的逻辑基本一样。

BaseViewHolder 里还有三个比较重要的成员

  • HashSet nestViews;
  • LinkedHashSet childClickViewIds;
  • LinkedHashSet itemChildLongClickViewIds;

这是跟点击事件相关的,后面会单独出一篇来进行学习。
BaseQuickAdapter 之生命周期分析
BaseQuickAdapter 实例化第一步当然是调用我们的构造方法:

public BaseQuickAdapter(int layoutResId, List<T> data) {
    this.mData = data == null ? new ArrayList<T>() : data;
 if (layoutResId != 0) {
        this.mLayoutResId = layoutResId;
  }
}
public BaseQuickAdapter(List<T> data) {
    this(0, data);
}

public BaseQuickAdapter(int layoutResId) {
    this(layoutResId, null);
}

可以看到,加入你不传入 data,内部会先为我们创建一个空的 list,

然后在构造时记录我们的布局资源 id。

那么,布局资源 id 会在什么时候用呢,当然是在 onCreateViewHolder 方法中创建 viewholder 的时候,那么我没继续看 onCreateViewHolder 方法的代码。而调用 onCreteViewHolder 前会先调用 getItemViewType 方法。

@Override
public int getItemViewType(int position) {
    if (getEmptyViewCount() == 1) {
        boolean header = mHeadAndEmptyEnable && getHeaderLayoutCount() != 0;
 switch (position) {
            case 0:
                if (header) {
                    return HEADER_VIEW;
  } else {
                    return EMPTY_VIEW;
  }
            case 1:
                if (header) {
                    return EMPTY_VIEW;
  } else {
                    return FOOTER_VIEW;
  }
            case 2:
                return FOOTER_VIEW;
 default:
                return EMPTY_VIEW;
  }
    }
    autoLoadMore(position);
 int numHeaders = getHeaderLayoutCount();
 if (position < numHeaders) {
        return HEADER_VIEW;
  } else {
        int adjPosition = position - numHeaders;
 int adapterCount = mData.size();
 if (adjPosition < adapterCount) {
            return getDefItemViewType(adjPosition);
  } else {
            adjPosition = adjPosition - adapterCount;
 int numFooters = getFooterLayoutCount();
 if (adjPosition < numFooters) {
                return FOOTER_VIEW;
  } else {
                return LOADING_VIEW;
  }
        }
    }
}

从代码可以看到,他是根据我们 data 的 index 值以及我们是否开启空视图之类的数据来决定在 onCreateViewHolder 中应该返回什么类型的 viewHolder。

我们继续看 onCreateViewHolder 的代码:

@Override
public K onCreateViewHolder(ViewGroup parent, int viewType) {
    K baseViewHolder = null;
 this.mContext = parent.getContext();
 this.mLayoutInflater = LayoutInflater.from(mContext);
 switch (viewType) {
        case LOADING_VIEW:
            baseViewHolder = getLoadingView(parent);
 break; case HEADER_VIEW:
            baseViewHolder = createBaseViewHolder(mHeaderLayout);
 break; case EMPTY_VIEW:
            baseViewHolder = createBaseViewHolder(mEmptyLayout);
 break; case FOOTER_VIEW:
            baseViewHolder = createBaseViewHolder(mFooterLayout);
 break; default:
            baseViewHolder = onCreateDefViewHolder(parent, viewType);
  bindViewClickListener(baseViewHolder);
  }
    baseViewHolder.setAdapter(this);
 return baseViewHolder;

}

但是,在上面的代码中我们并没有看到有使用我们的 mLayoutResId 资源 id 的代码。我们可以看到,switch 里面前几个都是创建空视图啊,头部视图,底部视图之类的。default 这个 onCreateDefViewHolder 估计是我们需要找的代码,我们来看下这个方法:

protected K onCreateDefViewHolder(ViewGroup parent, int viewType) {
    return createBaseViewHolder(parent, mLayoutResId);
}

里面调用来 createBaseViewHolder 方法,我们继续看:

protected K createBaseViewHolder(ViewGroup parent, int layoutResId) {
    return createBaseViewHolder(getItemView(layoutResId, parent));
}

这里面先调用 getItemView

protected View getItemView(int layoutResId, ViewGroup parent) {
    return mLayoutInflater.inflate(layoutResId, parent, false);
}

里面代码相当简单,就是根据布局资源 id 渲染我们的 view 然后返回。

然后才继续调用 createBaseViewHolder

protected K createBaseViewHolder(View view) {
    Class temp = getClass();
  Class z = null;
 while (z == null && null != temp) {
        z = getInstancedGenericKClass(temp);
  temp = temp.getSuperclass();
  }
    K k = createGenericKInstance(z, view);
 return null != k ? k : (K) new BaseViewHolder(view);
}

里面的代码主要是判断你是否在 adapter 中使用的 BaseViewHolder 的子类,大概意思是这样的,

temp=getClass()会返回我们当前的 adapter 的类型,然后其传入 temp 调用 getInstancedGenericKClass

private Class getInstancedGenericKClass(Class z) {
    Type type = z.getGenericSuperclass();
 if (type instanceof ParameterizedType) {
        Type[] types = ((ParameterizedType) type).getActualTypeArguments();
 for (Type temp : types) {
            if (temp instanceof Class) {
                Class tempClass = (Class) temp;
				//判断tempClass是否是BaseViewHolder类型或者其子类型或者接口
 if (BaseViewHolder.class.isAssignableFrom(tempClass)) {
                    return tempClass;
  }
            }
        }
    }
    return null;
}

该方法最终会判断当前的类是否是 BaseViewHolder 的子类或者接口,如果是返回,不是返回 null。经过下面的三目运算

return null != k ? k : (K) new BaseViewHolder(view);

如果你不实用集成自 BaseViewHolder 的子类时,基本调用的是

(K) new BaseViewHolder(view)

在我们上一篇分析 BaseViewHolder 中有一个 convertView 字段的值及来自这里。

那么好,当 viewholder 被创建后,接下来就是数据绑定了,我们看一下源代码:

@Override
public void onBindViewHolder(K holder, int positions) {
    int viewType = holder.getItemViewType();

 switch (viewType) {
        case 0:

            convert(holder, mData.get(holder.getLayoutPosition() - getHeaderLayoutCount()));
 break; case LOADING_VIEW:
            mLoadMoreView.convert(holder);
 break; case HEADER_VIEW:
            break;
 case EMPTY_VIEW:
            break;
 case FOOTER_VIEW:
            break;
 default:
            convert(holder, mData.get(holder.getLayoutPosition() - getHeaderLayoutCount()));
 break;  }
}

大家从上面会看到很熟悉的一个函数

convert(holder, mData.get(holder.getLayoutPosition() - getHeaderLayoutCount()));

为什么 0 是我们正常要显示的数据呢?

default:
    baseViewHolder = onCreateDefViewHolder(parent, viewType);
  bindViewClickListener(baseViewHolder);

从 onCreateViewHolder 中可以看到在 default 情况下就是 viewType=0,该值来自 adapter 的 getItemViewType 方法

public int getItemViewType(int position) {
	  ```
}

当既不是头部视图,也不是尾部视图,空视图时,他就会调用

getDefItemViewType(adjPosition);

protected int getDefItemViewType(int position) {
    return super.getItemViewType(position);
}

可以看到,他返回的就是 0,所以 viewType 等于 0 就是正常加载数据的 viewHolder,然后我们将 holder 和经过计算
mData.get(holder.getLayoutPosition() - getHeaderLayoutCount())
后得到的该 positions 下的 data 传入 convert 函数,我们就可以拿着 holder 和 data 进行数据的绑定操作了

@Override
public void onBindViewHolder(K holder, int positions) {
	  ```
}

从创建 adapter 到根据不同的情况创建不同的 viewholder 到绑定数据的流程。

BaseQuickAdapter 之预加载实现
autoLoadMore(int position) 见名知意,是与自动加载更多相关的。我们先看下该函数的代码实现

private void autoLoadMore(int position) {
    if (getLoadMoreViewCount() == 0) {
        return;
  }
    if (position < getItemCount() - mAutoLoadMoreSize) {
        return;
  }
    if (mLoadMoreView.getLoadMoreStatus() != LoadMoreView.STATUS_DEFAULT) {
        return;
  }
    mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_LOADING);
 if (!mLoading) {
        mLoading = true;
 if (getRecyclerView() != null) {
            getRecyclerView().post(new Runnable() {
                @Override
  public void run() {
                    mRequestLoadMoreListener.onLoadMoreRequested();
  }
            });
  } else {
            mRequestLoadMoreListener.onLoadMoreRequested();
  }
    }
}

第一句先判断 getLoadMoreViewCount 判断是否==0.其实他并不是简单的判断是是否有加载更多视图的数量。进入方法里:

public int getLoadMoreViewCount() {
    if (mRequestLoadMoreListener == null || !mLoadMoreEnable) {
        return 0;
  }
    if (!mNextLoadEnable && mLoadMoreView.isLoadEndMoreGone()) {
        return 0;
  }
    if (mData.size() == 0) {
        return 0;
  }
    return 1;
}

我们可以看到,他的返回结果跟很多因素有关,从代码很容易看出:

return 0 的情况:

1、你没有设置 mRequestLoadMoreListener 或者没有开启 mLoadMoreEnable 开关;

2、mNextLoadEnable = false ,mNextLoadEnable 在加载更多结束时,你调用

loadMoreEnd(boolean gone) 时会置为 false。且 mLoadMoreView 是处于 gone 状态的。
3、当数据源大小为 0 时接下来 autoLoadMore 方法中的第二句代码很重要

if (position < getItemCount() - mAutoLoadMoreSize) {
    return;
}

理解起来大概是这样的,mAutoLoadMoreSize 是标识开启自动加载更多的一个数量阀值。这个返回很巧妙。
假设你的 data.size =20 ,mAutoLoadMoreSize =10,当前 position=9, 按照理解,这个 pisition=9 是个临界值,因为我们设置了剩余数量 <10 个时自动加载更多,此时计算 9<20-10,position 等于 9,说明后面还有 10 个数据没渲染,当 position=10 时(未加载数据还剩 9 个,此时应该预加载更多),10<20-10,不成立,代码继续往下走,执行

if (mLoadMoreView.getLoadMoreStatus() != LoadMoreView.STATUS_DEFAULT) {
    return;
}

我们为什么还要做这个判断的。假如不做这个判断。直接执行下面的代码。

mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_LOADING);
if (!mLoading) {
    mLoading = true;
 if (getRecyclerView() != null) {
        getRecyclerView().post(new Runnable() {
            @Override
  public void run() {
                mRequestLoadMoreListener.onLoadMoreRequested();
  }
        });
  } else {
        mRequestLoadMoreListener.onLoadMoreRequested();
  }
}

那么会出现很好玩的 现象,当你快速上滑时,由于 position>=10 后满足条件,执行加载更多的回调,position=11 时也会执行,以此类推,那么你将收到多次加载更多的回调。所以我们需要判断此时是否当前的加载更能多回调已完成,保证每次到达阀值后只调用一次加载更多回调方法。
理解了这个方法之后,我们接下来看下该方法在哪里被调用呢?

@Override
public int getItemViewType(int position) {
    if (getEmptyViewCount() == 1) {
        boolean header = mHeadAndEmptyEnable && getHeaderLayoutCount() != 0;
 switch (position) {
            case 0:
                if (header) {
                    return HEADER_VIEW;
  } else {
                    return EMPTY_VIEW;
  }
            case 1:
                if (header) {
                    return EMPTY_VIEW;
  } else {
                    return FOOTER_VIEW;
  }
            case 2:
                return FOOTER_VIEW;
 default:
                return EMPTY_VIEW;
  }
    }
    autoLoadMore(position);
 int numHeaders = getHeaderLayoutCount();
 if (position < numHeaders) {
        return HEADER_VIEW;
  } else {
        int adjPosition = position - numHeaders;
 int adapterCount = mData.size();
 if (adjPosition < adapterCount) {
            return getDefItemViewType(adjPosition);
  } else {
            adjPosition = adjPosition - adapterCount;
 int numFooters = getFooterLayoutCount();
 if (adjPosition < numFooters) {
                return FOOTER_VIEW;
  } else {
                return LOADING_VIEW;
  }
        }
    }
}

在 getItemViewType 方法中,为什么在这个方法里面呢,因为根据 recyclerView.Adapter 的执行逻辑,在渲染一个新的 itemview 时,会先调用 getItemViewType 询问我需要加载什么类型的 ViewHolder。在这里调用能更早的调用我们的加载更多的方法,当前,你在 onBindViewHolder 数据绑定方法中调用也可以实现这个功能。接下来就很好理解了,当 RecyclerView 在渲染一个新的 itemView 时,就会调用下

autoLoadMore(position);判断是不是需要调用加载更多回调,需要就调用,有关预加载的分析就 OK 啦

BaseQuickAdapter 上拉加载实现

首先我们先了解几个有关加载更多功能的方法

第一步:打开上拉加载的开关

public void setEnableLoadMore(boolean enable) {
    int oldLoadMoreCount = getLoadMoreViewCount();
  mLoadMoreEnable = enable;
 int newLoadMoreCount = getLoadMoreViewCount();

 if (oldLoadMoreCount == 1) {
        if (newLoadMoreCount == 0) {
            notifyItemRemoved(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
  }
    } else {
        if (newLoadMoreCount == 1) {
            mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_DEFAULT);
  notifyItemInserted(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
  }
    }
}

通过上面方法打开我们的上拉加载的开关。首先我们先看下以下两个变量的意思。

1、oldLoadMoreCount 代表在改变这个开关时我们是否处于显示上拉加载的 view 的状态,1 表示处于该状态。

2、newLoadMoreCount 代表我们当前是否可以开启上拉加载功能,同样,1 表示可以。

这段代码很有意思

if (oldLoadMoreCount == 1) {
    if (newLoadMoreCount == 0) {
        notifyItemRemoved(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
  }
}

我们为什么要做插入这段代码呢,他的作用其实是这样的:加入当前处于显示加载更多 view 的状态,此时你想关闭该开关,那我们第一件事要做什么呢,当然是移除加载更多 view 了,这段代码的作用就是这个。

反过来,我们现在要开启上拉加载。走的是这段代码

else {
    if (newLoadMoreCount == 1) {
        mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_DEFAULT);
  notifyItemInserted(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
  }
}

因为们的的 loadMoreView 一直是处于最底部的一个 view,所以我们通过调用

notifyItemInserted(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
告诉 recycerlView 将 loadViewMore 显示出来。

当我们同过上拉加载加载新的数据完成后,我们需要告诉 BaseQuickAdapter 你可以恢复正常状态了,此时我们将用到以下方法:

@Override
  public void onLoadMoreRequested() {
        mSwipeRefreshLayout.setEnabled(false);
 if (pullToRefreshAdapter.getData().size() < PAGE_SIZE) {
            pullToRefreshAdapter.loadMoreEnd(true);
  } else {
            if (mCurrentCounter >= TOTAL_COUNTER) {
//                    pullToRefreshAdapter.loadMoreEnd();//default visible
  pullToRefreshAdapter.loadMoreEnd(mLoadMoreEndGone);//true is gone,false is visible
  } else {
                if (isErr) {
                    pullToRefreshAdapter.addData(DataServer.getSampleData(PAGE_SIZE));
  mCurrentCounter = pullToRefreshAdapter.getData().size();
  pullToRefreshAdapter.loadMoreComplete();
  } else {
                    isErr = true;
  Toast.makeText(PullToRefreshUseActivity.this, R.string.network_err, Toast.LENGTH_LONG).show();
  pullToRefreshAdapter.loadMoreFail();

  }
            }
            mSwipeRefreshLayout.setEnabled(true);
  }
    }

//加载完成第一个 if 是防止我们错误的调用该方法。可以看到,方法内部帮我们调用了更新数据源的方法。而且是局部更新。

public void loadMoreComplete() {
    if (getLoadMoreViewCount() == 0) {
        return;
  }
    mLoading = false;
  mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_DEFAULT);
  notifyItemChanged(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
}

我们看到这么一句恢复我们的 loadMoreView 为默认值,我们可以跟进去看下一下

mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_DEFAULT);

他内部是重置了 loadMoreStatus 这个字段

public void setLoadMoreStatus(int loadMoreStatus) {
    this.mLoadMoreStatus = loadMoreStatus;
}

而这个字段是在什么时候用到呢,LoadMoreView 的代码很少,可以看到

public void convert(BaseViewHolder holder) {
    switch (mLoadMoreStatus) {
        case STATUS_LOADING:
            visibleLoading(holder, true);
  visibleLoadFail(holder, false);
  visibleLoadEnd(holder, false);
 break; case STATUS_FAIL:
            visibleLoading(holder, false);
  visibleLoadFail(holder, true);
  visibleLoadEnd(holder, false);
 break; case STATUS_END:
            visibleLoading(holder, false);
  visibleLoadFail(holder, false);
  visibleLoadEnd(holder, true);
 break; case STATUS_DEFAULT:
            visibleLoading(holder, false);
  visibleLoadFail(holder, false);
  visibleLoadEnd(holder, false);
 break;  }
}

他是在一个 convert 方法中根据 mLoadMoreStatus 来改变 loadMoreView 的显示和隐藏,convert 方法大家应该很熟悉,参数 holder 其实就是我们的 loadMoreView 本身,那么 loadMoreView.convert 在哪被调用呢。

其实是在我们绑定数据时,如果判断当前 viewholder 时 loadMore 类型,就会调用。

@Override
public void onBindViewHolder(K holder, int positions) {
    int viewType = holder.getItemViewType();

 switch (viewType) {
        case 0:

            convert(holder, mData.get(holder.getLayoutPosition() - getHeaderLayoutCount()));
 break; case LOADING_VIEW:
            mLoadMoreView.convert(holder);
 break; case HEADER_VIEW:
            break;
 case EMPTY_VIEW:
            break;
 case FOOTER_VIEW:
            break;
 default:
            convert(holder, mData.get(holder.getLayoutPosition() - getHeaderLayoutCount()));
 break;  }
}

很好理解,我们的 loadMoreView 是一直存在的。作为我们 recyclerView 的最后一个 item,当加载到最后一个 item 的时候,他就调用 loadView 的 convert 方法,方法内部根据我们当前是否应该显示 loadView 来做相应的操作。这样我们就理解了 loadMore 的隐藏和显示的逻辑了。后面还有两个方法也很好理解,请看。

加载失败调用,可能你有需求在加载失败后要显示一个加载失败的 view 提示用户,而不是直接关闭 loadMoreView。此时你可以调用该方法。

loadMoreFail

/**
 * Refresh failed */public void loadMoreFail() {
    if (getLoadMoreViewCount() == 0) {
        return;
  }
    mLoading = false;
  mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_FAIL);
  notifyItemChanged(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
}

loadMoreEnd

/**
 * Refresh end, no more data * * @param gone if true gone the load more view
 */public void loadMoreEnd(boolean gone) {
    if (getLoadMoreViewCount() == 0) {
        return;
  }
    mLoading = false;
  mNextLoadEnable = false;
  mLoadMoreView.setLoadMoreEndGone(gone);
 if (gone) {
        notifyItemRemoved(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
  } else {
        mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_END);
  notifyItemChanged(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
  }
}

之后就到我们关心的回调部分了。首先我们需要设置我们的回调监听器

public void setOnLoadMoreListener(RequestLoadMoreListener requestLoadMoreListener, RecyclerView recyclerView) {
    openLoadMore(requestLoadMoreListener);
 if (getRecyclerView() == null) {
        setRecyclerView(recyclerView);
  }
}

在设置监听器的时候,代码也帮我们做了一个字段的赋值操作。默认开启上拉加载,mLoading 是表示当前是否处于上拉加载中。

接下来你可能要问,那这个 morequestLoadMoreListener 在什么时候被调用呢,其实这个也设计的比较好,上一章我们分析了预加载功能,其实就在上次介绍的代码中。

private void autoLoadMore(int position) {
    if (getLoadMoreViewCount() == 0) {
        return;
  }
    if (position < getItemCount() - mAutoLoadMoreSize) {
        return;
  }
    if (mLoadMoreView.getLoadMoreStatus() != LoadMoreView.STATUS_DEFAULT) {
        return;
  }
    mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_LOADING);
 if (!mLoading) {
        mLoading = true;
 if (getRecyclerView() != null) {
            getRecyclerView().post(new Runnable() {
                @Override
  public void run() {
                    mRequestLoadMoreListener.onLoadMoreRequested();
  }
            });
  } else {
            mRequestLoadMoreListener.onLoadMoreRequested();
  }
    }
}

如果你想关闭预加载,当时是 mAutoLoadMoreSize =0 ,此时要调用最后一句代码,条件就变成了

position

思路大概是这样的:

在关闭预加载功能时:如果加载到最后一个 item,首先会调用 getItemViewType 询问即将加载的 viewholder 是什么类型。我们前面说过了,loadMoreView 是一直作为最后一个 viewHolder 存在的。此时如果符合显示 loadMoreView 条件,那么就设置 loadMoreView 的状态,调用我们的函数。在执行到 onBindViewHolder 生命周期方法时,会根据我们设置的值显示或者隐藏 loadMoreView 视图,也就是说,onLoadMoreRequested 方法的回调在显示 loadMoreView 之前就被调用了。时间是很短的,用户基本察觉不出来。

本次分析就到这里,接下来会继续分析其余的代码。如果有需要想一起分析哪部份代码,也可以直接留言,我会调整顺序。

  • Android

    Android 是一种以 Linux 为基础的开放源码操作系统,主要使用于便携设备。2005 年由 Google 收购注资,并拉拢多家制造商组成开放手机联盟开发改良,逐渐扩展到到平板电脑及其他领域上。

    334 引用 • 323 回帖 • 4 关注

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...

推荐标签 标签

  • 工具

    子曰:“工欲善其事,必先利其器。”

    288 引用 • 734 回帖
  • PostgreSQL

    PostgreSQL 是一款功能强大的企业级数据库系统,在 BSD 开源许可证下发布。

    22 引用 • 22 回帖
  • 分享

    有什么新发现就分享给大家吧!

    248 引用 • 1795 回帖
  • Solo

    Solo 是一款小而美的开源博客系统,专为程序员设计。Solo 有着非常活跃的社区,可将文章作为帖子推送到社区,来自社区的回帖将作为博客评论进行联动(具体细节请浏览 B3log 构思 - 分布式社区网络)。

    这是一种全新的网络社区体验,让热爱记录和分享的你不再感到孤单!

    1435 引用 • 10056 回帖 • 489 关注
  • SpaceVim

    SpaceVim 是一个社区驱动的模块化 vim/neovim 配置集合,以模块的方式组织管理插件以
    及相关配置,为不同的语言开发量身定制了相关的开发模块,该模块提供代码自动补全,
    语法检查、格式化、调试、REPL 等特性。用户仅需载入相关语言的模块即可得到一个开箱
    即用的 Vim-IDE。

    3 引用 • 31 回帖 • 105 关注
  • jsoup

    jsoup 是一款 Java 的 HTML 解析器,可直接解析某个 URL 地址、HTML 文本内容。它提供了一套非常省力的 API,可通过 DOM,CSS 以及类似于 jQuery 的操作方法来取出和操作数据。

    6 引用 • 1 回帖 • 484 关注
  • 爬虫

    网络爬虫(Spider、Crawler),是一种按照一定的规则,自动地抓取万维网信息的程序。

    106 引用 • 275 回帖 • 1 关注
  • Gzip

    gzip (GNU zip)是 GNU 自由软件的文件压缩程序。我们在 Linux 中经常会用到后缀为 .gz 的文件,它们就是 Gzip 格式的。现今已经成为互联网上使用非常普遍的一种数据压缩格式,或者说一种文件格式。

    9 引用 • 12 回帖 • 147 关注
  • Typecho

    Typecho 是一款博客程序,它在 GPLv2 许可证下发行,基于 PHP 构建,可以运行在各种平台上,支持多种数据库(MySQL、PostgreSQL、SQLite)。

    12 引用 • 65 回帖 • 445 关注
  • 七牛云

    七牛云是国内领先的企业级公有云服务商,致力于打造以数据为核心的场景化 PaaS 服务。围绕富媒体场景,七牛先后推出了对象存储,融合 CDN 加速,数据通用处理,内容反垃圾服务,以及直播云服务等。

    27 引用 • 225 回帖 • 163 关注
  • 996
    13 引用 • 200 回帖 • 10 关注
  • Flume

    Flume 是一套分布式的、可靠的,可用于有效地收集、聚合和搬运大量日志数据的服务架构。

    9 引用 • 6 回帖 • 637 关注
  • V2Ray
    1 引用 • 15 回帖 • 1 关注
  • TGIF

    Thank God It's Friday! 感谢老天,总算到星期五啦!

    288 引用 • 4485 回帖 • 663 关注
  • 智能合约

    智能合约(Smart contract)是一种旨在以信息化方式传播、验证或执行合同的计算机协议。智能合约允许在没有第三方的情况下进行可信交易,这些交易可追踪且不可逆转。智能合约概念于 1994 年由 Nick Szabo 首次提出。

    1 引用 • 11 回帖 • 2 关注
  • Caddy

    Caddy 是一款默认自动启用 HTTPS 的 HTTP/2 Web 服务器。

    12 引用 • 54 回帖 • 159 关注
  • Docker

    Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的操作系统上。容器完全使用沙箱机制,几乎没有性能开销,可以很容易地在机器和数据中心中运行。

    492 引用 • 926 回帖
  • 反馈

    Communication channel for makers and users.

    123 引用 • 913 回帖 • 250 关注
  • NetBeans

    NetBeans 是一个始于 1997 年的 Xelfi 计划,本身是捷克布拉格查理大学的数学及物理学院的学生计划。此计划延伸而成立了一家公司进而发展这个商用版本的 NetBeans IDE,直到 1999 年 Sun 买下此公司。Sun 于次年(2000 年)六月将 NetBeans IDE 开源,直到现在 NetBeans 的社群依然持续增长。

    78 引用 • 102 回帖 • 683 关注
  • Kubernetes

    Kubernetes 是 Google 开源的一个容器编排引擎,它支持自动化部署、大规模可伸缩、应用容器化管理。

    110 引用 • 54 回帖 • 1 关注
  • 阿里云

    阿里云是阿里巴巴集团旗下公司,是全球领先的云计算及人工智能科技公司。提供云服务器、云数据库、云安全等云计算服务,以及大数据、人工智能服务、精准定制基于场景的行业解决方案。

    89 引用 • 345 回帖
  • CSS

    CSS(Cascading Style Sheet)“层叠样式表”是用于控制网页样式并允许将样式信息与网页内容分离的一种标记性语言。

    196 引用 • 540 回帖 • 1 关注
  • 区块链

    区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。所谓共识机制是区块链系统中实现不同节点之间建立信任、获取权益的数学算法 。

    91 引用 • 751 回帖 • 1 关注
  • SVN

    SVN 是 Subversion 的简称,是一个开放源代码的版本控制系统,相较于 RCS、CVS,它采用了分支管理系统,它的设计目标就是取代 CVS。

    29 引用 • 98 回帖 • 694 关注
  • SEO

    发布对别人有帮助的原创内容是最好的 SEO 方式。

    35 引用 • 200 回帖 • 27 关注
  • Electron

    Electron 基于 Chromium 和 Node.js,让你可以使用 HTML、CSS 和 JavaScript 构建应用。它是一个由 GitHub 及众多贡献者组成的活跃社区共同维护的开源项目,兼容 Mac、Windows 和 Linux,它构建的应用可在这三个操作系统上面运行。

    15 引用 • 136 回帖
  • Hibernate

    Hibernate 是一个开放源代码的对象关系映射框架,它对 JDBC 进行了非常轻量级的对象封装,使得 Java 程序员可以随心所欲的使用对象编程思维来操纵数据库。

    39 引用 • 103 回帖 • 715 关注