How do their APIs compare?

A direct "API comparison" doesn't quite apply here since these two repositories serve completely different purposes and aren't alternatives to each other — one is a utility library, the other is an RPC framework. Let me lay out what each actually exposes as its "API surface."

blankj/androidutilcode

This is a collection of static utility classes for Android app development, organized into two modules per the README:

• utilcode — commonly-used utilities (the main module)
• subutil — less common utilities that support the main module

The README describes it as providing "encapsulated APIs" to improve development efficiency, with each util having "complete demo and unit test." The API style here is fundamentally different from an RPC framework's — it's a large set of independent, stateless helper classes (things like file, string, device, network utils based on the module naming conventions), not a client/server request-response contract. From the excerpt available, I don't have specific class/method signatures to cite beyond the README's structural description [README (excerpt)].

snailclimb/guide-rpc-framework

This exposes a genuine RPC API surface with request/response semantics:

• Service annotations for defining APIs: @RpcService(group=..., version=...) to mark an implementation as a remotely callable service, and @RpcReference on the client side to inject a proxy — e.g. HelloController declares @RpcReference(version = "version1", group = "test1") private HelloService helloService; and calls it like a normal local method [example-client/src/main/java/github/javaguide/HelloController.java:L10-L25].
• Bootstrapping API: @RpcScan(basePackage = {...}) plus Spring's AnnotationConfigApplicationContext to start a NettyRpcServer [README-EN.md:L132-L168].
• Standardized error model: RpcStatusCode enum (OK, CANCELLED, UNKNOWN, DEADLINE_EXCEEDED, etc.) used across the transport layer to signal failures in a gRPC-status-like way [rpc-framework-common/src/main/java/github/javaguide/enums/RpcStatusCode.java:L11-L55]. This is thrown/wrapped inside RpcException when, for example, a request times out or the client is closed [rpc-framework-simple/.../SocketRpcClient.java:L80-L119].
• Serialization API: SerializationTypeEnum (KRYO, PROTOSTUFF, HESSIAN) lets you select the wire serialization format by code or name [rpc-framework-common/src/main/java/github/javaguide/enums/SerializationTypeEnum.java:L12-L40].
• Sync and async access: the README states the framework offers a synchronous proxy (local-call feel) alongside an async proxy returning CompletableFuture<T> [README.md:L27-L39].

Bottom line

• androidutilcode's "API" = a broad toolbox of static helper methods for Android, no networking/service semantics.
• guide-rpc-framework's API = a request/response RPC contract (annotations for service registration/reference, typed status codes, exception types, serialization selection, sync/async proxies).

They aren't really comparable feature-for-feature since one is a utility grab-bag and the other is a network framework with a formal contract (requestId, RpcStatusCode, timeouts). If you want, I can go deeper into a specific piece — e.g., how androidutilcode's modules are organized, or how guide-rpc-framework's timeout/cancellation model works in SocketRpcClient.

FOLLOW_UPS:

• What utility categories exist in androidutilcode's modules?
• How does guide-rpc-framework handle request timeouts?
• What serialization frameworks does guide-rpc-framework support?