最近公司在做SDK，这里总结下SDK开发规范

开发规范

  • API功能单一，减少类似enum的入参设计
  • 线程处理， 如非必要不要使用应用主线程，不能长时间占用，SDK内应有一个专门线程处理SDK 相关操作
  • 尽量减少全局回调
  • 提供异常情况回调和输出方便接入放定位，错误回调采用code+msg组合
  • 能不用单例的就尽量少的使用
  • 对iOS 来说能不用xib 就不用，能不用通知就不用通知

命名规范

  • 接口名称，参数命名清晰规范，参数尽可能少，所有传入参数要做好校验，禁止使用拼音和中文
  • 类名前缀和包命名缩写要一致
  • 函数命名遵循共性，不要出现歧义或者违背大家的共识
  • 所有资源命名前缀：mEft_xxx_ 工程命名：eft-sdk-xxx-android or eft-sdk-xxx-ios
  • demo 项目命名：demo，包名：cn.eft.sdk.xxx.demo sdk
  • 项目命名：mEftXxxSDK，包名：cn.etf.sdk.xxx

注释规范

  • 代码注释规范清楚
  • 接口注释要完善
  • 注释形式统一
  • 注释内容准确简洁

日志设计

  • 核心处理log日志可以配置
  • 可控制打印log级别
  • 主流程，异常日志存储方便定位问题

第三方库依赖处理原则

  • 能用系统的API解决的，就不要使用第三方，减少对其他库的依赖；
  • 最小可用性原则，即用最少的代码，如无必要勿增实体；
  • 最少依赖性原则，即用最低限度的外部依赖，如无必要勿增依赖
  • SDK开发中，需要尽量避免依赖第三方库以免引起不必要的冲突
  • 如果确实因为项目需要，要引入一些开源库，可以通过源码集成的形式引入，再更改一下包名（类名），避免集成冲突。

版本管理规范

  • 使用三位版本号，每位版本号最高三位数字如：1.0.12
  • 版本号递增原则：
  • 第三位：bug修复，极小的变更
  • 第二位：一般的功能迭代
  • 第一位：项目重构，功能变更较大，需团队共同确定

打包原则

  • 对外提供的包不能包含任何编译生成的文件和目录，如安卓的build目录 iOS XcodeData
  • 使用脚本一键打包，提升打包效率，降低手动打包带来的出错率
  • 打包脚本需与项目其他脚本分离，尽量职责单一， 包中尽量提供示例工程， 示例工程必须让开发者以最低的成本运行起来
  • 打包完成的SDK，集成到示例工程，要进过QA测试才能放给用户

通用规范 （注意事项）

  • 接口隔离 （小而 精简）
  • 接口易用性 （对外接口易用，易懂）
  • 向后兼容 （升级SDK兼容）
  • 配套有完整且详细的使用说明文档和版本更新说明
  • AppId 和 AppKey的分配，用于区分集成sdk的是哪一个公司，做好权限控制
  • SDK的 sdkVersion要尽量小，最好不要超过使用SDK的项目的Version（支持的系统）
  • 尽量不要引用第三方库，要尽量使用系统自带的功能，然后在其基础上进行封装。
  • SDK需要有较强的容错性，增减稳定，增大力度对于SDK内部异常进行捕获。
  • SDK内部对于关键路径要有详细的Log记录，便于后期排查问题。
  • 各个库之间要做到高内聚，低耦合
  • 核心代码的安全性