首页 文章 精选 留言 我的

精选列表

搜索[开发者预览],共10000篇文章
优秀的个人博客,低调大师

开发者如何应对APP臃肿化

【大咖・来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》 先来看一张图: 图上看到,所有平台上用户花费时间都在减少,除了移动端。观察身边也是如此,回家不开电脑的小伙伴越来越多。手机平板加电视,下班场景全搞定。连那些以前电脑苦手的长辈,现在也都活跃在朋友圈上,无责任转发各种小道消息、心灵鸡汤以及人生真谛。 上次在朋友圈发了一张图,晒同事“中二病”的药,立刻被家里长辈好几通电话,一定要我解释解释什么叫中二病…(对治疗中二感兴趣的同学请自行淘宝搜索) 随着用户时间倾斜到移动设备上,移动App对PC软件的取代作用也随之放大。用户期望App能一站式解决所有需求,不需要再切换平台操作。比如网购,从浏览到下单到支付,需要在一台移动设备上搞定。但随之而来的问题是,一些移动App重走PC软件老路,走向臃肿化。 App的臃肿化,一方面是用户需求使然,另一方面也标志着移动互联网进入下半场。大型App,平台型App开始出现,App的功能不断纵深和外延。 然而手机的小屏幕和用户的碎片化使用场景,毕竟不如PC互联网时代的大屏幕,发挥空间有限。照搬PC的大而全的App,很容易遭用户唾弃。 所以,App肿了肿么办? 整合 俗话说要想瘦,先学吃。 现实中,大部分的App还是在不断地添加着新功能。如何更合理地添加功能,使App胖得有节操,是消肿的***步。 1. 扩充导航 通过扩展菜单或导航,加入新的功能模块,是一个非常有效地添加新功能的模式。 如Path在3.0改版时,增加了了表情商店功能,在侧滑导航中添加一个新项就搞定了! 侧滑导航现在越来越常见,一个重要原因就是因为它充分利用了屏幕的纵向高度,具有良好的扩展性。 Acompli是一款邮箱App,如果你通过手机收发Exchange邮件的话,那它绝对值得一试。 这里只看它的架构,和系统默认Mail App相比,Acompli用Tab的形式,把日历,文档,联系人都整合到一个App里。尤其是邮件、日程、待办的整合,对于邮箱重度用户来说,不得不说 是相当高效的设计。不过即使整合地再合理,Acompli整体感觉还是会稍微偏重,取舍就看个人了。 2. Dashboard式的首页 该模式下,更适合有多个独立子功能模块的App。比较典型的案例,照片处理类产品,如美图秀秀,百度魔图,天天P图等。Dashboard模式的优点是扩 展性强,缺点是各模块相互分裂。如Line Tools这款App,本身就是各种小工具的集合,相互之间没有关联,就非常适合Dashboard模式。 3. 增加流程分支 在一些线性操作的App中,功能整合很可能发生在支线节点上。如Instagram为了进军微视频领域,而整合的视频功能。在拍照这里给了一个分支入口,进入视频拍摄模式。 插件 解决App臃肿,不得不提的就是插件化设计,试以微信举例。 微信在集成了聊天,交友,社交媒体,生活服务,社交网络,表情平台,游戏商店如此庞杂的功能的情况下,安装包不过30M出头,很大程度上依赖于插件化的设计思想。 1. 界面框架 微信早期就搭了一个非常有利扩展的界面框架。这使得微信那么多版本,不断增加新功能,但每次新版看起来都变化不大,总是熟悉的4个Tab。每个Tab就像一块主板,功能像内存一样插在上面。 2. 外部插件 相比内部插件,外部插件的耦合度更低,但是功能更强大。如微信在聊天窗口中,点击加号>应用,可以将其他应用的内容发送给好友。 3. 功能可配置 微信相当一部分功能可配置,非常灵活,比如漂流瓶功能,不用的话就可以关闭。还有些功能,当你不用到的时候是不可见的,如公众号。功能可配置+无感化,使得微信在这么大的体量下,依然可以保持相对简单。 分拆 插件化是非常好的思路,但并非每个App都如微信这般,要往平台化方向发展。最近很多国外的App拆分,也是应对功能App臃肿的好方法。如 foursquare一拆为二,把签到功能单独孵化成Swarm App。Facebook动作就更大了,拆分Messenger,试水Paper,下架Poke。App分拆之后,Facebook不用小心顾忌影响主 App,可以大刀阔斧的迭代和试错。Google Drive拆分文档和表格应用,也是一例。 App拆分的好处是,单个App可以更聚焦,拥有更良好的用户体验。 一个更具代表性的例子或许是Line了。基于Line本身的成功,Line公司推出了一系列App,可以称之为App矩阵。各App功能独立,但在 品牌上保持了高度的一致性。通过品牌和Avatar带来的强大影响力,App矩阵进一步增强用户黏性,并非常成功地辐射到周边产品。 拉动 我非常欣赏Facebook、Google对App的杀伐决断。 但是App分拆确实也会带来一些问题:新App需要从0开始积累用户。 而通过已有App去拉动新App的量,是最简单直接地方式。 下面来看看拉动有哪些做法。 1. 广告 InstaFood是一款给照片添加美食信息的App。 左下是它的主界面。通过Drawer切换到What’s new界面时,InstaFood会推送一些广告,比如下图这几个妹子自拍,推荐用户下载他家另一款App Selfiegram。 2. 入口 Line Camera的***一个Icon,Pick。看起来和其他icon类似,是一个功能入口,实际上Pick是Line的另一款独立App。点击这个icon之后,会跳转到Pick的产品介绍页。 3. 产品列表 产品列表模式的应用,更多见于系列App上。如Tapbots这家我很喜欢的公司,他们的设计自成一格,有一批固定粉丝。在App的关于界面,列出了Tapbots的所有产品列表,引导脑残粉去购买其他几款App。 4. 应用推荐 另一类做法更讨巧些,在App中内置应用推荐模块,如手机管家Android版。推荐优质App的同时,当然举贤也不能不避亲,顺便拉动自己公司的其他App:) 打通 App间的拉动,更多见于功能独立的App之间。 对于一些功能耦合度较高的App来说,App间的打通是非常重要的设计点。 1. 插件式打通 插件式的打通,比如在Line中调起Line Camera,在Line Camera中完成任务后,带着结果返回到Line。调用的只是Line Camera功能的局部,始于拍照界面,终于分享界面,是一个封闭的流程。设计师需要关注的重点是,起点和终点两个体验衔接的地方,以及过程中的分支差异 化处理,以保证流程的封闭性。 2. App间打通 点击Facebook的Tab bar上的Messenger按钮,就会直接跳转到Messenger App。不同于插件式打通,这里并不是一个封闭流程,Messenger的所有功能可用。而在Messenger App中,全局的头部高亮区域,可以回到Facebook App,体验非常精准而流畅。这里Messenger App头部的全局返回是一个亮点,跨Tab全局一致,在单独打开Messenger App时不可见,不会影响到Messenger单独使用时的体验。 打通的做法目前还不多见。在系统App中,如iOS通讯录,电话,短信,Facetime中也有体现。但随着App分拆变多之后,多个App之间的协同设计,应该引起设计师关注。 结语 移动互联网不是传统互联网的延续,更应视作颠覆。PC时代的庞然大物,不会也不应该出现在移动平台上。 对于增肥中的App,我们需要更有规划地整合新功能。对于过于臃肿的App,通过合理地插件化/分拆,App间的拉动/打通,才能在小而美和功能复杂性之间找到平衡点。 原文: 腾讯ISUX

优秀的个人博客,低调大师

RWKV-8 预览之 DeepEmbed:对端侧友好的稀疏设计,解决 MoE 显存占用

RWKV-8 "Heron" 是我们的下一代架构,具有多个全新技术。在此我们首先公布其中的 DeepEmbed 技术,它可以实现类似 MoE 的优秀推理性能,同时无需占用显存,甚至无需占用内存,可以让稀疏的大模型真正部署到所有端侧设备。 推理代码:https://github.com/BlinkDL/RWKV-LM/blob/main/RWKV-v7/rwkv_v8_rc00_demo.py rwkv-8-pile 模型:https://huggingface.co/BlinkDL/rwkv-8-pile 下文将详细介绍 DeepEmbed 的原理与实现: 什么是 DeepEmbed DeepEmbed 在模型的每一层 FFN 中为词表中的每个 token 训练一个可学习的高维向量,这可以写成 Embed 层。这些向量在训练阶段可被学习,而在推理阶段可存储于 RAM/SSD 中,对于每个 token 只需预读极少量参数,从而显著减少显存占用。 推理时,模型根据 token index 可提前预读本层的 embedding 向量,用于对 FFN 输出进行逐通道的乘性调制(channelwise scaling)。 这些基于 token 的 embedding 向量构成了一个规模庞大但稀疏的知识库,能够显著提升模型存储和调用世界知识的能力。尽管这些向量看似增加了模型参数量,但不需要占用显存,且在训练过程中可通过 TP(Tensor Parallelism)避免 DP(Data Parallelism)中梯度同步的带宽开销,并可进一步 offload 至 RAM 或 SSD。 在端侧推理场景下,这些向量同样可存储于内存中,或通过mmap等机制直接从硬盘按需加载。每个 token 仅引入几十 KB 的额外访存开销,使该机制非常适合在边缘设备上部署。 DeepEmbed 代码示例 原始 ReLuSq FFN: x = torch.relu(self.key(x)) ** 2 return self.value(x) DeepEmbed_1x ReLuSq FFN: self.deepemb = nn.Embedding(d_vocab, d_emb) ... x = torch.relu(self.key(x)) ** 2 return self.value(x) * self.deepemb(idx) DeepEmbed_4x ReLuSq FFN(效果更佳,参数更多): self.deepemb = nn.Embedding(d_vocab, d_emb * 4) ... x = torch.relu(self.key(x)) ** 2 return self.value(x * self.deepemb(idx)) 从代码可以看出,self.deepemb 用于对 FFN 的输出或中间结果进行乘法缩放。这里的 idx 是输入的 token 索引。需要:注意将 self.deepemb 向量初始化为常数 1,以确保训练初期不会干扰模型行为。 self.deepemb 向量并不直接修改 FFN 的参数,而是以 token 为单位,替代了原本基于输入动态生成的门控向量在通道维度上的乘性调制功能,使模型对 token 的语义或类别具备更强的感知能力。 由于查表操作在推理时不占用 VRAM,这些向量在参数量层面几乎是"免费的"。因此,还可以进一步引入 n-gram(如 bigram、trigram),提升模型对词组/片段的建模能力。如果词表规模较大,也可结合 LoRA 技术降低显存和训练开销。 实验结果表明:相较于 baseline,更大规模的 DeepEmbed 能够带来更显著的 loss 改善。 DeepEmbed 技术在 twitter 公布后,引发多方关注, 包括 ViT 作者 Lucas Beyer。 未来我们会逐渐公布 RWKV-8 的更多创新技术。 加入 RWKV 社区 欢迎大家加入 RWKV 社区,可以从 RWKV 中文官网了解 RWKV 模型,也可以加入 RWKV 论坛、QQ 频道和 QQ 群聊,一起探讨 RWKV 模型。 📖 RWKV 中文文档:https://www.rwkv.cn 💬 RWKV 论坛:https://community.rwkv.cn/ 🐧 QQ 频道:https://pd.qq.com/s/9n21eravc 📺 BiliBili 视频教程:https://space.bilibili.com/3546689096910933

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册