SDK设计心得之架构和资源

由于SDK的特殊性，所以对于SDK的开发来说，一开始对于SDK的一些通用的整体的元素的设计至关重要。因为SDK（尤其很多平台SDK,使用的应用成百上千）一个及其细微的调整都会影响很多开发者的版本周期。因此前期的设计显得尤为重要。关于这部分内容，我会分两篇来介绍，这篇重点介绍SDK的架构和一些资源的使用方式。另另一篇SDK设计心得之接口设计将重点介绍具体接口的设计。

最近一直看Android training相关的东西，慢慢发现拖太久了，这部分内容没之前想的那么清楚了，看来以后还是要勤快。目前先按照之前的规划全部写完，后续有一些想法再陆续补充。

关于SDK架构

对于这部分内容，处于种种原因吧，就简单介绍下。其实SDK的架构都差不多，类似与系统架构。一般：

• 大体上可以分为三层。API层、Framework层、Module层。
• API层最容易理解，他是对整个SDK的对外封装，经过这一层以后仅仅把需要暴露给外部的接口、结构体声明出来，向开发者隐藏具体实现。
• Framework层是核心层也是最底层，完成SDK的初始化、模块管理以及一些公共基础工具，例如数据存储、网络请求处理等。也有可能再细分一层libware，主要承载一些通用方法（如字符编码、文件读取、包信息读取等）的实现以及对通用库的封装（例如AsyncHttp等）
• Module层严格意义上应该称中间层，这一层一般是具体模块的业务逻辑，主要是具体的功能实现。
• 一般对于Module也又按照上面的三层结构来划分，做到各个模块之间的功能独立。

关于SDK目录层级

一般SDK的层级取决于SDK的复杂程度。初期我们的SDK比较简单，只有两层如下：

- SDK
	- API
	- Module
	- Framework
- SDKDemo

图中文件结构仅是为了说明问题哈，最终交付给游戏的内容是一个jar和一个demo工程。

后来随着SDK的发展，需求的不断增加，SDK的内容也逐渐增加。加入资源和JNI文件以后，只使用两层结构就出现了比较多的问题。于是MSDK的结构变成了三层。

- SDK
	- API
	- Module
	- Framework
- SDKlibrary
	- res
	- jni
	- libs
	- ...
- SDKDemo

此时的目录结构下，最终交付给游戏的内容将会包括：一个包含了SDK的代码jar以及资源和JNI的SDKLibrary工程（一个Android Library工程）和一个Demo工程。

目前最新的SDK开始支持Android Studio，因此我们的SDK的包又做了调整。除了上面的内容，还会提供一个SDK的aar给游戏。

关于资源

关于资源就几点：

• 所有的资源都放在Library中，然后SDK直接通过反射调用。这样可以方便SDK代码的打包、混淆等。
• 所有的资源和代码一样都是用统一前缀，并且可以区分到模块。例如com_example_sdk_module_XXX.xml；这样即有利于不同模块的资源区分，又可以防止资源冲突。

好吧，这里就再讲一个故事，前期我们的资源文件命名并不是很规范，都是直接随便用驼峰命个名。然后悲催的故事就这样埋下了伏笔。合入另一个SDK的，时候，就是那么巧，我们和他们的资源文件命名一致冲突了～～～呵呵呵呵！当时就在想，上天其实对我们不薄，要是我们的名字和开发者接入的别的SDK的资源文件名称冲突了，那才真真丢人呀。我们遇到的这种合入的时候就发现的，只是多了点工作量，其余都还好。