How do their APIs compare?

These two libraries are not really comparable in purpose — one is a thin HTTP request builder, the other is a hot-patch runtime — but here's how their public APIs differ in shape and philosophy.

hongyangandroid/okhttputils — fluent builder API over OkHttp

The entire surface is a chained builder pattern centered on a static OkHttpUtils facade:

• Request construction: OkHttpUtils.get()/.post()/.put()/... returns a per-verb builder (e.g. GetBuilder) that extends the shared OkHttpRequestBuilder<T> base, which exposes chainable setters like .url(), .tag(), .headers(), .addHeader(), .id() [okhttputils/src/main/java/com/zhy/http/okhttp/builder/OkHttpRequestBuilder.java:L11-L56]. Verb-specific builders add their own methods, e.g. GetBuilder.params()/.addParams() which append query params via Uri.Builder [okhttputils/src/main/java/com/zhy/http/okhttp/builder/GetBuilder.java:L16-L67].
• Execution: .build() produces a RequestCall, and .execute(Callback) runs it asynchronously. Callbacks are abstract classes (StringCallback, BitmapCallback, FileCallback, or custom subclasses of Callback<T>) with lifecycle hooks like onBefore, onError, onResponse, and for downloads inProgress [README.md:L220-L261; sample MainActivity.java:L312-L351].
• Global configuration: a single static setup call, OkHttpUtils.initClient(OkHttpClient), done once in Application.onCreate(), to inject a custom OkHttpClient (timeouts, interceptors, cookie jar, SSL) [README.md:L36-L61; sample MyApplication.java:L23-L70].
• Cross-cutting concerns are handled via OkHttp's own extension points rather than custom API: logging via LoggerInterceptor implements Interceptor [okhttputils/src/main/java/com/zhy/http/okhttp/log/LoggerInterceptor.java:L20-L59], and platform-specific callback threading via the internal Platform class, which picks a MainThreadExecutor on Android vs. a cached thread pool elsewhere [okhttputils/src/main/java/com/zhy/http/okhttp/utils/Platform.java:L25-L83].

So the API is small, synchronous-to-configure/async-to-execute, and deliberately mirrors OkHttp's own builder idioms — it's meant to be called directly from UI/Activity code for one-off requests.

tencent/tinker — application-lifecycle/runtime patching API

Tinker's API is not a fluent builder; it's an inheritance and annotation-driven integration that a host Application must adopt:

• Entry point is a base class you must subclass: TinkerApplication, which has no default constructor — you must call its constructor with flags describing what to support (dex-only, library-only, "all") and the fully-qualified name of your ApplicationLike implementation, passed as a string specifically so the shell APK has no compile-time dependency on your logic class [README.md:L13-L75].
• Business logic lives in ApplicationLike/DefaultApplicationLike, not in Application directly — you move your existing onCreate, etc., into a class like SampleApplicationLike, decoupling app lifecycle from the patch-loading shell [README.md:L13-L75].
• Annotation-based codegen option: tinker-android-anno lets you skip writing the TinkerApplication subclass by hand — you annotate your ApplicationLike with @DefaultLifeCycle(application=..., flags=...) and the plugin generates the boilerplate Application class [README.md:L13-L75].
• Helper/introspection API: TinkerApplicationHelper, for cases where Tinker isn't installed on every process, offering static helpers to check Tinker status without requiring installation [tinker-android/tinker-android-lib-no-op/.../TinkerApplicationHelper.java:L1-L30].
• Underneath, Tinker ships lower-level utility packages that aren't meant for typical app-level cons