用 Westore 构建原生微信小程序(一)

前言

一说 Westore，可能大部分人都是一脸懵，或者以为是那个卖微信周边的旗舰店。

当然这里要说的不是它，而是同样由腾讯推出的一套开源小程序架构

Westore-GitHub.jpg

如图所示，项目托管在 GitHub 上，没有发行版也没有官网，最近一次提交已经是5个月前(截止到今天)，属于是佛系维护了。

为什么不用 Uniapp/Taro?

相比于 Westore，Uniapp 和 Taro 确实要出名得多，作为行业最具代表性的跨平台开发框架，融入 Vue 和 React 这两个社区最热门的 JS 框架，可以让前端工程师省去大量学习成本，用一套技术开发全平台应用，真香！

事实也的确如此，绝大部分前端开发需求都可以用这两个框架来解决，除了一种需求：对性能要求十分苛刻的小程序

起因

刚接触小程序开发的时候，我并没有考虑太多性能问题，心想着：反正是微信客户端内部的小玩意儿，又处在行业风口，肯定有大厂团队做性能优化，我只管调库就完了。于是选了 React 阵营的 Taro (为什么不选 Uniapp ? 因为不太喜欢绿色...) 开始 coding，花了几周把最复杂的蓝牙功能做好，用自己的手机测试了几遍，OK没问题、上线、交差。

可把我厉害坏了.jpeg

过了几天自信满满的打开微信后台，用户反馈里一长串『功能异常』连珠炮，啪啪打脸。反馈的内容大多是白屏、卡顿，明明自己测试的时候都正常，怎么会...唯一不同的条件就是手机了，赶紧打开机型分布图

安卓机型分布.png

好家伙，安卓阵营里一大半都是黑户，剩下的也几乎都是中低端机型。

这么一分析，蓝牙功能为了展示实时的数据变化，需要近乎毫秒级的响应以及大量的 setData() 调用，在这些机器上运行，必然会“超载”。

Westore 登场

好在腾讯团队也一直在尝试解决这方面的问题，Westore 就是解决方案之一

Westore-架构.png

官方的架构图非常简洁，在原本的小程序架构基础上，将 View 挂载到 Store 上，由 Store 负责更新 View，同时让 Model 与 Store通过回调方式保持通讯，Model 执行真正的业务，在需要的时候通知 Store 更新 View，Store 就成了 View 和 Model 中间的“桥梁”。

这么解释仍然有些抽象，下一期我将从零开始，基于 Westore 开发一个兑奖小程序，并深入其源码，探索底层原理，一次性彻底搞明白。