📚 课程目录第1章 SDK开发基础概念与双端差异概述

1. SDK开发基础概念与双端差异概述

说实话，做SDK开发这件事，跟做App开发完全是两码事。

我自己刚转过来那会儿，也踩了不少坑。以为不就是把功能封装一下嘛，结果上了生产环境才发现——手机厂商的系统版本、屏幕尺寸、网络环境，任何一个变化都可能让你的SDK闪退。

所以第一节课，咱们先把基础概念理清楚。

什么是SDK？

SDK，全称是Software Development Kit，就是软件开发工具包。

说得直白点，你把一些通用的功能写好，打包成一个库，别人直接拿来用。

比如支付SDK、推送SDK、广告SDK，都属于这范畴。

API接口：别人调你的方法，你返回结果。
文档：说明怎么集成、参数是啥、回调怎么处理。
示例代码：让接入方有个参考。
配置文件：有些SDK需要初始化配置。

我个人习惯：写SDK时，一定会把示例代码和文档先写好。没有文档的SDK，等于没有说明书的产品。

Android和iOS，到底差在哪？

这个问题，我面试过不少候选人，很多人只能说出「开发语言不同」。其实远不止这些。

维度	Android	iOS
开发语言	Java / Kotlin	Objective-C / Swift
构建系统	Gradle	Xcode Build System
包管理	Maven / Gradle	CocoaPods / Swift Package Manager
UI框架	XML + View体系	UIKit / SwiftUI
线程模型	主线程不能做网络请求	主线程更新UI，否则崩溃
证书签名	APK签名	Provisioning Profile + 签名证书
分发渠道	各大应用商店	App Store独家

上面这张表，需要你记牢。尤其是线程模型，我在项目中遇到过一次——Android SDK里开了个子线程去更新UI，结果iOS那边调用时直接闪退。嗯，底层机制完全不一样。

双端SDK的核心组件对比

你想想看，一个SDK要跑在两个平台上，哪些东西是共通的，哪些是平台独有的？

网络层：Android用OkHttp，iOS用NSURLSession。封装逻辑相似，但API差异很大。
数据存储：Android有SharedPreferences，iOS有UserDefaults。但key-value存储的底层实现完全不同。
日志系统：Android推崇Logcat，iOS用os_log。如果你不做适配，开发者根本看不到你的日志。
线程管理：Android有Handler/Looper，iOS有DispatchQueue。这个是硬骨头。

我曾经写过一个日志模块，直接用Android的Log类输出，结果iOS接入方编译不过。后来学乖了，抽象出一个日志接口，双端各自实现。

为什么要做双端适配？

这问题说白了，就是「一次开发，两平台能用」。

我见过很多公司，Android和iOS各写一套SDK，维护成本直接翻倍。如果能把公共逻辑抽象出来，只对平台特有部分做适配，能省大量时间。

典型的适配方式有几种：

C++跨平台方案：核心逻辑用C++写，Android和iOS都调用同一份代码。
桥接封装：用统一的Java/Swift接口，底层调平台API。
二进制依赖：把公共部分编译成.so或.framework，各自引用。

我个人更推荐桥接封装，因为灵活性高，调试也方便。

一个真实的踩坑经历

有一次，我负责的推送SDK在Android上跑得好好的，一到iOS就频繁崩溃。

查了三天，终于定位到：Android在后台能保持长连接，但iOS对后台任务限制极严，连接被系统杀掉后没有正确处理。

解决办法：给iOS加了一个「断线重试机制」，并且在App进入前台时强制检查连接状态。

  关键教训：做双端SDK，永远不要假设一个平台的行为和另一个平台一样。系统规则不同，你的适配代码就得跟上。

本章知识体系

下面这张图，可以帮你快速理清思路：

双端开发环境准备的差异

这个点，初学者容易忽略。你以为装个IDE就能干活，其实不然。

Android：Android Studio + JDK + Gradle。仿真器跑得慢，建议用真机调试。
iOS：Xcode（必须macOS）+ CocoaPods。真机调试需要开发者账号。

我个人经验：如果你只有一台Windows电脑，做iOS开发是没戏的。要么买Mac，要么用云端Mac服务。

API设计风格差异

Android SDK习惯用接口回调，iOS SDK喜欢闭包/Block。

举个例子：

// Android 接口回调风格
sdk.startLogin(new LoginCallback() {
    @Override
    public void onSuccess(String ) {
        // 处理成功
    }
    @Override
    public void onError(int code, String msg) {
        // 处理失败
    }
});

// iOS 闭包风格
sdk.startLogin {  in
    // 处理成功
} failure: { code, msg in
    // 处理失败
}

你看，逻辑一样，但写法完全不同。做适配时，需要把这两种风格统一成一个抽象接口。

核心差异速查表

场景	Android实现	iOS实现
网络请求	OkHttp / Retrofit	URLSession / Alamofire
本地存储	SharedPreferences	UserDefaults
文件路径	getFilesDir()	NSSearchPathForDirectoriesInDomains
线程切换	Handler.post()	DispatchQueue.main.async
日志输出	Log.d()	os_log()/NSLog()

注意：即使是相同的功能，底层的系统行为也可能不一样。比如文件路径，Android和iOS获取的位置完全不同，别写死。

小结

这一章的内容，说白了就是帮你建立「双端意识」。

做SDK适配，不是写一遍再翻译一遍，而是先抽象出公共逻辑，再对平台差异做定制。

我刚开始做那会儿，总觉得多写一个平台很累。但做过几次之后你会发现——只要框架搭得好，后面全是重复劳动。嗯，这才是真正省力的地方。