|
|
|
本帖最后由 司徒正美 于 2019-6-20 10:58 编辑
nanachi（娜娜奇）是市场上唯一支持快应用的小程序转译框架。
众所周知，国内安卓手机的装机量是非常庞大，拥有十亿之众，基本上每部安卓手机都支持快应用，这么大的流量不利用起来就浪费了。然后，由于快应用的语法与其他小程序差异太大了，许多转译框架都没有支持快应用的转译。因此nanachi的出现是各大小开发者的福音。
在开发小程序与快应用的技术选型中，通常有三种选项。
一、是基于原生开发，这意味无法跨平台。每种小程序都有自己的语法与特殊的API，需要多个团队来维护多套代码，小公司是holdH5不住。
二、是基于H5开发，与APP的hybird开发一样，以webview加载H5页面，可以大大降低学习成本，我们只需要针对不同的平台做一些分支处理就行了。但是webview通常有许多功能限制，需要跳到原生页面执行操作，然后再回到webview。因此用户体验不太好。更要命的是，许多平台还是强烈希望推广自己的标准（毕竟招入大量人力物力开发了这套东西），不允许个人开发者使用webview。
三、就是使用转译框架，时下流行的转译框架有wepy, taro, mpvue，nanachi，都是一些大公司才能开发维护。
快应用主要问题有4个：
1，样式是基于纯flexbox布局，不能使用绝对定位与浮动（这是缺点也是优点吧，缺点让我们前端许多经验不能复用，优点是纯flexbox布局渲染性能超高，并且更易用原生实现，快应用本身就是一种原生APP）；
2，标签存在严格的套嵌关系，比较致命的是y文本一定要放在a, span, text, option这4种标签内，否则抛错，你也不能text里面放text, span里面放span，让许多H5的编写套路都不能直接搬过来；
3，接口与微信小程序完全不一样，需要费很大力气来兼容；
4，功能严重不足，像微信小程序，只要在JSON中配置一下，就能实现titleBar, tabBar, 分享转发，滚动等功能，在快应用中，需要自己一一实现。由于上面这4点，吓走许多潜用开发者，导致了社区不够活跃。
图1中的蓝色线框，黄色线框，绿色线框都需要我们自己实现。
图1
我们公司在流量日益枯竭的今日，抓住了小程序/快应用的风口，在评估了几个开源框架之后，决定自己开发一套转译框架，实现对微信，QQ，头条，百度，支付宝，快应用与H5的全面支持。图2是我们框架的demo展示
图2
大家只要安装了 nanachi，输入几行命令就能看到这画面了。``shell
npm install nanachi-cli -g
nanachi init aaa # aaa为项目名
cd aaa && npm i
nanachi watch:wx # wx代表微信，ali代表支付宝， bu代表百度，quick代表快应用，tt代表今日头条，h5代表H5，qq代表QQ
``` 图3
如果觉得不够真实，可以体验一下我们公司的APP。目前我们公司的百度，支付宝，QQ，快应用都是用同一套代码。参看图4， 图5
图4
图5
我们公司业务众多，拥有几百个页面，使用了最新的分包技术才能将它们塞到4M的包中。
再说一下我们如何兼容快应用吧。
nanachi是以react方式编写业务代码的，JSX会抽取成ux文件的template部分，里面一些不支持的标签，我们偷偷替换成React组件（我们称之为补丁组件，https://qunarcorp.github.io/schnee-ui/index.html）。
由于快应用的页面没有titleBar, tabBar, 分享菜单，因此我们为每一个页面包裹了一个PagerWrapper组件（其标签名为anu-pager-wrapper），通过它被与相应的功能。这些是在转译时完成，用户不需要自己添加。
图6
快应用众多的API，是我们辛苦集成到ReactQuick.js中，以微信小程序的调用方式重写。图7是ReactQuick的源码。
图7
在开发过程中，我们也得小米快应用官方的支持。正是他们的配合，我们才得以顺利兼容某些微信小程序的特殊功能。
当然，现阶段快应用也有一些无法用nanachi直接抹平的问题，我们在nanachi官网上也给出解决方案了，如：
* 快应用的scroll-view兼容
* 快应用的同步Storage API兼容
* 快应用与小程序盒子模型的区别
* 快应用获取页面参数
* 快应用与小程序转发分享
* 快应用onblur
* 场景值的兼容
* movable-area与movable-view的模拟
|
|
