uni-app开发APP之开发规范和一些注意事项

🌞个人体会

• 开发快速。uniapp最大的优势就是整合7端开发规范在一起，配合Vue让前端开发人员可以开发出“具有基本功能”的APP（对比flutter来说，uniapp对前端更友好），可以快速开发多端应用。一次编译，多端运行。
• 接口丰富。DCloud有h5 app经验，同时这部分的API也开放给uniapp可以直接调用，调用的时候同样也是用js引擎调用原生API。很多东西开箱即用，微信支付，消息推送等等。
• 过于全面。一般项目不需要7端都需要，但是官方必须考虑7端，所以很多东西必须用条件编译区分平台来做。
• 由于需要适配小程序，提升h5的性能，uniapp屏蔽了dom，规定了自己的规范，使用官方提供的方法可以选择节点，因此市面上的dom操作相关的库都不能使用。复杂特效只能用CSS配合官方接口和vue动态数据绑定来做。个人觉得做复杂动效需要费点时间。
• 虽然，uniapp是跨7端，但是跨越多的端，由于每种平台上规范不同，即使uniapp尽量统一这些不同的规范，但是仍然需要根据不同平台进行处理，就像排列组合一样，每多一种平台，不是单单的复杂加一，而是复杂加一倍。适合只做一种平台类型软件，但是没有对应平台软件开发工程师，可以跨语言障碍，仅此而已。而不是支持7端，就去做7端。
• 实际上，很多时候不需要开发出可以运行7、8端运行的程序，况且大部分产品也是天生只适合在某种平台上运行，一味的追求一套代码运行很多的平台，很多平台特有功能或者时说是优势能力因为妥协其他平台被牺牲掉，最后就像有好多短板的木桶一样，搞的产品在哪个平台上都没有优势。还不如针对于某一端做深耕一中平台代码，让前端人员可以用前端代码跨端运行，这也许会更符合实际开发需求，

🌞开发规范

• 组件不能使用纯HTML标签，不能用js对dom进行操作
• 接口能力靠近微信小程序规范，数据绑定方式靠近Vue规范，同时补充了APP和页面的生命周期
• 为了兼容多端运行，建议使用flex布局，配合upx使用
• 高版本安卓APP发送request请求必须使用https
• 微信小程序request请求也需要https，同时在小程序管理员后台配置可进行request请求的域名白名单。

🌞概念解释

• 很多概念不理解清楚，出现问题都不知道去哪里去找。🐶

1. HTML5Plus(h5+/HTML5+)：
2. 5+ Runtime：
3. 5+ SDK：HTML5+ 的SDK，是把5+ runtime封装为原生SDK，它有3个用途。
   1. 使用HTML5+ SDK实现本地打包。
   2. 通过原生代码扩展HTML5+ runtime的功能。
   3. 在现有原生项目中使用HTML5+ SDK替换原有的webview，以获得更强的web增强表现。
   4. uni-app项目做app时，也使用该sdk。
4. Native.js：Native.js技术，简称NJS，是一种将手机操作系统的原生对象转义，映射为JS对象，在JS里编写原生代码的技术。Native.js的运行环境是集成在5+runtime里的，使用HBuilder打包的app或流应用都可以直接使用Native.js。NJS是直接调用Native API，需要对Native API有一定了解，知道所需要的功能调用了哪些原生API，能看懂原生代码并参考原生代码修改为JS代码。否则只能直接copy别人写好的NJS代码，Native API具有平台依赖性，所以需要通过plus.os.name判断当前的运行平台。
5. 5+APP：HTML5 Plus移动App，简称5+App，是一种基于HTML、JS、CSS编写的运行于手机端的App，这种App可以通过扩展的JS API任意调用手机的原生能力，实现与原生App同样强大的功能和性能。
6. HTML5+ 应用架构：
7. MUI：

mui是一个前端框架，HTML5+是一套HTML5能力扩展规范，HTML5+ Runtime是实现HTML5+规范的强化浏览器引擎。
有点类似于bootstrap、w3c和chrome os的关系。
HTML5+规范隶属于http://www.html5plus.org，定义了HTML5规范中没有但开发者做App需要的扩展规范。
DCloud的5+ Runtime完整的实现了HTML5+规范。同时5+ Runtime还实现了Native.js，一种通过js调用几十万原生API的技术。

1. nvue：
2. native.js：
3. week：

🌞IDE配置，日常开发调试技巧

1. 安装插件，不要忘记安装使用到的插件，less/sass编译插件，ES6转换插件，升级开发IDE（HBuilderX）时，使用新版本解压包文件夹覆盖原来软件目录，这样以前安装的插件可以继续使用。

2. 开发调试：开发时，一般情况下，推荐使用H5端（运行->运行到浏览器）进行基础页面制作和页面布局（注意各端页面制作时，使用的技术是否都支持，否则H5上运行正常，换到小程序或者APP端出错），使用微信小程序进行数据交互和接口调试（自己感觉数据处理和接口调试方面微信小程序和APP端比较相似，诸如HTTPS要求），然后根据实际情况，根据各端特色功能和能力进行针对性的调试。比如：

   1. 动画的创建：所有端：css内可以使用transition和animation、非H5端：可以使用uni.createAnimation接口、H5端：可以使用transition组件
   2. APP可以调用的传感器H5端和微信小程序不可以，比如方向、设备信息的获取，而且位置的获取h5端（谷歌浏览器上）需要连接谷歌服务器。

3. App端提供真机运行的console.log日志输出，运行到真机或模拟器时，会在HBuilderX的控制台输出日志。注意无法输出对象，需要把对象转字符串后输出。

4. 调试时自定义重启首先展示的页面，调试时，可能正在做的页面需要从首页进行多次跳转才能打开，但是每次改动代码就会重新启动应用程序，可以在page.json里面配置。

5. 切换git分支之后，重新打开HBuilderX所有标签页，因为编辑器内容可能没有自动更新！

6. 【自定义基座使用】：自定义基座在调试第三方服务的时候非常有必要，默认情况下，直接开启开发者调试连接真机，运行程序，这时候使用的是HBuilderX自带的基座。我的理解是：基座，顾名思义就是平台，也可以理解成调试时候APP运行的手机环境，因为在调试的过程中，如果每次修改代码，想要查看结果就去重新打包安装，就太麻烦了。基座就是保证了基础配置的运行环境，然后每次改动了代码，IDE只会把改动的部分文件编译传输到真机上面，配合基座运行。因此需要如果需要查看第三方服务配置效果，必须制作自定义基座

   1. 自定义基座的制作：发行 -> 原生App-云打包，勾选自定义基座，制作完成之后，会在项目的unpackage目录下面生成安装包，安装上安装包，然后再进行程序的调试就可以了。

   

   1. 使用自定义基座调试运行程序：

7. **【H5端跨域】**H5页面使用浏览器调试时，提示跨域解决办法，chrome插件商店搜索安装Allow CORS开启，插件只是强制允许跨域，或者配置反向代理，如果不需要单点登录这样的需要跨域带cookies的高级需求，单纯的只是http请求，可以在本地使用nginx做代理，大致的配置：

server {
      listen       9001;
      server_name  127.0.0.1;

       location /api {
            proxy_pass https://xxx.xxx.com/;
            proxy_http_version 1.1;
            add_header Access-Control-Allow-Origin http://127.0.0.1:9000;
            add_header Access-Control-Allow-Methods "GET, PUT, POST, DELETE, HEAD, OPTIONS";
            add_header Access-Control-Allow-Headers "Content-Type,*";
            add_header Access-Control-Allow-Credentials true;
       }
        location /authsystem {
            proxy_pass http://**.*.**.**:10011/;
        }
    }

用nginx做端口转发，因为调试的时候HBuilderX运行程序在9000端口上面，所以Nginx不能监听9000端口，只能在nginx和前端程序之间再次跨域，但是可以在nginx上面设置想要设置的所有参数，nginx再向后端服务器接口请求，就可以了。但是这种方法是不推荐的，太过繁琐，开发调试要启动这个，启动那个，还要看端口占用情况，也可能是我没有配置好，反正就是不好用。

还有一种方法是最好的，就是uniapp的manifest.json中有反向代理的配置选项，可以直接配置的（ps：官方没有提，不知道为什么），在manifest.json文件中的h5 -> devServer中增加proxy选项，其实和Vue配置是一样的，大致如下：

"proxy": {
   
    "/api": {
   
      "target": "https://xxx.xxx.com/",
      "changeOrigin": true,
      "ws": true,
      "pathRewrite": {
   
        "^/api": ""
      }
    }