How do their APIs compare?

These two repositories aren't really comparable at the "API" level in a meaningful way, since they serve completely different purposes and languages — one is a collection of Spring Boot backend examples, the other is an Android UI/architecture library. Let me lay out what each actually exposes.

ityouknow/spring-boot-examples (Java/Spring Boot) This isn't a single library with one API surface — it's a large set of independent example modules, each demonstrating a specific Spring Boot integration. The "APIs" here are mostly:

• REST/MVC controllers, e.g. file upload endpoints like singleFileUpload/uploadStatus in [1.x/spring-boot-file-upload/src/main/java/com/neo/controller/UploadController.java:L16-L54] and the FastDFS-backed variant in [1.x/spring-boot-fastDFS/src/main/java/com/neo/controller/UploadController.java:L18-L80].
• Static utility-style client wrappers, like FastDFSClient with static methods upload, getFile, downFile, deleteFile, getStoreStorages, getFetchStorages, getTrackerUrl [1.x/spring-boot-fastDFS/src/main/java/com/neo/fastdfs/FastDFSClient.java:L11-L104].
• Simple DAO interfaces backed by Spring Data templates, e.g. UserDaoImpl with saveUser, findUserByUserName, updateUser, deleteUserById using MongoTemplate [1.x/spring-boot-mongodb/src/main/java/com/neo/dao/impl/UserDaoImpl.java:L18-L72].
• Multi-datasource configuration beans (DataSource2Config) and mapper-scoped controllers (UserController) [1.x/spring-boot-mybatis-mulidatasource/src/main/java/com/neo/datasource/DataSource2Config.java:L1-L21, 1.x/spring-boot-mybatis-mulidatasource/src/main/java/com/neo/web/UserController.java:L1-L14].

So its "API" is really dozens of small, tutorial-style Spring @RestController/@Service/@Repository classes — meant to be read and copied, not depended on as a library.

tencent/qmui_android (Kotlin/Java, Android) This is a proper library with structured, reusable public APIs for Android app architecture and UI:

• A scheme/routing system for handling deep links and in-app navigation: QMUISchemeMatcher [arch/src/main/java/com/qmuiteam/qmui/arch/scheme/QMUISchemeMatcher.kt:L1-L17], SchemeItem/SchemeValue for declaring routable targets [arch/src/main/java/com/qmuiteam/qmui/arch/scheme/SchemeItem.kt:L1-L28, SchemeValue.kt:L1-L17], QMUISchemeBuilder for constructing URIs [QMUISchemeBuilder.kt:L1-L21], and QMUISchemeHandlerInterceptor, a functional interface (fun interface) for intercepting scheme dispatch with an intercept(schemeHandler, activity, schemes) method [QMUISchemeHandlerInterceptor.kt:L1-L30].
• An annotation-driven fragment/activity contract, e.g. FragmentContainerParam for declaring required parameters on activities hosting fragments [arch-annotation/src/main/java/com/qmuiteam/qmui/arch/annotation/FragmentContainerParam.java:L1-L40].
• An effect abstraction (Effect) for architecture-layer event/side-effect handling [arch/src/main/java/com/qmuiteam/qmui/arch/effect/Effect.java:L1-L17].
• Internal bookkeeping like RecordIdClassMap [arch/src/main/java/com/qmuiteam/qmui/arch/record/RecordIdClassMap.java:L1-L18].

Key contrasts:

• Granularity/consumability: qmui_android exposes cohesive, importable public types meant to be used as a dependency in an app (matchers, builders, interceptors, annotations). spring-boot-examples exposes standalone demo code per module — not designed to be imported as a library at all.