技术分享:@AR 眼镜|移动端应用软件概述

技术分享:@AR 眼镜|移动端应用软件概述


        各位现场以及线上的同学们,晚上好~

        1、按照国际惯例,先简单做个自我介绍,我是移动端应用组的Swuagg,从事Android研发近10年,ZEEKLOG博客专家,提交专利局审核的专利数量30+;

         2、今天的分享,希望尽量用浅显易懂的语言去讲解,也欢迎大家在分享过程中打断我进行探讨;

        3、话不多说,接下来看看我们今天主要交流的3个点。

移动端应用是什么?

         首先,简单和大家聊一聊移动端应用是什么?

在做什么事儿?

        首先,会从AR眼镜设计研发框图、到整机设计研发、然后到OS以及应用层,由整体到局部,由浅入深,娓娓道来;

        然后,通过分享移动端应用的具体业务与技术方案,帮助大家深入了解移动端应用软件;

        最后,分享一些使用移动端应用的小技巧和小提示。

未来做什么?

        第三part,希望和大家分享下移动端应用未来的工作重心、聊一聊AI,以及AR+AI眼镜行业。

1. 移动端应用是什么?

        简单来说,是指智能手机、平板上的App,但不仅限于此,比如AR眼镜、车机、电视、以及人形机器人等基于移动开发系统的设备,都搭载了各式各样的移动端应用,可谓无处不在。

        跨平台应用:Flutter、React Native、Harmony、KMP——抽象层+适配层。架一层“抽象平台层 / Runtime”,把 UI、系统能力、线程/IO、事件、渲染 等能力在框架里统一,再通过适配层在各端映射到不同平台的 Native 实现。

        功能:输入和连接、传输,设备像“手脚”、App像“遥控器”、云端像“大脑”。

AR眼镜端:执行、显示;     移动端App:连接、控制、同步;     云端:数据存储与分析。

2. 移动端应用在做什么事儿?

        光学设计研发:光学信息从AR眼镜最终传递到人眼视网膜上,视网膜在接收到光信息后通过视神经传递到大脑,大脑进而感知到AR眼镜中呈现的光学信息。

应用层这块的研发重点主要在如下两方面:

        一方面,是AR眼镜上的应用研发,如:大桌面(即开机后显示的主界面)、设置应用、以及3DoF拍照、提词器、AI助手等一些AR眼镜中的特性应用;

        另一方面,是与AR眼镜配套的手机应用研发,目前主要包含Android手机端和iOS手机端。

当前AR眼镜依赖于手机端App提供一部分算力以及应用场景的扩展,帮助其更好实现市场化,AR眼镜要想单独作为一款独立智能设备终端,还需要一定时间。

        为什么需要移动端应用层?      ——现场提问

        显示(EyeBox相对较小、颜色是单绿色)、交互、算力等。

        角色定位:当前主流AR眼镜(特别是分体式、伴侣式AR眼镜)的技术架构——手机作为计算核心,AR眼镜作为显示和交互终端。

        右边新架构优点: 由模块化到组件化,高内聚、低耦合,遵循Solid设计原则。

3. 移动端应用未来做什么?

        1、 在我们这个行业,几乎人人都在聊AI,所以做分享不聊一聊AI,好像自己都跟不上时代的波涛汹涌。 那么目前主流思路是这2点:关注AI发展、使用AI工具。

        2、 AI使用分阶段,初级与中高级使用者提升的效率也是不一样;

        3、 AI幻觉,需要使用者具有判断能力。

        4、 AI时代的码农:人机协同( ~ 选择和判断 ~ 定义问题和识别方向 ~ 调教和沟通 ~ )

一、2022年11月30号,ChatGPT上线3年来,开发中使用到的AI工具小结:

        Gemini CLI、Cursor CLI:做成命令行编程工具的原因:1)可以随意嵌入到任何现有的IDE当中搭配着使用,不需员工放弃他们原本所熟悉的工具;2)未来你并不需要关心代码是怎么写的,你只需要在命令行窗口里给AI提需求就可以了,图形界面的IDE将会变得不再重要。

        ——提高编程效率但不提高编程能力

        ——Cursor不支持AS

        ——代码质量暂时是无法把控的

        ——Vibe Coding理念:只写提示词,不写一行代码来编写程序

二、 AI 工具传统风险点:

        ——人工把代码/日志直接复制进 ChatGPT → 数据外泄

        ——IDE 插件可能会自动上传项目文件

        ——外部 AI 工具不清楚上传数据范围

        企业级 MCP 架构:

        MCP Server 部署在企业内网/本机 → 模型永远不直接读取企业文件内容。模型看到的所有内容,必须经过 MCP Server 的规则过滤:

        ——只允许访问指定目录

        ——自动脱敏(如替换 API Key、手机号、userId)
        ——只允许读取片段,而不是整个仓库

        ——允许“diff 模式”而非全文模式

        ——只允许工具执行结果摘要(如 lint、构建日志)

        ——即使模型无意或误操作,也被 Server 层完全隔离。

三、AI竞争 VS 电力竞争

        首先,都带AI功能;其次,与自己生态结合;最后,流量入口争夺。

        AI眼镜元年、AI硬件元年,AI的最佳载体,手机可能是随身携带的端侧算力中心!

        百镜争鸣时代,我们的核心竞争力是否需要迁移?AI的最佳载体真的是眼镜吗?AR眼镜什么时候能成为独立一款智能设备终端?AR眼镜能代替手机吗?


Thinks~

Read more

亲测BGE-M3 WebUI:多语言语义匹配效果超预期

亲测BGE-M3 WebUI:多语言语义匹配效果超预期 你有没有遇到过这样的问题: 用户搜索“手机充电慢”,知识库却只返回“电池续航差”的文档; 客服系统把“退款申请”和“换货流程”当成完全无关的请求; 跨语言产品文档中,英文FAQ和中文帮助页无法自动关联…… 这些不是模型不够聪明,而是传统关键词匹配早已力不从心。直到我点开这个镜像——🧠 BAAI/bge-m3 语义相似度分析引擎,输入两段看似无关的文字,按下“分析”键,屏幕上跳出一个数字:87.3%。那一刻我才真正意识到:AI终于开始“理解”文字背后的意思了。 这不是理论推演,也不是参数堆砌,而是一个开箱即用、无需代码、连CPU都能跑得飞快的Web界面。今天这篇实测笔记,不讲原理、不列公式,只说三件事:它到底能做什么、在哪些场景下真的好用、以及你第一次打开时最该注意什么。 1. 为什么说这是目前最实用的语义匹配工具? 1.1 不是“

Git-RSCLIP智能相册开发:Vue前端+Node.js后端全栈实现

Git-RSCLIP智能相册开发:Vue前端+Node.js后端全栈实现 你是不是也有过这样的经历?手机里存了几千张照片,想找一张“去年夏天在海边拍的、有红色遮阳伞和狗狗”的照片,结果翻了半小时也没找到。传统的相册应用只能按时间、地点或手动添加的标签来搜索,一旦标签没打好,照片就像石沉大海。 现在,情况不一样了。想象一下,你只需要在搜索框里输入“红色汽车的照片”,或者“有彩虹的风景照”,系统就能瞬间从成千上万张照片中精准地找到它们。这听起来像是科幻电影里的场景,但今天,我们就要用Git-RSCLIP模型,结合Vue3和Node.js,亲手把它变成现实。 这篇文章,我就带你一步步搭建一个基于自然语言搜索的智能相册系统。我们不用去理解复杂的深度学习算法,而是聚焦于如何将前沿的AI能力,通过一套清晰、可落地的全栈技术方案,变成一个真正能用的产品。无论你是前端开发者想了解如何接入AI能力,还是后端工程师想学习向量数据库的应用,都能在这里找到答案。 1. 为什么我们需要智能相册? 在开始敲代码之前,我们先聊聊为什么传统的相册管理方式已经不够用了。 我自己的手机里大概有8000多张照

Qwen3Guard-Gen-WEB部署教程:开源安全审核模型一键部署实战

Qwen3Guard-Gen-WEB部署教程:开源安全审核模型一键部署实战 1. 引言 1.1 业务场景描述 随着大语言模型在内容生成、智能客服、社交平台等领域的广泛应用,用户生成内容(UGC)的安全性问题日益突出。不当言论、敏感信息、恶意诱导等内容可能对平台声誉和合规运营带来巨大风险。因此,构建高效、精准的内容安全审核机制成为AI应用落地的关键环节。 阿里云推出的 Qwen3Guard-Gen 是一款专为大模型输出内容设计的开源安全审核模型,能够自动识别并分级处理潜在风险内容,适用于多语言、高并发的生产环境。本文将详细介绍如何通过镜像方式快速部署 Qwen3Guard-Gen-WEB 版本,实现可视化网页端的安全内容检测功能。 1.2 痛点分析 传统内容审核方案存在以下典型问题: * 规则引擎覆盖有限:依赖关键词匹配,难以应对语义变体和上下文隐含风险。 * 第三方服务成本高:商用API调用费用随流量增长而上升,长期使用负担重。 * 响应延迟高:远程调用存在网络开销,影响实时交互体验。 * 不支持私有化部署:数据需上传至外部服务器,存在隐私泄露风险。 基于以上