MoreRSS

site iconobaby@mars修改

定居青岛,女,闺蜜圈开发者。AI界的小学生,逆向分析工程师,非专业APP开发者。
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

obaby@mars的 RSS 预览

成也UNI,败也UNI

2026-09-15 15:06:31

在不久的以前,写代码还需要大量人力的时候,跨平台框架无疑是最好的选择。不管是uni还是flutter,都是为了这个而生的,当然这不是最早的跨平台框架,在这之前还有很多其他的框架,可能大家都不曾听说过,我简单介绍个我用过的两个:b4a(basic for andorid),我最开始并不怎么喜欢写(再问就是不会)安卓的java代码,想着偷懒,不要去弄安卓那一套,偷懒玩了下b4a,这也是最开始做findu的时候最朴素的想法;另外一个是delphi的firemonkey框架,这个东西体验的更早,刚来青岛的时候,为了查询公交基于这个东西做了个公交查询的app,最后跑在了ios上。

这些框架,不能说生不逢时,只能说基础功能还是稍微有些欠缺,生态不完整,例如地图、Im等组件的支撑缺失,这也是最终为什么直接采用原生oc和java开发了最早版本的findu

然而,随着ai的发展,跨平台已经不再是一个主要的投入成本了。借助ai的能力可以快速复刻一个app到其他的平台,以前是点子不值钱,现在技术也不值钱了。跨平台唯一的好处仅剩下代码的可维护性,一套代码通吃各个平台,相对来说代码维护和bug修复的一致性会比多平台更加便捷。

可能这个发展偶尔也会有人会高喊暂停:

2026 年 8 月 11 日,美国参议员伯尼·桑德斯(Bernie Sanders)日前致信 OpenAI CEO Sam Altman、Anthropic CEO Dario Amodei 和 Meta CEO Mark Zuckerberg,要求三家公司暂停 AI 开发,并停止继续构建人类无法控制的 AI 系统。

至于暂停或者不暂停,现有的技术能力已经足够解决日常的技术问题和满足开发需求。也基于这种现有的技术能力,最近重新重构了findu,开发了新的portable claw。这里我想说的就是这个portable claw,借鉴之前的开发经验,想着一套代码解决所有问题,采用的架构依然是uniapp,不过不是uniappx。

按照uniapp 官方文档的说法,x其实是下一代,能达到原生的性能。我在开始的时候错误的评估了app在ios上对于性能的消耗,并且初期测试的时候主要也是基于ios模拟器测试,真机测试相对来说比较少,数据量也没有达到日常使用账号的数据量。导致对于app在ios真机上的性能过于乐观,数据量大了之后,会话窗口的绘制就成了一件痛苦的事情。

 uni-app 在 iOS 真机上的瓶颈,不只是「聊天列表用了 WebView」。换成 nvue,只是把聊天 UI 从 WKWebView 换成 Weex 原生控件,业务、流式更新、页面栈、桥接仍在 JS 容器里。所以能减轻长列表掉帧,但到不了 Swift + UITableView 那种原生体验。


uni-app 在 iOS 真机上真正卡在哪

1. 双运行时一直同时活着

本项目 iOS 不是「整 App 都是 nvue」:

  • 聊天:pages/chat/ios.nvue(Weex)
  • 状态 / 设置 / 登录 / 订阅:仍是 Vue + WKWebView
  • 业务宿主:stores/iosChatHost.js 挂在 App.vue 的 JS 服务层

chatRoutes.js 里写得很清楚:Vue 宿主和聊天 nvue 作为 subNVue 同时常驻,Tab 只挪 overlay。真机上等于:

  • 一套 WKWebView(设置等)
  • 一套 Weex(聊天)
  • 一套 5+ Runtime / Pandora

内存、启动、Tab 切换都比单进程 UIKit 贵。Android 用 index.vue 还能凑合,iOS 对 WebView 和后台 WebContent 更狠,真机掉帧、杀进程都更明显。

2. 主路径仍是 JS:解析、裁剪、再塞回 UI

Gateway / Hermes 事件、历史、tool 卡、附件、TTS、权限,全部在 JS 里做。nvue 不能 import gatewayMedia@noble/* 等,否则 Weex 白屏。于是每条流式更新都是:

JS 宿主算完 → cloneMessage 裁成短摘要 → uni.$emit 整份快照 → nvue 再 v-for 刷 <list>

原生工程则是:SSE 回调直接改 ChatMessageUITableView 按行刷新。中间没有「整窗 JSON 快照」。

3. 聊天数据本身就重

长会话卡、空会话不卡,文档里已经定性:推给 nvue 的是「当前窗口」的完整 JSON,最后十几条常带着大段 tool 输出和 data: 图。你们被迫:

  • 窗口大约 16 条,上限约 48
  • 正文截断、不传 toolCards、不传 data: 预览
  • 流式尽量 splice 一条,避免整表替换

这是在 迁就 Weex 序列化 + 布局,不是产品想要的完整列表。原生 ChatTableView 可以按 cell 复用、按行测高,不必先把历史砍成摘要。

4. 5+ / Weex 桥是同步税

例如内购注释:不要和 StoreKit 弹窗同时触发 Weex 布局,否则会 同步 调 getSafeAreaInsets 卡住。真机上 plus.*、相册、文件、支付、安全区,都会在 JS 线程和主线程之间来回。原生是直接调系统 API。

5. Weex 不是 UIKit

<list> / <cell> 看起来像原生列表,实际是:

  • JS 虚拟 DOM → Weex 原生节点
  • 能力子集(布局、富文本、手势冒泡都弱)
  • 本页还用了 list-flip 倒序列表 才能贴底,属于 Weex 滚动模型的绕路
  • Markdown、代码块、动态高度,Weex 测高和复用远不如 UITableView.automaticDimension

nvue 缓解了什么,为什么仍不够

nvue 确实缓解了「用 webview <scroll-view> 画几百条气泡」这一层:原生 view 绘制、有限回收、少一次 DOM/CSS。

它没有拿掉下面这些,所以仍然不是原生 App:

还在的成本 说明
双引擎
聊天 Weex + 其它页 WebView,Tab 常驻两套页面
快照协议
宿主和 nvue 用事件传 JSON,流式时反复 clone / emit / diff
瘦 UI
重逻辑不能进 Weex,热点路径仍在 JS
列表策略
必须截断、限窗,完整历史会把 <list> 打爆
容器
DCloud 基座、模块、plus、描述文件,启动和权限都比单 target Swift App 重
表达力
做不到原生那种 cell 精细复用、TextKit/AttributedString、键盘 inset、分屏

所以:nvue 是「聊天绘制层换引擎」,不是「App 换成原生」。 瓶颈从「WebView 排版」变成「JS 宿主 + 跨运行时同步 + Weex 列表模型」。对 Agent 聊天这种 高频流式、变高 cell、大 tool 输出 的场景,第二套瓶颈一样会被打满。

和原生工程差在哪(同一产品)

原生 native_ios 是单一 Swift 进程:UITableView + 按条 merge、键盘按窗口算 inset、没有 uni.$emit 快照窗。uni-app 即使用 nvue,也还是「JS 算完再通知另一套 UI」。

一句话: nvue 能让短会话、轻气泡比纯 Vue 页跟手;真机长会话、流式、工具卡、多 Tab 同时在时,瓶颈在运行时架构,不在某一两个 CSS。要到原生手感,只能像现在这样离开 Weex/WebView,用 UIKit/SwiftUI 自己画列表。


以上内容是基于ai的总结,基本也就是这个情况,尤其是对于这种可变cell+列表的绘制,性能就更是问题了,哪怕独立出来nvue页面,js主进程还是会卡住其他的操作。

相反,在andorid设备上就不会存在这个性能瓶颈,虽然都是uniapp框架,在安卓设备上流畅度基本能达到原生的效果。

实际真机效果对比:

上面的视频是 进入app之后,首先点了状态,后续其实又点了其他的tab页,但是此时已经卡死了。

上面的视频是基于swift的ios原生项目。

虽然页面功能一样,但是绘制的效果和性能却是天差地别。

当然,uni框架还有另外一个缺点就是,一些与系统打交道的东西还是需要原生插件支持,例如ios 的定位回调,ios的healthkit(闺蜜圈APP),安卓的各种系统设置等等,多数都是基于现有的uni插件来实现,所以,findu虽然是页面样式基础功能跨平台了,底层依然是基于原生的定位组件,系统操作组件,以及badge组件来堆起来了app的核心功能。

至于portable claw,则是需要tts引擎,很不幸baidu的tts引擎超过了200m,导致无法使用uni的云打包(打包也可以,交钱就行)。

这个问题,其实我之前在其他的文章中也提过。

为了解决云打包的问题,我是用uni的本地打包,基于xcode项目来实现打包,这也是ios版本发布的必经流程,这个操作其实也不算简单,需要配置一系列的东西,包括证书 mp文件等等。

这一系列的操作都是为了能够复用uni的代码,不用重新写。

只是,现实狠狠地给了我一巴掌,告诉我这个东西虽然可行,但是不够完美,或者说达不到自己的心理预期。作为一款app,这个运行效率是无法忍受的,这就有了原生的swift的ios项目:

说了这么多,并不是说uniapp一无是处。

在不需要与系统底层交互app中,uni无疑依然是开发效率和跨平台的最优选择,继承了基础的三方登录、内购、分享、地图等等能力,这些能力对于多终端的适配的确可以减少大量重复的工作。

不过,如果你需要一个高性能的app,那么最好的办法就是直接原生开发(有了ai,一切都简单了),至少目前我这里的优化已经到了自己的能力极限了。

成也UNI,败也UNI。

附简要跨平台框架性能对比(基于cursor总结)仅做参考:

奇异莓

2026-09-14 09:49:11

转眼,竟然又快到中秋了。回头看,似乎路上光秃秃的什么也没有,转回头,往前走,路上也是光秃秃的。过去和将来,看不出任何的区别,不过可能是路越来越崎岖不平,愈发难走了。

周五的时候,公司的财务姐妹过来找我让帮忙改个数,我在处理的时候,她抬起手腕说:『感觉我快挂了,你看我现在的心率,99。啥也没干,现在就这个心率,感觉快猝死了。』

是啊,工作使人变态,健康状况也开始变得异常。严重点的猝死了,即使不严重的,也多多少少有些健康问题:甲状腺结节、咽炎、颈椎病、腰椎病、鼠标手等等。

命名平时右手用的更多,这几天自己左手的指头竟然有些疼。贴了几贴膏药,感觉稍微缓解了一点,对象说是转移了。

昨天为了去同学那里拿一个猫砂盆,再次到了许久未曾去过的cbd区域。现在高架桥下来就直接到了理工大学附近。山东路的交通状况,感觉比之前更加的拥堵了。

倒闭的家乐福,门前的停车场有些空旷,多余车位都空着。进入商场,商铺多户都关着门,还有几家正在装修。楼上的家家悦超市的人是最多的,进门就看到了这个东西:奇异莓。

这个东西本质上是猕猴桃的一种,不知道什么时候开始多了一个名字叫做奇异莓,其实猜也能猜到可能跟奇异果🥝有关系,然而,我这小智商第一次看到这个东西还真没跟奇异果关联上,还以为是一种莓,例如:蓝莓、树莓、蔓越莓等等。

转悠到万达,吃了个大渔铁板烧。他们家真的是爱鱼籽,几乎所有的菜上都会带点鱼籽。199的家庭套餐,吃到最后也不知道到底吃了些啥,连菜单有啥都不清楚,稀里糊涂吃完饭,还剩下半份牛排和一份炒饭,打包带走。

人吃饱了,还得给猫猫准备吃的,昨天早上最后的一口猫粮给猫猫倒进碗里之后,就一点余粮也没有了。从万达直奔乐客城,当然,还有另外一个目的就是去给手机贴个膜。毕竟送了个贴膜次数,不用白不用。然而,贴完了回家就后悔了,贴的膜明显比手机屏幕小一圈,边缘滑动都剌手,这坑爹玩意儿。

好在之前买手机还有送的一张膜,果断把送的那破玩意儿撕下来,重新自己换上一张。

然鹅,这个曲面钢化膜也有问题,就是可见区域明显小于屏幕区域,尤其是四个角,可见范围明显变小了。

大好人

2026-09-08 13:25:57

不知道bilibili为什么选了这个名称,现在这个语境下,我老觉得大好人这个东西多少带点比较诡异的味道。一说到好人,感觉就是大怨种。

前段时间沸沸扬扬的『走个面』,在之前的美美的红十字会,各种所谓的公益,有时候难免让人真的觉得自己是个怨种。

最近又出了月捐停了之后,不断的打电话追问为什么停了的事件。

你觉得你贡献了爱心,而他们觉得,你贡献的还不够。至于国际的,嗯,还不如国内的。

希望,自己不是怨种。

如果自己真的是怨种,我也只能画个圈圈诅咒他(她)。

重生

2026-09-07 13:11:06

自从猫猫来到家里之后,所有长叶子,不长叶子🌱的东西,多多少少都经受过了数轮摧残,首当其冲的就是那盆十几年的文竹。

从郁郁葱葱的一人多高,吹下来还能在耷拉到地上的高度,硬生生的被咬成了光杆司令。

为了防止猫猫再去要其他的植物,对象该猫猫买了所谓的猫草,当然,多数人可能不知道哪个所谓的猫草其实就是麦子,对,你想的没错,就是我们平时吃的磨成面粉的麦子。

然而,猫猫对于这种植物并不感兴趣,连吃都不吃。对象说,你把猫草剪下来放到猫粮里看他吃不吃。理想很丰满,现实很骨感,事实证明他连闻都不闻。

『或许,等哪天麦子,长出关节来,硬邦邦的可能他就会吃了。』我说,然而,谁知道哪天这一盆麦子才能长大呢,挤在这么一个小盆里。

 

长方形的花盆里,撒下去的一包龙葵种子,也已经发芽,开始长出枝干,虽然大小不一,倒也是一片欣欣向荣的样子。住在楼上,最大的好处就是,不管什么时候,总是能保持一个相对来说温暖的温度,跟温室一样。

在这种环境下,植物也可以不在那么依赖于季节,春播秋收也可以不再严格遵守时节的规律。

文竹在备受璀璨之后,我把它挪到了洗衣机上面。那个高度虽然对猫猫来说没有什么难度。不过也算是暂时给了一个栖身之所,哪怕能躲过一时,也算是躲过了一时。至于什么时候躲不过了,那再提躲不过的事情也为时不晚。对象说,你可以买一盆新的放上。

只是,我觉得他还有救,之前也经历过枯萎,消亡。

之前挺过来了,这次,应该也可以。

罩亮前程👙

2026-09-04 15:12:52

前几天还在说《买垃圾》,实际上没过几天,我又开始买新的各种有用的无用的小玩意儿了。

来个特写:

除此之外,我还买了个钥匙扣:

亮闪闪的钥匙扣,看着还是蛮有意思的,虽然没什么大用。

前几天把之前白色的牛仔短裤扔掉了

重新买了一条蓝色的:

扔东西,总是要比买东西更困难一些。买东西可能头脑一热就买了,但是扔东西,总是觉得万一那天再穿呢。

晚上下班回家,把宝子的姥爷送到她小姨家,顺便去加油。不得不说,这suv的油耗真的是看着肝颤,虽然烧的是92但是跟粉皮烧95相比,价格并没有什么优势,这油耗的差距不足了燃油标号价格的差距。

上次加油的时候,还是6.6,现在竟然成了7.5,这还是优惠之后的,充500块钱,一下子用掉400。

这油价属实是有些离谱了,你涨我也涨,你跌我不跌。

希望这小罩罩,能照亮我的前程,也照亮你的前程!

迟钝

2026-09-02 10:59:39

总是说,自己缺少锐利的目光,深度的思考。在浪潮滚滚向前的时候,自己却固步自封,停在了那个地方。终于,洪峰过后,自己才想起来该去赶潮了。

所谓的人工智能,一轮轮的迭代,一代代的升级。ai变得越来越智能,各种工具也层出不穷,变得越来越先进。当然,跟着升级的还有价格,不再那么平易。龙虾潮退了,自己才开始玩龙虾,大家都开始玩够了harnes,自己才姗姗来迟,开始初体验。

互联网上工具一堆了,自己才想起来要开发个应用。虽然网上已经有一堆应用了,还是忍不住想要自己去开发一个。重复造轮子,这就是所谓的ai的正确用法。唯一的不同,这次开发的是付费应用,最开始的时候,也不过是想复刻一下自己常用的功能。能满足自己在移动端处理一些日常的事务就可以了,简而言之就是让龙虾去爬公众号的文章。

在实现的过程中,总觉得功能太单薄,不断的丰富功能和优化体验。从单一的龙虾客户端,变成现在龙虾 harnes多端客户端。当然,因为app购入了第一个ai域名,protableai.ai

不得不说,.ai后缀的域名是真的贵,当然,除了.ai,我还入了portableai.cn

为了能够上架苹果应用商店,期间改了无数次的名称、截图等等metadata信息,苹果认为包含claw字段的app信息,都会侵犯open claw的商标权,在一次次的更新优化之后,我连最开始的图标也放弃啦,从龙虾变成了章鱼,毕竟都说🐙是外星生物,应该会更聪明,更智能吧。

在改了无数次之后,我想据理力争,连ai都劝我说,尽量不要与苹果的审核员争执,只会激化矛盾。让你改,你就改吧!

很多的东西,怎么说呢。多数的时候就是路边的野草,连一个正眼看的机会都得不到,谁又会在乎路边的那些野草呢。

产品一样,人也一样,不管有没有人看,剩下的也只有,自顾自美丽了。

网站:https://portableai.cn

苹果:https://apps.apple.com/cn/app/portable-claw/id6779501378

安卓:https://app.zhongxiaojie.cn/app/portabl-claw/android/