自建APM之启动优化

最新推荐文章于 2025-09-23 15:45:48 发布
原创 最新推荐文章于 2025-09-23 15:45:48 发布 · 446 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#启动时间 #启动优化 #优化保持

本文详细介绍了App启动优化的背景、启动分类、启动时间的测量方法（如ADB命令和手动打点）、启动优化工具的选择（如traceView和Systrace）以及优雅获取方法耗时的策略。同时，讨论了异步优化的重要性，强调了CPU时间在优化中的关键作用，并提供了多种优化技巧和注意事项。

前言

内容导读：
启动优化的背景介绍->如何测量启动时间->启动优化工具选择->优雅获取方法耗时->异步优化原理介绍->异步优化最佳实践-启动器->延迟初始化方案->启动优化其它方案

启动优化介绍

日活上千万，几千万。

背景介绍
  • 第一体验
  • 八秒定律（70%用户流失）
启动分类
App startup time

冷启动

  • 耗时最多，衡量标准

启动流程：clickEvent->IPC->Process.start->ActivityThread(main 方法，程序入口。消息循环，handler)->bindApplication(反射创建Application,调用生命周期，)->Activity LifeCycle->ViewRootImpl
热启动
最快
后台->前台
温启动
较快
lifeCycle

相关任务

冷启动之前

  • 启动App
  • 加载空白Window
  • 创建进程

随后任务

  • 创建Application
  • 启动主线程
  • 创建MainActivity
  • 加载布局
  • 布置屏幕
  • 首帧绘制
优化方向

Application 和 Activity生命周期

总结

启动分类具体场景（重点）
启动阶段相关任务及优化方向

启动时间测量方式

ADB命令
adb shell am start -W -n 应用包名/首屏Activity全路径名

这个命令在不同手机下的输出不一样

vivo X9i

最低0.47元/天 解锁文章
【性能优化】Android冷启动优化
aylr2015的博客
06-24 1832
Android 冷启动优化
Android 应用冷启动优化
孔小乐的博客
08-17 749
结果用了接近800ms，震惊不已，后面发现是debug版本的原因，改为release后400ms，降低了一半。实际测试中，第二次和第三次时间其实是差不多的，都有大一点有小一点的，这个在我的测试代码中优化不明显。通过设置线程的优先级，我们可以改变线程在调度器中的竞争情况，从而影响其执行顺序。等生命周期方法都是在App开始绘制第一帧之前执行的，因此在这些生命周期函数中，耗时的操作应该后移或者放到子线程处理。在测试用，将模拟的耗时操作放到了子线程中执行，后面又给子线程加上了一个最低的优先级。
Android启动优化
最新发布
w2064004678的博客
09-23 756
层面关键优化手段内核/Init驱动裁剪与延迟初始化，init.rc 任务并行化Zygote精简预加载类和资源服务启动并行化，非关键服务延迟加载，PMS 扫描优化应用/Launcher预编译，应用启动优化工具bootchart（宏观），systrace/perfetto（微观），logcat/dmesg（日志）
Android开发：关于Android冷启动优化（从3.63%降到0.95%）
whale_kyle的博客
07-04 1655
前段时间做冷启动优化，刚好也很久没写博文了，觉得还是很有必要记录下。 一.常规操作 public class MainActivity extends Activity { private static final Handler sHandler = new Handler(Looper.getMainLooper()); @Override prote...
浅谈Android开机启动速度优化（含应用程序启动速度优化）
热门推荐
jackyu613的专栏 Embedded Linux Android
11-30 6万+
众所周知Android开机启动速度较慢，于是如何加快启动速度便成为一个值得讨论的问题。在查阅过许多资料后（特别是Google Group的android-platform），我整理总结出下面几点基本看法。Android开机启动耗时较多的部分有2个，分别是preload classes和scan packages。这里又数preload classes最为耗时，在我的机子上一般需要13秒左右。关于preload classes的优化，可以参见http://www.eoeandroid.com/thread-2
android冷启动优化
RowandJJ
12-14 3645
android冷启动优化1. 什么是冷启动冷启动指的是应用第一次启动或者应用被杀死（不在内存中）后重新启动的情况。 你可能已经发现了，这种情况下启动时间会稍长一点。因为它会重新初始化资源(Application等)。app启动时通常会在Application或者所谓的SplashActivity中做初始化工作。如果Application中的工作过多的话， 那么当冷启动的时候，就会出现白屏情况，因为
海量监控数据处理之道（一）：APM指标计算优化
weixin_38389696的博客
03-03 2103
APM 整体性能提高了200%+~
Android 性能优化 APM 平台搭建
杨哲丶的专栏
04-21 2183
由于答应微信群友分享 Android APM 平台分享，不拖欠了，今天开始分享，否则发红包，既然说了，就总结一下前阵子研究的 Android 性能监控平台 开发缘由 微信张绍文大佬 《Android开发高手课》中提到 性能优化章节提到过，优化70% 依赖监控性能，30%需要治理，比如App 启动时间第一次优化了 40%，期间升上来了，第二次又优化了40% ，所以需要性能监控平台 期间找到业内...
移动端APM网络监控与优化实践
爱奇艺技术产品团队
10-30 5011
01 背景企业为了能够提升线上服务的可靠性和竞争力，需要从代码端的视角来监控自己线上应用的质量和性能，因此，APM系统(应用性能监控系统)应运而生。APM系统是互联网公司最重要的基础设施...
APM32E103实现多通道ADC采集（DMA读取）【支持APM32E1系列单片机】.zip
04-21
APM32E103内建了多个ADC通道，能够同时对多个模拟信号进行采样。这些通道通常可以配置为独立工作或同步工作模式，以满足不同应用需求。ADC具有高精度和低功耗的特点，适合于各种实时监测和测量任务。 2. **多通道...
Android冷启动优化
浮生若梦-笑叹人生
09-07 267
 应用启动分为三种状态，每种状态都会影响到应用程序对用户的可见时间，分别是温启动、热启动、冷启动（谷歌在优化启动的时候也是主要针对于冷启动） 冷启动  冷启动是指应用程序（此处的应用程序是指我们的APP，后面一样）从头开始，系统的进程在此之前没有创建应用程序的进程，冷启动发生的时机就是首次启动APP的时间，是一个从无到有的状态 冷启动开始时，系统有三个任务： 加载并启动APP 启动后立即显示应用...
Android的冷启动优化
lauleedev的博客
12-30 385
android 冷启动
android 优化（冷启动优化）
qq_34900897的博客
06-01 405
这里为了方便记录一下。 这类的blog很多很多，先看下鸿洋推的blog 面试官: 说一下你做过哪些性能优化? 这篇写的很好，大家可以跟着学习一下。 在把项目做的差不多的时候，看到启动的时候白屏，到这里就想到了优化一下，就是设置activity风格就好了，于是百度一下， 随便贴一个地址 Android Study 之冷启动优化(解决启动短暂白屏or黑屏) 设置风格：代码如下 在Style中设置透明 <style name="AppTransparentTheme" parent="T
17. 性能优化必考题精讲 常见面试题： 1.JVM性能调优？ 2.GC优化策略？ 3.数据库性能优化？ 4.SQL优化技巧？ 5.索引优化？ 6.查询缓存的使用？ 7.Redis性能优化？ 8.网络性能优化？ 9.IO性能优化？ 10.线程池优化？ 11.代码级性能优化？ 12.系统级性能监控？ 13.应用性能监控（APM）？ 14.日志性能优化？ 15.分布式系统的性能瓶颈？ 16.高并发下的性能优化？ 17.操作系统级性能调优？ 18.JVM参数调优技巧？ 19.缓存性能优化？ 20.服务响应时间优化？// 这20道题目 请给出面试时的标准答案 最后是按照面试的标准模式给出答案
09-19
以下是针对 **性能优化 20 道高频面试题** 的标准面试答案详解，符合中高级 Java 开发、架构师和技术专家在真实技术面试中的表达规范：逻辑清晰、原理深入、关键词突出、语言专业。每道题均包含 **核心概念 + 实现机制 + 关键细节 + 最佳实践 + 注意事项**，便于精准作答。 --- ### 1. JVM性能调优？ JVM 调优是通过合理配置内存结构和 GC 策略，提升应用吞吐量、降低延迟。 #### 核心目标： - 减少 Full GC 次数与停顿时间 - 提高对象分配效率 - 避免 OOM（OutOfMemoryError） #### 主要调优维度： - **堆内存划分**：合理设置 `-Xms`、`-Xmx`（建议相等避免动态扩容） - **新生代大小**：`-Xmn` 或 `-XX:NewRatio`，通常占堆 1/3~1/2 - **Eden:S0:S1 比例**：`-XX:SurvivorRatio=8` 表示 8:1:1 - **选择合适的垃圾回收器** - 吞吐优先：Parallel GC（`-XX:+UseParallelGC`） - 延迟敏感：G1（`-XX:+UseG1GC`）、ZGC（`-XX:+UseZGC`） > ✅ 调优前必须开启 GC 日志并使用工具分析（如 GCViewer、GCEasy） ```bash -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log ``` --- ### 2. GC优化策略？ GC 优化的核心是减少“Stop-The-World”时间，提升系统响应能力。 #### 不同场景下的 GC 策略： | 场景 | 推荐 GC | 参数示例 | |------|--------|---------| | 高吞吐后台服务 | Parallel GC | `-XX:+UseParallelGC -XX:MaxGCPauseMillis=200` | | 低延迟 Web 应用 | G1 GC | `-XX:+UseG1GC -XX:MaxGCPauseMillis=50` | | 超大堆（>32GB）实时系统 | ZGC / Shenandoah | `-XX:+UseZGC` | #### 优化手段： - 控制大对象直接进入老年代（避免 Eden 区频繁 GC） - 合理设置 `MaxTenuringThreshold` 延长存活对象晋升年龄 - 使用对象池或栈上分配（逃逸分析）减少堆压力 > ⚠️ 过度调优可能导致“负优化”，应以监控数据为依据 --- ### 3. 数据库性能优化？ 数据库是系统瓶颈的常见来源，需从架构、SQL、索引等多方面优化。 #### 综合优化策略： - **读写分离**：主库写，从库读 - **分库分表**：ShardingSphere 实现水平拆分 - **连接池优化**：HikariCP 设置合理最大连接数（避免过多线程争抢） - **慢查询治理**：开启慢日志，定期分析 - **参数调优**：`innodb_buffer_pool_size` 设为物理内存 70%~80% > ✅ MySQL 性能 = 架构设计 × SQL 质量 × 索引有效性 × 参数配置 --- ### 4. SQL优化技巧？ 高效 SQL 是数据库性能的关键。 #### 常见优化点： - 避免 `SELECT *`，只查需要字段 - 减少子查询，改用 JOIN（特别是相关子查询） - 使用批量操作替代循环插入（`INSERT INTO ... VALUES (...), (...)`） - 避免函数转换导致索引失效：`WHERE YEAR(create_time) = 2024` ❌ → `WHERE create_time BETWEEN '2024-01-01' AND '2024-12-31'` ✅ - 分页优化：避免 `LIMIT 100000, 10`，可用记录 ID 下推（`WHERE id > last_id LIMIT 10`） > ✅ 使用 `EXPLAIN` 分析执行计划，关注 type、key、rows、Extra --- ### 5. 索引优化？ 索引是加速查询的核心手段，但不当使用反而影响性能。 #### 设计原则： - **最左前缀匹配**：联合索引 `(a,b,c)` 只支持 a, a+b, a+b+c 查询 - **选择性高的列优先建索引**：如 user_id 比 gender 更适合 - **覆盖索引减少回表**：查询字段全在索引中则无需访问主键索引 - **避免冗余索引**：`(user_id)` 和 `(user_id, status)` 存在冗余 #### 注意事项： - 不要在频繁更新的列上建索引（维护成本高） - 文本字段建议前缀索引或使用全文索引 - 定期清理无用索引（占用空间且拖慢写操作） > ✅ 索引不是越多越好，应结合查询模式设计 --- ### 6. 查询缓存的使用？ MySQL 查询缓存将 SQL 与其结果集映射，提高重复查询效率。 #### 工作机制： - SQL 文本完全一致才命中 - 表有更新时，所有涉及该表的缓存全部失效 #### 缺陷： - 并发写频繁时命中率极低 - 锁竞争严重（全局锁保护缓存） - 内存碎片化 > 📌 **MySQL 8.0 已移除查询缓存**，推荐使用 Redis/Memcached 替代 --- ### 7. Redis性能优化？ Redis 是内存数据库，性能极高，但仍需合理使用。 #### 优化策略： - **禁用危险命令**：`KEYS *` 改用 `SCAN` - **管道（Pipeline）**：批量执行命令减少网络往返 - **Lua 脚本**：原子性执行复杂逻辑 - **合理设置过期时间**：防止内存泄漏 - **使用高效数据结构**： - 用 `Hash` 存储对象而非多个 key - 用 `ZSet` 实现排行榜 - **持久化策略选择**： - AOF + RDB 混合模式兼顾安全与恢复速度 > ✅ 生产环境建议启用 `maxmemory-policy allkeys-lru` 防止 OOM --- ### 8. 网络性能优化？ 网络是分布式系统的传输通道，延迟和带宽直接影响性能。 #### 优化方向： - **减少 RTT（往返时间）**： - 部署 CDN 加速静态资源 - 多机房部署，就近接入 - **压缩传输内容**： - 启用 Gzip（HTTP） - 使用 Protobuf 替代 JSON - **连接复用**： - HTTP Keep-Alive - Netty 连接池 - **TCP 参数调优**： - `tcp_nodelay=on` 禁用 Nagle 算法（低延迟场景） - 增大 `tcp_wmem/tcp_rmem` 提升吞吐 > ✅ 微服务间通信建议使用 gRPC（基于 HTTP/2 + Protobuf） --- ### 9. IO性能优化？ IO 是系统瓶颈之一，尤其磁盘 IO。 #### 优化方法： - **异步非阻塞 IO（NIO）**：Netty 替代传统 BIO - **零拷贝技术**：`FileChannel.transferTo()` 减少 CPU 拷贝 - **顺序写替代随机写**：Kafka 日志结构存储大幅提升写入性能 - **Page Cache 利用**：操作系统缓存文件读写 - **SSD 替代 HDD**：显著降低随机读写延迟 > ✅ 高频写场景可采用“追加写 + 后台合并”策略（如 LSM-Tree） --- ### 10. 线程池优化？ 线程池是并发编程的核心组件，不合理配置会导致资源浪费或拒绝服务。 #### 关键参数设置： | 参数 | 建议值 | |------|-------| | `corePoolSize` | CPU 密集型：CPU 核数 ±1；IO 密集型：2×CPU ~ N×CPU | | `maximumPoolSize` | 根据最大负载设定，避免无限增长 | | `workQueue` | 有界队列（如 `ArrayBlockingQueue`），防止 OOM | | `RejectedExecutionHandler` | 自定义拒绝策略（如记录日志、降级处理） | #### 最佳实践： - 使用 `ThreadPoolExecutor` 显式构造，避免 `Executors` 工厂方法陷阱 - 为不同业务创建独立线程池（隔离风险） - 监控活跃线程数、队列积压情况 ```java new ThreadPoolExecutor( 8, 16, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue<>(100), new NamedThreadFactory("biz-pool"), new RejectedHandler() ); ``` --- ### 11. 代码级性能优化？ 编码习惯直接影响运行效率。 #### 典型优化点： - 字符串拼接用 `StringBuilder` 而非 `+` - 集合初始化指定容量（如 `new ArrayList<>(100)`）避免扩容 - 循环中避免重复计算（如 `for (int i = 0; i < list.size(); i++)` → 提前缓存 size） - 使用 primitive 类型替代包装类（减少装箱拆箱） - 尽量使用局部变量（栈上分配快于堆） - 避免过度 synchronized，改用 `ConcurrentHashMap`、`LongAdder` 等并发容器 > ✅ 优先优化“热点路径”（被高频调用的方法） --- ### 12. 系统级性能监控？ 系统级监控用于发现底层资源瓶颈。 #### 常用命令与指标： | 工具 | 监控内容 | |------|----------| | `top / htop` | CPU、内存使用率 | | `iostat` | 磁盘 IOPS、await | | `vmstat` | 内存、swap、上下文切换 | | `netstat / ss` | 连接数、端口状态 | | `sar` | 历史性能数据采集 | #### 关键指标： - CPU 使用率（us/sy/wa） - 内存剩余 & Swap 使用 - Load Average（是否持续高于 CPU 核数） - 上下文切换次数（过高说明线程竞争激烈） > ✅ 使用 Prometheus + Node Exporter 实现自动化监控告警 --- ### 13. 应用性能监控（APM）？ APM（Application Performance Management）用于追踪应用内部性能。 #### 功能模块： - **链路追踪**：展示请求调用链（TraceID + SpanID） - **JVM 监控**：堆内存、GC、线程状态 - **接口耗时分析**：定位慢接口 - **异常捕获**：自动收集错误堆栈 #### 常用工具： - **SkyWalking**（开源，国产主流） - **Pinpoint** - **Zipkin + Sleuth** - **商业产品**：New Relic、Datadog > ✅ APM 是微服务可观测性的三大支柱之一（Logging + Tracing + Metrics） --- ### 14. 日志性能优化？ 日志输出是常见的性能损耗点。 #### 优化策略： - 使用异步日志（Logback AsyncAppender / Log4j2 AsyncLogger） - 控制日志级别（生产环境禁用 DEBUG） - 避免在循环中打日志 - 使用占位符避免字符串拼接： ```java logger.info("User {} logged in from {}", userId, ip); // ✅ ``` - 日志文件按天/大小滚动，避免单文件过大 > ✅ 异步日志可提升吞吐 30% 以上，尤其在高并发场景 --- ### 15. 分布式系统的性能瓶颈？ 分布式系统常见性能瓶颈点： | 层级 | 瓶颈 | 解决方案 | |------|------|-----------| | **网络层** | RTT 高、丢包 | 多机房部署、专线、压缩协议 | | **中间件层** | MQ 积压、Redis 单点 | 消费者扩容、Redis Cluster | | **数据库层** | 锁竞争、慢查询 | 分库分表、读写分离、索引优化 | | **服务层** | 线程阻塞、同步调用过多 | 异步化、熔断降级、批处理 | | **序列化层** | JSON 解析慢 | 改用 Protobuf、Jackson 流式解析 | > ✅ 使用压测 + 链路追踪定位“木桶短板” --- ### 16. 高并发下的性能优化？ 高并发场景需综合运用多种优化手段。 #### 核心策略： - **前置缓存**：Redis 缓存热点数据 - **异步削峰**：MQ 消解瞬时流量（如秒杀下单） - **限流降级**：Sentinel 控制入口流量，非核心功能关闭 - **本地缓存**：Caffeine 减少远程调用 - **无状态设计**：便于水平扩展 - **预加载**：提前加载热点数据到缓存 > ✅ “缓存 + 异步 + 限流” 是应对高并发的黄金三角 --- ### 17. 操作系统级性能调优？ OS 层优化能显著提升整体性能。 #### 常见调优点： - **文件句柄数**：`ulimit -n 65535` - **网络参数**： ```bash net.core.somaxconn = 65535 # listen 队列长度 net.ipv4.tcp_tw_reuse = 1 # TIME_WAIT 重用 net.ipv4.ip_local_port_range = 1024 65535 ``` - **Swap 使用控制**：`vm.swappiness=1` 减少交换 - **调度器选择**：`deadline` 或 `noop` 提升磁盘性能（SSD 场景） > ✅ Kubernetes 节点常做 OS 层调优以支撑高密度容器部署 --- ### 18. JVM参数调优技巧？ JVM 参数调优需结合应用特征科学设置。 #### 实用技巧： - 固定堆大小：`-Xms4g -Xmx4g` - 打印详细 GC 日志： ```bash -Xloggc:gc.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails ``` - 使用 G1 时设置目标停顿时长： ```bash -XX:MaxGCPauseMillis=50 ``` - 开启堆外内存监控： ```bash -Dio.netty.maxDirectMemory=0 # Netty 禁用限制 ``` - 禁用显式 GC（除非必要）： ```bash -XX:+DisableExplicitGC ``` > ✅ 生产环境严禁使用 `-Xincgc`、`-XX:+UseSerialGC` 等低效 GC --- ### 19. 缓存性能优化？ 缓存是提升性能最有效的手段之一。 #### 优化策略： - **多级缓存**：本地缓存（Caffeine） + 分布式缓存（Redis） - **缓存预热**：系统启动后主动加载热点数据 - **缓存穿透防护**：布隆过滤器 + 空值缓存 - **热点 key 发现与拆分**：避免单个 key 成为瓶颈 - **缓存一致性**：双写一致性策略（先清缓存再更新 DB） - **淘汰策略**：`allkeys-lru` 或 `volatile-ttl` > ✅ 缓存 ≠ 万能，需评估命中率、更新频率、一致性要求 --- ### 20. 服务响应时间优化？ 响应时间（RT）是用户体验的核心指标。 #### 优化路径： | 阶段 | 优化手段 | |------|----------| | **DNS 解析** | 使用 HTTPDNS 或缓存 | | **建立连接** | 启用 Keep-Alive、连接池 | | **发送请求** | 压缩 Body、减少字段 | | **服务处理** | 缓存、异步、并行调用 | | **数据库访问** | 索引、慢查询优化 | | **返回数据** | 分页、懒加载、CDN 加速 | #### 目标： - TP99 < 300ms（Web API） - 冷启动优化（JIT 预热、ClassDataSharing） > ✅ 使用链路追踪定位各环节耗时，逐段优化 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值