浅谈Android性能优化

一、性能优化六项指标：

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

二、背景 ---- 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

         -- 新优化方案

             卡顿率 --> 帧率

             低端机优化