引言
回想起来，我在目前的团队（金融科技领域）待了有很长一段时间了，一直在做SDK研发，平时工作中经历过大刀阔斧一蹴而就的喜悦，也经历过被一个问题按在地上摩擦，无奈“废寝忘食”的不堪，日复一日年复一年，如果硬要吐露一下内心的感受，就一个字“难！”。
为什么说难呢？总结下来有两方面原因，一方面原因是所处行业为金融行业，金融行业相对其它行业，更加注重产品合规、功能稳定、数据安全、用户隐私等，所以在产品方面的要求非常严格甚至苛刻，严格到必须做各种眼花缭乱的测试报告，苛刻到不允许调用任何一个有可能存在风险的API。另一方面原因就是所研发的产品是SDK，SDK和APP一样，是代码、程序、软件，但和APP又不一样，SDK（Software Development Kit）被定义为软件开发工具包，具备工具的属性，是一种会被集成到其它软件里面的软件包，在开发SDK的时候，需要处理好SDK和宿主程序之间的关系，需要比开发APP考虑更多的问题，例如：SDK怎样设计才能更方便地被集成和使用，SDK怎样避免和宿主程序之间发生冲突，SDK如何保证前后兼容、SDK如何控制包体积等。
下面我们就来具体说说给金融科技领域编写客户端SDK，需要思考哪些方面的问题。
思考
实用
一款SDK之所以能作为产品诞生并不断发展，一定有它的社会价值，这种价值可能体现在它能给行业面临的一些问题带来解决方案，或者是能够降低生产成本，又或者是能够提升生产效率等，如果SDK不具备实用价值，不能为他人、为社会所需要，即使代码质量再高，也不可能在市场上取得成功，甚至都无法生存下去。
所以，思考千万条，实用第一条！
合规
正所谓“无规矩不成方圆”，人类从原始时期开始，一直到现在的文明社会，每个阶段都会在种群内部建立一套规章制度，用以约束个体行为，促进成员间的合作，保障社会活动有序进行，这种规章制度不断演进，不断合理化，就逐渐形成了法律法规体系，法律法规体系是一套逻辑严谨且高度完备的系统，从基本法到一般法律，涉及社会中的方方面面，这里面就包含对各行各业的法律规定，金融行业作为关系民生的基础行业，涵盖银行业、证券业、保险业、基金业、信托业等众多子行业，这么重要且庞大体系要能正常运转，自然离不开行业法律法规的支撑，国家不仅为金融行业颁布了各种法律条文，还建立了专门的监管机构来监督金融活动的开展过程，旨在建立合规合法的金融市场，保证金融行业的稳定可持续发展。
软件作为金融企业从传统服务行业到数字化高科技行业转型的基础设施，而SDK又作为众多软件的零部件，自然而然必须符合法律规范，接受国家的监督管理。软件是人类新时代文明的产物，大大解放了生产力，能用来做很多事情，如果利用得好，可以带来巨大收益，如果遭到滥用，则会带来严重损失甚至危害，所以必须对软件制定各种约束规则，时刻监督软件的运作过程，保证软件是用来提供优质服务的，而不是破坏社会正常秩序的。
安全
安全可以看作是合规的进一步延伸，如果说合规是通过技术之外的手段来约束软件的自由，而安全则是通过对技术内部的审查来判断软件是否达到安全标准，并决定是否允许使用软件。
任何一个软件都不是绝对安全的，是软件总会有漏洞，有漏洞就会存在被破解、被攻击、被非法利用的风险，一旦这种风险变为事故，损失可大可小，但对于金融行业而言，再小的事故都会导致口碑和客户信任感的急剧下降，所以金融行业在软件安全性方面是极度重视的。
金融企业通常会采取各种方式加强软件的安全性，例如：
- 代码扫描
金融企业会通过多种代码检测工具对代码进行安全扫描，扫描完成之后会形成书面检测报告，我们拿到检测报告之后要做的事情就是分析其中每个风险项产生的原因，思考解决办法，然后逐个清理掉。 - 软件加固
金融企业会借助专业的加固平台对软件进行加固，包括APP加固、二级制包加固等，加固是为了增加软件被破解的难度，最大程度防止软件被反编译，被他人窃取关键信息和软件劳动成果。 - 数据加密
互联网时代，最有价值的往往不是各种层出不穷的软件本身，而是隐藏在软件背后的数据，因为数据是记录系统中各角色信息以及用户行为的第一手资料，通过这些数据我们可以洞察整个行业的现状，并且分析预测出发展趋势，因此数据就是机密，对数据的保护至关重要。金融企业通常都会对数据进行各种加密处理，如数据传输加密、数据存储加密等。 - 软件安全认证
金融企业在软件类库方面有严格的管理机制，只有经过安全认证的软件类库才会被允许使用。部分企业会建立私有软件仓库，并把经过安全认证的软件类库同步到仓库里面，开发过程中，只允许依赖自己软件仓库里面的类库，不能随便引用外部的类库。 - 漏洞跟踪
金融企业对软件漏洞方面的关注程度是非常高的，每当有权威机构发布漏洞说明时，他们都会第一时间检查自己的产品里面是否有用到漏洞涉及到相关软件，如果有就必须及时处理。
以上只是列举了金融企业在软件安全性工作方面的一些常规操作，实际情况会复杂得多。我们在给金融企业编写SDK的过程当中，需要配合金融企业完成各种安全检测，并及时处理各种安全性方面的问题。
稳定
软件的稳定性也是影响到软件是否可用的重要指标，只有稳定运行的软件才能保证业务的正常开展。试想一下，如果一个软件bug层出不穷，经常用着用着就卡死了或者崩溃了，会有什么后果？可能会收到客户的反馈和投诉，导致客户受到损失，口碑日趋下滑，逐渐失去用户群体……这些都是作为乙方的我们最害怕，最不愿意看到的。因此，保证软件的稳定性是我们在软件开发过程中极为重要的一环。
SDK作为第三方库，会被集成到不同的宿主程序里面去，这就使得SDK面临的业务场景复杂多样，一些边缘场景更是无法预知，也许SDK在一个APP中表现“完美”，但到了到另一个APP中就开始“抽风”了，如何保证SDK在各种场景下都能稳定运行，成了一个不折不扣的难题，但是我们仍然可以通过努力来减少不稳定因素。
SDK要保证稳定性，需要产品、研发、测试三管齐下，团队成员齐心协力、紧密配合。
- 首先，SDK作为产品，在设计的时候，业务逻辑必须符合用户需求，不能过度设计，也不能有遗漏，更不能往错误的方向设计。
- 其次，在研发过程中，每位研发人员都必须尽职尽责，严格依据产品设计，对照验收标准进行研发，不仅要按时完成基本功能的闭环，还要积极发挥自己的主观能动性，考虑周全，想他人所不想，特别是一些边缘场景，做好容错处理，并且严格做好自测。
- 最后，在测试方面，测试人员需要根据产品需求设计好完整的测试用例，并且把测试用例同步给研发人员，测试用例应尽可能包含各种可能的场景，例如弱网环境下的测试、不同机型的测试等，待研发提测之后，对照测试用例逐一完成测试验收。测试人员还应该多借助自动化测试脚本、云测等工具进行辅助性测试，以发现更多潜在问题，达到更好的测试效果。
SDK要保证稳定性，在版本控制方面也需要做好管理，例如SDK可以分不同的版本发行，提供诸如稳定版、开发版、体验版之类的各种版本，用于满足不同用户的需求，稳定版可以很长时间更新一次，追求稳定的客户可以使用稳定版，开发版可以在开发过程中有更新的时候发布，用于内部测试等，体验版可以每个迭代或几个迭代发布一次，用于及时对外发布更新，一些热衷尝鲜的用户可以提前拿来体验。这样稳定版的更新频率不会太频繁，可以在一定程度上避免稳定性问题。
友好
何为友好？人与人之间的友好体现在大家相互尊重，能够礼貌、和谐、融洽地相处，那么SDK的友好又体现在哪些方面呢？和SDK直接打交道的是集成SDK的宿主程序，所以SDK的友好性也是直接体现在SDK和宿主程序之间的，要思考SDK友好性的问题，就需要思考SDK如何才能和宿主程序和谐共处。
宿主程序要使用SDK，第一步要做的便是集成SDK，因此，体现SDK友好性的第一点就是SDK集成起来简单方便。以Android工程为例，在build.gradle文件中仅添加一行代码，就把SDK依赖到了工程里面，除此之外，不需要改动工程原有的任何配置，不需要处理任何编译报错，便能成功把工程运行起来，这就说明SDK在集成方面非常友好。
宿主程序要使用SDK，需要SDK提供各种接口给外部调用，例如初始化SDK的接口、调用SDK内部各种能力的接口、监听SDK内部事件的接口等等，因此，体现SDK友好性的第二点就是SDK提供的接口很完善，接口命名合理，参数含义准确，注释清晰，调用起来很容易很方便。
不管是集成SDK还是使用接口，如果有一份清晰完善的文档拿来参考，那便是再好不过的了，这样能大大降低开发者的学习门槛，因此，SDK的友好性也体现在提供了高质量的使用文档。
除了文档，开发者们往往也希望有示例可以参考，毕竟有一份现成的代码学习起来会更加直观，示例能帮助开发者更加快速地掌握SDK使用方法。因此，SDK的友好性还体现在有完善的示例可供参考、学习。
轻量
在做移动端开发的时候，我们经常面临的一项优化内容就是APP瘦身，APP为什么要瘦身？因为如果APP体量太大，就意味着下载APP需要耗费更多的流量，网络不好的话下载耗时也会增加，安装APP也需要占据更大的存储空间，用户使用APP的成本就增大了，体验也大打折扣，这就是为什么当下小程序如此流行的原因，因为小程序足够轻量，安装卸载都非常方便，使得大众在平时工作和生活中往往更倾向于使用小程序，而不是到手机应用市场里面去获取一个笨重的APP。
虽然小程序对原生应用产生了很大冲击，但并不意味着小程序能够完全替代原生应用，因为小程序毕竟还是一种介于原生和前端之间的技术，它支持垮端，能够调用很多原生的能力，拥有比纯Web应用更好的UI交互体验，但是比起原生应用，还是不如原生应用那么流畅，渲染出来的控件还是不如原生应用那么精美，原生应用的优势是小程序无法替代的。
不过小程序等优秀前端技术的出现，还是给原生应用开发敲响了警钟——原生应用也需要更加注重轻量化。其实不仅仅是金融企业，很多互联网企业在开发APP的时候，都会尽可能地缩减应用体积，有的APP对体积大小非常敏感，例如当SDK的体积超过1MB时就会犹豫要不要使用SDK了。所以，SDK开发者们不得不面对这样一个问题，那就是SDK必须“小而美”。小，要求SDK占用的体积小，美，要求SDK小的同时还必须功能强大，要能满足用户的各种需求。
俗话说“鱼与熊掌不可兼得”，我们如何实现SDK的小而美？这里简单罗列一下可以采取的措施：
- 保证代码的简洁、清爽、优雅。
架构合理，逻辑清晰，干净整洁的代码，阅读起来会更加容易，开发人员维护起来也会简单许多，出现代码冗余，“屎山”堆积的情况也会大大减少，反之如果代码逻辑混乱，程序员A今天这么写，程序员B明天那么改，久而久之，代码不仅可能BUG丛生，而且会变得越来月臃肿，臃肿的代码自然而然无法做到轻量。 - 对资源文件进行处理。
SDK中占体积最大的可能不是代码，而是各种资源文件，包括图片、音频、视频等，我们可以对这些文件进行处理，例如：- 调整获取文件的时机
我们可以不把这些文件直接打包到SDK里面，而是改为在运行过程中要用到的时候再下载，这样SDK包里面就没有这些资源文件了，体积会大大减少。 - 对文件进行压缩
这些文件的原始体积可能较大，我们可以通过转换格式、降低分辨率等方式对这些文件进行压缩，以减少文件所占据的体积。
- 调整获取文件的时机
- 对代码进行压缩。
例如，在Java里面我们可以借助ProGuard工具对代码进行混淆，混淆过程中会移除代码中无用的类、字段、方法，并且用简短无意义的名称对类、字段、方法重命名，这样在保护代码的同时也能够减小代码占据的空间。 - 减少对第三方库的依赖。
在实现一些复杂功能的时候，我们往往倾向于找现成的轮子直接套用，但是直接依赖第三方库会带来一些问题，其中一个问题就是可能会增加代码体积，因为有的库虽然功能很强大，但是体积也很大，实际上，有时候我们只需要其中一部分功能，这个时候我们最好不要直接依赖第三方库，我们可以对其进行裁剪，只保留我们所需要的代码，或者借鉴其思路自己编码实现，在实现过程中也许还能够对代码进一步做精简。 - 组件化
把SDK按照功能模块拆分为多个小的SDK，每个小的SDK作为单独的组件进行维护和发布，用户在集成SDK的时候就只需要依赖要用到的SDK就可以了，这样就避免了一下子引入整个SDK带来的体积问题。 - 插件化
把SDK按照功能模块拆分为多个小的SDK，每个小的SDK作为单独的插件进行维护，用户只需要集成核心SDK，其它SDK可以在运行过程中通过核心SDK动态下载并加载，这样SDK的体积也会大大减小。
适配
同一套代码，在不同的机型上面，或不同版本的操作系统中，或不同的场景下，表现可能会不一致，有的不一致属于正常现象（例如某个二次开发的操作系统更改了UI样式，和原生操作系统不一样了），但也有一些不一致是因为没做好适配导致的。其实，适配一直是需要投入大量精力且让人头疼的工作，因为移动设备类型太多，有全面屏的也有非全面屏的，有内存大的也有内存小的，有系统魔改的好的也有被改的乱七八糟面目全非的，碎片化很严重，只能说开发者们太难了！
一个好的产品，在适配方面一定是做得还不错的，所以要想把产品做好，也一定要做好适配工作，想办法让自己的代码兼容更多的机型、兼容不同版本的系统、兼容各种复杂的场景。
做好适配工作，一方面需要研发人员了解基本的适配规则，例如屏幕适配原则，在研发过程中严格遵循这些规则，同时主动跟进系统版本变化情况，及时做好版本适配，有时候还要深入挖掘不同机型之间的差异，以弥补手机厂商们改造系统时带来的问题。另一方面，测试人员需要做大量测试，以及时发现一些适配问题，交给研发人员修复。
兼容
SDK研发是一个不断迭代升级的过程，每隔一段时间就会对外发布新的版本，在这个过程当中，我们必须做好前后兼容，不然会出现各种问题，例如：
- 业务逻辑异常
SDK需要请求后端接口获取数据，从某个版本开始，后端因为某些原因对接口进行了调整，返回的数据和之前的不一样了，SDK也跟着调整了处理接口返回数据的逻辑，不过没有对旧接口返回的数据进行兼容，SDK改造完毕发布了一个新版本，用户拿到新版本SDK进行了升级，但是忘了升级后端服务，这个时候就出现了新版本SDK+旧版本后端接口的情况，旧的后端接口返回旧的数据，而新版本SDK已经不再兼容旧的数据了，于是接口返回的数据没能在SDK这边被正常处理，出现了数据加载异常的情况。
客户端SDK和服务端不能保证每次都是配套升级的，有可能只升级了SDK或者只升级了服务端，因此，我们需要考虑新旧版本SDK搭配新旧版本服务端是否会有兼容问题，如果有则应该想办法做好兼容处理。 - 用户需要改动现有代码，不能平滑升级
SDK对外提供了一个接口，宿主程序会调用这个接口来完成某些功能，某次升级SDK版本之后，突然发现这个接口找不到了，查了一圈文档，又问了SDK这边的工作人员，才发现原来旧接口已经被去掉了，需要使用新的接口来替换旧接口。这种情况下，用户改改自己的代码，调用新接口也是可以的，不过这种直接强行让用户改代码的行为还是不那么友好，改动小倒还好，如果改动较大，用户调整代码的成本就增大了，用户不一定情愿，结果可能还是要SDK这边把旧接口加回来。
在开发SDK时，应该尽可能保证对外的接口不频繁变动，如果要更改，也应该在兼容旧版本接口的基础库上改，例如增加一个新接口，同时保留旧接口，旧接口的实现改为和新接口一致，并且把旧接口标注为已过时，提示用户旧接口在未来的某个版本会彻底废弃，建议改为调用新接口。 - 数据丢失
旧版本SDK在某个文件目录下存储了一些数据，新版本SDK调整了存储数据的目录位置，如果在SDK升级过程中，没有将旧目录下的文件数据导入到新目录的文件中，那么这部分数据就会丢失。
如果旧的数据不重要，影响会比较小，反之影响就比较大了，我们应该在升级过程中将旧的数据迁移到新的数据文件中，保证新版本SDK仍能读取到存储下来的数据。
冲突
不管是我们自己使用别人的库，还是别人开发的时候集成我们的SDK，我们经常会遇到一类问题，就是SDK和宿主程序之间不兼容，也就是我们常说的“冲突了”，当然，冲突包含很多种，例如依赖库冲突、工程配置冲突、资源冲突等，举一些例子：
-
依赖库冲突
依赖库冲突是指SDK和宿主依赖了同一个库的不同版本，不同版本之间相互不兼容，而且不同版本不能同时共存，这种情况下，到底是选择SDK依赖的版本，还是宿主依赖的版本呢？好像都不合适，因为不管依赖哪个版本，都会对SDK或宿主其中一方造成影响。
那么要如何解决这个问题呢？站在SDK的角度，如果宿主能够把依赖库的版本改为和SDK依赖的版本一致，然后做一下适配，问题就解决了，但现实情况往往是宿主方不愿意自己做改动，而是希望SDK能够单方面处理掉这个问题。客观来讲，确实是由SDK来处理才能从根本上解决问题，因为SDK面对的是众多宿主程序，出现依赖库冲突的可能不止是个别宿主程序，总不能要求出现问题的宿主程序都来适配SDK。因此，SDK只能从自身出发来解决问题，那么，SD应该怎么处理呢？我想到的有以下几种方式：- 如果依赖库比较简单，或者SDK只用到其中一小部分能力，那么可以尝试去除依赖库，改为自行编码实现。
- 如果依赖库比较复杂，直接去掉依赖库改造成本会很大，则可以调整依赖库的依赖方式，改为通过源码的形式进行依赖。
- SDK把依赖库的版本改为使用最普及、前后兼容做得最好的版本，最大程度上避免依赖冲突问题的发生。
依赖库冲突是一个典型且麻烦的问题，建议开发SDK的时候，尽可能少依赖第三方库，特别是版本兼容做得不好的第三方库。
-
工程配置冲突
如果SDK和宿主的编译脚本配置不一致，可能会导致宿主在编译构建时发生报错不能正常通过，或者在运行时发生异常，例如Android工程里面：- SDK中指定的
minSdkVersion比宿主指定的minSdkVersion大，编译阶段报错； - SDK设置的主题和宿主设置的主题类型不一致，运行阶段崩溃。
为了避免工程配置冲突，在开发SDK的过程中，应该避免使用容易对宿主造成侵入的配置，如果必须使用，则应该让配置在最大程度上能兼容更多的宿主应用程序。
- SDK中指定的
-
资源冲突
如果SDK和宿主使用了同名的资源，会出现宿主资源覆盖SDK资源的问题，这样SDK中引用资源的地方就会出现问题。为了避免资源冲突，可以采取的做法是对资源命名时加上能够避免重名的前缀或后缀。
冲突并不可怕，因为冲突总是能够被解决的，但是作为SDK开发者，我们要做的应该是主动出击，做到尽可能避免和宿主发生冲突。
一致
因为操作系统、编程语言种类较多，所以同一套SDK可能会用不同的编程语言去实现，例如有在iOS上运行的Objective-C、Swift版本，有在Android上运行的Java、Kotlin版本，也有在鸿蒙上运行的JS、Java、C/C++版本，当然还有支持垮端的Flutter版本等等，但不管是什么语言开发的，既然是同一套SDK，那就应该保持一致，这里的一致不光是指表现上的一致，还包括实现上的一致，以及文档上的一致，一致程度的高低不仅在一定程度上体现了SDK的质量，也反映了SDK研发团队内部协同工作的水平。
- 表现一致
表现一致是指SDK在UI、功能、交互、体验等外在表现形式上的一致。 - 实现一致
实现一致是指SDK在架构设计、数据模型、接口设计、编码逻辑等内部实现上的一致。 - 文档一致
文档一致是指SDK集成文档、接口文档等关键性文档内容和风格上的一致。
灵活
SDK研发是一个从0到1，再从1到100的过程。当SDK基于某个最初的想法诞生之后，就需要结合更多的想法让自己走得更远，这些更多的想法来自于哪里呢？可能来自于团队成员们天马行空的创意，但更多更有价值的还是来自于用户的实际需求，只有能解决实际问题的产品才是好产品。
然而，用户的需求永远是五花八门，让人意想不到，捉摸不透的，因为每个用户在意的点不一样，需要解决的问题也不一样，因此，SDK面临的实际业务场景是非常复杂的，SDK必须要能满足多样化的需求，这就对SDK的设计、SDK的灵活性、可扩展性提出了更高的要求。
SDK要想做到足够灵活，应该怎么做呢？我认为可以采取以下方式：
- 通用性原则
SDK在设计和实现上应该做到尽可能通用，即核心部分能够满足绝大多数使用场景而无需做任何定制化开发。 - 抽象接口
SDK可以把具体的业务逻辑抽象化，通过接口或抽象类的形式暴露给外部，允许外部自定义具体实现并替换SDK内部的默认实现。 - 丰富配置
SDK可以提供足够丰富的配置项，外部通过设置配置项来控制SDK内部的状态。 - 丰富组件
把具备通用性的用户需求提炼出来并进行分类，然后按照类别开发不同的组件，这样就能逐渐形成一套功能完善，不同功能之间又相互解耦的SDK，用户根据自己的需要自由组合这些组件即可。 - 定制化开发
实际上，考虑到多种因素，我们并不能保证SDK不做任何定制化开发，如果确实需要做定制化开发，那也还是得做，不过在做的过程当中，可以思考如何从产品设计或者技术架构上入手，让定制化内容最终也变得通用。
服务
成功的产品除了产品本身质量过硬之外，还必须要有高质量的服务与之配套，SDK作为服务于企业、服务于广大开发者的产品，自然要做好服务工作。站在SDK研发人员的角度，我认为好的服务至少包括以下方面：
-
及时响应客户
客户在使用SDK的整个过程当中，包括前期试用阶段、后期正式使用阶段，不可避免的会遇到各种各样的问题，当客户反馈问题之后，我们必须第一时间响应客户，协助客户定位问题原因，给予解决办法，有的问题可能是目前尚未解决有待处理的，这类问题也应该向客户说明当前的情况和后续处理计划，让客户心里有底。 -
及时且高质量地交付产品
正常情况下，SDK都会按照迭代节奏定期发布新版本，但有时候客户的一些要求可能会打乱我们正常发版的节奏，比如说客户使用了比较旧的稳定版，但是发现该版本有一些bug需要修复，或者是要在该版本的基础上增加一些功能，客户把诉求传达给了我们，并且给了交付时间截止日期，秉承客户至上的理念，只要客户的要求还在合理范围之内，我们还是要做好服务工作的，所以即使是加班加点，也得想办法按时交付。
虽然说按时交付，时间上可能会很紧张，但这并不意味着可以降低交付标准，需求文档、产品设计、技术文档、测试用例、研发自测、测试验收等等，该有的环节还是一个都不能少，而且不能敷衍了事，必须保证最终交付到客户手里的是完全符合交付标准的产品。 -
维护好文档及示例
在前面也提到过文档和示例，但这里还是要重申一下文档和示例的重要性，因为文档和示例关系到用户能否顺利地使用SDK，其重要性并不亚于SDK本身。- 一般来讲，文档至少包括SDK集成文档、SDK接口文档、SDK发版日志，此外，如果做得好的话，还有FAQ文档、详细的版本变化说明文档、使用教程、技术博客等。文档内容力求表达清晰、描述精准，一定不要有错别字和病句。
- 示例应该尽可能完整，至少涵盖SDK的基本使用方法（集成、初始化）和主要使用场景。示例代码要保证干净、整洁，无需使用额外的框架，力求开发者好理解，关键的地方写好代码注释。
不管是文档还是示例，一定要做到及时更新。
保护
到此，我们说了这么多，更多是从用户的立场出发来思考问题的，现在我们来站在SDK厂商权益的角度来说一说还需要做些什么事情。
- 申请软著和专利
软著和专利关系到SDK厂商的核心利益，例如：法律维权、税收减免、高企申报、投融资等，其重要性不言而喻，因此，必须在第一时间申请SDK软著和专利。 - 源码安全
出于技术知识产权的考虑，SDK厂商不会对外开放核心源码，对于这部分闭源代码，有必要采取严格的保护措施，例如代码混淆、代码加固、代码仓库权限限制等，以防源码泄露。 - Key校验
我们在集成使用SDK的时候，经常会需要先在开发者平台上面申请一个Key（SDK Key、API Key等），然后把Key配置到工程里面，才能正常使用SDK，这是因为SDK厂商需要通过Key来校验、限制开发者的SDK使用权限，否则开发者可以无限制地使用SDK，厂商利益就得不到保障了。
总结
以上便是我对研发金融科技类客户端SDK的一点点体会，思考不一定全面，其中每一点也仅是粗略地阐述，没有深入挖掘，后续有机会我会在专门的文章里面就其中某些方面进一步探讨。
研发SDK其实就是造轮子，要把轮子造得又圆又结实，必须经过长期打磨，需要自上而下的顶层设计，也需要每一位成员发挥自己的工匠精神，不畏艰难险阻，精心雕琢每一个细节。