Kbone原理详解与小程序技术选型( 二 ) _Kbone原理详解

支持多个前端框架：Vue、React、Preact 等

支持更为完整的前端框架特性：Vue 中的 v-html 指令、Vue-router 插件等

提供了常用的 dom/bom 接口

可以使用小程序本身的特性：live-player 内置组件、分包功能等

提供一些 Dom 扩展接口：getComputedStyle 接口等

Kbone实践脚手架kbone-cli官方已经提供了kbone-cli可以用来快速开发：
用npm全局安装kbone-cli

文章插图

可以根据自己的技术栈选择不同的开发模板：React/Vue/Omi/Preact

文章插图

然后就可以愉快的进行开发啦~

文章插图

生成的demo项目结构如下：

文章插图

demo中包含了多页跳转、vue-router、vuex等的使用示例，以及mp-webpack-plugin的配置示例。
对于多页面的应用，在 Web 端可以直接通过 a 标签或者 location 对象进行跳转，但是在小程序中则行不通。同时 Web 端的页面 url 实现和小程序页面路由也是完全不一样的。
Demo实例对比

文章插图

其中，有一部分两端差异的业务逻辑功能，也给出了3种不同的解决方案：
利用vue-improve-loader，在构建时对dom树节点进行删减，在需要提出的节点加上check-reduce属性利用reduce-loader，将业务中不需要被打包的代码进行去除，使用行内loader和环境变量来判断使用样式隐藏，即设置不需要显示的节点样式为 display:none
其他问题在实际开发中，还会碰到一些细节，例如：

多页面开发：修改webpack和mp-webpack-plugin配置
小程序内置组件：部分用html标签代替，其他用wx-component + behavior标签
小程序自定义组件：修改mp-webpack-plugin配置，补充wxCustomComponents字段，将自定义组件放入组件根目录，使用自定义组件
自定义app.js和app.wxss：监听app的生命周期，修改webpack配置补充app.js的构建入口，修改插件配置的generate.app字段，补充app.js
扩展dom/bom对象和API：使用 window.$$extend追加方法
代码优化：用reduce-loader做体积精简，dom树精简用vue-improve-loader
区分环境实现不同功能：process.env.isMiniprogram

更新迭代kbone由于目前在快速发展期，更新迭代非常迅速，以下特性是对比了8月份的版本和11月份版本，可以看出已经解决了近2/3的问题。

文章插图

小程序技术选型详细了解了kbone之后，我们来分析下小程序技术框架到底应该怎么选？
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
写在最后小程序在非常快速的更新迭代，就算是原生框架也还是有一些坑的，因此没有哪种框架是百分之百完美，需要根据业务具体需求以及自身技术栈偏好来进行选择。