过去三年里，我的主要精力都放在小程序研发上，先后完成大概20多个小程序。其中规模最大的两个是电商类小程序，都有较大的研发团队协作开发。
前端项目通常需要在性能、质量和效率之间取舍。有多端同构诉求时，团队会希望由开发框架处理容器差异。
性能不能只看单个指标。基于 raf 计算 FPS 的方案即使指标正常，用户实际使用时仍可能感到卡顿，这与小程序的双进程架构有关。FMP 指标也不完全等同于用户感受到的首屏，我们使用了类似 LVC 的指标。指标约束可以让不同方案有横向比较的基础。我们实践过三类方案：原生小程序、类似 taro 的编译时方案，以及类似 remax 的运行时方案。性能P、质量Q、效率E无法同时满足所有要求，选择方案时需要明确优先级。
前两年团队主要关注交付效率。业务处于探索期，团队规模不大，但需要尝试的方向很多，因此希望用一套移动端架构跨端支撑业务发展。我们实现过一套接近当前 remax 的方案：跨端设计与 taro 接近，实现方式与 remax 类似，使用 react-reconciler 实现小程序端渲染器。它支持 React 的能力，也能支持H5。这是第一代跨端框架的雏形，解决了部分交付效率问题。
业务后来开始面向下沉市场。目标设备性能较低、网络条件较差，中高端手机上可以接受的体验无法直接适用。系统版本需要兼容到 ios9 和 android4，部分高级能力无法使用；小程序包体积限制也使 polyfill 无法使用。低版本系统还限制了小程序基础库版本，需要兼容到2.0.0，这进一步限制了可用的框架能力。
大规模协作还会增加高频冲突。如果缺少隔离各自修改的方式，按小程序原生的 index.js、index.wxml、index.wxss 模式开发，很难处理多人同时修改同一页面的问题。
