How do their APIs compare?

Here's how the two libraries compare in terms of API design and purpose — they solve very different problems, so the comparison is mostly about scope, structure, and usage pattern.

blankj/androidutilcode — a broad utility-belt API

androidutilcode is organized as a large collection of static-style utility classes ("utils") covering nearly every common Android need — things like file I/O, networking, device info, permissions, etc. Per the README, the project is split into two modules:

• utilcode — the commonly-used utilities, meant to be the main entry point for app developers [README.md excerpt].
• subutil — rarer utilities that are less frequently needed but help simplify/support the main module.

The API surface is intentionally huge and heterogeneous: rather than one cohesive object model, you get many independent XxxUtils classes, each exposing static helper methods for a specific Android concern (file, string, device, etc.). This is a "toolbox" API style — you import only the utility class you need, call a static method, and get a result. There isn't a unifying runtime object graph; each utility is largely self-contained.

facebookarchive/rebound — a small, focused physics-modeling API

Rebound's API is much narrower and object-oriented, centered on modeling spring dynamics for animations. Key pieces visible in the retrieved code:

• Spring — the core object representing a single spring physics model. It exposes a listener API for reacting to spring updates: addListener, removeListener, removeAllListeners, all fluent (return Spring for chaining) [rebound-core/src/main/java/com/facebook/rebound/Spring.java:L498-L537].
• SpringConfig and SpringConfigRegistry — configuration objects that parameterize spring behavior (tension/friction), with a registry pattern (singleton getInstance()) for naming and tracking configs across an app: addSpringConfig, removeSpringConfig, getAllSpringConfig, removeAllSpringConfig [rebound-core/src/main/java/com/facebook/rebound/SpringConfigRegistry.java:L20-L90].
• SpringSystem / BaseSpringSystem / SpringSystemListener — used to drive springs each frame, as seen wired into example code like BallExample [rebound-android-playground/src/main/java/com/facebook/rebound/playground/examples/BallExample.java:L1-L37].

This is a much smaller, cohesive API: you create a Spring (via a SpringSystem), configure it with a SpringConfig, attach a SpringListener to receive value updates each tick, and drive your own view properties from those callbacks. The playground app demonstrates usage patterns rather than being part of the library API itself — e.g., PlaygroundActivity [rebound-android-playground/src/main/java/com/facebook/rebound/playground/app/PlaygroundActivity.java:L42-L81] just lists sample activities (SimpleExample, SpringScrollViewExample, SpringChainExample, etc.) that consume the Spring API.

Summary of the contrast

Aspect	androidutilcode	rebound
API shape	Many independent static utility classes	Small number of collaborating objects (Spring, SpringConfig, SpringSystem)
Style	Procedural/static helpers	Object-oriented, listener/observer pattern
Scope	General-purpose Android app development	Narrow: spring-based physics animation
Extensibility model	Add more utility classes	Add SpringConfigs to a registry, attach SpringListeners
State	Mostly stateless helpers	Stateful physics objects updated per frame

If you want, I can dig deeper into a specific utility class in androidutilcode or into the Spring/BaseSpringSystem update loop in rebound to compare method-level design more concretely.

FOLLOW_UPS:

• How does Spring's update loop work internally?
• What utility categories exist in androidutilcode's utilcode module?
• How do SpringListener callbacks get invoked per frame?