How do their APIs compare?

API Comparison: baseadapter vs butterknife

These two libraries solve completely different problems, so their APIs reflect very different design philosophies.

baseadapter — inheritance/composition-based Adapter API

Core pattern: subclass + override Its main entry point is CommonAdapter, used like a template method pattern — you subclass it and override convert() to bind data:

new CommonAdapter<String>(this, R.layout.item_list, mDatas) {
    public void convert(ViewHolder holder, String s) { ... }
}

This is shown in the README [README.md:L36-L46].

Multi-type items via delegation For heterogeneous item types, it uses a delegate-based API (MultiItemTypeAdapter + ItemViewDelegate<T>), explicitly inspired by the AdapterDelegates library [README.md:L176-L184]. Each delegate implements getItemViewLayoutId(), isForViewType(), and convert() — seen concretely in MsgComingItemDelagate [README.md:L71-L84].

Decorator-style wrapping for extra behavior Rather than annotations or code generation, it uses runtime object composition — e.g., HeaderAndFooterWrapper wraps an existing adapter instance to add header/footer views, described as "类似装饰者模式" (decorator-pattern-like) [README.md:L110-L124].

ViewHolder helper methods ViewHolder exposes chainable setter methods like setText(id, text), setImageResource(id, res), setOnClickListener(id, listener) to avoid findViewById boilerplate — all resolved at runtime, no compile-time code generation involved.

So baseadapter's API surface is 100% plain Java: interfaces, abstract classes, and object wrapping — no annotations, no build-time processing.

butterknife — annotation + code-generation based API

Core pattern: annotate fields/methods, let the compiler generate binding code Instead of manual findViewById, you annotate fields (@BindView) and methods (@OnClick, @OnPageChange, etc.), and an annotation processor generates a _ViewBinding class at compile time.

Listener-binding annotations are declarative and metadata-driven @OnPageChange is a good example: it's defined with @ListenerClass metadata specifying the target type (ViewPager), setter/remover method names, and listener interface, plus an inner Callback enum where each constant is annotated with @ListenerMethod describing the exact callback signature to hook into (onPageSelected, onPageScrolled, onPageScrollStateChanged) [butterknife-annotations/src/main/java/butterknife/OnPageChange.java:L1-L74]. This is a much more structured/meta-programmed API than baseadapter's plain interfaces.

Build-tool integration is part of the API surface Unlike baseadapter, butterknife's API extends into Gradle: ButterKnifePlugin hooks into AGP's variant API to generate an R2 class per variant, parsing manifests for package names and wiring output directories into the build [butterknife-gradle-plugin/src/main/java/butterknife/plugin/ButterKnifePlugin.kt:L20-L95]. There's no equivalent surface in baseadapter — it has no custom Gradle plugin or generated classes.

Multiple interchangeable artifacts for different use cases butterknife also exposes API variants at the dependency level — butterknife-reflect as a drop-in, processor-free alternative to butterknife + butterknife-compiler for faster IDE iteration, being binary-compatible so it can be swapped per build variant [butterknife-reflect/README.md:L36-L62]. baseadapter has no analogous concept — it's just plain library jars (base-adapter, base-rvadapter) with a single straightforward API.

Evolution toward optimization/build compatibility The CHANGELOG shows butterknife's API generation strategy evolving significantly over time — e.g., 8.4.0's generated _ViewBinding classes being made directly usable to support ProGuard/R8 without extra rules [CHANGELOG.md:L211-L218], and 9.x changes to support AndroidX and newer AGP versions with R2-based generated references [CH