技术品质目标和路线 2020/10/30
## 技术品质目标和路线 2020/10/30
<style>
table th:nth-of-type(2) { width: 600px; }}
</style>
|关键内容|目标和关键点|第一负责人|第二负责人|
|-|-|-|-|
|目标设定|● 目标：通过对比同品类的头部标杆游戏，确定下面各个内容的具体数据目标；<br>● 要充分研究标杆游戏的各个指标，以及一些关键流程，例如热更包管理机制等；<br>● 某些指标可能需要向外部打听； |阿荣|拉隆|
|数据监测|● 目标1：建立一个集中的、可视化的、可靠的现网版本质量监测系统，能客观准确地反应各项质量指标，能按渠道平台等条件筛选查看，能追溯至少一年以内的版本质量变化，杜绝【凭感觉优化】。<br>● 目标2：躲猫猫和蛇蛇共用；<br>● 需要前端和后端、产品和运营的配合，并且这块工作需要先做起来，让后续的工作有眼睛有耳朵。|阿荣|前端：摩卡<br>后端：宝骡或马克|
|U3D升级|● 目标：确定一个稳健可用的最新的U3D版本，并完成升级，让后续优化工作的上限更高；<br> ● 需要解决XP用户问题； <br>● 需要排除各种兼容性风险，并进行灰度测试；|拉隆|约克|
|帧率和卡顿|● 目标：保证单局内的最低和平均帧率、偶发卡顿的次数达到目标值；<br>● 借助UWA工具和服务；<br> ● 先在Unity 5.6上进行优化，后续根据Unity升级进展再做调整； |白云|杰洛|
|内存和资源|● 目标1：减少大厅和单局的内存使用，让PSS峰值控制在目标值以内；<br>● 目标2：让新内容的加入不会过大影响大厅和单局的内存;<br>● 借助UWA的工具和服务；<br>● 需要梳理各种类型的资源使用和依赖关系，了解工程的整体情况； |摩卡|杰洛|
|热更支持|● 目标1：研究IL2CPP代码更新，让安卓大版本更新不用重新下载apk安装（除非U3D版本再次升级）；<br>● 目标2：支持资源热更，建立热更包版本管理机制；<br>● 目标3：用LUA写单局外新的业务层需求，例如活动等；|约克|拉隆|
|网络和外挂|● 目标：解决外挂问题，尝试用新网络框架替代Photon，并保证操作手感不变；|拉隆|白沙|
|界面加载|● 目标：确保登录、进单局、回大厅以及各个UI界面的加载进入的流畅性达到目标；<br> ● 内存和资源优化、热更功能可能会影响加载时间，需要平衡和取舍；<br> ● 相对后置，可以在以上工作基本完成后再开展； |白云|摩卡|
|崩溃率|● 目标：将安卓和IOS崩溃率降低到目标值以下；<br>通过升级U3D能解决一部分崩溃；<br>通过降低内存能解决一部分崩溃；<br>剩下的还需要想办法排查；<br>相对后置，可以在以上工作基本完成后再持续开展；|约克|拉隆|
## 其它问题
1. 如何一边开发新内容，一边进行优化是个问题。为了降低风险，应该遵守以下原则：
- 优化版本不跟新内容版本（主线版本）同时发出去；
- 优化版本要以非强更的方式，灰度发布出去；
- 优化版本需要一个单独的分支，并需要有一个人或自动化机制将新内容版本持续合并进去；
- 完成灰度测试的优化版本的改动，要合入到主线版本中；
2. 打包时间过长，安卓要30分钟以上，PC也要15分钟；
> 磨刀不误砍柴工，特别是在做优化工作时，因为会涉及到非常多的【修改】-》【验证】-》【修改】的循环，因此迭代的效率对解决问题至关重要。要么需要想办法优化打包速度，要么需要想其它方法，不需要重新打包也能有效地验证改动；
## 时间轴
