微信小程序项目问题及微信小程序面试题

thewar196

已于 2022-04-03 08:56:47 修改

阅读量4.1k

点赞数 5

文章标签：前端

于 2022-04-01 13:55:40 首次发布

本文链接：https://blog.csdn.net/thewar196/article/details/123893611

版权

微信小程序

1、小程序与h5的区别

简单来说，小程序是一种应用，运行的环境是微信（App）；H5是一种技术，依附的外壳是是浏览器。

1.运行环境的不同

H5的运行环境是浏览器，包括webview，而微信小程序的运行环境并非完整的浏览器，因为小程序的开发过程中只用到一部分H5技术。

小程序的运行环境是微信开发团队基于浏览器内核完全重构的一个内置解析器，针对性做了优化，配合自己定义的开发语言标准，提升了小程序的性能。

2.系统权限

这里的系统权限，可以理解为隐私级别比较高的，如通讯录，或能调用硬件的，比如蓝牙功能等。从这个角度看，H5 本身可以说几乎是没有什么系统权限的。虽然也有摄像头之类的接口，但是重度依赖浏览器能力，兼容性有限。

而小程序，由于依赖微信客户端本身，所以微信小程序团队将客户端的很多能力开放给了小程序环境，当然，前提是你给微信也授权了相关的能力，比如允许访问麦克风，允许访问相册等。

所以，如果你的产品重度依赖这些能力，那小程序一定是不二之选，因为 H5 很难做到这些，对于很多小程序提供的能力，H5 是根本没有可能实现的。

3.开发成本

H5 的开发，涉及开发工具（vscode、Atom等）、前端框架（Angular、react等）、模块管理工具（Webpack 、Browserify 等）、任务管理工具（Grunt、Gulp等），还有UI库选择、接口调用工具（ajax、Fetch Api等）、浏览器兼容性等等。尽管这些工具可定制化非常高，大部分开发者也有自己的配置模板，但对于项目中各种外部库的版本迭代、版本升级，这些成本加在一起那就是个不小数目了。

而开发一个微信小程序，由于微信团队提供了开发者工具，并且规范了开发标准，则简单得多。前端常见的HTML、CSS变成了微信自定义的 WXML、WXSS，WXML，官方文档中都有明确的使用介绍，开发者按照说明专注写程序就可以了。需要调用后端接口时，调用发起请求API；需要上传下载时，调用上传下载API；需要数据缓存时，调用本地存储API；引入地图、使用罗盘、调用支付、调用扫码等等功能都可以直接使用；UI库方面，框架带有自家weui库加成。并且在使用这些API时，不用考虑浏览器兼容性，不用担心出现BUG，显而易见微信小程序的开发成本相对低很多。

4.运行流畅度的不同

在运行流畅度方面，无论对于用户还是开发者，都可以直观体验出两者的差异。这也是普通大众最容易区分小程序与H5的一点。打开H5，实际上是打开一个网页，而网页需要在浏览器中渲染。所以加载这一过程，会给人明显的「卡顿」感觉，面对复杂的业务逻辑或者丰富的页面交互时尤为明显。

而微信小程序，它的代码直接在微信上运行，省去了通过浏览器渲染的步骤，因此，在微信中使用小程序，才会比H5流畅很多。除了首次打开需要几秒的加载时间外，小程序各个页面的切换、跳转等体验已经媲美原生App，有着同样的柔丝般顺滑的效果。

5.迭代周期

开发成本低，未必迭代周期就短。对于 H5 我们可以随时发布上线，不用受任何牵制。而小程序的特点，就是每次提交版本都要经过微信方面的审核，且审核时间的长短很随机，着急上线的项目就很无奈了。

至于其他速度，取决于开发人员技能熟练程度，系统复杂度，对基础能力的依赖等，就不好估算了。

6.访问入口

在访问入口这个点上，H5 的核心竞争力就是能在微信之外玩，不依赖微信本身。而小程序的优势，就是有 50+ 微信提供的场景入口，并且聊天界面顶部的“最近使用”和“我的小程序”这个入口，相对 H5 来说是有绝对优势的。

用户关闭之后，H5 页面如果想继续访问，可能会通过收藏入口，或者转发给“文件传输助手”等聊天界面保存，还可以缩小到图标稍后阅读等等。本质上还是跟 PC 时代的浏览器收藏夹差不多，需要有个地方把 H5 的链接地址保存下来，方便下次访问。如果没有保存，下次就很难找到了。

至于微信内的搜索，是可以同时搜索 H5 和小程序的，可以根据 H5 的名字和内容、小程序的名字和介绍来搜索。这里 H5 有个天然优势就是，只要你的链接在各大搜索引擎提交过，那么使用其他的搜索引擎也能搜出这个 H5，比如百度搜索。

7.外部限制

由于小程序依赖微信平台，因此微信平台要对内容安全等事项负责，比如你想搞个有 UGC 的产品，用 H5 可能还可以趁着监管宽松无证裸奔一阵，或者说做大了再补证。

而小程序，就很可能完全不能过审，根本上不了线。比如试听类，社交类，都有对应的资质，而这个资质还可能很难获得。

类似的，H5 页面可以不用搞 HTTPS，有个网站就能玩，甚至用工具做个小活动也都可以玩。但是小程序，从后端开始就有限制，要求域名备案 +HTTPS，一定程度上也是一点成本。

此外，小程序对文件大小也有限制，虽然现在已经支持分包加载，但是在文件大小方面，H5 本身是没有什么限制的。只是实际开发的时候，要照顾用户的体验，不能让页面打开太慢。

优势：

1）容易上手，只要之前有HTML+CSS+JS基础知识，写小程序基本上没有大问题；当然如果了解ES6+CSS3则完全可以编写出即精简又动感的小程序

2）基本上不需要考虑兼容性问题，只要微信可以正常运行的机器，就可以运行小程序；

3）基本组件库已经比较齐全：Toast,Loading框,Picker,定位及地图,Image,Input,Checkbox,Text,TextArea,ScrollView等常用的组件都有，而且使用也挺简单、方便；

4）发布、审核高效，基本上上午发布审核，下午就审核通过，升级简单，而且支持灰度发布；

5 ) 微信官方提供使用人数、频率等数据统计，小程序js脚本执行错误日志；

6）开发文档比较完善，开发社区比较活跃；

7）最近刚开放的牛x功能，新增webview组件，可以展示网页啦，这个比较爽；

8）支持插件式开发，一些基本功能可以开发成插件，供多个小程序调用；

劣势：

1）后台调试麻烦，因为API接口必须https请求，且公网地址，也就是说后台代码必须发布到远程服务器上；当然我们可以修改host进行dns映射把远程
服务器转到本地，或者开启tomcat远程调试；不管怎么说终归调试比较麻烦。

2）前台测试有诸多坑，最头疼莫过于模拟器与真机显示不一致

3）真机测试，个别功能安卓和苹果表现迥异，我们的小程序里有很多页面有定位功能，模拟器和iphone定位瞬间完成，然而安卓手机就蛋疼了，老显
示“定位中…”要很久才能定位好。后来没办法只能优化，减少定位次数。

4）native组件，展示很不好，比如textarea，不能在滚动页面出现，而且至于顶层，经常其它组件会被它遮挡，点击其它组件时，就进入textarea输入
框；画布组件也是如此；

5）页面跳转深度不能超过5个页面，这个比较麻烦，有些复杂的页面跳转没法实现，不过太复杂的话也有悖小程序简单易用的原则啦；

6）小程序升级问题，官方文档说会自动更新，实际情况往往是要先把原来的小程序删除掉，重新搜索添加，才能加载最新版本；

7）页面渲染稳定性有待提高，已经好几次出现部分用户的页面显示异常，整个页面被放大了好几倍，先删除原来小程序再添加回来，如此重复好几次，
才能显示正常；

8）js引用只能使用绝对路径，很蛋疼；基于安全性及MINA框架实现原理，小程序中对js使用做了很多限制，不能使用：new Function，eval， Generator，不能操作cookie，不能操作DOM；

9）开发工具bug比较多且效率比较低，三天两头升级，解决老问题的同时又出现问题；文件查找、资源定位、代码编辑较eclipse有一定差距。经常出现
把a.js当做b.js来修改

2、app.json配置，app.js作用

app.json：

app.json 用来对微信小程序进行全局配置，决定页面文件的路径、窗口表现、设置网络超时时间、设置多 tab 等

pages：设置页面路径

window：设置默认页面的窗口表现

tabBar：设置底部tab的表现

networkTimeout：设置网络超时时间

debug：设置是否开启debug模式

app.js：

app.js文件是比较特殊的，它是微信小程序的入口文件，掌控整个小程序的生命周期，同时有一些全局的属性、变量也存放在这个文件中。

3、布局弹性盒子单位rpx

小程序设置rpx的目的：为了内容的高宽会随着机型变化（型号、分辨率的不同）会有一个自动的适应

						尺寸单位
						rpx（responsive pixel）: 可以根据屏幕宽度进行自适应。规定屏幕宽为750rpx。如在 iPhone6 上，
						屏幕宽度为375px，共有750个物理像素，则750rpx = 375px = 750物理像素，1rpx = 0.5px = 1物理像素。
						设备	rpx换算px (屏幕宽度/750)	px换算rpx (750/屏幕宽度)
						iPhone5	1rpx = 0.42px	1px = 2.34rpx
						iPhone6	1rpx = 0.5px	1px = 2rpx
						iPhone6 Plus	1rpx = 0.552px	1px = 1.81rpx
						建议： 开发微信小程序时设计师可以用 iPhone6 作为视觉稿的标准。
						
						注意： 在较小的屏幕上不可避免的会有一些毛刺，请在开发时尽量避免这种情况。

4、生命周期

小程序生命周期：

onLaunch：小程序初始化完成（全局只触发一次）

onShow：小程序启动，或从后台切入前台时触发

onHide：小程序从前台切入后台时调用

onError：小程序发生脚本错误，或者api调用失败时触发，会带上错误信息

onPageNotFound：小程序要打开的页面不存在时触发，会带上页面信息回调该函数

页面的生命周期：

onLoad：页面加载时触发

onShow：页面显示时触发

onReady：页面初次渲染完成触发

onHide：页面隐藏时触发

onUnload：页面卸载时触发

页面执行时的钩子：

onPullDownRefresh：监听用户下拉动作

onReachBottom：页面上拉触底事件

onShareAppMessage：用户点击右上角转发

onPageScroll：页面滚动触发事件

onTabItemTap：当前是Tab页，点击Tab时触发

5、路由跳转几种方式以及它们的区别

1、wx.navigateTo()

保留当前页面，跳转到应用内的某个页面。但是不能跳到 tabbar 页面。

2、wx.switchTab()
跳转到 tabBar 页面，并关闭其他所有非 tabBar 页面。

3、wx.redirectTo()
关闭当前页面，跳转到应用内的某个页面。但是不允许跳转到 tabbar 页面。

4、wx.navigateBack()
关闭当前页面，返回上一页面或多级页面。可通过 getCurrentPages 获取当前的页面栈，决定需要返回几层。
注意：此方法返回上个页面，页面不会重新加载。

5、wx.reLaunch()
关闭所有页面，打开到应用内的某个页面。

6、导航组件：,跳转方式默认为navigator,可通过open-type属性改变跳转方式。

6、用户授权包括哪些授权

获取当前的地理位置、速度：wx.getLocation(Object object)

获取手机号：需要将 button 组件 open-type 的值设置为 getPhoneNumber，当用户点击并同意之后，可以通过 bindgetphonenumber 事件回调获取到动态令牌code，然后把code传到开发者后台，并在开发者后台调用微信后台提供的 phonenumber.getPhoneNumber 接口，消费code来换取用户手机号。每个code有效期为5分钟，且只能消费一次。

获取用户信息：wx.getUserInfo(Object object) (旧api)

			获取用户信息：wx.getUserProfile(Object object)   (新api)

7、登录流程

			小程序可以通过微信官方提供的登录能力方便地获取微信提供的用户身份标识，快速建立小程序内的用户体系。

首次登录：

1、首先需要调用小程序api接口 wx.login() 获取临时登录凭证code ，这个code是有过期时间的。
2、将这个code回传到开发者服务器（就是请求开发者服务器的登录接口，通过凭证进而换取用户登录态信息，包括用户的唯一标识（openid）及本次登录的会话密钥（session_key）等）。
3、拿到开发者服务器传回来的会话密钥（session_key）之后，前端要保存wx.setStorageSync(‘sessionKey’, ‘value’)

再次登录的时候，就要判断存储的session_key是否过期了：
1、获取缓存中的session_key，wx.getStorageSync(‘sessionKey’)
2、如果缓存中存在session_key，那么调用小程序api接口wx.checkSession()来判断登录态是否过期，回调成功说明当前 session_key 未过期，回调失败说明 session_key 已过期。登录态过期后前端需要再调用 wx.login()获取新的用户的code，然后再向开发者服务器发起登录请求。
3、一般在项目开发，开发者服务器也会对用户的登录态做过期限制，所以这时在判断完微信服务器中登录态如果没有过期之后还要判断开发者服务器的登录态是否过期。（请求开发者服务器给定的接口进行请求判断就好）。
4、无论是微信服务器过期了还是开发者服务器登录态过期了，都要像首次登录那样开始三步骤。所以注意封装代码。

8、小程序如何实现分包

具体查看官网：https://developers.weixin.qq.com/miniprogram/dev/framework/subpackages/basic.html
配置方法
假设支持分包的小程序目录结构如下：

├── app.js
├── app.json
├── app.wxss
├── packageA
│ └── pages
│ ├── cat
│ └── dog
├── packageB
│ └── pages
│ ├── apple
│ └── banana
├── pages
│ ├── index
│ └── logs
└── utils
开发者通过在 app.json subpackages 字段声明项目分包结构：

写成 subPackages 也支持。

{
  "pages":[
    "pages/index",
    "pages/logs"
  ],
  "subpackages": [
    {
      "root": "packageA",
      "pages": [
        "pages/cat",
        "pages/dog"
      ]
    }, {
      "root": "packageB",
      "name": "pack2",
      "pages": [
        "pages/apple",
        "pages/banana"
      ]
    }
  ]
}

subpackages 中，每个分包的配置有以下几项：

字段	类型	说明
root	String	分包根目录
name	String	分包别名，分包预下载时可以使用
pages	StringArray	分包页面路径，相对与分包根目录
independent	Boolean	分包是否是独立分包
打包原则
声明 subpackages 后，将按 subpackages 配置路径进行打包，subpackages 配置路径外的目录将被打包到 app（主包） 中
app（主包）也可以有自己的 pages（即最外层的 pages 字段）
subpackage 的根目录不能是另外一个 subpackage 内的子目录
tabBar 页面必须在 app（主包）内
引用原则
packageA 无法 require packageB JS 文件，但可以 require app、自己 package 内的 JS 文件；使用 分包异步化 时不受此条限制
packageA 无法 import packageB 的 template，但可以 require app、自己 package 内的 template
packageA 无法使用 packageB 的资源，但可以使用 app、自己 package 内的资源
低版本兼容
由微信后台编译来处理旧版本客户端的兼容，后台会编译两份代码包，一份是分包后代码，另外一份是整包的兼容代码。 新客户端用分包，老客户端还是用的整包，完整包会把各个 subpackage 里面的路径放到 pages 中。