最近需求需要接入地图SDK，本想腾讯地图确实不给力，想看看竞品做的如何，发现高德的SDK更烂。
首先是sdk还停留在十年前，使用jar包方式集成。需要拷贝一大坨jar包到工程项目中。
后来下载了demo，一堆报错，2024年了，demo中的gradle版本还是4.6版本，gradle tool 版本更是3.0，与java11 都不兼容。
解决完工程结构后，发现运行竟然报错。报错的原因是变更了jar包中类的处理。
大量的类在构造的时候需要Catch住？真的是毁了三观。
作为一个知名的地图开放平台，显得太不专业了。
一些思考
其实，在工作中，总是会接入一些第三方的工作，近年来发现很多团队对这些第三方提供的服务越来越不友好。记得刚刚入行的那几年，也接过不少sdk，发现都非常简单易懂，即使作为刚入门的小白，跟着步骤来基本都能摸透里面的使用。
近年来，不知道是由于降本增效还是什么原因，感觉很多厂商并不重视这些工程建设。总是想着搞出花样来。似乎功能越多越好，别人有的我要有，别人没有的我也要有。于是这些看起来非功能性的接口设计，文档就都交给非核心员工或者一些实习生，外包来处理了。而这些功能，页面都很少亲自站在使用者的角度来设计接口，因为自己不是用户嘛。
那如何才是一个好的sdk呢，最近在看公司的iRead 课程正好有了解过一些关于接口设计的规范。这里我也将sdk的设计泛化到接口设计上来。
我认为是足够简单，足够健壮，足够安全
足够简单
接口名称易于理解，不会模棱两可，通过接口名称和参数名称就知道意图是什么，最好能达到不需要注释的地步。
参数要非必要就不要。对于多参数的接口应当采用builder模式。
开箱即用的调用示例。上面的例子中，一个例子就是示例都有编译问题，可能在之前老版本的Android Studio中是ok的，但是很久没有更新了，主流IDE版本不能开箱即用，感觉说不太过去。
足够健壮
也就是对于异常调用能处理好，比如参数校验，多线程甚至多进程调用。
一些接口可以设计成幂等就不要抛异常。
接口调用如果有回调就一定要有回调，不要出现调用以后有可能有，也有可能没有回调。实在如果没有，应该设计成超时接口供调用方处理。
足够安全
因为很多第三方接口是收费的，因此如何让sdk保证是有权限的app在调用呢。对于支付类sdk特别敏感，是否信任调用方，通过怎么样的设计在保证安全的前提下尽可能简化（有时候安全和简单是两个对立面）
一般比如外部提供的sdk要求包名和签名一并在网站上注册才能调用，在进行关键数据请求时会校验签名。对于支付类请求，还要求参数用非对称加密以及sha签名防篡改。