MobileInfo 架构解析ContentProvider 自动初始化 Helper 设计如何让 SDK 简单好用【免费下载链接】MobileInfo【Android】Hardware Information. For detailed network diagnosis, please refer to【HttpInfo】项目地址: https://gitcode.com/gh_mirrors/mo/MobileInfoMobileInfo 是一款面向 Android 的设备硬件信息 SDK它最聪明的地方在于两个设计决策用ContentProvider 实现自动初始化无需在 Application 里写一行 init 代码以及用Helper Info Bean 三层结构把 CPU、内存、电池、摄像头等 30 多种设备信息统一封装成「一个静态方法返回一个 JSON」。对新手开发者来说这套架构堪称写 SDK 的教科书级范例。为什么 SDK 初始化常常是噩梦很多 SDK 要求接入方手动做初始化// 传统 SDK 的接入方式容易忘、容易错 public class MyApplication extends Application { Override public void onCreate() { super.onCreate(); SomeSdk.init(this); // 忘了写后面全部 NPE } }问题在于接入方可能根本不知道要写这一行。忘了初始化、传错 Context、初始化时机不对都是线上崩溃的经典来源。MobileInfo 的解法是把初始化这件事交给 Android 框架自己。核心设计一ContentProvider 自动初始化Android 有一个常被利用的技巧——ContentProvider 的 onCreate() 会早于 Application.onCreate() 执行且由系统自动调用。只要你在 AndroidManifest.xml 里声明一个 Provider无需任何代码它就会被实例化。MobileInfo 的模块 Manifest 中就这样声明了一个「空壳 Provider」mobilehardware/src/main/AndroidManifest.xmlprovider android:namecom.mobile.mobilehardware.MobInitializer android:exportedfalse android:authoritiescom.mobile.mobilehardware.MobInitializer.${applicationId} /这个 Provider 的实现只有三行核心代码其余 query/insert/delete 全部返回 null因为它根本不负责数据mobilehardware/src/main/java/com/mobile/mobilehardware/MobInitializer.javapublic class MobInitializer extends ContentProvider { Override public boolean onCreate() { Context context getContext(); MobileHardWareHelper.init(context); // 自动完成全局 Context 注入 return true; } }几个值得抄走的细节 exportedfalseProvider 不对外暴露纯粹当初始化钩子用安全无副作用authorities 拼接${applicationId}用构建变量占位符让 authorities 随包名唯一化多模块/多 flavor 场景下也不会冲突init 只是存一个全局 ContextMobileHardWareHelper.init(context)只负责把 Context 缓存到静态字段所有真正的采集逻辑延迟到调用时才执行启动零开销。接入方从此不需要写任何初始化代码依赖一加进来SDK 就是可用状态——这就是「简单好用」的第一块基石。核心设计二Helper Info Bean 三层结构MobileInfo 把每种设备信息CPU、内存、电池、蓝牙……都按同一套三层模式组织以 CPU 为例mobilehardware/src/main/java/com/mobile/mobilehardware/cpu/ ├── CpuHelper.java // 入口层public 静态方法对外 API ├── CpuInfo.java // 逻辑层读 /proc/cpuinfo、解析、容错 └── CpuBean.java // 数据层纯数据载体各层职责非常干净 层级类职责入口层CpuHelper暴露public static方法如mobGetCpuInfo()逻辑层CpuInfo包级私有真正的采集与解析逻辑包私有类防止被直接绕过入口调用数据层CpuBean继承BaseBean只装数据其中BaseBean做了一件很实用的小事每个 Bean 内部持有一个JSONObject并统一处理空值兜底空值一律填unknown保证返回给业务方的 JSON结构永远完整业务侧不用做判空。mobilehardware/src/main/java/com/mobile/mobilehardware/base/BaseBean.java核心设计三一个 Facade 收口所有 API如果让业务方直接调用 30 个不同包的XxxHelper等于制造了一堆新的学习成本。MobileInfo 用一个门面类MobileHardWareHelper把所有能力收口成同一形态的静态方法mobilehardware/src/main/java/com/mobile/mobilehardware/MobileHardWareHelper.javaMobileHardWareHelper.getCpuInfo(); // CPU 信息 MobileHardWareHelper.getMemoryInfo(); // 内存信息 MobileHardWareHelper.getBatteryInfo(); // 电池信息 MobileHardWareHelper.isRoot(); // Root 检测 MobileHardWareHelper.getEmulatorInfo();// 模拟器检测业务方只需记住一个类名、一种调用姿势、一种返回类型JSONObject或boolean心智成本几乎为零。每个方法内部只是一行委托如getCpuInfo()→CpuHelper.mobGetCpuInfo()新增信息类型时往 Facade 里加一行即可完全符合开闭原则。彩蛋Native 能力也遵循同一套模式需要读取内核文件如/proc/sys/kernel/random/boot_id的能力被放进MobileNativeHelper它实现了一个空的标记接口MobileInterface静态块里System.loadLibrary(fairymob-lib)加载 C 库JNI 细节被完全隔离在这一层。对 Java 层来说native 方法和纯 Java 方法的调用体验毫无区别——对外统一、对内分层正是这个 SDK 好维护的根本原因。mobilehardware/src/main/java/com/mobile/mobilehardware/MobileNativeHelper.java新手可直接套用的架构清单如果你正在写自己的 Android SDK可以把这套模式抄走 ✅声明一个exportedfalse的 ContentProvider 作为初始化钩子onCreate 里注入全局 Context让接入方零代码接入每种能力拆成 Helper入口 Info逻辑 Bean数据三层逻辑层设为包级私有数据层统一继承一个 BaseBean内置 JSON 序列化与空值兜底保证输出结构稳定用 Facade 门面类收口所有对外 API保持方法签名形态一致Native/平台相关实现隔离在专用 Helper 中用一个标记接口如MobileInterface统一风格方便后续替换实现。小结MobileInfo 用「ContentProvider 自动初始化 三层 Helper 结构 门面收口」这套组合拳把「设备信息采集」这件复杂的事压缩成了业务方一行MobileHardWareHelper.getXxxInfo()就能拿走的体验。对新手而言它示范的不仅是如何写一个硬件信息 SDK更是如何让 SDK 简单好用的架构方法论——接入无感、API 一致、输出稳定三点缺一不可。【免费下载链接】MobileInfo【Android】Hardware Information. For detailed network diagnosis, please refer to【HttpInfo】项目地址: https://gitcode.com/gh_mirrors/mo/MobileInfo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考