火山引擎 MARS-APMPlus X 美篇 | 形成应用性能全面监控，大幅提升APP稳定性

最新推荐文章于 2025-05-23 09:55:27 发布
最新推荐文章于 2025-05-23 09:55:27 发布
阅读量4.3k 收藏
点赞数
分类专栏： 火山引擎MARS专栏 文章标签： 字节跳动 apm 运维 监控程序 安全
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/YZcoder/article/details/122878141
版权
美篇App采用火山引擎MARS-APMPlus提升应用性能稳定性，通过Java崩溃、Native崩溃、ANR等监控，减少卡顿和OOM问题，实现Android和iOS平台性能显著提升。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

在这里插入图片描述

本文主要介绍了美篇 App 通过使用火山引擎 APMPlus ，使应用性能的稳定性大幅提升的技术实践。 2月24日晚 MARS TALK 直播间，我们邀请了火山引擎 APMPlus 和美篇的研发工程师，为大家分享相关技术方案及实现细节。现在报名加入活动群 还有机会获得VR一体机——Pico Neo3哦！

一、「美篇」业务场景

美篇是南京蓝鲸人网络科技有限公司的主要产品，主打朋友圈的图文创作分享，定位为“不惑后”表达自我、结交同好、学习提升的互联网内容社区。
在这里插入图片描述

「美篇」业务规模：

自2015年7月正式上线以来，累计注册用户2亿，累计创作用户4000万 ，APP月活跃用户1200万， 日新增作品18万。 成立至今获得腾讯双百计划、经纬创投、真格基金、芒果文创基金等一线投资机构多轮累计1.8亿元融资，估值10亿元。2021年10月，美篇APP 7.0发布。

二、「美篇」业务痛点及问题

「美篇」业务现状形成的痛点
用户量快速增长：用户规模快速增长，创作用户突破4000万
海量内容沉淀：美篇作为一个强大的兴趣内容社区，拥有海量UGC图文&视频

最低0.47元/天 解锁文章
【火山引擎】调用火山大模型的方法 | SDK安装 | 配置 | 客户端初始化 | 设置
静谧、淡雅
10-14 1756
调用火山大模型的方法 | SDK安装 | 配置 | 客户端初始化 | 设置
火山引擎MARS-APM Plus x 飞书 ｜降低线上OOM，提高App性能稳定性
YZcoder的博客
10-13 1242
通过使用火山引擎MARS-APM Plus的memory graph功能，飞书研发团队有效分析定位问题线上case多达30例，线上OOM率降低到了0.8‰，降幅达到60%。大幅提升了用户体验，为飞书的性能品质保驾护航。 应用程序稳定性是影响用户体验及留存的关键因素 对于移动App的开发者来说，最基础也是最关注的问题就是应用程序的稳定性。而崩溃问题是影响稳定性的重要因素， 包括NSException、Signal、卡死、OOM(Out Of Memory)等问题类型。其中，OOM问题是随着业务的迭代，慢慢.
字节旗下两款AI编程工具
晓的博客
03-04 1850
Trae 和 MarsCode 是字节跳动推出的两款 AI 编程工具，旨在通过人工智能技术提升开发效率和质量。
火山引擎推出一站式小程序监控方案
YZcoder的博客
02-23 969
火山引擎 APM 团队打造出一站式小程序监控平台，旨在为开发者提供可跨平台、监控能力完善、简单易用的小程序监控服务。
火山引擎MARS- APMPlus专栏—— iOS Heimdallr 卡死卡顿监控方案与优化之路
YZcoder的博客
01-20 2792
本文主要介绍Heimdallr对卡死、卡顿异常的监控原理，并结合长时间的业务沉淀发现的问题进行不断迭代和优化，逐步实现全面、稳定、可靠的历程。
使用火山引擎 APMPlus 优化 iOS 内存性能的全套指南
字节跳动云原生计算官方账号
11-08 1065
本文面向 iOS 研发，不会涉及复杂的底层原理，而是直接告诉 iOS 研发答案，即怎么做，只需要花半小时阅读本文，就可以在开发需求的时候，知道如何更好利用内存来提升用户体验，同时避免稳定性相关问题给业务带来负向的用户体验；同时本文作者的初心是希望这篇文章能成为研发同学的一个“字典”，在一些特定场景或者感觉可能会踩内存坑的时候可以翻阅，快速找到最佳的编码规范。
提升汽车APP用户体验，火山引擎APMPlus的“独家秘笈”
YZcoder的博客
11-25 728
火山引擎 APMPlus 为企业提供全链路应用性能监控服务。
iOS自动化测试驱动工具探索
YZcoder的博客
03-03 1万+
本文主要介绍了字节 iOS 自动化测试驱动工具的探索过程及实现原理。
APMPlus 发布 HarmonyOS NEXT 鸿蒙系统 App 性能监控
ma_dewei的博客
11-28 416
APMPlus（火山引擎应用性能监控全链路版 App 监控）全新推出 HarmonyOS NEXT “鸿蒙星河版”App 性能监控服务，致力于为鸿蒙星河版 APP 用户提供优质的使用体验。我们积极携手鸿蒙星河版生态建设，更是荣幸地成为 DevEco Studio Partner SDK 专区首款 Performance Monitoring 类型 SDK。在此，我们诚邀对鸿蒙星河版 App 性能监控有诉求的企业接入并使用我们的服务。
使用火山引擎 APMPlus 解决抖音Top 1 Java 崩溃的通用优化方案
热门推荐
字节跳动技术团队官方博客
11-29 1万+
背景近3个月，抖音 Android 版面临一个多次触发线上报警的崩溃问题，全量版本和灰度版本的异常数据激增，该问题不仅容易触发报警，更成为了 Java Top 1 崩溃问题，带来巨大困扰，急需攻坚解决。本文展现了具体的分析过程、优化思路和解决方案，同时提供了已集成该方案的实用工具。初步分析多维特征我们以某发版期间数据为例进行分析：机型方面：比较分散，有聚集部分samsung sm-s9180 占比...
GTC 火山引擎线上专场 | 解码字节跳动多场景技术内核及应用
字节跳动技术团队官方博客
12-16 1万+
活动简介12 月 19 日，GTC 智能增长技术专场，火山引擎将以「智能增长」为主题，为大家带来字节跳动在机器学习领域沉淀的技术经验，智能平台、数据智能、语音识别、联邦学习等场景的前沿应...
火山引擎被谴责不尊重开源规则，非法重新发布Apache SkyWalking
ITValue的专栏
01-29 603
关注ITValue，看企业级最新鲜、最价值报道！钛媒体App 1月29日消息，火山引擎不尊重开源规则，非法重新发布Apache SkyWalking 的消息受到业界关注。Apache S...
火山引擎 RTC 视频性能降级策略解析
字节跳动技术团队官方博客
11-16 4500
动手点关注干货不迷路1. 背景随着 RTC 使用场景的不断复杂化，新特性不断增多，同时用户对清晰度提升的诉求也越来越强烈，这些都对客户端机器性能提出了越来越高的要求 (越来越高的分辨率，越来越复杂的编码器等)。但机器性能差异千差万别，同时用户的操作也不可预知，高级特性的使用和机器性能的矛盾客观存在。当用户机器负载过高时，我们需要适当降级视频特性来减轻系统复杂性，确保重要功能正常使用，提升用户体验...
CloudWeGo + APMPlus：打造从开发到可观测的一站式体验
volcenginetod的博客
05-06 894
Kitex 是 Golang 微服务 RPC 框架，具有 高性能 、 高可扩展 的特点，支持多消息协议（Thrift/Protobuf/gRPC）、多消息类型（PingPong/Oneway/Streaming）、服务治理、代码生成，具有完备的开源社区生态兼容性。数据分散 、 链路追踪复杂 和 故障传播 三大挑战。作为 CloudWeGo 生态中的最新成员，Eino 的开源进一步扩展了 CloudWeGo 的生态边界，使其不仅适用于传统的微服务场景，还能够赋能大模型驱动的智能化应用开发。
构建满足流批数据质量监控用火山引擎DataLeap
m0_60025795的博客
12-04 232
面对今日头条、抖音等不同产品线的复杂数据质量场景，火山引擎 DataLeap 数据质量平台如何满足多样的需求？
wordpress上传图片时出现服务器无法处理图片
jianzhanyes的博客
05-23 192
检查服务器配置：如果是使用 Nginx，可在 nginx.conf 文件中添加 client_max_body_size 64M;压缩图片文件：在上传前使用图片压缩工具(如 TinyPNG)优化图片大小，控制图片宽度在 2500px 以内。检查文件夹权限：确保 /wp-content/uploads/ 目录的权限为 755，文件权限为 644。upload_max_filesize 和 post_max_size 设置为 64M 或更高。等待并重试：有时服务器繁忙是暂时的，等待几分钟后重新上传图片。
轻帆云ITSM：以AI赋能制造业，构建高效运维新范式
最新发布
Sharon0408的博客
05-23 430
随着自动化生产线与工业互联网技术的深度应用，生产系统的稳定性已成为保障连续生产的关键要素。MTTR（平均故障恢复时间）作为衡量运维效能的核心指标，直接反映了企业在故障响应、处理及系统恢复方面的综合能力。对于制造业而言，优化MTTR不仅意味着运维效率的提升，更是保障业务连续性的重要举措。基于AI技术，为制造业打造“标准化-自动化-智能化”三位一体的运维体系。该体系通过整合流程、工具与数据，实现从故障预防、快速响应到知识沉淀的全链路闭环管理，助力企业构建高效、可靠的运维能力。
查看使用宿主机模式的Docker容器端口
ALex_zry的博客
05-22 257
时，容器会直接使用宿主机的网络命名空间，这意味着容器和宿主机共享相同的网络接口和端口。在这种情况下，容器内部的进程就像在宿主机上直接运行一样，不会通过Docker的网络栈进行端口映射。不过，我们可以通过查看宿主机上的进程和端口使用情况来确定容器使用了哪些端口。以下是使用Mermaid绘制的解释图，展示如何查看宿主机模式下容器的端口使用情况。如果你不确定容器内部运行的进程名称，可以进入容器内部查看。如果你不知道容器的进程号，但知道容器的名称或ID，可以使用。命令结合使用，来查看这些进程使用的端口。
编写一个 SQL 查询，查找 Person 表中所有重复的电子邮箱。 示例： +----+---------+ | Id | Email | +----+---------+ | 1 | a@b.com | | 2 | c@d.com | | 3 | a@b.com | +----+---------+ 根据以上输入，你的查询应返回以下结果： +---------+ | Email | +---------+ | a@b.com | +---------+ 说明：所有电子邮箱都是小写字母。
05-13
<think>好的，我现在要解决用户的问题：查找Person表中所有重复的电子邮箱。根据用户提供的引用内容，我需要综合各种方法，并确保SQL语句正确有效。 首先，用户提到的引用中有多种方法，比如使用GROUP BY和HAVING子句、自连接、临时表等。我需要先确认哪种方法最常用且高效。GROUP BY结合HAVING的方法在多个引用中被提到，比如引用1、3、5，看起来这是主要推荐的方法。这种方法通过按Email分组，然后筛选出计数大于1的组，直接得到重复的邮箱。这种方法简单直接，应该优先考虑。 接下来，我需要验证这种方法的正确性。引用1中的示例数据是三个记录，其中有两个相同的邮箱，执行后的结果正确显示重复的邮箱。另外，引用3和5中的SQL语句也是类似的，都是SELECT Email FROM Person GROUP BY Email HAVING COUNT(*) > 1。这说明这种方法是广泛认可的标准解决方案。 不过，用户可能还有其他疑问，比如为什么不用自连接或者临时表。自连接的方法在引用1中也有提到，使用DISTINCT p1.email FROM person p1, person p2 WHERE p1.id != p2.id AND p1.email = p2.email。这种方法通过比较不同ID的相同邮箱来找到重复项。虽然可行，但性能可能不如GROUP BY，尤其是在数据量大的情况下，因为自连接会产生较多的中间结果，影响效率。临时表的方法则是先创建子查询，再进行过滤，逻辑上和GROUP BY类似，但写法稍复杂，可能不够简洁。 用户的问题中还提到需要注意SQL的执行顺序，比如WHERE、GROUP BY、HAVING、ORDER BY的顺序。在GROUP BY方法中，正确的顺序是先分组再过滤，所以使用HAVING而不是WHERE来过滤分组后的结果。这一点在引用1中也有强调，确保COUNT(email) >1放在HAVING子句中，而不是WHERE，因为WHERE是在分组前过滤，而HAVING在分组后。 另外，用户提到的所有引用中都指出Email字段不为NULL，并且都是小写字母，所以在查询时不需要处理大小写或空值的情况，可以直接比较。这简化了查询条件，无需额外的函数如LOWER()或COALESCE()。 还需要考虑索引的问题。如果Person表的Email字段有索引，GROUP BY操作会更高效。但用户的问题中没有提到索引的情况，所以可以默认不考虑，但如果有性能要求，可能需要建议添加索引。 关于结果的展示，用户希望返回重复的邮箱，每个重复的邮箱只出现一次。GROUP BY方法自然满足这一点，因为分组后每个Email只出现一次，然后通过HAVING过滤出重复的组。而自连接方法需要使用DISTINCT来去重，因为同一邮箱可能会有多个匹配项导致重复列出。 最后，确保SQL语句的语法正确。比如，在GROUP BY子句后，HAVING的条件是否正确，字段名是否与表中一致。例如，检查是否有拼写错误，如Email字段是否是大写或小写，根据引用中的表结构，Email字段是varchar类型，列名正确。 总结下来，使用GROUP BY和HAVING的方法是最优解，因为它简洁、高效，并且被多个引用支持。同时，需要考虑是否需要添加事务控制或性能优化，但根据用户当前的问题，直接提供标准答案即可，扩展问题可以在相关部分提及。</think>根据数据库查询规范和引用内容[^1][^3][^5]，查找重复电子邮箱的标准SQL实现如下： ### 标准解决方案（推荐） ```sql SELECT Email FROM Person GROUP BY Email HAVING COUNT(*) > 1; ``` **执行过程解析**： 1. **分组统计**：通过`GROUP BY Email`将相同邮箱合并为组 2. **过滤条件**：`HAVING COUNT(*) > 1`筛选出现次数超过1次的邮箱[^3] 3. **结果保证**：由于id是主键，邮箱重复即表示至少存在两条不同id记录[^2] ### 替代方案对比 | 方法 | SQL示例 | 时间复杂度 | 适用场景 | |------|---------|------------|----------| | 分组统计 | 上述标准方案 | O(n) | 标准场景（推荐） | | 自连接 | `SELECT DISTINCT p1.Email FROM Person p1, Person p2 WHERE p1.Id != p2.Id AND p1.Email = p2.Email` | O(n²) | 小数据量验证 | | 窗口函数 | `SELECT Email FROM (SELECT Email, COUNT(*) OVER(PARTITION BY Email) cnt FROM Person) t WHERE cnt > 1` | O(n) | SQL Server/PostgreSQL等 | ### 关键注意事项 1. **空值处理**：题目已明确email字段不为NULL，无需`IS NOT NULL`判断[^2] 2. **大小写敏感**：所有邮箱存储时已统一为小写字母，无需`LOWER()`转换[^3] 3. **索引优化**：若表数据量大，建议在email字段创建索引： ```sql CREATE INDEX idx_email ON Person(Email); ``` ### 扩展验证 可通过EXPLAIN验证执行计划（以MySQL为例）： ```sql EXPLAIN SELECT Email FROM Person GROUP BY Email HAVING COUNT(Id) > 1; ``` 典型输出应显示`Using index`（如果创建了索引）或`Using temporary`（临时表处理分组）
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值