文章目录

• 小程序面试问题汇总及解答
• • 双向绑定
  • git开发流程
  • **上线管理**
  • **前后端问题解决方式**
  • **路由跳转方式**
  • **安全策略**
  • **包限，分包处理**
  • **setData 同步还是异步**
  • **双向绑定原理**
  • **宏任务 微任务**
  • **小程序常用的API**
  • **```openId unionId```**
  • **css3动画**
  • **整个敏捷开发是怎样的**
  • **前端用到的加密技术**
  • **叙述小程序登录**

小程序面试问题汇总及解答

双向绑定

与React中的数据更新机制类似，在小程序中，直接使用赋值语句，如this.data.value = e.detail.value在逻辑层的修改，并不会让视图层有相应的更新，必须使用this.setData({ value: e.detail.value })才行

git开发流程

• 微信小程序git开发步骤及注意事项

上线管理

前后端问题解决方式

• 跨域
  • 后端支持：允许任何的请求域名、请求头、方法

路由跳转方式

主要是以下四种方式

• wx.redirectTo： 关闭当前页面，跳转到应用内的某个页面，但是不允许跳转到tabbar页面
• wx.navigateTo： 保留当前页面，跳转到应用内的某个页面。但是不能跳到tabber页面。使用wx.navigateBack可以返回到原页面。小程序中页面栈最多可以叠加十层
• wx.relaunch： 关闭所有页面，打开到应用内的某个页面
• wx.switchTab： 跳转到tabBar页面，并关闭其他所有非tabBar页

安全策略

• 授权登录
• 外部网站，不允许放链接，不允许相互之间跳转

包限，分包处理

微信小程序设置2M的代码包限制，是出于对启动速度的考虑，让用户使用小程序时，能够有“秒开”的体验, 多团队共同开发时可以更好的解耦协作

然而，2M的大小也限制了小程序的业务和功能的扩展，超过2M之后，需要使用分包加载

分包简单介绍：

大部分小程序都会由某几个功能组成，通常这几个功能之间是独立的，但会依赖一些公共的逻辑，并且这些功能通常会对应某几个独立的页面。那么小程序代码的打包，大可不必一定要打成一个，可以按照功能的划分，拆分成几个分包，当需要用到某个功能时，才加载这个功能对应的分包

微信开放文档 分包加载

修改底部导航栏样式

app.json中配置

setData 同步还是异步

• 在逻辑层的操作是同步的，this.data中的数据会立即更新；
• 在视图层的操作是异步的，页面渲染不会立即进行，而是等到某个特定的时间

因为将数据从逻辑层发送到视图层相比在逻辑层内操作，需要更多的时间，也会有更多的不确定；另外，频繁地更新视图层也会有更大的性能开销，所以一般将多处的视图层重新渲染合并为一次，使用异步更新

考虑到有些操作需要在视图更新后立即执行，并需要使用到更新后的数据，所以setData方法的第二个参数是回调函数，在该函数内，可以访问最新的this.data

双向绑定原理

数据变化通知视图更新，视图变化改变数据

• 逻辑层的数据变化会让视图层重新渲染
• 基于小程序原生的组件事件，将组件状态变化的事件绑定到Page中的方法，从而改变数据

宏任务 微任务

宏任务和微任务都是异步任务，JS引擎会在执行完主线程中的所有同步代码之后，处理异步任务

微任务的优先级高于宏任务，也就是说，当JS的事件循环至异步队列时，会先查看微任务队列中是否为空，不为空的话，先执行微队列中的所有任务，直到微队列清空，才会去执行宏队列中的任务

常见的微任务、宏任务，及在浏览器和Node中的表现如下：

小程序常用的API

• wx.login

• wx.switchTab

• wx.reLaunch

• wx.redirectTo

• wx.navigateTo

• wx.navigateBack

• wx.showToast

• wx.showModal

• wx.showLoading

• wx.showActionSheet

• wx.hideToast

• wx.hideLoading

• wx.stopPullDownRefresh

• wx.startPullDownRefresh

openId unionId

• openId： 表示用户在你的当前应用中的唯一标示 ，比如小程序、微信公众号，这都算一个应用。也就是说，同一个用户，在同一个微信开放平台下的不同应用中的openId是不一样的
• unionId： 同一个微信开放平台帐号下的移动应用、网站应用和公众帐号（包括小程序），用户的 UnionID是唯一的。换句话说，同一用户，对同一个微信开放平台下的不同应用，unionid是相同的

css3动画

• 关键帧：@keyframes
• transform
• animation

整个敏捷开发是怎样的

• B站评论

  目前参与过公司的项目，公司专业从事敏捷开发，也比较成熟，可以分享下其中的细节。
  
  1、概念，可以参考敏捷宣言，强调适应变化，四句指导
  
  个体和互动 高于 流程和工具（动员每个人积极交流，相互之间可以 battle，头脑风暴）；
  工作的软件 高于 详尽的文档（好的代码是不需要注释和文档的，顶多有一些规范指南一类的在线协作文档）；
  客户合作 高于 合同谈判（真心实意为客户创造价值，而不止于眼前的功能交付，这个很难，由此还专门有一个角色去 control 这件事）；
  响应变化 高于 遵循计划（计划是赶不上变化的，随时改需求随时变动迭代计划，有迭代的概念）；
  
  基于于右边，而更注重左边的价值，并不是说完全抛弃传统的瀑布式开发。
  
  2、人员架构
  
  因为公司没有所谓的各种领导，这里就说下交付组里，我所见的一些角色，也是每天在一起工作的小伙伴：
  
  PM：项目管理者，这里不是项目经理，负责和客户签合同，各种会议的组织者，没有项目经理那种权利
  BA：业务分析师，专门和客户谈需求，超强的交流和控制客户的能力，几乎每天都和客户泡在一起开会过需求，疯狂开会，驱动客户（我们组的BA是御姐型的，气场极强）
  QA：测试人员
  DEV：开发人员，其中有掌握技术话语权的 TL
  
  PO：比较特殊，是客户某的部门领导人，一般和 PM 单独沟通，几乎没出现过，网友一样的存在
  
  一个团队一般 1 PM、1 BA、1 QA 、6 DEV (三前三后，至少两个TL)
  
  这里没有 MS，所以每个人都是 SM，233333
  
  3、会议
  
  IPM：迭代会议，每个迭代开始之前开一次，主要是排下个迭代的故事卡，并给每张卡估点，我遇到的是两周一个迭代（一般会有卡墙，有物理的，也有线上的）
  Showcase：开发成果展示，每个迭代结束开一次，一般是BA或QA给客户演示上个迭代做的功能，当然也是优化和新改动提得最多的时候
  Retro：回顾会议，每个迭代结束开一次，讨论上个迭代团队做得好和做得不好的事（不是针对和人，不含人身攻击），并给出改进方案，在下个迭代中执行
  Stand Up：每天早上的站会，大家站成一圈，一般由 PM 主持，轮流阐述自己的昨天工作内容和工作进度，和今天要完成的工作，以及遇到的一些问题，及时反馈出来（我们组有个小龙猫的毛绒玩具，大家挨个传递，挨个阐述）
  
  每天还有 Code Review，动态安排时间，我们团队一直坚持，刚开始是前后端一起过昨天每个人写的代码，后面时间太长，就前后端分开。大家一起来找茬，你的命名和代码逻辑划分，代码风格，都有个能会被挑刺。在相互找茬的过程中，坚持下去，对个人的成长有很大很大的帮助。
  
  4、写代码
  
  DEV 要做开发，就要先领故事卡，俗称开卡，自己选好一张故事卡，拉上BA和QA去过其中的细节，理清细节，然后才能上手开发，开发完后再拉上BA和QA去结卡，检查卡中的功能是不是都完成了，有问题就被打回去改，直到BA和QA觉得完善了，才能关卡。。。
  
  代码质量要求很严格，遵循 TDD，前端有 lint，有单元测试（不能偷懒，而且有覆盖率要求），有 e2e 测试（必须写，和QA一起看），当你的代码走过这三个流程，提交到公共仓库，CI 自动构建会拉你的代码，再走一遍测试（挂了就要修代码），然后自动发布新版本到 Dev 环境。
  
  你以为这就完了？还有代码嗅探器，时刻在扫描代码仓库，有两个重复的函数不行、重复率太高不行、使用了骚代码去做类型转换之类的不行、空间内有命名重叠不行。。。。这一套下来，再加上 code review，菜鸟开发每天一半的时间都在改昨天的代码。
  
  项目还有规定，CI 不能红过夜，当天的问题当天要修好。。。。
  
  以上这些，小公司就别说什么没时间，项目吃紧，然后就没做，自求多福吧
  
  这些都是我所经历的，敏捷实践各不相同，大家看看就好
  

8.gitFlow流程

同上

9.项目做的亮点难点功能
10.上线问题处理

前端用到的加密技术

CSDN博客

• Base64
  • 使用64可打印字符（A-Za-z0-9±）标识二进制数据
  • 可用于在HTTP协议中传递较长的标识信息，Base64编码具有不可读性，只有解码之后才能阅读
• MD5
  • 加密原理是散列算法（哈希算法）
  • 相同字符串加密后也一定是相同的，所以，用户的密码只有用户知道
  • 该加密方式没有解密算法， 单向不可逆
• SHA
  • 安全散列算法
  • 单向不可逆

加密小结：

• 避免私密信息在网络中明文传输，被人截取数据包而泄露数据
• 在前端使用JavaScript加密，减少了服务器加密时的资源消耗，从理论上提高了服务器的性能。为了安全，很有必要再做服务器端的加密，无论从理论还是实际，两道门比一道门要安全些，至少给攻击者造成了一个障碍
• 前端能处理的比较有限，想要做到更加安全就得需要在服务器中对用户的信息以及重要数据进行加密

1）技术相关
2）开发规范
3）上线问题处理、遇到比较棘手的问题（思路、处理）

叙述小程序登录

• 前端所做的工作就是调用wx.login()获取临时登录凭证code，接着将code发送给开发者服务器

• 开发者服务器端微信接口服务提供的服务器API auth.code2Session 获取用户应用程序唯一标识OpenId、用户在该开发者平台下的唯一标识UnionId、会话密钥session_key

• 之后开发者服务器关联openid、session_key返回自定义登录态

注意：

1. 会话密钥 session_key 是对用户数据进行 加密签名 的密钥。为了应用自身的数据安全，开发者服务器不应该把会话密钥下发到小程序，也不应该对外提供这个密钥。
2. 临时登录凭证 code 只能使用一次

2，css3动画

3，敏捷开发
4，防抖节流

防抖：用户的某个行为（比如点击）在一定时间多次触发，只会执行最后一次触发的回调

节流：用户的某个行为（比如点击）执行一次后，在一定时间内不允许重复执行

5，数据管理

官方的全局数据管理解决方案

小程序目前最大的痛点是状态管理和跨页通讯

• 父子组件数据

6，组件
7，带参数分享
8，路由api

生命周期

• 页面实例的生命周期

在一定时间多次触发，只会执行最后一次触发的回调

节流：用户的某个行为（比如点击）执行一次后，在一定时间内不允许重复执行

5，数据管理

官方的全局数据管理解决方案

小程序目前最大的痛点是状态管理和跨页通讯

• 父子组件数据

6，组件
7，带参数分享
8，路由api

生命周期

• 页面实例的生命周期