二次渲染，暂不支持
- 暂时用预设的 template 嵌套方案，后面几期做支持
crash 监控，版本回滚机制
- 后续支持脚本错误，crash 信息，可能在 appjs 里捕获这些信息；
- 回滚暂时还是需要审核，应用发安卓市场还是 appstore 也都存在这个问题，质量把控，平台做再多的事情可能也不如开发者做得更好一些。
缓存在文件的数据防篡改
- 底层机制：文件存放微信应用数据中，且每个小程序相互隔离；
- 保证了其他应用无法访问微信应用数据（除非root或越狱），小程序间无法互相篡改和访问
小程序的生命周期
- 小程序存活在微信的运行环境，
- 被销毁的情况一种情况是用户长时间没有操作，
- 还有一种是基于内存管理，如果用户开启更多的小程序，之前的小程序就可能被结束生命周期
c端用户进入小程序的方式
- 十二月初确定，会有一个固定的入口，会有一些分享的能力，后期慢慢会有发现的能力
（新金融研发）提交审核版本时候设置标签的限制。如何快速通过审核，如何更好的设置标签
- 功能页面和标签、类目的设置一致，千万不要些和功能类目无关的标签（比如业务是外卖，就把点评、美团都堆砌上去）；
- 站在c端用户的角度去理解自己的产品，思考用户会使用哪些词来描述这个产品，标签的作用就是用户和小程序之间连接的桥梁
车险业务，能够提供什么样级别的用户分群的状况，比如说车险是不是能支持到微信用户是否车主？微信大概会拿出什么样的资源和大家一块做，这个可能会影响到业务方决定投入多少到这里面
- 数据这一块，用户画像会开放的比较慢，至多会提供一个群组，比如这一组人是什么标签，不会在用户没有授权的情况下透露用户的信息，这也是微信一只不敢做的事情；
- 在自己的阅历范围内，还没见过微信这么卖力的做一件事情，它会整合各个 BG（事业部） 资源，至少龙哥态度上是很支持这件事情的，会有每周一到两次的例会，具体来说：固定的入口，分享的能力，后面每件事情会比较谨慎，应该不会是爆发性的资源介入，而是一个过程，至于是怎么给，也只能说拭目以待。
教育类产品，每天推送模版消息让用户点击参与，希望将学习部分的功能迁移到小程序，但是小程序不支持主动推送
- 小程序本身对媒体类的服务不排斥，但是比较轻的媒体，还是建议做服务号，如果现有体系已经能够很好的满足。
- 小程序的目的是。公众号和小程序形态上是比较独立的，需要企业根据服务情况和偏好决定采用哪种，不会有强关联。
账号体系打通
- unionid
实名信息，活体识别、视屏验证
- 实名信息不会提供；可考虑使用视屏组件，截某几帧内容传到后台识别。如果现有能力不能够支持可以提需求。
保险营销很多是场景式嵌入，h5 嵌入到各个页面，但小程序是相互独立的
- 点对点合作，可能可以跳转限定数量的页面活小程序，已经提上日程，但要在小程序开放后的一段时间，预计是明年2、3月份
平安产险业务，1 车险每年快到期前三个月如何发提醒 2 模版消息发送 3 是否可以带参数 4 可否从公众号跳转小程序
- 前期不会放开公众号跳小程序；
- 独立的模版消息和公众号不太一样，不需要关注，只和是否页面互动有关；
- 一年后是否可发消息，暂无法预测；
- 参数可通过二维码传入
面向c端的入口什么时候开放；微信公众号和小程序之间的关系
- 个人觉得十二月份应该要落地，但还取决于客观因素，希望在发布是能囤积一些优秀案例；
- 关系和差别：
- 龙哥之所以要做这件事，是因为觉得服务号没有把服务这件事做好，希望通过这套技术架构能够有个约束，真正做一些好的东西出来；
- 消息类，媒体这类消息类的东西还是适合在，页面形式的交互，还是适合在小程序上完成，后续会把以页面为主，消息为辅的功能在小程序这边做的更好些。
绑定体验者的账号也要求绑卡，不方便测试；自定义”返回“按钮动作
- 策略存在不合理的地方，后续考虑优化；
- 会考虑
（泰康在线）是否提供查询搜索关键字热词的接口，以便产品优化
- 暂无计划，需要和搜索同事了解下。
提交审核时，走测试流程问题，保险产品购买受监管，重复购买会引起有关部门注意
- 待研究
小程序模版消息发到哪里
- 对话界面“服务通知”，不是以账号维度发送
1M 尺寸的限制
- 几个方面：
- 小程序在移动网络中使用，希望做成轻量
- 目前看复杂的应用足够满足，图片资源用 cdn 纯文本 1M 是足够的
是否需要做设备适配
- 不需要
是否会对小程序做推荐，比如提供分类排名
- 不会做推荐，分类排名还没有定
向日葵保险，是否支持多任务；是否可接入别的支付
- 支持多任务，可以切回聊天，小程序会在后台运行，按照堆栈顺序关闭使用频率最低的；
- 不会
