详解机器视觉软件开发SDK

SDK 就是 Software Development Kit 的缩写，中文意思就是“软件开发工具包”。

这是一个覆盖面相当广泛的名词，可以这么说：辅助开发某一类软件的相关文档、范例和工具的集合都可以叫做“SDK”。具体到我们这个系列教程，我们后面只讨论广义 SDK 的一个子集——即开发 Windows 平台下的应用程序所使用的 SDK。

呵呵，其实上面只是说了一个 SDK 大概的概念而已，理解什么是 SDK 真有这么容易吗？

恐怕没这么简单！为了解释什么是 SDK 我们不得不引入 API、动态链接库、导入库等等概念。^_^，不要怕，也就是几个新的名词而已，其实学习新知识就是在学习新名词、新概念和新术语。

首先要接触的是“API”，也就是 Application Programming Interface，其实就是操作系统留给应用程序的一个调用接口，应用程序通过调用操作系统的 API 而使操作系统去执行应用程序的命令（动作）。其实早在 DOS 时代就有 API 的概念，只不过那个时候的 API 是以中断调用的形式（INT 21h）提供的，在 DOS 下跑的应用程序都直接或间接的通过中断调用来使用操作系统功能，比如将 AH 置为 30h 后调用 INT 21h 就可以得到 DOS 操作系统的版本号。而在 Windows 中，系统 API 是以函数调用的方式提供的。同样是取得操作系统的版本号，在 Windows 中你所要做的就是调用 GetVersionEx() 函数。可以这么说，DOS API 是“Thinking in 汇编语言”的，而 Windows API 则是“Thinking in 高级语言”的。DOS API 是系统程序的一部分，他们与系统一同被载入内存并且可以通过中断矢量表找到他们的入口，那么 Windows API 呢？要说明白这个问题就不得不引入我们下面要介绍得这个概念——DLL。

DLL（又是一个缩写，感觉 IT 这个行业里三字头缩写特别多），即 Dynamic Link Library（动态链接库）。我们经常会看到一些 .dll 格式的文件，这些文件就是动态链接库文件，其实也是一种可执行文件格式。跟 .exe 文件不同的是，.dll 文件不能直接执行，他们通常由 .exe 在执行时装入，内含有一些资源以及可执行代码等。其实 Windows 的三大模块就是以 DLL 的形式提供的（Kernel32.dll，User32.dll，GDI32.dll），里面就含有了 API 函数的执行代码。为了使用 DLL 中的 API 函数，我们必须要有 API 函数的声明（.H）和其导入库（.LIB），函数的原型声明不难理解，那么导入库又是做什么用的呢？我们暂时先这样理解：导入库是为了在 DLL 中找到 API 的入口点而使用的。

所以，为了使用 API 函数，我们就要有跟 API 所对应的 .H 和 .LIB 文件，而 SDK 正是提供了一整套开发 Windows 应用程序所需的相关文件、范例和工具的“工具包”。到此为止，我们才真正的解释清楚了 SDK 的含义。

由于 SDK 包含了使用 API 的必需资料，所以人们也常把仅使用 API 来编写 Windows 应用程序的开发方式叫做“SDK 编程”。而 API 和 SDK 是开发 Windows 应用程序所必需的东西，所以其它编程框架和类库都是建立在它们之上的，比如 VCL 和 MFC，虽然他们比起“SDK 编程”来有着更高的抽象度，但这丝毫不妨碍它们在需要的时候随时直接调用 API 函数。

开发SDK时需要注意的问题

1. 修改类别文件名及类别方法。

开发ＳＤＫ时通常会用到比较多的第三方的类别方法，这样的话，开发者在使用你的ＳＤＫ时，因为他可能也会加一些第三方的开源库，比如都使用了NSString的md5类别文件。由于这两个文件都是从网上下载来下的，所以文件名是一样的。这样在编译时就会报错。然后就想到要去修改这个类别文件名，等修改类别文件名后。发现类别中的方法名是一样的，而iOS在调用两个相同方法的类别方法时，不能确定其调用的哪个方法，但可以肯定地是只会调用一个类别方法，如果恰好开发者自己又修改了这个类别方法，那就有问题了。

所以在ＳＤＫ开发过程中，需要修改引入进来的类名，及方法名，建议添加项目前缀，最好是三个字母的，如ＮＡＢ，（两个字母为苹果自己保留使用）

2. 在开发ＳＤＫ时，如果发现某个方法命名时比较困难，那么几乎可以肯定的是，这个方法藕合度太高，需要再次进行分解。

3. 开发ＳＤＫ时，需要考虑到升级的问题，并且可以指定某些版本必须强制升级。（以防某些版本到后期发现有明显问题，需要及时替换）

4. 开发ＳＤＫ时，需要留出一个接口，能通过后台服务器强制关闭掉某个接入应用的调用。（这可能会发生在恶意地攻击行为，以及非恶意地使用行为，如某应用频繁自动重启事故，每次重启都会调用咱们的ＳＤＫ，然后就会使得咱们的ＳＤＫ服务器压力陡增），这个时候，如果后台能根据这个应用的ＡＰＰＩＤ啥的，强制关闭它发的请求，或者屏掉他的请求，你会发现世界如此美好。

5. 统计方面，ＳＤＫ存储每个接口调用的次数，以在一定的情况下发送给服务器，便于后期分析某些接口是否有问题，或者是根本就没有用户使用的情况。

6. 有些ＳＤＫ使用的前提条件，最好是在编译期就提示给用户，而不是在运行期，可以使用类似下面代码来进行提示

#warning – Release scheme, this is not work.

#if !__has_feature(objc_arc)

#error iBeaconSDK requires automatic reference counting

#endif

更好地构建SDK

1. 了解墙外的世界，把握好需求

试着去关注你的竞争对手或者与你相似领域的公司都做了什么。这可能会给你一些参考的角度。采纳你喜欢的地方，改善你不喜欢的地方。

2. 简洁

代码简洁——简洁的代码意味着你的客户用起来得心应手。这可能包括尽可能减少与代码交互的方式，比如只公开一个接口类；或是简短的方法签名，比如少量的输入参数，等等。

除了初始化阶段（只发生一次且可能要求进行配置），请让SDK方法使用起来尽可能简单。

同样地，请尽量减少方法签名中的参数。

你可以通过提供默认配置以及允许高级用户进行覆盖的默认实现类来达到这一目的。

隐藏用户不需要使用的类和方法，比如，只将用户必须使用的类/方法设定为公有的，否则就将它们的使用范围设定为局部或者私有。一个 IDEs 提供了代码检查与清除功能，可以帮你自动实现这一点。

参考文档简洁——让你的文档尽可能简单易懂。这意味着有时候你得多写注释，有时候又得尽量少写。内联样本代码通常很有帮助，因为大多数人都是通过例子来学习的。

3. 提供简单的开始步骤

这是指一个人可以在五分钟内上手使用你的代码。这一点非常重要，因为客户往往希望尽可能不费力地进行集成。除此之外，有时候客户想要评估你的产品，但如果无法进行简单的测试，他们就很可能选择跳过你的产品。

4. 短小精悍

保持简短主要是文档的责任，但是同样与用户和SDK代码的交互方式有关；为了保持文档的简短，可以提供代码样例、一目了然的方法名或使用默认数据来实现。

5. 集成

请谨记客户开发环境的多样性。

比如说，如果你在写一个安卓库，它的集成方式在客户使用Android Studio加gradle 框架和使用Eclipse集成开发环境时就非常不同。前者需要aar工件并发布到远程存储库中，而后者需要你提供jar文件，以及关于如何为SDK更改AndroidManifext.xml文件和独立eclipse项目的指导。

这可能会影响你的构建机制及其工件。然而，不要试图取悦所有客户，请先满足你的第一位客户，或者预期中的大多数客户的需求。

6. 项目示例

在GitHub上创建一个最基本的项目，模拟使用SDK包的用户。

这可以向客户展示你的产品如何满足他们的需求，以及如何集成你的产品。如果你想展示高级用法，那就在另一个项目里进行展示。通常，客户会将项目示例作为主要的参考文档，因此，请提供行内评论，并尽量用一目了然的方式书写代码。

7. 概述

在参考文档的开头，或是GitHub项目的README.md文件中，请用直白的语言对你的解决方案进行概述。在此部分，笔者通常会提供一个使用样例来解释SDK的典型用法。如果有可能，请提供一个简单的表格或是图表，这样一来，不喜欢阅读操作指南的用户也可以快速了解该SDK的优势。

8. 初始化

使用在SDK域内可接受的惯例。

这些惯例可能是可重载的构造函数，某种构建模式等。初始化应当巧妙地使用默认值来简化流程。

9. 默认值

默认值对于保持代码的简洁性和减少配置过程（见简洁性部分）是非常重要的。你所提供的默认值（不管是在配置还是实施过程）应该代表在你眼中大多数SDK用户会进行的操作。