作为幕后的产品经理，我发现很多开发者或者业务部门的朋友，刚开始了解我们的时候，都很好奇我们想要解决什么问题。在上一篇文章《With：轻量级应用平台与前端开发框架》发布之后，我们得到了很多朋友的认可和支持。同时也收到了用户新的疑问，“跟 Ant 有什么区别？”

在本文中，我们将深入探讨和之间的区别，以及它们的优势和劣势。 是蚂蚁金服出品的移动应用程序开发平台，功能非常丰富，但还有其他更好的选择可以为移动应用程序提供小程序支持。

作为幕后的产品设计师，我的观点可能并不中立（我会尽量做到客观），你可以访问了解我们的产品和功能，以验证本文的观点。1. 是蚂蚁金服（支付宝）衍生的移动开发运营平台

官方网站

（全称as a）是一站式App开发、测试、运维云到端解决方案，可有效降低技术门槛、减少研发成本、提高开发效率，帮助企业快速构建稳定、高质量的移动应用。

通过整合阿里云上各项服务，如统一消息推送服务、移动数据分析、应用安全加固等，为开发者提供更加完善的移动研发平台，同时也方便开发者对已有应用进行改造。

小程序是支付宝小程序的精简版

支付宝小程序官方网站

小程序衍生自支付宝小程序框架，继承了支付宝小程序框架的易开发、跨平台、性能等特点，不仅可以帮助开发者为自己的应用推出小程序，还可以快速构建和打包小程序，覆盖支付宝、淘宝、钉钉等应用。

简单来说，小程序就是在支付宝小程序基础上精简、去依赖的小程序SDK，开发者可以编写一套小程序代码，在支付宝和自有APP上发布运行，甚至可以构建自己的小程序生态。

基于小程序，开发者可以快速优化发布包大小，节省流量和存储。同时服务迭代不再受版本发布的限制，可以快速发布迭代。事实上，基于统一的开发标准，小程序只需开发一次，即可快速部署到多个终端。

借助支付宝官方小程序IDE工具，开发者还可以完成小程序的设计和开发预览，小程序可以在阿里业务旗下各种场景和流量入口上线。

我不想掌控移动开发的所有流程，只想专注于小程序

与大而全的移动开发平台不同，我们从始至终关注的核心问题一直是“为企业和开发者提供良好的小程序体验，让任何人都能轻松让自己的APP拥有运行小程序的能力”。我们之所以相信小程序能打造数字化APP，主要基于以下几点原因：

如果要找到一个兼顾活跃度、体验度、开发效率、开放度的最佳选择，那么答案一定是小程序。

接下来我们把视角转移到小程序层面，看看有什么不同：

小程序 vs 小程序

在小程序层面，目前无法为开发者提供较为完善的产品功能，但在小程序上为用户提供了更为丰富的产品功能体验。无论是iOS应用、APP、应用、RN应用，甚至是APP，都可以在其中集成SDK并运行，无论是微信小程序，还是基于第三方框架设计的小程序。

此外，其在小程序的学习成本、小程序上下架及灰度发布的生命周期管理、集成小程序SDK后App的大小变化、小程序渲染架构模型等方面都具有明显的优势和特点。

我们在开放的小程序管理平台中也支持API，你可以根据实际需求将小程序全生命周期管理能力与现有的内部研发体系进行集成，实现更进一步的小程序管理效果。

同上，我们也尝试编译运行同一套小程序DEMO，看看有什么区别。由于和 合作过，我们分别测试了IDE中提供的“小程序示例模板”、“多终端开发模板（uni-app）”、“多终端开发模板（）”和“微信小程序基础模板”。

小程序示例模板

首先我们选择了中提供的小程序示例DEMO，对其进行编译，然后通过微信IDE和IDE编译小程序代码资源。从下图结果可以看出小程序只能在环境中编译运行，无法在微信和环境中运行。

所选的小程序官方示例DEMO无法在微信IDE中运行及IDE编译运行多端开发模板()

然后我们选择了 提供的多端开发模板 ()，进行编译，然后使用IDE自带的调试工具调出微信IDE进行编译。由于支持跨终端小程序输出，所以最终的小程序资源在微信IDE和IDE中都可以运行。

在使用模板之前，开发者需要确保当前系统中已经安装了节点服务，并在IDE左侧的依赖管理中安装好模板所需的所有依赖服务后，才能使用多端开发模板。

该模板可以编写出可以在微信IDE和IDE中运行的小程序多端开发模板（uni-app）

然后我们选择了 IDE 中提供的多终端开发模板（uni-app），并进行编译，然后使用 IDE 自带的调试工具调出微信 IDE 进行编译。由于 uni-app 支持跨终端小程序输出，所以最终的小程序资源在微信 IDE 和 IDE 中都可以运行。

在使用uni-app模板之前，开发者需要确保当前系统中已经安装了node服务，并在IDE左侧的依赖管理中安装好uni-app模板所需要的所有依赖服务后，才能使用多端开发模板。

uni-app模板可以编写出可以在微信IDE和IDE中运行的小程序微信小程序基础模板

接下来我们尝试运行一个原生的微信小程序，看看它是否可以在FIDE或uni-app中运行。

微信原生小程序可以在 中编译运行，但无法在 IDE 中编译运行

测试的结论和我们在《并且：轻应用平台与前端开发框架》一文中得出的理念基本一致：uni-app只能重新编译使用uni-app语法原生开发的小程序，无法编译使用微信原生wxml语法的小程序。

概括

也就是说，除非小程序本身是基于uni-app设计的，否则还是无法将小程序基于设计移植到移动端APP上，如果想将小程序集成到现有的APP中，也无法兼容现有的微信小程序。

编译完成后，小程序可以调试输出为微信格式的小程序，也可以在IDE中编译预览，这再次说明了支持微信小程序语法的优势。3. 定价及收费模式——主要按流量使用量收费

定价策略

其中集成了阿里云的很多功能（比如统一推送服务、移动应用安全加固等），所以需要将所有功能解耦，并提供免费的使用额度。一方面可以最大程度减少对用户已购买的第三方服务的影响，另一方面也可以为用户提供一次体验服务的机会。

定价页面也对小程序的收费模式做了说明：“作为动态技术方案，容器是免费的，转化后的离线包和小程序包调用发布服务实现实时发布更新，这涉及到‘发布服务更新接口调用次数’和‘下载流量费’。”也就是说，只要将小程序发布到用户端，或者用户打开小程序获取，都会消耗相应的接口调用次数。”

以“消息推送服务”为例，“极光推送”免费版提供每日200万条推送额度，“百度回推”免费版提供每秒30万条推送额度，“腾讯信格”根据应用月活跃度制定了更灵活的定价策略，但不限制推送次数，目前每月仅提供1万条免费推送（有点高）。——定价主要基于使用次数

定价策略

相比较而言，的收费方式以免费使用小程序SDK为主，并按功能数量收费为辅（如小程序数量、关联应用数量、并发用户数量、灰度发布数量等）。同时还提供了社区版本供开发者免费使用，方便开发者或小微企业在自有环境中免费使用，尝试App数字化转型。

针对大型企业和客户，我们还将根据具体需要定制或实施任务，提供更加合理、周到的收费策略。

4. 根本的区别是什么？

以上我们对两款产品进行了初步的对比，各位读者应该感觉到两款产品还是存在一定的区别的。

作为移动应用开发平台，其更注重提升移动应用开发效率，通过客户端开发框架、移动发布服务、移动网关服务、研发协作平台等子模块，为用户提供一站式移动应用开发解决方案，第三方服务的聚合与对接，配合按量付费的定价体系，也能降低开发者的前期投入。

如果开发者想为现有的移动应用程序寻找一种新的、经过验证的开发模式，我想这一定是最好的选择。

但如果仅从降低开发成本、优化用户体验、为应用添加热更新能力等角度考虑，通过小程序完成移动应用转型或许是一个门槛较低的选择。

提供的小程序能力受限于产品定位，需要借助第三方服务实现，无法对微信wxml小程序提供丰富的支持。

在项目启动之初，我们从未想过（也不可能）解决移动开发过程中的所有问题。我们相信市场上已经有足够充足的第三方技术服务和架构来解决移动应用开发过程中绝大部分困难和复杂的问题，开发者也可以根据自己的实际业务场景和需求，灵活选择所需的服务。

因此，我们也把所有的研发精力都集中在“让我们自己的应用中的小程序能够像微信小程序一样流畅运行”这个问题上。支持不同平台的小程序SDK、对接微信小程序API和组件功能、保持高稳定性和安全性也成为了日常研发工作的重中之重。

目前已有基于iOS、、、RN、平台的小程序容器SDK上线，且该SDK已于2021年10月通过中国信息通信研究院SDK专项测评，获得认证证书。

考虑到小程序分发流量的实际占比，在各大厂商设计的小程序特有语法中，开发者还需要优先支持微信的wxml小程序语法（如下图所示）。

艾瑞咨询指出，微信小程序渗透率超90%。5. 结论

移动开发的最终目标一定是更加开放、更加快速、更加稳定。

我们确实通过蚂蚁集团内部的业务实践积累了足够的业务经验，并将这部分经验抽象和解耦，试图为开发者提供清晰、合理、贴近实际业务场景和开发的移动应用架构实践。我相信这也是开发者选择和信任我们的原因之一。

它更加注重小程序本身，不仅提供了跨客户端、跨系统的小程序运行沙箱，方便客户在自己的应用中运行已有的小程序，还拥有完善的开发者中心，帮助开发者管理和控制小程序的整个生命周期。

我们有一个更明确的目标：通过小程序减少企业数字化转型过程中的障碍。

随着业务的发展，现有的Web应用和H5应用都会面临提升用户体验和业务性能的需求。在切换到通过小程序提供服务的过程中，提供的小程序解决方案不仅可以解决企业目前面临的“小程序迁移”问题，还可以利用小程序全生命周期管理能力帮助打通企业内部信息系统，再加上具有自动化和定制化支持的相关工具和资源，可以更可靠、更放心地帮助企业完成数字化转型过程。

我们还有一份更加情感化的理解：我们相信一线产研人员的原创创造力。

在小程序诞生之前甚至更早的时代，研发人员通过对技术的追求，在研发工作中展现出了惊人的创造力，也正是这种完成工作、做好工作的驱动力，催生了更多新颖、高效的框架和工具的出现。

相信并采纳大公司成熟的技术方案和建议当然是选项之一，但资源的天然倾斜，产研成本的天然不平衡，总是让我们谨慎。这也是促使我们发展的核心原因。我们和你一样，都是经验丰富的一线开发者，我们更关心你遇到的问题，想让小程序更直接、更全面地解决你所有的问题。

我们希望通过小程序容器技术，帮助更多开发者打造性能优越、体验良好的应用。