append 可以不加锁。参考 https://docs.python.org/3.5/faq/library.html#what-kinds-of-global-value-mutation-are-thread-safe

GIL 可以保证同一时间只有一个线程在活动，但如果你的操作本身不是原子操作，就是说由几步构成的，那有可能你干到一半就切到另一个线程上了。

是有点铺张。几个点可以注意一下。

首先，CPU 其实可以买淘宝散片，因为这东西用不坏，所以无所谓售后，那就只有零售价跟批发价的区别。大概省 300

其次，主板没必要上这么好的。因为主板跟你性能其实没有关系，主板的价格 = 扩展性 + 超频支持程度+ 品牌溢价，
我推测你不超频，也没有很高的扩展需求（比如 3 个 M2+2 个显卡），所以直接选 B760 的板子就可以了。好用还便宜。
大概省 2000 。还是要折腾，那就选差一点的 Z790 。

然后内存和硬盘，你现在内存选的国产低价品牌，硬盘选的国外品牌。我建议反过来，
内存选个芝奇什么的老品牌，稳妥。
硬盘选个国产颗粒的，实惠。


至于机箱散热，看得顺眼就行，不予置评。但你最好前后各加点扇子，转速开低也没声音。

至于 4090 选哪个，这一代都被英伟达耍了，散热规模超出很多，所以买各大品牌的乞丐款都可以。

其中值得一提的，七彩虹的水神是一体水，可以满足你静音的需求。其它都差不多。

我觉得很大的一个原因在于，前端开发的目的， 从编写美观合理的网页， 变成开发基于浏览器接口的客户端应用。

今天你纯用 HTML ，CSS 和 Javascript ，在一个文件里面，也是可以用简单易懂的代码写出效果还不错的页面，放到浏览器上就能跑了，也不需要纠结七七八八的东西。

但要写个应用，就很麻烦。哪怕用 Android Studio 就写个 Hello World ，项目结构也是很复杂的。因为要兼顾很多方面么。

更何况浏览器本来也不是专门为了应用开发而设计的接口，所以还有一个从 页面 ----> 应用的转换工作要社区去集思广益，就出来好多不同解决方案，增加了理解的复杂度。

没毛病啊。

TLS 是一揽子解决方案，除了信道加密以外，它还有其它机制来提供身份验证、防中间人攻击、防重放攻击。

你仅仅搞个 AES 加密，防不了那么多东西。

但或许对你的需求而言也无所谓。至少加密后传输的东西，中间人确实解不了，内容中加时间戳，可以防重放攻击。

想破解还是得攻破终端，拿到密钥。

能做到这一步了，哪怕用 TLS 搞双向验证，私钥也是在终端上的，同样是不安全的。

按你这描述，可能是做出了守护进程，在主程序挂了之后，守护进程再把它拉起来。相当于没有完全关闭，它就不停复活。你可以试试关闭手机重启，它还会不会自己冒出来。

安卓应用常驻后台还是很常见的。你划掉可能只是应用的 Activity ，它还有个 Service 在后台运行着。Service 除了没界面，其它的活儿都能继续干的。

正常做自签名证书，先是生成一个数字证书做 CA ，
然后用这个 CA 来签出其它的证书。

这样你把这个 CA 证书，加入到信任列表，你用这个 CA 签的其它证书就能过关。

就第二种啊，还能怎么玩。

Flutter 的跨平台思路很大胆激进，是彻底的另起炉灶。
而 React 本质还是基于 JS 的一套妥协的玩法，发展潜力不大了。
从战未来的角度，Flutter 或许更值得研究。

但跨平台的本质并无不同。统一界面代码，调用平台原生功能。
选对的不如选会的。

Eclipse 的 MQTT Client 实现还可以，Broker 端好像性能不太好。
建议直接就 emqx 。

至于你说的 mqtt 和 16 进制字节流的区别。我感觉你误解了 MQTT 。
MQTT 本身就是一种建立在 TCP 上的字节协议。
它帮助你建立并维护 Client - Broker 之间的连接， 使用基于 Topic 的 推送 /订阅机制，间接实现 Client 与 另一个的 Client 的数据传输。

比如你的场景，用 MQTT 来实现。就是服务器订阅某个 Topic ，20000 个设备往这个 Topic 上推送，利用 Broker 来实现服务器监听 20000 个设备上报的数据。

如果你不用 MQTT ，那就要换个方式去接。

比如你可以开一个 HTTP Server ，让 20000 个设备发送 Post 请求来上报数据。

或者开一个 TCP Socket Server ，让 20000 个设备以 Tcp Client 的形式连到你的 Server 上，然后用自己设计个协议去接。

你说的可能就是这种自己编协议的吧。

我不是专业移动开发，但是 Android 、桌面、Web ，也都做过一些东西。
也聊聊这个话题。

首先遗忘我觉得不是问题，遗忘本来就是大脑帮我们减负的机制，一个东西你一段时间用不到，自然印象就淡了。等用到了，反正你有印象，再复习也快啊。比如正则表达式，你不是天天写规则，那记不住语法非常正常，偶尔遇到了再去搜搜咋用，又有什么问题呢？

就你要做的到，学过的东西，明白它的大致原理，可以用来干嘛，遇到需求时，能想到这么一茬。我感觉就可以了。


然后说回移动开发，现在是百花齐放

光入口就有移动 Web 端、移动端、小程序端。

跨平台开发，就有 Flutter 、ReactNative 、Uniapp 等不同途径。

哪怕做原生开发，也有 Swift 、Kotlin 等新语言带来不同途径。

每种途径都有自己的开发逻辑，你如果每种都想搞成熟手，这个是有些不切实际的，而且对你可能也没有必要。

你接的活儿，无论用什么途径开发，做的事情可能都是接近的。

所以我感觉你最好是先定一个主技术栈，在这个主栈上把你的东西做熟。

其它的开发方向，你可以了解，尝试一些小 Demo ，了解它的开发步骤。等真的需要在它们上面开发的时候，把主栈上的经验套过来就成了。

随便找个机子开个 SMB 共享完事了，你这个也不涉及自动同步什么的，

就做成一个网络访问的存储空间，你塞东西进去就行了。

额，楼主，我有个思路，不知道能不能帮到你啊。

我观察了一下你这个数据的构成。有很多形如 0.28,0.56 这种小数字。这些小数字拉高了遍历的轮次，导致你算不出来。

可不可以把这一大坨小数字，合成几个大数字，再参与你的遍历。出了结果后，再把它分解回小数字呢？

以你主题中的例子，
有 30 个 0.28 ， 要匹配 3 个数。
一个数字中的 0.28 的数量,可以表示为 2n 或者 2n+1 。 这里 2n 个 0.28 ，可以转成 n 个 0.56 。
根据鸽笼原理，3 个数，我们留 3 个 0.28 参与最后的匹配，剩下的 27 个 0.28 ，都换成 0.56 。

同样的，2n 个 0.56 可以换成 n 个 1.12...

这样参与最终匹配的数字降下来，你这个问题就能找出解。

找出解以后，你再还原回去。

我建议用第一个方案，起码有个外壳。方案 2 ，我用的树莓派 + 硬盘盒，搁那裸奔，看着就不专业。当然用其实也能用。

我觉得你可以试试自己建，玩一玩。

讲白了 NAS 就是找一台低功耗的电脑，一头连网线，一头连硬盘，上面跑各种各样的服务，让其它计算机能使用网络去访问硬盘，也就是所谓的“网络附加存储”。

群晖这些系统做的事情，是把各种常用或者不常用的服务集成在他的 NAS 系统里面，一条龙服务，省得淘神费力。

而当你的需求已经需要通过 Docker 容器自己装服务去满足，那其它功能你也可以自己装服务去实现，不需要用群晖那套东西。

用户在你们网站，选择支付宝支付，出来的付款码，是国内支付宝生成的，最后收钱也是国内的那个付款码关联的账户。是这个意思么？

这种方式我只见到机场充值这种灰色地带用，正规企业没必要吧。

听你意思，感觉是想达到书同文、车同轨这种效果啊。
那好像只能写一个取名清单，类似代码规范，让系统开发者遵守。

如果目的是不同模块互相交流方便。那还是要定一个规矩。
然后要么上面写个统一的模块，让下面系统引用
要么底下每个系统按规矩去写转换函数。

说到例子，我用过 Andorid Studio 开发安卓应用，那个挺符合 MVC 的。
它的每个页面，由表里两部分组成。表面是视图 View ，作用是用 XML 定义页面中控件的位置、大小、样式。
里面是 Activity ，这里面声明了页面中用到的控件的 Java 类实例。
类实例和 View 中的控件，通过资源 id 关联到一起。

然后它是怎么更新视图呢？是在 Activity 里面写触发。

比如点击按钮，更新文本框。是在 Activity 中编写 onBtnClick 事件，这个事件中，调用 TextView 的类实例，改里面的 text 值，然后 TextView 类实例会触发更新，反馈到视图上。


我曾经试过用 WPF 开发桌面应用，那是初次体验 MVVM 。感觉区别就是，像上面这个需求，onBtnClick 中，变成直接改 text ，由于 text 跟 TextView 控件有过绑定关系，所以 text 一改，TextView 显示的东西会改。并不需要我直接调用 TextView 中的 Function 或者 Prop 。