由于SDK的特殊性,所以对于SDK的开发来说,一开始对于SDK的一些通用的整体的元素的设计至关重要。因为SDK(尤其很多平台SDK,使用的应用成百上千)一个及其细微的调整都会影响很多开发者的版本周期。因此前期的设计显得尤为重要。关于这部分内容,我会分两篇来介绍,这篇重点介绍SDK的架构和一些资源的使用方式。另另一篇SDK设计心得之接口设计将重点介绍具体接口的设计。
最近一直看Android training相关的东西,慢慢发现拖太久了,这部分内容没之前想的那么清楚了,看来以后还是要勤快。目前先按照之前的规划全部写完,后续有一些想法再陆续补充。
对于这部分内容,处于种种原因吧,就简单介绍下。其实SDK的架构都差不多,类似与系统架构。一般:
大体上可以分为三层。API层、Framework层、Module层。
API层最容易理解,他是对整个SDK的对外封装,经过这一层以后仅仅把需要暴露给外部的接口、结构体声明出来,向开发者隐藏具体实现。
Framework层是核心层也是最底层,完成SDK的初始化、模块管理以及一些公共基础工具,例如数据存储、网络请求处理等。也有可能再细分一层libware,主要承载一些通用方法(如字符编码、文件读取、包信息读取等)的实现以及对通用库的封装(例如AsyncHttp等)
Module层严格意义上应该称中间层,这一层一般是具体模块的业务逻辑,主要是具体的功能实现。
一般对于Module也又按照上面的三层结构来划分,做到各个模块之间的功能独立。
一般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的资源文件名称冲突了,那才真真丢人呀。我们遇到的这种合入的时候就发现的,只是多了点工作量,其余都还好。