技术选型方案怎么写_小程序技术怎么选型？

小程序技术选型

我们来分析下小程序技术框架到底应该怎么选？

kbone & 小程序原生

• 已有web版，需要小程序版：kbone
• 跨平台需求(web + 小程序)：kbone
• 对性能特别苛刻 or 追求稳定 or 要用最新功能：小程序原生
• 页面节点数量特别多( 1000 节点以上)，且对渲染性能要求高：静态模板转义方案(第三方框架：mpvue/taro等)

第三方框架

• MpVue ：不推荐再用了，坑越来越多，内部也表示之后不会投入太多维护
• WePY 1.7.x ：不推荐再用了：1.7.x 的版本在最初的设计上的缺陷导致遗留了很多比较严重的问题
• WePY 2.0：现在还是 alpha 阶段，内外部有一些小程序在跑，体验和反馈还可以。但依然 issue 比较多。害怕踩坑的也不推荐使用
• Taro: 也还是有不少问题，但相对来说应该是比 mpVue 和 WePY 更稳定一点
• Uni-app：mpvue的衍生版，跨端 (官方示例有6端) 支持的很好，在H5端实现了一套微信模拟器，可以尝试，是目前唯一支持app端的商用方案，有独立的编辑器HBuildX
• Chameleon: 统一的多态协议，渐进式跨端，提供脚手架命令工具，规划比较宏大
• Omi ：基于Taro完成的框架，kbone有支持omi的模板
• Nanachi: 基于react的编译期间的转义框架

总结

没有跨端需求，只需要微信小程序 ==> 小程序原生

web端转小程序 or 两端 or 想要尝鲜 ==> kbone

多端 or Vue 技术栈 ==> uni-app

多端 or React 技术栈 ==> taro

不介意学习新技术栈 ==> wepy 2.0 or chaemeleon

写在最后

小程序在非常快速的更新迭代，就算是原生框架也还是有一些坑的，因此没有哪种框架是百分之百完美，需要根据业务具体需求以及自身技术栈偏好来进行选择。

吐槽下

小程序的定义是什么：小程序是一种新的开放能力，开发者可以快速地开发一个小程序。小程序可以在微信内被便捷地获取和传播，同时具有出色的使用体验。现在的需求都“变态”了，恨不得把小程序做出个原生APP来~~~