第二类开发方式，很多云服务公司已经提供了包有一定 pup 连接能力的平台。这两种方式对于当前的用户或者开发者来讲，都有一定的挑战。
前者会遇到开发门槛高的问题。通常来说只有在自研 IoT 平台的一些头部品牌商和硬件平台上才能进行，也会遇到硬件方案选型的往返、反复的过程。
我们遇到过非常多的开发者，都是在硬件选型几乎完成的过程中，发现音视频开发的种种挑战，又回过头来改方案，这对于他来讲是一个非常大的挑战。
如果是后者，就回到了一开始，我们提到这个行业对 RTC 没有认知度，还停留在之前点对点的传输方式，是没有体验保障的，所以它可以相对较快地完成功能的开发，但是功能的同质化很严重，音视频体验也不足以让用户随时地进行远程互动。
我们发现市面上没有一个体验好用的音视频互联网平台，便主导做了一个 aPaaS 级的平台产品，叫做声网灵隼，它是一个为音视频硬件开发而生的物联网平台。
基于过去提供的单点能力，我们把音视频的通讯和云信令进行了轻应用级的分装，提供能够解决开发者开发困难的端到端的平台型产品，包括覆盖到设备端、客户端和服务端的一些迁移用户的能力。除了音视频之外，还包含呼叫服务、云存服务、报警服务和设备管理。
这样一个音视频的设备，基本上最快在 15 分钟内就可以跑通demo，开发的整个周期也会从过去的半年以上缩短到个把月，这也是我们在平台化的产品中，为客户和开发者带来的价值。
另外一个是利用我们自己的 web RTC 开放协议来对接三方生态，像海外的 Alexa 、Google assistant 这样的智能音箱，这个思路是对标了现在全球物联网的 matter这样的跨生态的协议。所以未来只要是一个标准 web RTC，我们就可以很轻易地帮开发者跨平台和跨终端地互联互通。
gle assistant 这样的智能音箱，这个思路是对标了现在全球物联网的 matter这样的跨生态的协议。所以未来只要是一个标准 web RTC，我们就可以很轻易地帮开发者跨平台和跨终端地互联互通。
最后是如何帮助整个市场规模加速，帮助产业缩短产业链之间的鸿沟。我们在生态化上做了两件事情，一是用上游思维，找到在各个垂直领域赛道非常有优势的一些主流平台，结合刚才的场景化和平台化的战略，跟不同的平台去做场景化的深度适配。
像无人车和机器人领域，我们选择英伟达；在手表领域选择了绝对第一的紫光展锐，音视频摄像头、门铃选择了像乐兴、博流这样的平台。一方面能够让我们的上游厂商像卖模组一样去卖我们的能力，加速整个市场覆盖；另一方面是解决了开发者的困扰。
解决了上游之后，还有其他能力的伙伴，像AI、视觉类、音频类的能力。当我们落地到不同场景，比如智慧社区、智慧工业这些不一样的垂直领域，能够把我们的能力转化为他们行业经验的ISV。
除了面向客户，我们也定义了面向生态伙伴的部分开源规划。用了部分开源之后，行业ISV 还可以用我们的 SDK 去做从 Turkey SDK 到 Turkey solution 的演进。这样我们的产品就成为一个共创的连接器，通过部分开源和一些轻松 ECO 的接口，帮助市场上下游伙伴和中游伙伴快速覆盖市场。
