Android 卡慢监控组件简介

   <h3><strong>1. 功能简介：</strong></h3>    <p>• Android卡慢监控组件，用于监控app在整个使用过程中出现的界面卡顿现象，尝试还原其中的调用堆栈信息，追踪代码来源；<br> • 以堆栈信息的形式体现出来，附加了CPU使用率做参考；<br> • 上报到统计平台，进行聚合排名 。</p>    <h3><strong>2. 监控原理：</strong></h3>    <p><strong>第一步：</strong></p>    <p>• 利用Looper.getMainLooper().setMessageLogging() 接口；<br> • Looper源码如下：</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/76022d80de465c2002d4ae38245b2831.jpg"></p>    <p>重载println方法 ，可以统计出dispatchMessage的执行耗时情况。</p>    <p><strong>第二步：</strong></p>    <p>使用子线程定期抓取主线程的堆栈调用（图片中展示了3个消息执行，子线程产生了5次调用堆栈的抓取）。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/6915e083e8c2e6b6dacfd48a7016f65c.jpg"></p>    <p><strong>第三步： </strong></p>    <p>主线程消息执行耗时长的情况发生时，关联出该时间段的主线程调用堆栈信息。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/a4d51e642a91f446dae93606a6d893fb.jpg"></p>    <p>从上图可以看出：</p>    <p>1. CPU的信息采集，包括的整个手机的CPU使用率，和自身app的使用率，用于鉴别是否发生其它app抢占CPU使用的情况。</p>    <p>2. T1和T2细分为线程时间和真实时间，用于鉴别是否该线程真的执行慢，还是该线程得不到CPU执行，被其它线程抢占。</p>    <p>3. 查看每次采集的时间点，是否发生过自身监控线程也卡住的情况。</p>    <p><strong>第四步：</strong></p>    <p>上报关联出的堆栈信息，汇总到后台进行信息聚合和top排名，上报的样本越多，top排名的真实度越高，越能反映出用户的真实卡慢情况；在上报用户非常大的情况下，一次3秒耗时的消息被监控到的上报数量，理论上是1秒耗时的消息的上报数量的3倍，耗时越长，数量越排前。</p>    <h3><strong>3. 监控策略：</strong></h3>    <p>• 开发阶段自动化测试；<br> • 灰度用户全部监控；<br> • 正式版本小范围监控，下发开关控制。</p>    <h3><strong>4. 统计平台信息展示：</strong></h3>    <p>包含时间，堆栈的第一行聚合，版本，次数，用户量等基本信息：</p>    <p><img src="https://simg.open-open.com/show/4a9734d63962db20a89bed154314dcbd.jpg"></p>    <h3><strong>5. 卡慢问题分析和解决：</strong></h3>    <p>问题主要集中在以下几块：</p>    <p>• 主线程进行文件I/O读写<br> – Sharepreference<br> – SQL操作<br> – File(image/config)<br> • 同步锁等待<br> • 布局太复杂， 加载过慢<br> • 算法逻辑执行太慢<br> • 跨进程等待<br> • 程序之外的其它卡慢因素影响<br> – 子进程抢占CPU和I/O<br> – 其它app抢占CPU和I/O</p>    <p><strong>解决办法：</strong></p>    <p>• 降低I/O次数，异步写，读取看情况异步<br> • 内存操作锁和文件操作锁分开<br> • 布局拆分，分段加载<br> • 重构逻辑/算法<br> • 异步化线程处理<br> • 避免重复获取，做好内存缓存</p>    <h3><strong>6. 组件的缺陷：</strong></h3>    <p>• 单个用户的定位不太精确；</p>    <p>• 单次监控触发的堆栈采集， 可能不是真实的问题所在，依赖后台的信息聚合；</p>    <p>• 但如果一次卡慢关联到2次堆栈信息（消息执行的时间是堆栈采集间隔的2倍以上），并且堆栈一致，就可以定位到该处堆栈是问题所在；</p>    <p>• 监控本身存在一定的性能消耗；</p>    <p>• 获取堆栈调用情况，获取CPU使用率，时间打印等，监控组件需要消耗5%以上CPU资源，视监控间隔而定，间隔越短，CPU使用率越高。</p>    <h3><strong>7. 总结：</strong></h3>    <p>该组件是一个巧妙利用卡慢时间关联出抓取堆栈，并由后台进行聚合的概率统计手法，问题以调用堆栈的信息展示，也是最快的定位手段。组件刚投入项目中就显著的发现大量问题，并有效解决，收益高。公司内产品：QQ音乐、全民K歌、天天P图、画报、企鹅电竞，已接入该监控组件，显著优化了界面卡慢问题。</p>    <p> </p>    <p>来自：http://mp.weixin.qq.com/s?__biz=MzI1MTA1MzM2Nw==&mid=2649796870&idx=1&sn=fd911850e32dd955316664c8c4104946&chksm=f1fcc55ec68b4c4865fd7466cc21f5e0b72080a034757613678cd011162858561310513834af&scene=0</p>    <p> </p>