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         -- 新优化方案             卡顿率 --> 帧率             低端机优化