vux-hybrid 探索

[airyland]

目前仅仅是想法和探索。

平台

暂时考虑 iPhone，因为 webview 性能已经完全可以接受。

为什么不考虑 weex

因为在性能可以接受的情况下，需要更多开箱即用的原生功能，比如我想能直接调用相机，集成支付。而 weex 目前可以说是一个性能比较高的 web 容器，但是扩展使用原生功能对于 web 开发者十分不方便。

哪个原生封装工具？

cordova 或者 apicloud ？

cordova 很多插件功能是社区贡献，质量参差不齐。

国内的 apicloud 相对封闭，但是功能齐全，相比 dcloud 这个 n 久不见动静的产品，至少是迭代快速。

如何做

通过一个预处理工具来转换路由逻辑、转换依赖于路由的 vuex 状态、用 vuex 维持不同 window 间的通讯数据、转换 vue-router 的路由切换为窗口切换、注入原生事件和原生接口。

等简陋的构建工具开发完，提供一个测试包大家测试一下。后面再继续考虑是否靠谱。

[abell123456]

只考虑IOS平台？

[airyland]

@abell123456 暂时是。

[iflamed]

说一下我的建议吧

1. 选择cordova 吧，ionic 好像也有考虑vue化的可能性，相比之下联系apicloud不如去联系ionic ，也许还能换个工作呢～～；
2. 可以参考一下framework-vue；
3. router 的问题，不再建议使用vue-router. 因为vue-router 会卸载dom 树，使用的时候切换明显闪屏效果;
4. 可以参考手办酱APP，早期我们用过vux的。底层我们选择的是cordova；
5. 希望vux 能够做成ionic 之类的平台。（这一点上可以交流一下）

[airyland]

@iflamed 在web中使用 vue-router 但是在app中其实我想在打包时分割为不同页面。会直接替换掉vue-router的代码，但是保留路由信息，即当前页面的路径信息。

[iflamed]

@airyland 实际应用中，应该还是SPA 比较多吧。SPA 配合HMR 开发调试也会方便很多的。Framework-vue 有一个很好的体验，类似iOS的侧滑返回。要实现这个就需要自己基于路由组件切换机制。

其实更多参考ionic就好，ionic 很多页面效果是基于iOS 原生的，vux 基于weui 感觉也会很好的。

[WalterZou]

@iflamed 目前我们的产品中是原生+WebApp，WebApp是基于vue+vue-router+vuex的，但是正如你所说切换时闪屏，以及生命周期状态管理（比如：在同一个组件中切换不同数据，返回后的状态保持）比较难做。目前也看了framework7-vue，但是打包后JS好大，也放弃了...

[iflamed]

@WalterZou 那点js 对于app 来说还是不大的。对于webapp 来说感觉也不会打多少的。

[lsvih]

其实dcloud的jsBridge基本可以满足“开箱即用”的理念，实际应用起来流畅度也还不错。 他们的产品也并不是半天没有动静，H5+SDK更新的还比较勤快。半天没有动静的是他们的mui框架，抛开不用即可。

[airyland]

@lsvih 官网看起来就是工程师风格并且 n 久没更新。这可能说明了一些问题。个人看法。

另外就是这篇他们的这个帖子：

[yuanxj1024]

个人也建议cordova，之前也是用过ionic ，参考一下ionic应该会少很多坑，感觉将来对支持android会好一些，同时支持楼主

[murmurwoodz]

@iflamed 3这个问题不难解决，把router的变换动画改一下，改为先进后出，然后略微调整一下叠放顺序，让新view永远在上面，这样旧view unmount的时候就完全被盖住了 我们已经这样做了 我遇到的一个问题是打包后的路径问题。。所有的资源都被打成绝对路径了。。pc端开发还好，上了cordova就挂了，我最后是写了个脚本批量改成相对路径

[iflamed]

@murmurwoodz，unmount 之后就没有了iOS侧滑返回的效果。侧滑的时候正常背景层应该显示出来的。不过你router的先进后出策略不错，是vue-router的可选项吗？先进后出+过度效果感觉非APP用起来也很好

发自 刘兵 的 iPhone

On 5 Mar 2017, at 1:24 PM, murmurwoodz notifications@github.com wrote:

@iflamed 3这个问题不难解决，把router的变换动画改一下，改为先进后出，然后略微调整一下叠放顺序，让新view永远在上面，这样旧view unmount的时候就完全被盖住了 我们已经这样做了 我遇到的一个问题是打包后的路径问题。。所有的资源都被打成绝对路径了。。pc端开发还好，上了cordova就挂了，我最后是写了个脚本批量改成相对路径

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[xiaohui-zhangxh]

@murmurwoodz 如果你是用vue webpack生成的项目，像这样修改https://github.com/xiaohui-zhangxh/vue-webpack-cordova/blob/master/template/build/utils.js#L10 就会把所有资源放在同一个目录，然后把assetsPublicPath 改为空问题就解决了 https://github.com/xiaohui-zhangxh/vue-webpack-cordova/blob/master/template/config/index.js#L10

[xiaohui-zhangxh]

我也很期待vux hybrid的最佳实践，我们公司现在一个外包项目就打算用vue+cordova做，还不知道结局如何，有些担心。

[wxs77577]

我觉得能实现用单文件的vue直接对应编译到不同的html就够了，至少不用现在这样每个window和frame都写一个html，强迫症求治疗。大神可否指点一二 @airyland

[hukuiabc]

支持cordova

[lymanlai]

在1年前就是用cordova+vux开发了一版app，类似微信聊天的功能+链接蓝牙硬件功能。只是公司看不懂这些，最终只能放那边了。

[cinos1]

如果可能的话，做一些weex适配，这样可能方案是最完美的，在性能和展示以及开发效率上达到了一个完美的平衡，只是目前weex的css兼容上有大量的不支持，恐怕现有很多样式都需要按照flex规范重写了

[airyland]

@cinos1 没有适配 weex 的计划，这个工作量之大和适配小程序一样，花精力还看不出有什么好处，个人公司项目也并没有用到 weex。

[cinos1]

@airyland 确实如此，weex和rn一样，都是把js作为脚本，类似lua在游戏开发中的脚本的作用，最后全要转义成原生代码来执行，已经脱离了web容器的概念。阿里官方推荐是把它作为原生中的一部分，用于解决热更新问题。现阶段直接用js做跨平台开发，最简单易行的方案还是cordova，目前微软对它的支持力度还不错，更新频率也可。也许1-2年后，阿里的weex可以把css转义部分的编译工作都完成，这样就无需再进行适配了。也可能1-2年之后随着手机硬件更新换代，性能问题就没那么突出了。再加上vue的ssr技术的引入，现阶段单页模式下首页打开的效率问题也基本解决掉了。

[grojef]

keep-alive 也会闪屏吗？没测试过，纯问！

[iflamed]

Dom 被卸载，然后在挂载回来，时间超过多少就会闪屏

发自 刘兵 的 iPhone

On 11 Jul 2017, at 10:46 AM, supatato notifications@github.com wrote:

keep-alive 也会闪屏吗？没测试过，纯问！

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[dmlzj]

期待vux+weex的联姻,weex是个趋势啊，毕竟性能更高。 @airyland

[murmurwoodz]

写两笔 遇到的一些问题 v2.3.3： (1)转场动画不符合要求，客户喜欢滑出和滑入同时进行，但是在老版本ios或者android上，因为vue动画的设计，有明显的in-out阶段分界，解决办法就是只用in，然后爆改vue的动画部分，当加入in-active的时候，通过选择器给老路由加一个属性触发out的部分，做到in-out同时进行的效果 (2)没有保存滚动条位置，scroller在转场时有个析构动作，会导致scroller的位置被置于0点，这个只能在unmount的时候先记录scoller的位置，然后把位置转换为外层div的padding，稍微可以减少下跳动感 (3)ios和android两套样式，图标字体太坑了，一个手机一个对齐，我把一部分图标字体改成了图片，对齐稍微好处理点 (4)很多区域加大了一倍的尺寸，方便用户点击 (5)客户端要求自体可调，这就尴尬了，只能狂改css，搞出很多rem出来

另外，发现国产手机的android浏览器调教的比ios safari舒服多了，safari才是真坑，只要放弃android 4.4- 混合应用也是可以的 这里说的不是安卓版本问题，是如果现在还不升4.4的手机，基本已经可以扔垃圾桶了

[x007xyz]

整理下使用vue构建app的思路吧：

1. spa，直接使用vue-cli生成文件，嵌入app中，使用到原生的地方就使用封装工具提供的方法。
2. 将路由替换为原生的webview，页面内容依旧是html。
3. 类似于weex、RN直接编译为原生app。

第一种方法，要求最简单，基本会vue就可以搞定一个app，难度大多在封装工具方法的调用上。性能上可能比较差。 第二种方法，如果实现了路由的编译转换，性能相对于方法一能得到很大提升，同时编写者无需做多余的修改。这个编译转换有两种方式，一种是直接转换为原生，另一种是转换为封装工具的方法（dcloud，apicloud都有提供创建原生页面的方法，cordova没有使用过）。方式一，成本较高，方式二，依赖封装工具。 第三种方法，最终结果是完全原生，性能最优，但是编写代码要完全遵循其规范，vux要实现的话其实就是按其要求修改代码。

[airyland]

@x007xyz 在尝试实现的是第2种。

[Evansy]

写一笔自己使用过的个人感受. 使用过decloud，decloud的更新确实是蛮频繁的其实。而且官方的支持也还好，论坛和官方群响应还是蛮快的。 公司有个APP我是通过decloud的h5+runtime、mui、 vue来写的, decloud提倡的就是一个页面一个webview,页面之间跳转就是webview跳转，vue是通过js引入的方式使用的，它里面如果对页面进行预加载的话，web跳转确实是非常快，无白屏，体验真的很好，但是写到后面，页面越来越多的时候，预加载的webview越来越多了，就开始卡顿了，这个时候，就部分页面采用预加载，其他采用正常打开销毁，这里就和浏览器新开tab差不多了。。。、 后来进行了一个重构，采用spa、h5+runtime，mint-ui （大部分组件自己写，时间插件这种有点麻烦就用它的了），因为使用原生到的api, h5+runtime里都封装好了，真实使用其实也不是很多，无非调用相册，拍照，网络状态检测，推送啥的。这里吐槽一下，decloud的mui确实很不好用。性能比原来确实好了很多，反应快了，体积也小了很多，原来打包成app后有7-8m,切换vue单页3-4m一个app，做个过渡动画的话，其实切换还好。

[RoseEnd]

期待weex

[kitkimwong]

@airyland How about Quassar Framework? Maybe it is a good reference for your develop.... http://quasar-framework.org/