在Android开发中，内存泄露是一个严重的问题，它可能导致应用程序性能下降、卡顿，甚至崩溃。以下是对两个现象的深入分析及解决策略。
现象一：内存泄露导致应用重启
在这个问题中，开发者首先观察到应用在运行一段时间后黑屏并恢复，同时全局变量丢失。这表明应用程序进程已经死亡并重新启动。通过Logcat没有找到明显的异常，但发现ActivityManager的日志显示进程被kill。接下来，使用DDMS的Update Heap视图进行内存监控，发现在特定的两个界面之间切换时，堆内存持续增长，最终导致进程重启。进一步使用MAT工具分析heap dump文件，发现自定义Application对象中一个List持有大量Activity的Context引用，这造成了Activity的内存泄露。解决方案是修改代码，避免在Application中保存Activity的Context，改用更安全的方式来管理全局变量，如使用Singleton模式。
现象二：不同Android版本上内存问题的差异
这次问题出现在Android 2.3.5和4.0.3上，虽然不是典型的内存泄露，但导致了类似的结果——进程重启。在两种版本上监测heap内存使用，都显示正常，但在Android 2.3.5上长时间操作后进程会重启。研究Android内存管理机制后发现，每个应用都有自己的Dalvik VM，堆内存由Dalvik VM管理，而Linux内核管理native空间。通过adb shell dumpsys meminfo命令查看，发现在Android 2.3.5上native空间被大量占用，原因是自定义字体（arial.ttf）的加载过程中，JNI调用C代码时出现了native内存泄露。这个问题在Android 4.0.3上得到了修复，泄露的内存能够及时释放。因此，解决方案是在Android 2.3.5上，缓存Typeface对象，避免每次需要时都创建新的Typeface实例，从而防止JNI内存泄露。
从这两个现象中，我们可以学习到以下知识点：
1. **内存泄露的排查**：使用Logcat检查异常，使用DDMS的Update Heap视图监控内存，以及使用MAT等工具分析heap dump文件。
2. **Context的使用**：避免在Application或静态对象中保存Activity的Context，以免导致Activity无法被正确回收。
3. **Android内存管理**：理解Dalvik VM与Linux内核如何共同管理堆和native内存，以及Android不同版本之间的内存管理差异。
4. **JNI内存管理**：在使用JNI时要特别注意内存的释放，避免在C/C++代码中产生内存泄露。
5. **版本兼容性**：针对不同Android版本可能存在的特性差异，需要进行适配和测试，确保应用在各版本上的稳定性。
6. **资源复用**：对于消耗资源的对象（如Typeface），应考虑复用机制，减少不必要的创建和释放。
这些知识对于优化Android应用的性能和稳定性至关重要，开发者应当时刻关注内存管理，确保应用的健康运行。
VIP享7折，此内容立减4.47元 
