Android 系统性能优化（11）---UC性能优化方案

       一、性能优化六项指标：

              性能、内存、稳定性、流量、电量、安装包大小；

       二、背景 ---- Android程序卡顿产生原因：

              1、Android系统低效

              --渲染线程、同步接口、广播机制

             ：没有独立的渲染线程

             ：广播机制引入，可能同时又几百个广播机制在后台运行

              2、运行环境恶劣

              --后台进程、安全软件

              3、低端机占比高

               --低内存、弱cpu、IO瓶颈

             ：开源平台，导致高中低端的机型普遍存在；；

             ：低内存影响最大，一般可用内存在小于50M，意味着会由于小于50M就会杀死一些进程来维护内存的大小

             ： GPU是其次；

             ：读写速度比较慢，在有的手机上；

              4、产品考虑不足

               --功能定义简陋、功能堆积严重

             ： 一般的产品只会考虑需求，我要做什么，而并没有把整个闭环考虑清楚；

             ：在版本迭代的过程，在不注意间可能启动过程会越来越慢；

              5、技术考虑不足

              --很多

       三、用户反馈应用卡顿怎么办？

               困难：

              1、复现性

              -- 用户描述模糊、不稳定出现（复现率比较低）；

              2、定位难

              -- 不同机型、固件、系统状态表现不一

              --程序细节多、可疑面广

              3、衡量难

              -- 卡顿严重程度难以量化

              -- 卡顿问题不便分类

             ： 是有一点卡、非常卡、还是什么

             ： 没有针对性的目标，提升百分之多少等等，不知道极限在哪里；

      四、解决思路

             1、卡 vs 顿，卡为主，顿为辅。卡和顿没有一个明显的界限，大部分顿的问题当环境足够恶劣时就会表现为卡。所以抓住卡，就能解决很多问题。 
             2、打点统计 vs 全局监控：

               短期目标：主路径性能保障，打点统计；

               长期目标：整体的卡顿优化，全局监控；
             3、 线下分析 vs 线上监控：

              线下分析：实验室调试去复现一个问题，精确定位、粒度细；

              线上监控：指标衡量、粒度粗。 

             4、打点统计分析：

              （1）、启动速度

              （2）、响应速度

              （3）、版本比对 ： app版本、Android版本

             5、用户反馈分析：

               将用户性能方面的反馈，测试人员进行分析，以邮件形式发送给技术负责人，进行分析；

               反馈等级： 

                 --预警机制

                 --用户分类

                 --功能分类

                 -- 纵向对比

             6、anr日志分析：

              --精确定位 ： 堆栈信息比较清晰 

              --数据量化  

              主线程超时(5s ---> 1s)

              -- 暴漏更多蕾体

              -- 精确定位问题

              -- 方便用户联调

              -- 如果一个按钮响应时间超过800ms，用户感知起来就会很难受了。

             7、全局监控 -- Looper Hook

             -- 监测系统消息循环

             --计算消息耗时

             -- 定位耗时点

             卡顿：无非就是主线程被卡住了，就是主线程的消息循环里面的某一帧执行时间非常长，导致后续的消息无法来得及执行，

             数据指标卡顿率： 卡顿用户数/日活总数

             8、 问题回顾：

             -- 下载界面展开卡顿： 分段加载

             -- 二维码界面展示慢： 延时加载、先出界面在初始化相机

             -- 启动完成后操作卡： 线程枪战，低优先级后台进程+队列

             -- 共享存储卡顿： sharedPerference（ 主线程IO ， commit(主) ---> apply(子)）

             -- 视频播放控制卡顿（API兼容性问题，异步化，视频播放停止暂停线程）

             -- 获取网络代理卡顿（IPC异常【进程间通信】，异步DNS+缓存）

             -- 第三方反馈卡死（固件问题，shield Activity，全部采用一个新的activity去做，这样不会对原来activity产生影响）

             --  网页滑屏操作卡顿（GPU加速 开启硬件加速）

             -- So加载/jni注册卡（异步加载 + 时序控制）

             -- 安全软件事件拦截（沟通反馈）

           --微信卡顿（调频、文件系统优化）

      五、经验推广：

         禁止：

         -- 主线程文件IO(标记文件读写外)

         -- 主线程耗CPU操作

         -- 主线程同步IPC调用（时间不可预期）

         推荐：

         -- 异步化

            【1】、 产品及程序设计 : 加载肯定是需要时间的，不可能实时展现；

            【2】、预加载 （数据必备，功能执行之前将这些事先数据准备好）

            【3】、闲时加载： 利用cpu的闲时做一些事情，主线程会设置一个ido handler，主线程所有消息操作完成之后会回调一个handler

            【4】、按需加载

         -- 线程管理

             1、线程量限制 + 任务队列

             2、非主线程优先级调低

         --压力测试

         -- 防御式编程

         -- 全局性能检测

     六、延伸

         -- 精确化 & 自动化

            用户反馈、卡顿日志

         -- 新监控方案

             Api Hook

         -- 新优化方案

             卡顿率 --> 帧率

             低端机优化