# Uniapp 渐进式迁移
# 背景
随着我们的小程序用户基数的增长和业务复杂度的提升，发现当前的小程序框架在性能、开发效率和维护成本等方面开始出现一些挑战。为了提供更好的用户体验和提高开发团队的效率，就考虑迁移回原生小程序，通过编译输出不同端的产物。迁移回原生小程序需要重写全部代码，目前没有这么多资源一下子投入，迁移策略偏向渐进式，可以逐步替换重构的部分。这样核心问题就变成多个技术栈和版本如何共存并行，新旧的代码要都能正常工作。
目前社区上没有uniapp的迁移方案，要支持这种渐进式的过度的可行性需要一步步摸索,不是所有问题都可以预知以及如果遇到多端底层无法兼容的问题，本次重构迁移就要作废。
# 具体的问题
- 性能问题
- 它的性能可能仍然无法与完全用原生代码开发的应用相匹配
- 现在小程序功能越来越复杂，同样另一个用原生开发的小程序，完全没有性能优化的苦恼以及包体积的的苦恼，目前主包体积已经到了1.8M，无法再加任何需求了
- 对于H5平台，UniApp的runtime体积约为220KB
- 对于微信小程序，UniApp的runtime体积约为190KB
- 它的性能可能仍然无法与完全用原生代码开发的应用相匹配
- 平台限制
- 可以跨平台，但其实还是要针对平台处理
- 扩展性不足（平台特有的功能无法完全发挥）
- 分包异步化
- 处理import(),替换__webpack_require__.e成require.async
- commonplaceholder
- 以及其他平台特性配置无法及时跟上，就需要一直写插件支持，目前已经写了11个插件了
- 更新迭代受限制
- 如果一个平台推出了新的API或功能，uni-app可能需要一段时间来支持这些新特性
# 迁移方案
核心就是要能将老项目直接集成到新的工程
- 将原有的小程序作为多个子包集成到新的原生小程序中
- 新老项目路由兼容
- 全局性的逻辑处理
- 主包体积问题
# 多独立分包
独立分包意味着原来公共的依赖需要重新集成，且原来依赖app的初始化的部分以及全局样式都需要重新集成
compiler.hooks 里执行产物调整
排除 common/main.js,common/runtime.js,common/vendor.js,app.js
剩下的js文件，注入一段require代码
修改json文件的配置，存在usingComponents的时候，路径统一加上分包前缀
# 路由兼容
路由存在两个问题要解决
- uni-simple-router会根据路由表拦截，导致不在路由表里的分包无法跳转
- 由于变成分包，所有路径都加了前缀
问题一只能是把uni-simple-router换掉，就需要实现一个新的路由支持原来uni-simple-router提供的方法
# 全局逻辑
给vendor.js 文件注入补丁代码，重写app 和 page 对象
# 主包体积
利用commonplaceholder，让新工程主包用原工程主包的tab页,让原工程主包拆成两个分包，
这样主包的体积就压缩到1.5M