微信小程序生命周期
我们组的项目是用微信小程序编写一个中大活动。目的是开发一款浏览活动，在线活动报名，在线活动组队，在线活动讨论和分享平台。这就需要没有小程序编写经验，只有一点Vue经历的我开始学习小程序的编写。与此同时，第一次迭代我还是一名产品经理，进行基础功能的定义和期望UI的设计。
其中我想总结的是小程序的生命周期学习总结。我对于这一部分是极其陌生的，理解小程序的生命周期极为重要。
官网给出的生命周期和状态图
由上图可知，小程序由两大线程组成：负责界面的视图线程（view thread）和负责数据、服务处理的服务线程（appservice thread），两者协同工作，完成小程序页面生命周期的调用。
视图线程有四大状态：
初始化状态：初始化视图线程所需要的工作，初始化完成后向 “服务线程”发送初始化完成信号，然后进入等待状态，等待服务线程提供初始化数据。
首次渲染状态：当收到服务线程提供的初始化数据后（json和js中的data数据），渲染小程序界面，渲染完毕后，发送“首次渲染完成信号”给服务线程，并将页面展示给用户。
持续渲染状态：此时界面线程继续一直等待“服务线程”通过this.setdata（）函数发送来的界面数据，只要收到就重新局部渲染，也因此只要更新数据并发送信号，界面就自动更新。
结束状态：页面被回收或者销毁、应用被系统回收、销毁时触发。
服务线程五大状态：
初始化状态：此阶段仅启动服务线程所需的基本功能，比如信号发送模块。系统的初始化工作完毕，就调用自定义的onload和onshow，然后等待视图线程的“视图线程初始化完成”号。onload是只会首次渲染的时候执行一次，onshow是每次界面切换都会执行，简单理解，这就是唯一差别。
等待激活状态：接收到“视图线程初始化完成”信号后，将初始化数据发送给“视图线程”，等待视图线程完成初次渲染。
激活状态：收到视图线程发送来的“首次渲染完成”信号后，就进入激活状态既程序的正常运行状态，并调用自定义的onReady()函数。此状态下就可以通过 this.setData 函数发送界面数据给界面线程进行局部渲染，更新页面。
后台运行状态：如果界面进入后台，服务线程就进入后台运行状态，从目前的官方解读来说，这个状态挺奇怪的，和激活状态是相同的，也可以通过setdata函数更新界面的。毕竟小程序的框架刚推出，应该后续会有很大不同吧。
结束状态：页面被回收或者销毁、应用被系统回收、销毁时触发。
当我们直接启动小程序的时候，首先调用的是app.js中的onlaunch方法和onShow方法，同时还会执行主页面的onload方法和onshow方法以及onReady方法。
onlaunch：当小程序初始化完成时，会触发 onLaunch（全局只触发一次）；
onShow:当小程序启动，或从后台进入前台显示，会触发 onShow；
主页面onLoad：加载页面；
onshow：页面显示；
onReady：页面初次渲染完成；
整个页面加载完成后，我们开始操作主页面，当从主页面跳转到另一个新页面时，有两种跳转方法(wx.navigateTo和wx.redirectTo)，如果跳转执行navigateTo方法，
此时主页面会执行onHide方法，新页面会依次执行onLoad、onShow、onReady方法。当新页面返回主页面时，这时候新页面会调用onUnload方法，主页面又会调用onShow方法。
如果跳转执行的是的redirectTo方法时，主页面会执行onUnload方法（卸载），新页面会相继执行onLoad、onShow、onReady。这时候不能返回到主页面，因为redirectTo方法是将新页面覆盖原页面，而原页面已被卸载。
这就是小程序页面的生命周期。
应用的生命周期对页面生命周期的影响
UML学习过程中总结的基本内容
UML用例图
用例图的4个基本组件：参与者(Actor)、用例(Use Case)、关系(Relationship)和系统(system)。
泛化(generalization)：
泛化关系是一种继承关系，子用例将继承基用例的所有行为，关系和通信关系，也就是说在任何使用基用例的地方都可以用子用例来代替。泛化关系在用例图中使用空心的箭头表示，箭头方向从子用例指向基用例。
扩展(extend)：
extend关系是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。extend的基用例中将存在一个扩展点，只有当扩展点被激活时，子用例才会被执行。 extend关系在用例图中使用带箭头的虚线表示(在线上标注<
包含(include)：
include为包含关系，当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示(在线上标注<
扩展关系与包含关系
相同点：
- 都是两个用例之间的关系。（只有泛化关系不仅可以表示两个用例，还可以是两个参与者之间）
不同点：
条件性：
- 包含关系是无条件的
- 扩展关系是有条件的
插入原则：
- 包含关系中被包含用例的事件流一定插入到及用例中去。
- 扩展关系可以根据一定条件来决定是否将扩展用例的事件流插入到基用例事件流。
插入点：
- 包含关系中插入点只有一个。
- 扩展关系的插入点可以有多个。
重点区分include和extend，因为十分容易搞混，通过下面的例子进行说明。
这里销户操作必须建立在计算的基础上，这就符合了表示子用例是父用例的一部分，通常强调离开这个特性，父用例无法达成目标或失去意义。具体到这里就是如果子用例结算不存在，那就无法进行销户。
而短信提醒和邮件提醒是可选的功能，符合表示子用例是父用例的可选场景或技术特征。