一对一直播系统源码，怎样设计一个稳定流畅的系统_android process.getstartuptimemillis-CSDN博客

背景

随着日益快速增长的业务，一对一直播系统源码逐渐臃肿，大厂的很多app的卡顿问题一直被用户诟病，而且随着互联网的发展，下沉人群的占有量也在逐渐扩大，保证一对一直播系统源码的体验，帮助业务提速，提高各个业务场景的转化率尤为重要。

前言

启动优化对于开发同学来说，经常会以主观感受衡量，可能经常听到的是’好像变快了、好像变慢了‘；所以需要建立合理的数据指标，通过数据的视角衡量优化过程中的各个优化点的效果。
另外作为技术，在做技术需求的时候不仅关注技术指标，而且需要关注业务指标，我们做这个能给业务带来什么价值。另外启动优化不能过于 KPI 化，要从用户的真实体验出发，要着眼从点击图标到用户可操作的整个过程，首页渲染完后的流畅可操作。

整体设计

整体设计主要包括，后续将拆分多篇文章详解整体内容。

启动框架解决启动依赖、效率等问题；建立启动任务开发规范。
数据指标设定和监控。
AB实验验证优化效果；保障稳定安全上线
各个阶段埋点和日志的采集，保障恶化归因分析问题。

指标设定

技术指标

技术指标通常分为启动到首页渲染完成的耗时。

将整个过程拆分到技术层面可分为进程启动、app创建、首页创建、数据请求、数据渲染

进程创建耗时

进程创建耗时描述的是进程创建的系统时间，通过这个时间可以客观真实的反应用户从点击目标程序的icon到用户进入目标页面可操作的时间。
早前的启动时间往往是从Application.attachBaseContext获取目标进程第一行执行代码的时间，这个时间是一个“不错的程序启动时间”，但是它不够完美，我们希望去获取客观真实的用户体感数据。因此查询了linux相关的资料，发现/proc/slef/stat文件记录进程的一些状态数据。
所以我们可以启动的时候通过异步线程去获取 /proc/slef/stat信息，能真实客观的反应用户的真实体感，能把Zogyte创建子进程及初始化子进程所需的资源的准备时间也能包含进去。 Android 8.+后的设备系统提供了Process.getStartUptimeMillis()，Process.getStartUptimeMillis()的时间是在ActivityThread的第一消息BIND_APPLICATION的时候Process.setStartTimes()设置进去的，有兴趣的同学可以看这一部分的代码，了解写8.+之后ActivityThread的细节上的区别。通过上面的分析，APM的实现在8.-的设备上通过/proc/slef/stat获取进程创建时间，8.+通过Process.getStartUptimeMillis()获取进程时间，通过这个时间点和用户到目标页面的可交互点，两者的间隔生成用户冷启动的时间。
在低版本使用/proc/slef/stat获取进程创建时间发现了大量的脏数据，于是就开始思考新的实现，进程在创建的时候会创建进程相关的内存文件，是否能通过文件创建的时间来确定进程创建的时间，java提供的文件最后一次修改时间file.lastModified()，这个很好的指标，只要找到一个与目标进程相关的文件，并且它在创建之后不在修改，那它是一个很好的时间。那么/proc/slef/stat显然不能满足需求，因为stat涉及到很多进程相关的信息，如io_wait,进程状态等信息，会随着进程的状态变化而变化。很庆幸有/proc/slef/comm这文件存在这进程创建的名称，即进程创建后进程名称开始创建并且不会在被修改。于是新算法将启动时间设置为/proc/slef/comm文件的最后一次修改时间。

数据渲染

由于Android渲染机制，如何定义首页渲染完成。

刚开始我们参考了美团的文章，将数据加载完成后根布局首次drawChild完成定义为渲染完成，但是这种方案有个问题，是数据加载完后还需要异步加载图片，这个时候图片是没有渲染完成的。
后续我们研究，通过开启线程遍历根布局，判断控件真实渲染，通过计算控件的单个面积合成总的渲染面积，超过屏幕面积的80%认为渲染完成。。
- TextView , View、ViewGroup等认为渲染完成
- ImageView判断是BitmapDrawable认为渲染完成

业务指标

业务指标跳失率，首页曝光率、留存等。

AB实验

有了数据指标，我们就需要通过AB实验衡量我们优化的成果，另外因为优化逻辑可能改动很大，需要逐渐放量，保证安全稳定，出问题及时止血。
对于小型公司没有完整的数据平台可以简单将配置中心拿来当AB实验，在所有的数据埋点都带上配置中心分桶的信息。另外对于AB实验，需要保证对照桶和优化桶条件因子一致，放量比例一致。