从父视图移除UIView并置为nil后，内存会被释放吗？

嘿，我完全懂你遇到的这个头疼问题——明明把占内存的ViewB从父视图移除，还把引用置为nil了，结果内存就是降不下来，对吧？这种情况在带复杂图形（比如你说的Graph）的视图里太常见了，我帮你拆解下核心原因和靠谱的解决办法：

为什么内存没被释放？ #

大概率是这几个坑没踩对：

• 循环引用没处理干净
  带Graph的ViewB肯定少不了闭包回调（比如数据更新、动画完成的回调），如果闭包里直接用self却没加weak/unowned，就会形成循环引用链：ViewB持有Graph组件，Graph持有闭包，闭包又持有ViewB，ARC根本没法回收它。
  举个反例，你可能写过类似的代码：

  // 错误示例：形成循环引用
  self.graphView.onDataRefresh = {
      self.reloadGraphData()
  }
  

  这种写法直接把ViewB和Graph绑死了，就算你移除视图、置空引用，内存也释放不了。

• 父视图的引用没彻底清除
  如果你只靠Tag来移除ViewB，比如viewWithTag(1001)?.removeFromSuperview()，但ViewA的某个属性（比如var activeGraphView: ViewB?）还攥着旧的ViewB引用，那ARC会认为这个视图还在被使用，自然不会回收。

• Graph的底层资源没手动释放
  很多自定义Graph或者第三方库会用到CADisplayLink、Core Graphics上下文、甚至OpenGL的渲染资源，这些东西如果不在ViewB销毁时手动清理，会一直占用内存，还可能间接持有ViewB的引用。比如CADisplayLink如果没从RunLoop里移除，它会一直跑，死死拽着ViewB不放。

怎么解决？ #

按这几步来，基本能搞定：

• 第一步：打破循环引用
  所有闭包中引用self时，必须用weak self（不确定场景的话优先用weak，unowned适合确定self不会提前销毁的情况）：

  // 正确示例：避免循环引用
  self.graphView.onDataRefresh = { [weak self] in
      self?.reloadGraphData()
  }
  

  同时给ViewB加个deinit方法打日志，确认它真的被销毁了：

  deinit {
      print("ViewB 被销毁了！")
  }
  

  如果控制台没输出这句话，说明肯定还有地方在持有它的引用。

• 第二步：规范ViewB的替换流程
  别再靠Tag瞎找了，在ViewA里维护一个ViewB的强引用，替换的时候一步到位：

  // ViewA中的替换逻辑
  func refreshGraphView() {
      // 1. 先清理旧视图
      currentGraphView?.removeFromSuperview()
      // 2. 置空引用，给ARC回收信号
      currentGraphView = nil
      
      // 3. 创建并添加新视图
      let newGraphView = ViewB()
      // 配置新视图的布局、数据...
      newGraphView.frame = self.graphContainer.bounds
      self.graphContainer.addSubview(newGraphView)
      currentGraphView = newGraphView
  }
  

  这样能确保旧的ViewB没有被任何地方意外持有，ARC就能正常回收了。

• 第三步：手动清理Graph底层资源
  在ViewB的deinit里，把所有可能残留的资源都清掉：

  deinit {
      // 停止并销毁CADisplayLink
      displayLink?.invalidate()
      displayLink = nil
      // 释放Core Graphics上下文（如果用了的话）
      if let ctx = graphRenderContext {
          CGContextRelease(ctx)
      }
      // 第三方Graph库的话，调用它的销毁方法（比如有的库有destroy()）
      graphView.cleanup()
      
      print("ViewB 被销毁了！")
  }
  

调试小技巧 #

用Xcode的Memory Graph Debugger（调试栏里的那个内存图标），查看ViewB的引用链，一眼就能看到是谁还在抱着它不放，针对性解决就行。另外别忘了检查ViewB的代理属性是不是弱引用——如果代理是强引用，也会导致内存泄漏（正确写法是weak var delegate: GraphViewDelegate?）。

内容的提问来源于stack exchange，提问作者Reimond Hill