BaseRecyclerViewAdapterHelper 源码分析(1)

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

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 回帖

相关帖子

欢迎来到这里!

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

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

推荐标签 标签

  • Flutter

    Flutter 是谷歌的移动 UI 框架,可以快速在 iOS 和 Android 上构建高质量的原生用户界面。 Flutter 可以与现有的代码一起工作,它正在被越来越多的开发者和组织使用,并且 Flutter 是完全免费、开源的。

    39 引用 • 92 回帖 • 1 关注
  • Gitea

    Gitea 是一个开源社区驱动的轻量级代码托管解决方案,后端采用 Go 编写,采用 MIT 许可证。

    4 引用 • 16 回帖 • 5 关注
  • CSS

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

    198 引用 • 550 回帖
  • OnlyOffice
    4 引用 • 3 关注
  • 笔记

    好记性不如烂笔头。

    308 引用 • 793 回帖 • 1 关注
  • Log4j

    Log4j 是 Apache 开源的一款使用广泛的 Java 日志组件。

    20 引用 • 18 回帖 • 31 关注
  • Hexo

    Hexo 是一款快速、简洁且高效的博客框架,使用 Node.js 编写。

    21 引用 • 140 回帖 • 1 关注
  • jsDelivr

    jsDelivr 是一个开源的 CDN 服务,可为 npm 包、GitHub 仓库提供免费、快速并且可靠的全球 CDN 加速服务。

    5 引用 • 31 回帖 • 58 关注
  • Angular

    AngularAngularJS 的新版本。

    26 引用 • 66 回帖 • 537 关注
  • RESTful

    一种软件架构设计风格而不是标准,提供了一组设计原则和约束条件,主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁,更有层次,更易于实现缓存等机制。

    30 引用 • 114 回帖 • 2 关注
  • Bug

    Bug 本意是指臭虫、缺陷、损坏、犯贫、窃听器、小虫等。现在人们把在程序中一些缺陷或问题统称为 bug(漏洞)。

    75 引用 • 1737 回帖 • 5 关注
  • Windows

    Microsoft Windows 是美国微软公司研发的一套操作系统,它问世于 1985 年,起初仅仅是 Microsoft-DOS 模拟环境,后续的系统版本由于微软不断的更新升级,不但易用,也慢慢的成为家家户户人们最喜爱的操作系统。

    222 引用 • 473 回帖 • 1 关注
  • BAE

    百度应用引擎(Baidu App Engine)提供了 PHP、Java、Python 的执行环境,以及云存储、消息服务、云数据库等全面的云服务。它可以让开发者实现自动地部署和管理应用,并且提供动态扩容和负载均衡的运行环境,让开发者不用考虑高成本的运维工作,只需专注于业务逻辑,大大降低了开发者学习和迁移的成本。

    19 引用 • 75 回帖 • 642 关注
  • 创造

    你创造的作品可能会帮助到很多人,如果是开源项目的话就更赞了!

    179 引用 • 995 回帖
  • CodeMirror
    1 引用 • 2 回帖 • 129 关注
  • MyBatis

    MyBatis 本是 Apache 软件基金会 的一个开源项目 iBatis,2010 年这个项目由 Apache 软件基金会迁移到了 google code,并且改名为 MyBatis ,2013 年 11 月再次迁移到了 GitHub。

    170 引用 • 414 回帖 • 387 关注
  • Electron

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

    15 引用 • 136 回帖 • 1 关注
  • Python

    Python 是一种面向对象、直译式电脑编程语言,具有近二十年的发展历史,成熟且稳定。它包含了一组完善而且容易理解的标准库,能够轻松完成很多常见的任务。它的语法简捷和清晰,尽量使用无异义的英语单词,与其它大多数程序设计语言使用大括号不一样,它使用缩进来定义语句块。

    543 引用 • 672 回帖 • 1 关注
  • Postman

    Postman 是一款简单好用的 HTTP API 调试工具。

    4 引用 • 3 回帖 • 3 关注
  • Android

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

    334 引用 • 323 回帖
  • FreeMarker

    FreeMarker 是一款好用且功能强大的 Java 模版引擎。

    23 引用 • 20 回帖 • 463 关注
  • DevOps

    DevOps(Development 和 Operations 的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。

    47 引用 • 25 回帖
  • SQLServer

    SQL Server 是由 [微软] 开发和推广的关系数据库管理系统(DBMS),它最初是由 微软、Sybase 和 Ashton-Tate 三家公司共同开发的,并于 1988 年推出了第一个 OS/2 版本。

    21 引用 • 31 回帖
  • 禅道

    禅道是一款国产的开源项目管理软件,她的核心管理思想基于敏捷方法 scrum,内置了产品管理和项目管理,同时又根据国内研发现状补充了测试管理、计划管理、发布管理、文档管理、事务管理等功能,在一个软件中就可以将软件研发中的需求、任务、bug、用例、计划、发布等要素有序的跟踪管理起来,完整地覆盖了项目管理的核心流程。

    6 引用 • 15 回帖 • 114 关注
  • Swagger

    Swagger 是一款非常流行的 API 开发工具,它遵循 OpenAPI Specification(这是一种通用的、和编程语言无关的 API 描述规范)。Swagger 贯穿整个 API 生命周期,如 API 的设计、编写文档、测试和部署。

    26 引用 • 35 回帖 • 1 关注
  • Pipe

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

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

    132 引用 • 1114 回帖 • 124 关注
  • Maven

    Maven 是基于项目对象模型(POM)、通过一小段描述信息来管理项目的构建、报告和文档的软件项目管理工具。

    186 引用 • 318 回帖 • 302 关注