支付宝很卡怎么处理,支付宝很慢很卡怎么回事

那么虚拟内存的使用应该如何度量呢？简单的方式是直接从/proc/{pid}/status文件读取vmsize数据，但如果要做到能感知线上内存水位变化并快速定位问题还需要更细粒度的分类。如上图所示，通过对/proc/{pid}/maps地址文件的内存分配标记进行分类可量化成20 个细粒度内存指标，在支付宝启动后的内存空间分析中可以看到在支付宝启动后留给业务的内存空间大概在1-2G左右，如果没有有效的内存监控释放手段，随着应用使用时长的增加，内存地址空间会被迅速耗尽。下面会介绍线上主要的几个内存监控方式。

基于虚拟内存的水位监控主要作用是感知活动或者开关变更导致的内存上涨，同时能确定业务维度的内存水位变化，通过制定告警阈值，让线上问题定位达到分钟级别。

大促活动期间首页氛围图或腰封上线lottie动图引起的Libcmalloc上涨约涨20-50M，导致OOM闪退率上涨30%，相比业务上线活动首页氛围和腰封的变更影响是全局的基础水位，对OOM闪退率影响较大。下图为某次活动0点发布氛围后支付宝整体内存水位上涨40M。针对这一问题我们对所有lottie上线资源做了动态的内存检测，超过阈值则被禁止上线，同时通过线下的内存检测结果可预估lottie上线后对线上闪退率的影响

0点活动上线内存水位上涨

线上闪退率预估

随着渲染技术迭代新春五福，双11活动的页面动画特效复杂度越来越高，已经不再局限于2D动画，并且活动页会为支付宝内其他业务引流，当用户不断跳转页面访问时内存可能不会及时释放，导致短时间的内存叠加效应引起内存水位升高同时OOM闪退率上涨。针对这一问题，支付宝活动都会针对渲染特效设计几种降级方式，在内存水位变化幅度超过阈值或OOM闪退率上涨情况下可以对业务进行统一降级，动画->静态图，3D->2D等

Dexpatch发布引起的端整体Public-File水位上涨50M左右，由于Dexpatch本身的实现方式要在native解包和替换，导致mmap了大量内存，目前在32位包已经不再使用Dexpatch热修复。下图是线下测试结果：

uc压缩内核推动动态bundle，通过用户日志可以发现so解压后出现错误，导致用户重复进行初始化进而导致Public-Files内存上涨后触发OOM闪退。在推送回滚后，整体崩溃率下降。

蚂蚁庄园3周年活动，生活号文章插入超大gif动图导致GPU增幅超过300M引起线上OOM闪退告警，暴露了目前对于h5/小程序中的大图、视频和动图没有提前发现的能力。基于这个问题在对业务准入的时候增加图片视频的静态尺寸检测和动态内存检测，避免类似问题再次发生。