过去三年里，我的全部精力都用在了小程序研发上面，先后完成了大概20多个小程序，目前最大规模的有两个电商类的小程序，都有很大规模的研发团队在协作开发。 我们做的很多前端项目主要还是在 性能，质量，效率三者上做一定的协调。如果有多端同构的诉求我们更希望有一个开发框架来屏蔽容器上的一些差异。 首先针对性能，这里的性能好坏并不是狭义上的一些性能指标数据，而是一种类似体感的指标。比如一个基于raf的方案去计算FPS就算指标上没问题，但是实际用户使用的时候还是会卡顿，这和小程序双进程架构有关；比如FMP的指标是和用户感觉上的首屏是不一样的，我们使用了类似LVC的指标。通过一系列的指标约束，我们可以对很多方案做和横向的对齐，实际实践了三种不同的方案，原生小程序的就不谈，还有类似taro的编译时方案，类似remax的运行时方案。 在这个过程中很明显就能感受到 性能P，质量Q，效率E 三者基本上如同 CAP理论一样不能同时都满足。

前两年主要精力都在交付效率上，业务毕竟是一个探索期的业务，团队规模也不是很大，但是要尝试的东西很多，所以希望有一套移动端架构方案可以跨端来支撑整个业务发展，这个过程中，我们摸索出了类似现在remax的一套方案，跨端设计上和taro比较接近，但是整体实现方案和remax很像，都是使用了 react-reconciler 实现了一个小程序端的渲染器。所以基本上支持所有react的能力，不受限。同时又很好的能支持H5。这个就是我们第一代的跨端框架雏形，很好的解决了我们交付效率的问题，但是业务变化开始主打下沉的市场，这时候遇到了很大的问题，下沉市场的手机非常非常差，网络情况也不好，导致很多在中高端手机上能接受的体验完全被击穿。在系统层面又降回到了ios9和android4，这导致很多高级的能力不可用，同时小程序包体积的限制polyfill也不可用，同时低版本的系统限制了小程序基础库版本，我们要兼容到2.0.0，基本上就限制住了一些高级框架能力。

大规模协作还会带来高频冲突的问题，如果没有合适的方式来隔离每个人的更改，按照小程序原生的 index.js、index.wxml、index.wxss 这种模式就很难很好的做好。

Written by xi ming You should follow him on Github