h5游戏优化的一点小经验

前言：
    一直都没有写文章随笔的习惯，也是因为在饥人谷学习，强制要求写blog才申请的账号，记录学习的知识点。说来也是可惜，没有把写总结，记录问题的习惯保持下来。
    到现在，工作一年多了，一直在做h5游戏，之前学习前端的东西也好久没有用，都忘了七七八八。工作一年，总感觉自己这半年里都在原地踏步。所以决定开始写blog，记录自己的工作学习历程。输出自己的工作心得之类的，记录一些知识点，以这种方式提醒自己不可偷懒。

对一年工作的一些回忆

    2017.9.14，入职中青宝，做的h5游戏开发工程。也是前端，但是跟前端关系不大，主要是做游戏，h5游戏，用的是egret引擎。那时候，我也是第一次使用egret。那是我egret入门。
    刚入职那会，第一个星球基本就是按照egret官网，将里面的demo全跑一遍。因为那时候对官方文档琢磨的比较多，现在对官方的文档都很熟悉。那时候，还有写日志的入职习惯，部门新入职员工每天写一份工作总结，我那时候还满满写了三个月的工作日志，记录自己学习egret，到使用egret的历程。转正之后就基本没有写了，这也是一个小可惜。每天写一点东西，总结一下每天的工作，反思一下自己的工作状态，这样通过第三方的视角去观察自己，才能更好的发现自己不足之处。用一些大拿的话说，就是将自己的知识输出。在输出的过程中，无形中就复习工作中所运用到的知识点，有利于提高自己。
    再说回工作，那时候在中青宝做的是棋牌项目，也就是麻将，牛牛，斗地主这些。那时候，棋牌非常火，深圳这边工作做棋牌的工作一抓一大把。我在项目里面主要负责维护一个已经开发好麻将项目。那时候，整体开发已经完成，架构也稳定了，我也只需要做一些修修补补的小工作。但是在这个成熟的项目中，还是可以学到很多东西的。我那时候算是比较勤奋，刚工作，热情也比较大。一有空闲时间都在看整个项目的代码，看里面的源码，看底层的架构，学到了很多东西。还是很感谢在中青宝的日子。
    在中青宝，说是做h5，更多的是利用h5的便捷性，迅速完成游戏逻辑开发，然后打包成app和ios。这也是egret的一大优势，一套代码，三端发行，大大提高了开发效率。也是在那时候，我对前端的概念也有了更广泛的认知。所有与用户交互的界面，都可以称之为前端，包括pc端，web端。也是从那开始，入了游戏的坑，出不来了，现在已经完全不会写web界面了。当然，收获就是，熟练掌握了typescript。
    后来，就是离职到了现在工作，继续做h5游戏，继续使用egret。这次就是完全的h5小游戏了，打包成网页小游戏，而不是app。
    在现在公司工作了快一年了，一直都在开发休闲游戏，一直是一个人负责项目，对于egret，游戏也有了更深的认知。首先，开发一款游戏，首先最重要的，就是一个整体架构，对游戏更个部分的划分，这个是很重要，对后期帮助很大。一开始划分不清晰，后面就是改之不尽的bug了，各种各个部分之间的交互，通信，消息出来，各种麻烦。整体框架的思想，就是大而化小，各个部分之间解耦。这样开发起来，效率就会很高了。

h5游戏的优化之路

    在公司开发了几款小游戏之后，满满的，开始处理游戏性能，体验方面的问题，包括游戏资源加载速度，用户交互之类的。最近处理的比较多，颇有些感触，所以，才会有了写一写的想法。这篇blog算是一个开始，写一写学习计划，工作总结之类的东西，对自己进行总结，反思，才能才编程的路上走得更远。

• 1.资源分步加载
      游戏和web界面不同，是有很多动画，图片资源，这部分的体积占了游戏的90%，如何处理好游戏资源的加载，这对游戏的加载速度体验很关键。
      针对游戏的分为各个部分，模块，资源也可以相应的划分为各个组，egret在资源这块处理的很好，提供了RES这个模块进行资源的处理，资源分组。相应的，在游戏中，进行分步加载也变得更加简单。比如，我把游戏资源分为三个组，游戏主场景，比赛场景，以及一些二级弹窗资源，这样划分之后，就可以对资源进行分步加载。一开始进入游戏，只加载主场景资源，提高游戏启动速度，加快进入游戏时间，避免在加载界面停留过长而流失用户。进入游戏之后再进行加载比赛场景和一些二级弹窗。当然，这样做的话，也会有一些弊端，在二级弹窗和比赛资源还没加载完成时，这时进入比赛或者点弹窗，就需要一些处理，等待资源加载完成后再进入，可以采用promis异步，或者添加事件监听。这样会造成一定的体验不好，需要取舍。如果资源整体不大，就无需分步加载。
• 2.对象池
      对一些复用的组件，建立对象池，这是一个很常见的做法，也是最需要做的事情。虽然现在浏览器的性能有了很大提升，但是，对于一低端机型，对象池还是很有必要。建立对象池，对一些重复使用的组件进行回收利用，而不是直接销毁，这对页面性能提升很大。这是因为js的垃圾回收不是及时的，如果在一些密集渲染的情况下，就会出现卡顿，设备发烫的现象出现，影响用户体验。
      比如，我之前做的一个战舰战斗的场景，10艘战舰进行随机发射炮弹，鱼雷和火箭筒，还伴随着爆炸效果动画，轰炸的声音。这么多的图片动画渲染，对设备性能要求是很高的，在一些低端机上，会出现卡顿，发热现象。我统计过，webgl的drawcall达到了300+，这是一个很恐怖的数字，内存的占用也达到了一个恐怖的数字。总之，这是一个糟糕的用户体验。后来，我做了一些处理，写一个对象池，对炮弹进行复用，提升很大，卡顿，发热现象没有了，画面也流畅了，内存占用也大大减少。
• 3.屏幕适配
      针对不同的机型，进行适配一直是件很头疼的事情。市面的手机太多了，各种不同尺寸的屏幕，还有一些刘海屏，全面屏，适配是很麻烦的事情。屏幕适配这块，egret提供一些见简单的适配方案，比如拉伸占满屏幕，按宽度适配，高度适配，缩放保持原宽高比。这些方案都有些不足，会出现图片拉伸变形，黑边等等问题。所以，手机端的适配最好的方法是背景拉伸占满屏幕，而里面的组件就按照相对位置进行摆放。所以，在设置各个组件位置的时候，就必须写相对坐标，而不是绝对坐标，在一开始就解决屏幕适配问题。
      pc端的话，就更加麻烦，所以，我的处理是之间缩放占满屏幕。
• 4.其他一些小坑
      图片资源一定要压缩，能压缩很多。之前美术提供的图片没压缩，一张图片就达到了2M多，几张图片就十几M，这加载速度肯定很慢。压缩之后，只有几十k，速度一下子就上去了。
      对于图片进行合并，这是常规做法，但是需要注意的点是注意合图尺寸，手机端不要超过2048。目前发现在苹果6s和小米黑鲨手机上会出现图片加载黑块的问题。帧动画的合图也是。
      还有就是，写界面时，划分一定要清晰，哪怕多写几个类也要分清楚，这对后期需求变更修改起来方便很多。都知道，需求变更这种事情是很常见的。

定个小目标

    上面算是对自己的一点小总结，一直懒于动手，今天总算是写出来了，算是克服了自己的懒堕。以后要坚持下去，保持每周写篇总结。
    按照惯例，到最后总要给自己定个计划的。学习go也是一直没有动手写代码，一直在看别人的代码，看书，作为码农还是要多动手，所以，为了督促自己的学习进度，给自己定个小目标，利用业余时间多写写go，用go搭建个blog，在年前完成。