ForChange客服小弟

> 当你把B页面的seesionStorage的值改变了，你会发现A页面的sessionStorage的值没有改变 这个确实也是很蛋疼，新开窗口实际上只是继承了，并不是共享

any update？

我和楼主一样差不多14年先接触Vue，然后一直到现在，期间也经历了非常相似的事情。 不过我现在相当于是第三个阶段的选择期 第二个阶段选择期就是[email protected]和React相比，Vue确实不太好维护，各种黑盒处理，导致了其他很多不好的影响。 然后也是同样的学习了React然后使用过Taro，但内心还是更喜欢Vue，而不是React。因为我的优先顺序是利用UI框架 + 加上自己的设计思路 = 一个成熟的解决方案 而UI框架上，如果使用React，那前期的路确实很长，而且强迫症我会想要真正熟练使用，那就真的时间不够。 讲到这里，我的建议就是开始的时候还是学习React好，因为你的目标是实现一个成熟的方案去服务业务，而不是仅仅提高了自己的开发舒适度和速度 -------- 经历第二个阶段确实非常迷茫，因为那时候已经看到头了，就是以后肯定要换成React，但是现在实在没有时间。 特别其中一点也是文中说的关于维护，团队开发最麻烦的就是你不一定能看懂别人到底在写什么？特别是在使用Vue的过程，各种Mixin，this啥的，你根本不知道这些是啥，会有什么影响，能不能改。就算是自己写得，以后回过头可能都忘记这是什么了？ ---- 而另外一个原因就是跨端开发，也是开始接触小程序的时候，mpVue也好uni-APP也好这种野路子团队做出来的东西，能跑起来已经万幸了，更别说加了更多的黑盒处理...而市面上也没有更好的方案。 所以那时候我决定web端和小程序端分离，小程序端单独写构建，然后参考Taro加入了JSX的支持。当然TypeScript肯定少不了。 这样在小程序端确确实实实现了和Vue一样的开发舒适和项目管理。 但面临的坑更多了，特别是JSX要实现编译成小程序的代码，不仅限制多还容易出问题。而且还不能进一步优化。 而且这始终不是个好办法... 只是临时补救一下，当然并不只是Vue这样，[email protected]的版本也一样，只是社区比较活跃而已。 直到运行时编译的方案被用到了小程序上，就是kbone和[email protected]的方案。这个方案用上以后，解决一个大问题就是小程序端+web端真跨端开发。再也没有什么限制，也不要求一定要Vue或者React。 然后看到这，实际上问题就剩下一个那就是Vue本身的问题，黑盒太多的问题。 然后奇迹又发生了... [email protected]版本发布了 我的天，[email protected]的特性直接解决了剩下的所有问题。我们团队用了半年了，目前来说没有任何问题，开发速度快，代码review可行，写得代码可维护也清晰可以说没有任何管理上的问题。所以再大的项目都能处理。而且写起来还是很快，但这次的快没有任何黑盒的代价。而且从设计模式上，实现起来很快 在这个阶段，[email protected]可以说确确实实做得非常好，而且已经没有什么之前说的问题了。 所以我们讨论的是 [email protected] + 运行时编译跨端方案...

前端价值很难证明，也很难有机会证明。建议有理想目标的同学转后端

> @xmsz 提供多些信息吧，哪些场景下，手机型号，最好有 demo。 小程序：京喜 手机型号：z5x 华为p20 华为p30 三星S20 表现： - 页面渲染需要一定时间，大部分页面开始会有一小段白屏 - 长列表滚动并不是很流畅 - 用不久手机会出现略微发烫 - 切换页面会有些许卡顿 - 大概体验感受就是不够流畅，总觉得卡卡的，反应也比较慢 再iOS上肯定没问题 所以大概率还是跟动态渲染有关，安卓机子支撑不起 有时间我会录屏 有没有其他大一点应用是采用3.0的，我们也想测试一下。

> 他们使用的是 2.0，而且也不一定接近你的场景，所以还是说你在什么场景遇到什么问题，而且没有 demo，也没法帮助你。 居然是2.0 2.0都有这么卡 感觉3.0更难说。我们有项目从2.x版本升到3.x版本。明显吃力太多，毕竟运行时操作变多 我们现在遇到的场景和电商应用很像，就是一些产品 功能模块很多； 而单个页面上，首页上的功能多到不行。这种就导致一个页面上有很多『动态』的东西，包括定时器，用户触发等一些系列会造成视图渲染的操作 这个时候，安卓的用户就惨了，因为安卓传输到视图的操作无论耗时还是性能损耗都很大，所以卡炸掉

> 复杂页面（比如电商类型的首页），完全采用taro，微信小程序上在中低端机型上的性能确实是不行的（在支付宝小程序上会好很多）。我们目前的方案，除了常规优化，主要是两点： > 1）把一些模块用原生写（比如不满足虚拟列表应用条件的长列表的列表项组件）。 > 2）对于白屏，我们给每个页面注入了loading的预渲染（类似H5的懒加载路由过渡loading）。 > 经过这些优化后，整体性能有巨大提升，重渲染时长降低了1.5倍以上，在低端机效果尤为明显。 > 个人觉得，对于复杂页面，不使用混写的前提下尽量保证性能，需要思考怎么将懒加载和虚拟化应用到一些复杂场景，比如，各模块（不一定是列表）高度不定的场景能否适用虚拟化技术。 > 如果有什么好的思路，也希望能在这里交流下。 嗯 我们暂时用的也是这个方案，虚拟列表 + loading。能解决掉长列表页面的例如粉丝列表页的性能问题。 但确实只能是暂时的方案，而且也是一样基础能优化的都优化了 所以来问问有没有从框架本身或者其他优化的方案

不好意思 周末回复晚了 1、这是我的store文件 ``` export default { data: { user_info: {}, user_coin: function() { return this["user_info"]["coin"] || 0; } }, globalData: [ "user_info", "user_coin", ], /** * @name 打开授权弹层 */...

any update?

还有运行`npm run start` 会卡住 ``` ● Web █████████████████████████ building (28%) 1/3 entries 58/76 dependencies 21/40 modules 15 active babel-loader › rax-platform-loader › node_modules/html-entities/lib/named-references.js (node:6671) [DEP_WEBPACK_DEV_SERVER_ON_BEFORE_SETUP_MIDDLEWARE] DeprecationWarning: 'onBeforeSetupMiddleware' option is deprecated....