共计 5237 个字符，预计需要花费 14 分钟才能阅读完成。
目录
一. 我的项目背景 …………………………………………………………………………………………………………………………………………………………………………………….3
二. 所遇到的挑战 ………………………………………………………………………………………………………………………………………………………………………………3
三. 以 OOM 为例，解说下此类问题的解决步骤 ………………………………………………………………………………………………………………………………………………………………………………3
1. 什么是 OOM………………………………………………………………………………………………………………………………………………………………………………3
2. 如何查看 JVM 虚拟机的可用内存 ………………………………………………………………………………………………………………………………………………………………………………4
3. 如何监控和优化利用的内存状况 ………………………………………………………………………………………………………………………………………………………………………………5
4. 内存失常与异常情况比照 ………………………………………………………………………………………………………………………………………………………………………………5
5. 利用的内存优化 ………………………………………………………………………………………………………………………………………………………………………………7
四. 对 IOS 及 React Native 利用的监控 ………………………………………………………………………………………………………………………………………………………………………………9
五. 总结 ………………………………………………………………………………………………………………………………………………………………………………10
附录：《个人简介》………………………………………………………………………………………………………………………………………………………………………………11
一. 我的项目背景
在我司开发的某能源 APP 中，服务于多家用能企业员工。在这几年的开发中，也着实遇到过很多用户上报的反馈意见，然而有些问题的本源却不得而知，有时候甚至须要对一个模块整体重构才解决问题，通过了这几年迭代，将线上利用的一些实战经验分享于此。
在开发 App 过程中，常常会遇到 OOM（out of memory）内存溢出的状况，本文将联合本人多年的开发教训，探讨下遇到性能问题的解决方案。
二. 所遇到的挑战
在我司上线的 App 和小程序中，会遇到很多并发的操作，尤其在 App 端更为严重，在有些管制操作时，往往受到网络稳定、响应速度的影响，其操作常常会失败、异样退出、甚至闪退等问题，遇到此类问题，往往是程序员头疼的事，因为问题不好定位，不容易发现问题呈现的地位。也给线上用户带来了不好的体验。
尽管是 2B 的业务，短期虽不会对用户量造成损失，然而如果长期解决不了此类问题，不少用户的应用频率逐步降落。还有些相似手机端近程智能管制机器的场景，如果产生谬误，可能呢还会造成不必要的经济损失。
三. 以 OOM 为例，解说下此类问题的解决步骤
1. 什么是 OOM
在收集到的错误信息中，先来看下 OOM 报错时的样子：
09-08 21:15:38.771: E/dalvikvm-heap(123452): Out of memory on a 20455736-byte allocation. 09-08 21:15:38.779: E/AndroidRuntime(23231): java.lang.OutOfMemoryError
这就是因为程序申请应用“20455736”byte 内存，但 Java 虚拟机无奈提供这么大的内存，所以程序就被迫死掉了。
2. 如何查看 JVM 虚拟机的可用内存
咱们零碎的内存不会全副给 JVM 虚拟机来应用的，所以，咱们须要得悉真正的可用内存是多少，能力晓得咱们应该优化的方向。
在开发中，能够通过 java 一下命令，来测试出，以后零碎的可用内存
java -XmxXXXXM -version
如：执行命令 java -Xmx2000M -version，如果显示出 java 的版本信息，则阐明 2000M 内存是可用的。
如此这般，能够始终批改内存大小来测试，直到显示出：
呈现上图内容，阐明内存曾经超出了 JVM 可用的内存了，那这个内存就是以后 JVM 的最大内存。
咱们能够依据模拟器设置的内存大小，计算出能供应利用应用的内存大小了。不同的机型，内存也不一样大，要确保支流机型偏下的配置，可能失常晦涩的运行程序。
3. 如何监控和优化利用的内存状况
不论是 Android APP 还是 Java 程序咱们都能够通过监控该 APP 在 JVM 中的运行状况，来判断是否出现异常。
咱们能够通过 JDK 监督和治理控制台（jconsole.exe），在装置目录：jdk/bin。
通过此平台，能够监控利用的运行状况，占用内存状况，曾经是否呈现死锁的线程，如下图：
4. 内存失常与异常情况比照
内存应用失常的利用，其内存监控应该是下图这样：
有内存问题的利用，其内存曲线是这样的（继续递增，不会降落）：
上图，示意利用内存从启动后，始终递增，垃圾回收后，内存仍然供不应求。那么曲线的起点就是利用产生 OOM 的极限左近值了。
5. 利用的内存优化
内存优化的目标，就是通过咱们对 JVM 参数的调整，让利用所应用的内存，可能很好的回收，长期运行也不会呈现内存只增不减的景象。
①. 优化老生代内存占比
如果 Old GC 占用的内存始终递增，且占比拟大，咱们能够通过优化 JVM 参数，将 -XX:NewRatio 值设置为 4，意味着：新生代占 1，老年代占 4，年老代占整个堆的 1 /5。这样优化，多调配给 GC 老年代的一些内存。
SurviorRatio 也设置为 4，即设置 Eden 区的比例占多少,S0/S1 雷同。
②. 进步 survivor 区的指标使用率
设置 survivor 区的指标使用率，当使用率达到时从新调整 TenuringThreshold 值，让对象尽早的去 old 区。
-XX:TargetSurvivorRatio：一个计算冀望 Survivor 区存活大小 (Desired survivor size) 的参数。默认值为 50，即 50%
-XX:TargetSurvivorRatio=50（默认为 50，即达到）
对象进入 Survivor 区之后，因为应用的是默认的自适应策略，导致当年龄为 1 的时候，Minor GC1 次，就被挪动到老年代了。导致老年代内存耗费过快，在并发场景下，一会就产生一次 FGC。
咱们能够增大该值，
-XX:TargetSurvivorRatio=90
③. 调高程序运行期间的最大内存
如果通过优化后，程序在某些消耗资源的工夫点，仍然须要很大的内存，那么咱们只能调高 JVM 中利用运行的最大内存。
-Xmx1024M
④. 抉择最佳的垃圾回收算法
不同垃圾回收办法测试数据，在第①步和第②步中，咱们理论是一点点的测试，最初确定应用哪种计划的，屡次试验记录：
四. 对 IOS 及 React Native 利用的监控
上述提到动监控工具以及优化策略都是针对基于 Java 平台的，那么像 IOS 和 React Native 开发的利用该怎么监控呢？如何理解这些利用运行时，产生了哪些谬误和异样呢？如何将这些谬误收集，转入到开发人员的 Bug 修复打算中呢？
在这举荐一款利用性能监控平台 U -APM：
在此平台上，咱们能够实时监控当天利用呈现的异样，并且有残缺的统计发成的异样以及异样数、机型、版本号、利用下载起源市场、操作系统、用户地区。也有对于利用对各个机型的内存的占用状况，咱们用再多的模拟器和真机测试，也抵不上实在的用户的大数据。
友盟 U -APM 挪动利用性能监控平台提供的解体、卡顿、启动、内存、网络等剖析数据，能够全方位笼罩开发人员还原 Bug 的各项指标，帮忙开发人员疾速定位和修复 bug。
五. 总结
1、性能调优要做到对症下药，须要依据理论业务零碎的特点，以肯定工夫的 JVM 日志记录为根据，进行有针对性的调整、比拟和察看。
2、性能调优是个及其耗时且无止境的过程，要综合衡量调优老本（蕴含人力老本）和更换硬件老本的大小，来换取用户体验。
3、性能调优不仅仅包含 JVM 的调优，还有服务器硬件配置、操作系统参数、中间件线程池、数据库连接池、数据库自身参数以及具体的数据库表、索引、分区等的调整和优化。
4、通过特定工具（利用性能监控平台 U -APM）查看代码中存在的性能问题并加以修改是一种比拟经济快捷的调优办法，上工治未病，不能等到用户反馈，开发人员才迟迟发现问题。所以，监控平台肯定要上，将平台捕捉到的异样，修复和优化在用户感知之前。
附录：《个人简介》
自己目前就任于某上市能源企业，从事互联网开发行业 7 年，在挪动开发方向，参加过两款 Android APP 和 RN 小程序，在其中负责 APP 架构设计和次要开发人员。目前负责能源互联网数字化转型相干工作，对物联网数据平台、监控平台、能源管理平台等利用有多年教训，对数据治理、数据管理、利用开发、平台运维都深有波及。
业余时间，喜浏览，学习不限于计算机领域的常识。常撰写博客，分享技术和从业常识，与同行探讨技术细节。