共 3 篇相关文章
这篇讲的是作者如何系统性地分析和改善Android应用的内存泄漏问题。他以实际优化案例开头，展示了将应用退出后内存占用从100多M降至20M以内的显著效果，并成功定位了InputMethodManager和MTK WebView中的具体泄漏点。 作者分享了一套行之有效的方法论：首先遵循“数据说话”和“持续改善”的原则。具体步骤上，建议优先用Android Studio的静态分析解决常见泄漏，比如Handler、未关闭的IO资源和Context使用不当等问题。对于更隐蔽的泄漏，则需要借助Leakcanary或adb命令在程序运行后进行监控，并使用MAT工具对内存快照进行深入分析。文章还详细说明了如何验证改善效果，形成闭环。 整篇文章就像一份手把手的排障指南，从原则、具体操作到验证，流程清晰。特别是对使用MAT时的关键注意事项（如关注Retained Size、排除软弱引用）的总结，对于实际解决问题很有参考价值。
这篇文章聚焦Java应用内存泄漏排查的关键一步——heap dump的获取与解析。作者指出，当需要定位堆内存被何种对象占满时，常规的jstat监控已力不从心，此时获取一份精确的堆内存快照（Heap Dump）就成了分析的核心。 文章系统梳理了触发dump的几种实战方法：可以直接使用jmap命令行工具，或通过jconsole的图形界面操作；更稳妥的方案是在应用启动时配置JVM参数`-XX:+HeapDumpOnOutOfMemoryError`，让它在OOM发生时自动生成现场。文中也提及了hprof，但明确指出其严重拖慢JVM性能，仅适用于调试环境。 在分析环节，作者对比了三款主流工具。IBM HeapAnalyzer能够直观列举堆内存使用状况，定位泄漏源头。JDK自带的jhat则将堆对象转为HTML页面展示，并支持OQL查询语言进行深度探查。而Eclipse Memory Analyzer (MAT) 作为一款功能强大的图形化工具，集成了从获取到分析的完整流程，适合快速诊断。文章最后还补充了一个实用细节：对于NIO等框架直接向操作系统申请的堆外内存，需通过`-XX:MaxDirectMemorySize`参数单独配置与监控。
这篇讲的是从近期Web标准化交流会的一场讨论出发，试图重新审视JavaScript在前端开发中的角色。文章没有否定JS的重要性，而是通过回顾活动中的具体内容——比如精美的PPT演示、对《闭包应用实例》的深入探讨，以及围绕“9个版本的tab制作”和脚本组件设计展开的高手现场PK——来引出一个更宽广的视角。 作者指出，尽管JS在交互和逻辑层面至关重要，但一次高质量的前端呈现，同样离不开扎实的HTML语义化结构和精心设计的CSS表现。这场交流会的气场，恰恰来自于对这些“非JS”基础技术的共同打磨与深度碰撞。文章通过这些鲜活的讨论场景提醒读者，避免陷入“唯JavaScript论”的单一思维，才能更全面地构建出健壮且优雅的Web应用。
