拆东墙补西墙

上周的时候看到有人提到关于评论区链接地址的安全性问题，这个所谓的安全性指的是访客的域名是不是还是一个健康的站点。鉴于博客圈人来人往，这个事情就变得非常不可控。毕竟，一旦博主放弃了域名或者卖了域名，那些链接就变成了一个地雷，不知道什么时候会炸掉。

除了评论，还有另外一个也可能会出问题的地方，就是友链。相对来说，友链比较固定，哪怕出了问题也比较容易全部处理掉。为了解决这两个问题，我在nilai.la 启动了个新的服务，专门用来检测现在已经添加的所有链接的健康成都，在检测到异常问题之后会给我发邮件以及app推送消息。如果我确认网站有问题，会同时给所有关注这些站点以及添加了这个站点友链的用户邮箱发送邮件。当然，这个检测不会遍历所有的页面，主要是检测首页，词库数量可能也会影响检测质量，不过聊胜于无，总比什么都不知道会更好。

除此之外，给优化了所有评论区的链接点击，url也不再显示明文，点击之后会弹窗提示之后进行跳转：

当然对于这种前后端分离的页面，如果不渲染页面本身也看不到url信息。

上周的时候，看到另外一条消息，那就是苹果要求app在27年4月之前强制适配iPhone Duo，在这之后提交的更新必须要包含Duo的截图，否则连提交审核的资格都没有。https://developer.apple.com/cn/iphone-duo/

对于各种比较新的技术和设备，我一向不会迅速跟进（主要是因为穷，买不起新的设备）。包括之前的apple watch、carplay，apple watch 很久之前就有了，但是却不曾针对它做过任何的开发。carplay 后来有了却局限于各种权限申请，直到最近才开始做一些开发，陆续上线。至于其他的设备，那是真的买不起，例如最新的Duo。

不过，既然苹果说了这个东西，还是要尝试下的。平常使用的mbp，磁盘空间实在有限（天天报磁盘空间已满），暂时也没想着去把xcode 升级到27.1，就把家里的那台mac mini 利用起来，安装了27.1版本的xcode。

这台m2的mini 入手之后其实并没有怎么用，之前总是觉得带不动两个4k显示器（后来发现是hdmi线缆问题导致的），一直用的windows。还有另外一个问题，那就是性能的确比自己的windows电脑差的太多。

重新升级各种工具，环境之后，就可以启动duo的模拟器了。在这个8g内存的mini上运行模拟器的确是比较折磨人。系统非常卡，毫无体验可言。如果同时运行多个模拟器：watch，iPhone系统的可用性就变得更差了。

不得不说，当时为了便宜，买了个8g版本还是失算了，如果要做开发之类的用途，最好还是16g起步的版本吧，否则在上面开发就是折磨。

目前的适配效果：

app在这种折叠屏的适配上，主要是重新布局绘制的修改和工作量，目前uniapp 官方的打包暂时还不支持iPhone duo的适配，所以直接从云打包打的自定义基座无法运行在iphone duo上，需要下载离线打包sdk和工程修改编译目标配置来实现打包。Duo 模拟器的架构是arm64 ，而传统模拟器的架构是x86-64，当然之所以无法运行并不单纯是架构的问题，iOS sdk升级之后调整了部分方法废弃了部分方法，导致原生的xcode 离线打包的示例项目及时能跑起来也可能会白屏，要修复这个问题又是一顿折腾。

除此之外，这几天还折腾了一下apple watch的适配，当然，如果我所料不错的话，那就是料对了，uniapp 同样无法支持apple watch的打包。也就是说，如果要开发apple watch应用依然要用原生开发，并且这个东西开发完之后，连ai都建议我直接离线打包，把所有的东西复制进去。不过这件事情，是在我开始折腾Duo适配之前搞的，我并不想去搞所谓的离线打包，毕竟要同步的资源太多了，更何况已经开发了一堆原生插件，如果在弄个原生工程，何不直接xcode 原生项目重构？鉴于我对ios 系统以及架构的了解，最终让ai按照自己的想法来实现了这个apple watch的打包运行，代价就是又写了一堆脚本。当然，如果最后还是要靠原生xcode项目，或许，不该写这一堆脚本。

时过境迁，原来为了节省开发时间，便于代码维护的一些方法或者框架，在功能实现越来越底层，交互要达到原生水平的时候，很多事情就不得不向原生开发转移，这么一来，原来的跨平台优势当然无存，取而代之的是各种插件以及原生组件的维护。之前就因为uni的性能问题，把Portable AI的ios端app直接用swift重写了。现在又因为底层交互以及设备支持，原生实现了healthkit 插件，apple watch app，carplay 插件，为了兼容iPhone duo 修改了uni的离线打包示例代码。这一系列的开发升级维护，让uni的跨平台和单代码优势所剩无几。

当然，如果只是做一个跨平台的app，不涉及底层交互，不涉及原生设备适配，uni还是不错的选择。对uni来说，要适配的东西或者设计的东西依然不少，之前鸿蒙兼容的时候，放弃了vue2。鸿蒙的代码我用vue3重构了，现在再次升级兼容的时候，不知道又会放弃什么，至于uniapp x所谓的接近原生的运行效率，是个不错的尝试，但现在在ai横行，无处不在的情况下，这种跨平台优势和所谓的性能优势，依然不再明显。

为了实现自己的各种目标和要求，代码的数量依然与项目开始的时候不是一个数量级了，太多原生语言开发的内容以及插件的大小限制，让我不得不考虑如果再开发一个新的app的时候是否依然要uni梭哈了。

屎山有的是因为代码写的烂，有的是因为从开始就注定了只能拆东墙补西墙，uni搞不定的上插件，插件依然搞不定，那就只能原神重构。

更何况，屎山这个东西是移不完的，为了实现功能，总是要写代码。

这世界上本没有屎山，写的代码多了，屎山自然也就出现了。