缘由

1、为什么要迁移到uniapp？

公司原本的前端走了。wepy框架虽然不难。但是受众面积小。并且该框架是wepy1.X

把公司项目变成自己的项目

2、熟悉公司业务

其实每次到了一个新公司都会有一个问题。负责人或者你必须要接受当前公司的业务环境，人，还有代码。但是这个代码是真的丑啊。

3、很多公司目前都不会想着要更新自己的技术。

就像我上一篇文章，都是能用就行。为什么还要去升级，要迁移。我一个打工的，打工就好了

4、迁移的目的是为了更好的维护

当一个公司技术栈非常杂乱的时候，作为某一块的技术负责人应该要反思，为什么有这么多的技术栈。会给团队带来什么样的好处和坏处。

5、目前公司还有5个pc端vue项目也是老版本的vuecli2，后续我将会逐步的更新换代。

6、大家会觉得我总是喜欢升级，换代，其实是因为我追求的太新潮了吧。不知道是不是一个缺点

技术要点

1、vue非常熟练，你要对vue的本身构建，结构要有自己的成熟的认知。也就是只要是vue项目，你就不存在我不会这种想法

拿我自身来说，uniapp我从来没有写过。但是我只是看过uniapp的文档。但是这次进入新公司，我已经把50个设计图（半个月），用uniapp开发完成了。

2、熟读wepy文档，起码需要能启动。知道结构配置

3、uniapp熟练度要求较高，像我这样能独立写东西才行

为什么选择自己手动迁移

这个其实原因很简单，有人说官方推荐的wepy转uni-app转换器：github.com/zhangdaren/…

说实在有用，但是非常有限。仅做参考，无法实际使用。但是也有一点点小用处，就是少写点代码，有个参考对比

wepy和uniapp框架对比

注意这里是uniapp最新的开发工具2.7.X，而wepy为1.X版本

两者都是vue框架，可以说目录结构基本一致，但是配置上大相径庭，目录结构也有很多不一样的地方。

a、uniapp有独立的开发工具，随着使用，我发现还是比较不错的，虽然比webstorm差了一些。主要也是官方推荐。

b、wepy是纯vuecli框架，所以目录都在src下面，但是uniapp由于是开发工具，本身目录就是src目录

c、两者目录结构非常类似，但是功能差异很大，并且uniapp提供了更多的便捷

开始对比

1、wepy的app.vue耦合了小程序app.json，app.js功能

2、uniapp的app.vue和小程序保持一致，只负责app.js，而app.json由page.json代替，负责了每个页面的注册，配置，组件导入等

3、两者都有pages目录，都作为页面存放目录，其实可以变啦，不过一般遵循官方规范

4、uniapp的components目录可以进行快捷组件注册，不需要手动的进行vue组件注册，具体看官方文档

5、对于小程序的组件注册方面uniapp需要独立的创建wxcomponents文件存放，然后在page.json中注册

6、两者都使用vue语法，但是api上的封装uni方面全部都有自己的实现，但是wepy主要是微信官方为主

7、虽然wepy是用的vue语法，但是开发过程中vue类的创建却是不一样的，这点uniapp方面基本保持了所有的vue习惯。除了无法实现部分，基本和vue行为保持一致。这点是非常喜欢的地方。

8、两者都对部分api进行的promise封装，但是uni做了一点变化，就是uni对进行了封装的api返回的是一个数组，【err，result】，这个在后面的迁移中变化也是改变巨大

9、wepy1.X还需要手动更新视图this.$apply，但是uni不需要

10、globalData数据取用方面wepy采用this.$perent，但是uni遵循小程序规范，采用全局的getApp()

11、页面之间通讯方式有所差异，但是差不多

12、mixins方面也有很大的写法差异

…………………………

应该还有更多，但是上述的这些基本上是我在项目迁移中的问题。具体差异应该是更多，更多

开始迁移

先看两个目录结构，这就是我们要迁移的项目

下面开始迁移

1、把wepy的app.vue其中的配置项和函数部分分离，然后分别放入uniapp的app.vue和page.json。观察是否有授权项目，然后在manifest.json中配置授权

2、还是关于配置部分，把每个wepy中关于页面配置部分全部手动copy到，page.json的页面配置中

3、关于tabbar部分配置整体拷贝

4、将wepye的assets静态文件拷贝到uniapp的static中，并且修改page.json关于静态文件的路径

5、wepy的小程序组件导入方式不一样，在uniapp中新建wxcomponents文件，全部放这里，然后page.json部分导入书写配置

6、wepy如果存在components文件则在uniapp中需要新建其他文件名称，然后重新修改所有组件的导入名称

7、pages页面中的wepy页面或者其他文件中的wepy文件利用官方推荐的wepy to uniapp转义下格式，然后先拷贝。

再因为上述修改了这么多地方，只要中间vue部分，就是

export default class extends wepy.page {}

这个格式的全部改为export default

同时删除关于config部分的配置，因为你上面已经迁移到page.json中了

8、这个时候其实已经基本算是迁移完成了，但是我们还没有把关于插件文件等等的导入进来，这部分大家就靠本事，自己手动拷贝，然后修改文件中关于这部分的代码路径

9、开始修改两者框架的代码不兼容部分

10、上面说到了vue文件格式导出不一样，还有就是wepy的api也不一样，其中大部分是用的wx. 而uni是uni.注意不要把关于原生组件部分覆盖进去，然后全局替换

11、uni的golbalData取数据格式不一样，从原来的this.$perent改为getApp()

12、清理所有this.$apply，全局替换为空

13、关于wepy的events部分全部放入当前页面的methods中。然后查看wepy.$emit部分注意和uni的页面通讯保持一致

14、所有uni封装的异步接口，比如uni.request等是会返回一个数组【error，succcess】,如果封装过接口的那么你省事，否则每个页面都去一点点替换代码。同时还有其他的异步api都要进行处理

至此基本改造完成，可以跑起来看看了

最后总结

总共迁移时间是一天，有这个想法也是在这个一天里面。

早上花了2小时翻文档，试试，然后就干起来了。下午5点基本迁移完成。但是还有一些api方面的问题

没事别瞎折腾，我这个小程序18个页面，总体还算简单。但是上面还只是部分。我还测到一些问题，并且我是后接手。原维护人员已经跑路。所以还有一些坑需要填。

放个跑起来的图