Copilot Workspace自行产生了繁杂多余的代码, 我凭借于三个步骤清除掉了内存方面出现的泄漏。
前一周, 接到了一个需要进行重构的需求, 我心里想着, 要去尝试一下, GitHub最近才发布出来的Copilot Workspace。
原本想着能够节省些许时间, 然而跑了一回之后发觉生成的代码之中隐匿着一个巨大的坑洼。
连接池没关，对象引用没释放，直接导致移动端服务内存飙升。
排查了整整一下午, 结果发现, 是它极其“听话”地依照模板去生成代码, 然而却全然不懂业务方面的上下文情况呢。
说实话，这工具现在还不是全自动的，你得盯着它生成的每一步。
之前, 我用过不少AI编程助手, 然而, Workspace的这种“包含计划以及执行”的模式, 算得上是头一回遇见。
它能够依照你以自然语言进行的描述, 首先绘制出一项开发计划, 该开发计划涵盖文件列表以及代码片段。
然后自动去创建文件、写代码，甚至还能顺手把单元测试给写了。
是不是感觉听起来蛮美好? 然而, 我此次所踩的坑, 恰恰就出在了这个算得上是“自动执行”的环节那里。
我所要进行修改的, 是一个属于老项目的图片加载模块, 此模块涉及到数量众多的网络请求, 以及相关缓存逻辑。
那时候, 我于提示词当中, 仅仅表述了这样一番话语: “将图片加载予以优化, 让本地缓存得以增加, 使网络请求实现减少。”。
它所产生的计划清晰明确, 具体为, 要去新建一个名为CacheManager的类, 对ImageLoader类进行修改, 还要更新单元测试。
代码结构看起来也很规范，依赖注入、接口分离，一应俱全。
我心想这下稳了，直接合并提交。
然后, 到了第二天上线的时候, 监控发出报警, 表示内存占用出现不正常的情况, 经过几个小时之后, 就出现了OOM（OutOfMemory错误）。
我赶紧回退代码，开始排查。
一开始以为是并发问题，加了锁也没用。
打那之后, 将日志级别调整为Debug , 一行一行地去查看GC日志 , 这才察知存在一个奇特的现象。
每次在进行大图加载这个行为的时候, Old Gen, 也就是老年代, 其使用量呢, 都恰恰是在以较为缓慢的态势进行着爬升这种情况。
并且, 哪怕页面已经被销毁了, 可是那些大图的Bitmap对象依旧会留在堆里面。
这便格外邪乎了, 分明在ImageLoader当中撰写了release()方法。
我把生成的代码拉出来仔细对比，发现了一个细节。
保存在CacheManager之中的, 并非是图片对象的弱引用, 而是其强引用。
换个角度来讲, 情况变得更为糟糕的是, 它在进行回调操作的过程之中, 直接对Activity的Context进行了持有。
倘若在安卓系统开发范畴之内, 这无疑堪称是那种会送命的题目 , 情况稍微轻一些的话就会造成内存出现泄漏 , 情况严重的话则会使得应用程序崩溃。
值得感到有意思的是, Copilot Workspace在开展生成测试用例这一行为的时候, 竟然没有对这个场景进行测试。
它只跑了单例模式的初始化测试，没跑生命周期管理的集成测试。
这让我意识到，AI目前还不懂“上下文”这个词的重量。
它晓得如何撰写出契合语法规范的代码, 然而却不明白何种代码在生产环境当中会导致严重后果。
说实话，这工具现在的智能程度，离“放心交棒”还有距离。
它更像是一个超级快的初级工程师，手速快，但经验少。
给它安排写个工具类, 它不会出问题；可要是安排让它去处置复杂的业务状态管理, 那它就很容易出现状况出错。
我的解决思路分三步走，希望能帮到同样想尝鲜的朋友。
第一步，强制要求使用弱引用或软引用存储缓存数据。
我于提示词之中增添了这样一句话, 即: “运用WeakReference对缓存对象予以包装, 以此避免内存泄漏。”。
这次再生成的CacheManager，引用类型就对了。
第二步，显式声明Context的生命周期绑定。
我提出要求, 让它于ImageLoader里接收LifecycleOwner, 并且在onDestroy这个时刻去清理资源。
虽然代码变长了，但至少安全了。
第三步，引入静态代码扫描工具。
我利用SonarQube对生成的代码进行了一次运行, 果真扫描出了好几个潜藏着的资源泄露风险之处。
要是不进行这一步骤, 仅仅凭借肉眼去Review, 或许压根就没办法看出来那些隐蔽的引用链。
历经了这三步的调整之后, 内存曲线最终达到了平稳的状态, 并且图片加载的速度也提高了40%。
这个过程让我明白，AI生成代码只是起点，不是终点。
你必须是那个最后的守门员，负责把关性能和安全。
存在这样一个问题, 其并非仅仅GitHub Copilot Workspace会有, 别的主流AI编码助手, 同样有可能遭遇。
比方说像Cursor那样的, 还有Codeium这般的, 甚至于各类IDE里面所内置的智能补全。
它们全都有着生成那种“最为常见”的代码模式的倾向, 然而却把特定业务的边界条件给忽略掉了。
尤其在涉及资源管理, 领域, 并发控制且包含事务处理这类范畴时, AI极易疏忽, 不当回事。
所以，别指望它能替你思考架构缺陷。
你得把最核心的设计原则，拆解成具体的约束条件喂给它。
举例而言, 存在“禁止持有Activity Context”这种情况, 还有“所有IO操作必须经try-catch-finally处理”这种说法, 另外还有“缓存最大容量被限制为100MB”这种规定。
把这些规则写进Prompt里，比事后排查要高效得多。
此外, 本人提议各位, 在生产环境投入使用之前, 一定要构建壹套完备的自动化测试流水线装置。
不要只信它的单元测试，那些测试往往是基于理想状态写的。
有一些非主体案例测试你得去补充, 像是网络连接中断的情况, 还有内存容量不够的情况, 以及存在并发冲突的情况等等。
这样才能确保生成的代码不仅在本地跑通，在线上也能扛住压力。
总之, Copilot Workspace是个不错的事物, 然而, 它目前仍旧处于一种并非完全成熟完善的状态, 也就是所谓的“半成品”状态了。
将它利用好的关键所在, 并非取决于你驾驭提示词的能力高强与否, 而是在于你对底层原理钻研理解至何种程度。
你只有比它对Java有更深的了解, 对Android能够更熟练撑握, 对系统架构能有更精准拿捏, 才能够驾驭它。
否则，它就是给你制造Bug的机器。
最近, 你们是否曾使用过得类似于这样的, 人工智能工作流程工具? 在此过程当中, 有没有遭遇到什么, 是事先没有预料到的, 麻烦或问题?
未来3年，你认为AI会如何改变你的工作方式？欢迎留言讨论。
