小程序----实战lpl赛事直播

5，8，9，10，11，12，13，14，16 差不多10天左右的时间。将小程序完成到4.17号早上可以勉强上线。

期间遇到的问题

1. 获取用户信息并存放在app中，由于是异步的，所以必须写到回掉函数onUidReady确保用户信息已经获取到。 （onUidReady，所有需要用户信息的操作均在此回掉后执行）
2. 由于ios和android 对于new Date()中的字符串格式不一样，android仅支持 '年/月/日 时:分:秒' 格式，导致与时间判断的所有分支均在android上异常。（将所有需要用的时间字符串统一为/分割）
3. 由于用户频繁点击／或其他操作，导致函数被不停的执行，从而出现误差。 （使用throttle函数，将一定时间内的点击或其他事件忽略）
4. 由于微信share触发时，不能在其获取新房间后，将值赋值给path，所以将整体房间的逻辑进行了调整。 （耗时约1天）
5. 其中耗时最长的莫过于，与房间弹幕的连接，由于重连机制，网络终端和手动关闭后再次进入都触发重连机制，所以会出现再次进入房间时，连接到上一次之前的房间弹幕。
6. 由于弹幕库文件的重写（由于自身对此不了解，所以主要是服务端在帮忙修改逻辑），在销毁和创建中由于没有进行合理的处置，所以导致会出现异常。
7. 在创建了DMSrv后，将其赋值给this的一个属性，由于重新进入该页面的时候其this会改变，虽然都是当前页面对象。所以导致在接收到服务端弹幕下发后，虽然将值放到了对应的数组，但此时的数组并非页面渲染的数组。

在后三点的问题中，由于缺少定位问题的经验，并且对弹幕服务的业务不熟，所以一开始仅是一位的引用已有的服务文件，并没有针对这次业务做出正确的更改，导致给自己以及团队埋下了很大坑。

项目本来预计在12开赛的时候上线，由于个人原因，使项目拖到17号才能上线。

反思：

1. 对小程序的页面加载机制，并没有做深入的了解，起码连每次加载都会更换this的道理都不清楚，导致绑定的数据绑定了错的对象。
2. 对弹幕服务的清晰程度，一开始就单纯的认为这个项目我只需要切图，按照ui给的设计稿，完成页面逻辑即可，没有想到自己会涉及更改弹幕服务这边的核心代码。
3. 在做页面逻辑的时候，由于自身代码设计问题，所以在需求逻辑被迫发生变更／需求逻辑变更，导致代码越来庞大，代码越来越难以维护／更改。
4. 代码中的嵌套逻辑，导致单个函数过于庞大，导致查找问题时，变得更困难。将函数简化，使每个函数都有明确的具体功能，这样在出问题的时候可以快速的定位，以便bug的解决。
5. 调试bug的经验不足，导致经常看着打出的日志，对错误原因好无头绪。

经验总结：

1. 创建页面／对象时，this对象的变更，赋值给this的一个属性，去判断其到底是否更改。
2. wx:for等渲染时，框架自动判定为复用。
3. webSocket的使用：创建，连接，断开连接，重连，销毁。

---

4.17更新
在flex布局的scroll-view中，发现ios 10.3.3系统中， flex：1时，其高度并没有正常进行计算，并且无法正常滚动。已提至微信，原因不详，解决方式是使用最最原始的absolute定位替代flex:1自适应高度。