ylt's Notes
0%

Posted on Edited on In

CentOS 7 防火墙端口

sudo firewall-cmd --zone=public --add-port=3000/tcp --permanent
sudo firewall-cmd --reload

查看防火墙规则:

firewall-cmd --list-all

Posted on Edited on In

最近对客户端进行内存泄漏排查，绝大部分内存泄漏的地方都很容易找出来，对着Android Studio分析的结果，一步步点开Depth 为0 的引用，然后Jump to Source 分析分析就行了。

但是有个内存泄漏比较诡异：

mCallerContext in com.facebook.imagepipeline.cache.BitmapMemoryCacheKey

一个缓存的key居然引用了Activity，对着Depth为0的引用也找不出有什么异常的地方。然后去看了半天fresco源码分析BitmapMemoryCacheKey里面Context 的来源，但是传入Context 的地方太多，分析源码的时候突然想到打个断点不就行了。。

思路对了就很简单了，在创建缓存key的地方(getBitmapCacheKey)打了几个断点，Context为Activity 的情况下顺着调用栈就找到了泄漏的地方。

找到问题的根源之后又看了下fresco的源码，作为callerContext 传入的Context 都会被静态引用。所以解决办法有两个：

  • 所有的callerContext 只传入ApplicationContext
  • 在每个Activity.onDestroy() 的地方调用clearCache 相关方法
    • cleanCacheForUri()
    • cleanAllData()

Posted on Edited on In 
//主要是配置这个，更改gradle的默认缓存策略

configurations.all {
    resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
    resolutionStrategy.cacheDynamicVersionsFor 0, 'seconds'
}

dependencies {
    compile group:"xxx" ,name:"xxx",version:"latest.integration"
}