大型 APP 的性能优化思路(1)，腾讯面试题前端

最新推荐文章于 2024-11-13 18:25:44 发布

2401_84170414

最新推荐文章于 2024-11-13 18:25:44 发布

阅读量908

点赞数 20

分类专栏：程序员文章标签：性能优化

本文链接：https://blog.csdn.net/2401_84170414/article/details/137727594

版权

程序员专栏收录该内容

171 篇文章 0 订阅

订阅专栏

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数HarmonyOS鸿蒙开发工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年HarmonyOS鸿蒙开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

htt

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上HarmonyOS鸿蒙开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新

如果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注鸿蒙获取）

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

预加载任务调度时机

那么预加载框架对于添加进来的 task 如何调度呢？这就是一个预加载框架复杂的的地方的，我们可以有很多策略，比如这三种：

关键节点调度策略：比如各个生命周期阶段，页面渲染完成阶段等去执行，也可以在任务添加进来后立刻执行。
性能调度策略：比如判断 cpu 是否忙碌，温度是否过高，内存是否充足等，只有在性能较好的情况下才进行调度
用户行为调度策略：如果做的更复杂一些，还可以结合用户的行为指标，如该业务用户是否会使用，如果某一个用户从来不适用这个 app 里的这个功能，那么改业务添加进来的预加载任务就可以完全舍弃到，这里面可以用一些端智能的方案来精细化的控制预加载任务的调度

每种调度策略不是单独执行的，我们可以将各种策略整合起来，形成一套完善的调度策略。

2.2 速度和流畅性优化：如何让业务在资源紧张时做出更优的策略

上面提到的是站在全局的视角，如何管控预加载任务的，除了预加载任务，还有很多其他的异步任务我们都可以用一些框架来规范化的管控起来，这里再举一个例子，对于大型 APP 来说，业务在使用的过程中很容易出现因为 cpu 或内存不足导致卡顿，响应慢等性能问题，所以在做性能优化时，是需要推动业务方在资源不足时，做出相应策略的，这个时候我们就需要降级框架来处理了。降级框架需要解决这两个问题：

性能指标的采集
降级任务的调度

2.2.1 降级框架

性能指标的采集

想要再资源紧张时让业务做出优化策略，那么对资源紧张的判断就是必不可少的一步。我们一般通过在程序运行过程中，采集设备性能指标来判断资源是否紧张，最基本的性能指标有 cpu 使用率，温度，Java 内存，机型等，除机型外其他性能指标一般都是以固定的频率进行采集，如 cpu 使用率可以 10s 采集一次，温度可以 30s 采集一次，java 内存可以 1 分钟采集一次，采集的频率需要考虑对性能的影响以及指标的敏感度，比如 cpu 的使用率采集，需要读取 proc/stat 的文件并解析，是有一定性能损耗的，所以我们在采集时，不能太频繁；温度的变化是比较慢的，我们采集的频率也可以长一些。降级框架需要整合这些性能指标的采集，减少各个业务自己采集造成不必要的性能损耗。

当降级框架采集到性能指标，并判断当前资源异常时，通用的做法是通知各个业务，业务收到通知后再进行降级。比如系统的 lowmemorykiller 机制，都是采用通知的方式。

但是在大型 APP 中，仅仅将触发性能阈值的通知给到各个业务方，效果不会太好，因为业务方可能并不会去响应通知，或者个别业务响应了，但是其他业务不响应，依然效果不佳。无法管控业务是否进行降级，这显然不符合在大型 APP 做性能优化的思路，那么我们要怎么做呢？

降级任务的调度

添加任务：我们依然可以推动各个业务将降级的逻辑封装在 task 中，并且注册到降级框架中，并由降级框架来进行调度和管理。因为往降级框架注册 task 时，需要带上业务的名称，所以我们能也能清楚的知道，那些业务有降级处理逻辑，哪些业务没有，对于没有注册的业务，需要专门推动进行降级响应以及 task 的注册。

调度任务：和预加载框架一样，对于注册进来的 task，降级框架的任务调度要考虑清楚调度的时机，以 cpu 使用率为例，不同的设备下的阈值也是不一样的，高端机型可能 cpu 的使用率在 70%以上，app 还是流畅的，但是低端机在 50%以上就开始卡顿了，因此不同的机型需要根据经验值或者线上数据设置一个合理的阈值。当 cpu 到达这个阈值时，降级框架便开始执行注册到 cpu 列表中的降级任务，在执行降级任务时，不需要将队列里的 task 全部执行，我们可以分批执行，如果执行到某一批降级 task 时，cpu 恢复到阈值以下了，后面的降级 task 就可以不用在执行了。可以看到，通过降级框架，我们就可以站在全局的维度，去进行更好的管控，比如我们可以度量业务做降级任务的效果，给到一个评分，对于效果不好的，可以推动优化。

2.3 内存优化：如何度量业务对资源的消耗

上面两个例子将的是在大型 app 中，如何管控业务对资源的使用，以及如何让业务在资源紧张时做出更优的策略的思路，我接着基于内存优化的方向，讲一讲如何度量业务对资源的消耗。

当 app 运行过程中，往往只能获得整体的内存的数据占用，没法获的各个业务消耗了多少内存的，因为各个业务的数据都是放在同一个堆中的，对于小型 app 来说这种情况并不是问题，因为就那么几个业务在使用内存，但是对于大型 app 来说就是一个问题了，有些业务为了自己性能指标能更好，会占用更多的内存，导致整体的内存占用过高。所以我们需要弄清每个业务到底使用了多少内存才能推动业务进行优化。

我们可以线下通过分析 hprof 文件或者其他调试的方式来弄清楚每个 app 的内存占用，但是很多时候没有充足的时间在版本都去统计一下，或者即使统计了，也可能因为路径没覆盖全导致数据不准确。所以我们最好能通过线上监控的方式，就能统计到业务的内存消耗，并且在内存消耗异常的时候进行上报。

我在这里介绍一种思路。大部分的业务都是以 activity 呈现的，所以我们可以监听全局的 activity 创建，在业务的 onCreate 最前面统计一下 java 和 native 内存的大小，作为这个业务启动时的基准内存。然后在 acitvity 运行过程中，固定采集在当前 activity 下的内存并减去 onCreate 时的基准内存，我们就能度量出当前业务的一个内存消耗情况了。在该 acitvity 结束后，我们可以主动触发一下 gc，然后在和前面的基准内存 diff 一下，也能统计出该业务结束后的增量内存，理想情况下，增量内存应该是要小于零的，由于 gc 需要 cpu 资源，所以我们只需要开取小部分的采样率即可。

当我们能在运行过程中，统计各个业务的内存消耗，那么就可以推动内存消耗高的业务进行优化，或者当某个版本的某个业务出现较大的劣化时，触发报警等。

除了上面提到的思路，我们也可以统计在业务使用过程中的触顶次数，计算出一个触顶率的指标，触顶及 java 内存占用达到一个阈值，比如 80%，我们就可以认为触顶了，对于触顶次数高的业务，同样也可以进行异常上报，然后推动业务方进行修改。这些数据和指标的统计，都是无侵入的，所以并不需要我们了解业务的细节。

如果我们想做的更细一些，还可以 hook 图片的创建，hook 集合的 add，remove 等方法，当监控到大图片和大集合时，打印堆栈，并将关键信息上报。在飞书，如果是低端机中，图片如果占用内存过大的，都会在 hook 方法中进行一些压缩或者降低质量的兜底处理。

总结

除了速度及流畅性，内存方向的优化外，还有其他方向的优化，如包体积，稳定性，功耗等，在大型 APP 上都要基于管控业务对资源的使用；度量业务对资源的消耗；让业务在资源紧张时做出更优的策略这三个方向去进行优化，这里我就不再一一展开讲了。

当然我这里讲的优化思路并不是大型 app 做性能优化的全部，我讲的只是在做大型 app 的性能时相比于中小型 app 需要额外做的，并且也是效果最好的优化，这些方案在中小型 app 上可能并不需要。除了我这篇文章讲的内容外，还有很多优化的方案，这些方案不管是在大型 app 还是中小型 app 上都是通用的，比如深入了解业务，基于业务逻辑去做分析和优化，抓 trace，分析 trace 等等，或者基于系统层或者硬件层去做一些优化等等，这里就不再展开讲了。

为了帮助到大家更好的全面清晰的掌握好性能优化，准备了相关的核心笔记（还该底层逻辑）：https://qr18.cn/FVlo89