ZComposer 镜像诞生于 2017 年 3 月份，至今已不间断稳定运行 2 年多了。如何保证Composer 镜像的稳定性，是面临的最大难题，所以简单聊一些开发和解决问题的思路，希望能对你有一点启发。如果你觉得有些收获，请点下鼠标，在 github 上给我 1 个 star（支持下），谢谢。
安全性，不对原有的 json，zip 做修改，否则会引起 hash 变化，重新计算 hash 没问题（之前第三方有这么做的），这样带来的问题是，无法对包的安全性做校验，假如有恶意黑镜像，对数据做了修改，就无法判断了。所以 ZComposer 的镜像，所有的包都是和 packagist.org 官方一致的，可以比对 hash ，没有任何修改。 稳定性，因为不间断的采集数据，上传数据，中间有一个环节出现差错，就可以导致有问题，所以务必对采集完的包，通过 hash 值做完整性检查。有时候第三方的 API 策略，或者 CDN 线路都可能导致出现问题。所以做镜像最大的难点，是稳定性的保障。 Webysther/packagist-mirror（官方推荐的镜像开源） fork 自 hirak/packagist-crawler，但这些镜像开源都没有处理 dist 包，而 dist 包才是最大 / 最多的，最值得 CDN 处理的。 ZComposer 开源是全量镜像，包含了对 dist 部分的处理。dist 包还有个 65000 上限子目录数 的问题，1 年的时间，包的数量都是成倍的增加。软连接的方案是我原创出来的，或许随着包的无限增加，还需要设计其他方案。具体情况，请大家关注本次专辑…… 混沌工程（Chaos Engineering）最近也变得有点热闹，前阵子阿里才刚开源了混沌工程工具 ChaosBlade，近日 VMware 也开源了一款混沌工程编排工具 Mangle。  Mangle 是一个混沌工程工具，它是一个 Spring Boot 应用，实现了在受支持的端点上调用故障注入的 Web 服务。它能够针对应用和基础架构组件无缝地运行混沌工程实验，以评估系统弹性和容错能力。 Mangle 旨在通过非常少的预配置引入故障，并且可以支持可能拥有的任何基础架构，包括 K8S、Docker、vCenter 与任何启用了 ssh 的远程计算机。凭借其强大的插件模型，可以根据模板定义所选的自定义故障并运行，而无需从头开始构建代码。更多内容，请关注本次专辑…… Android 中应用自动扫描 Wi-Fi 信号是一大耗电元凶，在 Android Pie 中，谷歌对此进行了一些限制，前台应用的尝试扫描次数大幅减少为每 2 分钟 4 次，而后台应用则只能够每 30 分钟扫描一次。
但是这样对于一些开发者来说是不友好的，比如室内定位、网络接入点检查或信号强度测量类的应用强依赖于自动扫描 Wi-Fi，所以开发者自去年起就对谷歌有一些抱怨，比如他们发起了这个 Google Issue Tracker 帖子：https://issuetracker.google.com/issues/79906367。 这些开发者认为再不行也要给用户一个开关选项，选择开启或关闭 Wi-Fi 扫描限制，因为他们在使用这一类型的应用之前肯定是对耗电有一定的心理准备的，而实际上应用提供的功能就是他们自己需要的。 但是上周谷歌表示在 Android Q 中将不会修复开发者提出的这个问题。这也就意味着，就算不关闭上图这些选项，Android Q 也会继续限制它们对电池续航时间的影响。 但是谷歌同时也在 Android Q Beta 中提供了一个开发者选项，它允许 root 设备关闭这个 Wi-Fi 扫描限制，只不过开发者认为这对用户的应用并没有什么意义。更多详细内容，请大家关注本次专辑…… |
