由于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比较简单，只有两层如下：
代码语言：javascript复制- SDK
- API
- Module
- Framework
- SDKDemo图中文件结构仅是为了说明问题哈，最终交付给游戏的内容是一个jar和一个demo工程。
后来随着SDK的发展，需求的不断增加，SDK的内容也逐渐增加。加入资源和JNI文件以后，只使用两层结构就出现了比较多的问题。于是MSDK的结构变成了三层。
代码语言：javascript复制- 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的资源文件名称冲突了，那才真真丢人呀。我们遇到的这种合入的时候就发现的，只是多了点工作量，其余都还好。
