最近在做一款购物小程序，由于不同接口需要不同的权限，导致小程序的初始化流程以及各种获取数据的逻辑十分混乱，BUG频出。为了解决这一问题，决定重构小程序的初始化流程，在此之前，我们需要罗列一下不同接口所需的权限，调用的情景等信息。
| 接口 | 简介 | 小程序权限 | 需要登录 | 调用时间 | 备注 |
|---|---|---|---|---|---|
getLoginInfo |
获取登录信息（token） | × | × | 启动时 | |
getUserInfo |
获取用户信息 | √ | √ | 登录后 | |
getLocation |
获取用户位置 | √ | × | 启动时 | |
getMerchantInfo |
获取商户信息 | × | × | 获取位置后 | 需要用户位置 |
getMenu |
获取商品菜单 | × | × | 启动时 | |
getUserAddress |
获取用户的地址列表 | × | √ | 下单时 | |
getOrderList |
获取订单列表 | × | √ | 订单列表页 |
分析上面的列表，我们可以分析得出，这些接口可以分为3类，一类是启动时需要调用到的，一类是基于某些接口完成后需要调用到的，而最后一类是用户操作时要调用到的，用结构图表示大概是下面这样子：
- 启动时
- 获取登录信息
- 获取用户信息
- 打开下单页面（用户主动操作）
- 获取用户地址列表
- 打开订单页面（用户主动操作）
- 获取订单列表
- 获取用户位置
- 获取商家信息（用户信息用于匹配最近商家）
- 获取商品菜单
- 获取登录信息
画出上面的结构图后，我们对整个小程序的初始化流程的设计思路应该已经比较清晰了。首先，启动时获取用户的登录信息、用户位置、商品菜单是可以同时进行的。接着，完成这三个请求后，又会有对应的请求要执行。在这里我们有两个问题要明确：
- 如果有在某一步请求失败如何处理？
- 在需要授权的时候。如果用户拒绝授权如何处理？
先说第二个问题，小程序的某些权限是需要用户授权的，换句话说，就是必然存在用户拒绝授权的情况。因此，我们在设计程序的执行流程时，必须做到即使用户拒绝授权，也不影响使用（除非你的APP能保证用户一定会授权，然而很难存在这种情况）。
我们从上表分析，需要用户授权的地方只有两处，一个是获取用户信息、一个是获取用户位置。获取用户信息下没有别的请求要执行，通常我们获取用户信息是为了在个人信息页面显示头像、昵称等信息，这并不影响小程序的使用，我们可以在需要这些信息的时候做个判断，没有的话再次提示用户授权。获取用户位置之后再获取商户信息，但如果无法获取用户信息，这也就没法匹配最近的商户，那只能返回不带距离参数的商家信息了。当然，你也可以专门弹出页面，要求用户授权，否则不能继续使用。
再回到第一个问题，如果某一步请求失败如何处理？请求失败不像用户拒绝授权，拒绝授权是可以视为必然发生的事件，而请求失败是可防可控的。是网络问题，是系统bug，还是其他原因，这些问题都是可以针对性解决的。对于网络问题造成的请求失败，可以通过重试的逻辑处理来解决。试想一下，如果第一步登录的时候就已经失败，那么后面所有需要登录的接口自然就都没法用了。
当然，这里还要明确一个逻辑，如果某一步失败了，而通过重试之后又成功了，那么对于这一步操作下面的请求通常也要重新请求一次。在网页SPA应用中，当我们检测到没有登录时，系统可以直接进入登录页面，登录后再重新进行初始化进程。然而在小程序中，我们通常不会在登录后重启整个小程序，因此在设计小程序的启动流程时，应该明确每个步骤的流程，封装成不同组件，以便当某一步出错时，再从这一步开始初始化进度，这样可以有效防止后面数据错了以及bug的出现。
说到这里，还有一种情况要考虑的，就是如果登录状态过期呢？我们从上面的程序结构图看出，登录失败后，可以静默重新登录，登录成功后再执行获取用户信息等后续操作。
言简意赅的说，设计软件的初始化流程，就是先分析好各个步骤所需的条件，并把它们封装起来，以便后面从哪里失败，便从哪里重新开始。然而如何分析初始化流程呢？像上面说的，先列表，把它们所需的条件、权限、调用情景列出来，再列成流程结构图，再来分析就十分清晰了。
