首页 文章 精选 留言 我的

精选列表

搜索[线性回归]，共7936篇文章
优秀的个人博客,低调大师

创始人回归，Solus Linux 改变发展方向

Solus 是一个独立开发的 Linux 发行版，它的一大特色就是 Solus 自创的 Budgie 桌面环境（最新的 Fedora 也已经新增了这个桌面环境），当然用户也可以选择其他常见的 GNOME、MATE 或 KDE Plasma 作为桌面环境。它的软件包管理器 eopkg 是基于 Pardus Linux 的 PiSi 软件包管理系统。 在 2018 年，Solus 的创始人 Ikey Doherty 退出了该项目，并发起了一个名为 Serpent OS 的新发行版。在创始人离开后，Solus 的负责人就变成了 Joshua Strobl，他也是 Budgie 桌面环境的主要开发者。 2022 年 1 月，Joshua Strobl 在担任 Solus 负责人近 4 年后（参与开发工作近 7 年），同样宣布将从该项目中退出，离开后 Joshua Strobl 将加入 Solus 创始人 Ikey Doherty 发起的 Serpent OS 项目，但会继续负责 Budgie 桌面环境上的开发工作。 在这种群龙无首的情况下，今年 1 月 Solus 基础设施遭遇了一个硬件层面的问题，导致服务中断。这一中断，就是近三个月的时间，这个故障严重影响了 Solus 更新和交付软件包，以及 Solus 论坛上的交流或访问网站的功能，甚者导致了轻微的数据丢失。 面对这个问题，Ikey Doherty 领导的 Serpent OS 项目主动提出了解决方法，使 Solus 重新恢复了运营，这也成为了 Ikey Doherty 和 Joshua Strobl 重回 Solus 的一个契机。 近日，在 Solus 官网的一篇博客中，Joshua Strobl 表示 Solus 发行版有了新的方向，将重新基于 Serpent OS。 我们的建议是，在其日常运作的同时，我们将开始探索将我们的发行版重新建立在 Serpent OS 的基础上，并采用 Serpent OS 的工具和流程。这将优雅地解决在如何发展 Solus 并将其带入新未来的问题。 只不过 Serpent OS 目前的状态也是还没有完成，在正式完成之前，Solus 维护者团队将继续发布具有最新组件的新 ISO 镜像，使用户能够在更多最新的硬件上部署 Solus。Solus 具体何时会重新基于 Serpent OS，我们暂时不得而知。
2023-04-19
优秀的个人博客,低调大师

马蜂窝 iOS App 启动治理：回归用户体验

增长、活跃、留存是移动 App 的常见核心指标，直接反映一款 App 甚至一个互联网公司运行的健康程度和发展动能。启动流程的体验决定了用户的第一印象，在一定程度上影响了用户活跃度和留存率。因此，确保启动流程的良好体验至关重要。 「马蜂窝旅游」App 是马蜂窝为用户提供服务的主要阵地，其承载的业务模块不断丰富和完善，产品功能日趋复杂，已经逐渐成长为一个集合旅行信息、出行决策、自由行产品及服务交易的一站式移动平台。 「马蜂窝旅游」iOS App 历经几十个版本的开发迭代，在启动流程上积累了一定的技术债务。为了带给用户更流畅的使用体验，我们团队实施了数月的专项治理，也总结出一些 iOS 启动治理方面的实践经验，借由本文和大家分享。 0X0如何定义「启动」 要分析和解决启动问题，我们首先需要界定启动的内涵和边界，从哪开始、到哪结束，中间经历了哪些阶段和过程。以不同视角去观察时，可以得出不同结论。 技术视角 App 启动原本就是程序启动的技术过程。作为开发人员，我们很自然地更愿意从技术阶段去看待和定义启动的流程。 App 启动的方式分为冷启动和热启动两种。简单来说，冷启动发生时后台是没有这个应用的进程的，程序需要从头开始，经过漫长的准备和加载过程，最终运行起来。而热启动则是在后台已有该应用进程的情况下发生的，系统不需要重新创建和初始化。因此，从技术视角讨论启动治理时，主要针对冷启动。 从技术视角出发，分析 iOS 的启动过程，主要分为两个阶段： pre-main: main() 函数是程序执行入口，从进程创建到进入 main 函数称为 premain 阶段, 主要包括了环境准备、资源加载等操作； post-main: main() 函数到-didFinishLaunchWithOptions:方法执行结束。该阶段已获得代码执行控制权，是我们治理的主要部分。 <premain><postmain> +----------------X------------------------------------X---------> startmain-didFinishLaunchWithOptions: 用户视角 iOS App 是面向终端用户的产品，因此衡量启动的最终标准还是要从用户视角出发。 从用户视角定义启动，主要以用户主观视觉为依据，以页面流程为标准。这样看来，常见的 App 启动可以分为三个阶段： T1：闪屏页 闪屏页是启动过程中的静态展示页。在冷启动的过程中，App 还没有运行起来，需要经历环境准备和初始化的过程。这个过渡阶段需要展示一些视图，供阻塞等待中的用户浏览。 iOS 系统 (SpringBoard) 根据 App Bundle 目录下的 Info.plist 中"Launch screen interface file base name"字段的值，找到所指定的 xib 文件，加载渲染展示该视图。 闪屏页的展示是系统行为，因此无法控制；加载的是 xib 描述文件，无法定制动态展示逻辑，因此是静态展示。 对应技术启动阶段的 pre-main 阶段 T2(可选)：欢迎页（广告） App 运行后根据特定的业务逻辑展示的第一个页面。常见的有广告页和装机引导流程。 欢迎页是业务定制的，因此可根据业务需要优化展示策略，该阶段本身也是可选的。 T3：目标页(落地页) App 启动的目标页。 可以是首页或特定的落地页 目标页的加载渲染渲染完成标志着 T3 阶段的结束，也标志着启动流程的结束。 启动治理的最终目标是提升用户体验，在这样的思想下，本文关于启动流程的讨论主要围绕用户视角进行。 0X1方法论及关键指标 APM 方法论 对 iOS 启动的治理，本质上是对应用性能优化 (App Performance Management) 的过程，其基本的方法论可以归纳为： 界定问题 准确描述现象，确定问题的边界 确定量化评价手段，明确关键指标 分析问题 分析问题产生的主要原因，根本原因 确定问题的重要性，优先级 性能问题可能是单点的短板，也可能是复杂的系统性问题，切忌「头痛医头，脚痛医脚」。要严谨全面地分析问题，找到主要原因、根本原因予以优先解决 解决问题 确定解题的具体技术方案 根据关键指标量化成果 对问题进行总结，积累沉淀 持续监控 性能问题是持续的，长期的 对关键技术指标建立长效的监控机制，确保增量能被及时反馈，予以处理 关键指标 1. 启动耗时 启动耗时是衡量启动性能的核心指标，因为它直接影响了用户体验并对用户转化率产生影响。 对启动耗时指标的拆解有助于细粒度地监控启动过程，帮助找到问题环节。具体可以拆解为： 技术启动耗时指标 pre-main core-postmain 主观启动耗时指标 T1_duration ：从程序运行起点到主视窗可见 T2_duration T3_duration total_duration 根据对马蜂窝 App 用户的行为数据分析确认，我们得到以下结论： 启动耗时和启动流失率正相关 启动耗时和次日留存负相关 2.启动流失率 1). 如何定义启动流失 用户视角的启动流程完成前（即目标页渲染完成前），用户主动离开 App(进入后台，杀死 App, 切换到其他 App 等)，记做一次启动流失。 启动流失率计算公式为： 启动 PV 流失率：启动流失 PV / App 首次进入前台 PV 启动 UV 流失率：启动流失 UV / DAU UV 绝对流失率：当日仅进入前台一次且流失的 UV / DAU 2)如何定义首次进入前台 我们先来区分下冷启动，热启动和首次进入前台的概念： iOS App 有后台机制，App 可在某些条件下，在用户不感知的情况下在后台启动（如后台刷新）。由于用户不感知，如果当日该用户没有主动进入前台，则不会记作活跃用户。因此，单纯的后台启动不是启动流失率的分母。 但是当 iOS App 从后台启动，并留在内存中没有被操作系统清除，而一段时间后，用户触发 App 进入前台，这种情况虽然是热启动，但应被看作「首次进入前台」。 3)如何定位流失的时机 根据定义，用户主动离开 App 则记作一次流失。从技术角度可以找到两个点： applicationdidEnterBackground applicaitonWillTerminate 但在实践的典型场景中我们发现，从用户点击 Home 键到程序接收到-applicationdidEnterBackground 回调存在一定的时间差，该时间差会影响到流失率的判断。 例如，用户在时刻 0.0s 启动 app，启动总时长为 4.0s。用户在时刻 3.8s 点击了 home 键离开 App，则应该记作 launch_leave = true。而程序在时刻 4.3s 接收到了-applicationDidEnterBackground 回调，此时启动已经结束，获得了启动耗时 4.0s。通过比较 Tleave > Tlaunch_total，则错误地记为launch_leave = false。 由此推测，这里的 delay 是设置灵敏度阻尼，消除用户决策的摆动。这个延时大约在 0.5s 左右。 为了避免这个误差，我们的解决方案是利用 inactive 状态，找到准确的用户决策起点: 用户即将离开前台时，会先进入 inactive 状态，通过-appWillResignActive：拿到决策起点的时间戳 Tdetermine 根据用户最终决策行为，是否确实离开，再决定决策 Tdetermine 是否有效 最终根据有效的 Tdetermine 作为判断流失行为的标准，而不是-applicationdidEnterBackground 的时间点 3.启动广告曝光率 广告是 App 盈利的主要手段之一。广告曝光率直接决定了广告点击消费率；而广告曝光 PV 和加载 PV 直接影响了广告售价。 我们定义：启动广告曝光率 = 启动广告曝光 PV / 启动广告加载 PV。 其中广告素材需要下载，素材渲染需要一定耗时，这些都会对广告曝光率产生影响。进一步来说，启动广告的曝光率会受到 App 启动性能的影响，但更主要的是受缓存和曝光策略的影响，详细阐述在下文「精细化策略」部分介绍。 0X2iOS App 启动优化 以上，我们对 iOS App 启动治理的思路和关键指标进行了分析和拆解，下面来说一下从技术层面和业务层面，我们对启动性能的优化和流程治理分别做了哪些事情。 一、技术启动优化 1.优化pre-main 1). pre-main主要流程分析 在进行该阶段的优化前，我们需要对 Pre-Main 阶段的过程有所了解，网上的文章较多，这里主要推荐两篇 WWDC 参考文章： App Startup Time: Past, Present, and Future（https://developer.apple.com/videos/play/wwdc2017/413/） Optimizing App Startup Time（https://developer.apple.com/videos/play/wwdc2016/406/） 总结来看，pre-main 主要流程包括： 1. fork 进程 2. 加载 executable 3. 加载 DYLD 4. 分析依赖，迭代加载动态库 a. rebase b. rebind c. 耗时多 5. 准备环境 a. 准备 OC 运行时 b. 准备 C++环境 6. main 函数 2).优化建议 尽量少使用动态库 a. 尽量编译到静态库中，减少 rebase，rebind 耗时 b.尽量合并动态库，减轻依赖关系 控制 Class 类的数量规模 由于 selector 需要在初始化时做唯一性检查，应尽量减少使用 少用 initializers a. 严格控制 +load 方法使用 多用 Swift a. Swift 没有运行时 b. Swift 没有 initializers c. Swift 没有数据不对齐问题 3).性能监控：如何获取启动起点 启动的结束时间相对来说是比较好确定的，但如何定位启动的起点，是启动监控的一个难点。 对于开发环境，可以通过 Xcode 配置启动参数，获得 pre-main 的启动报告： DYLD_PRINT_STATICS=1 对于线上环境，根据 premain 主要流程的分析，我们的解决方案是： 创建动态库 ABootMonitor.dylib ABootMonitor.dylib实现+load 方法，记录启动起点时间 将 ABootMonitor.dylib 放在 executable 动态库依赖的头部 通过上述方法，可以在线上环境尽量地模拟出最早的启动时间点，从而更好地监测优化效果。 2.优化post-main post-main 阶段的技术优化主要针对两个方法的执行耗时来进行： - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions: - (void)applicationDidBecomeActive:(UIApplication *)application; 为什么包含 2，需要我们对 iOS App 生命周期有一定理解。从操作系统的视角来看，iOS App 本质上是一个进程。对于 Mac OS/iOS 系统，进程的生命周期状态包括了： not-running running 进程激活，可以运行的状态 suspend 进程被挂起，不可以执行代码，通常在 UIApplication 进入后台后一段时间被系统挂起 zombie 进程回收前的临时状态，很短暂 terminated 进程终止，并被清理 而对于 UIApplication，定义了生命周期状态： //UIApplication.h typedefNS_ENUM(NSInteger,UIApplicationState){ UIApplicationStateActive,//前台，UIApplication响应事件 UIApplicationStateInactive,//前台，UIApplication不响应事件 UIApplicationStateBackground//后台，UIApplication不在屏幕上显示 }NS_ENUM_AVAILABLE_IOS(4_0); 组合起来的状态机如下图： 通过上面的讨论，我们可以分析出以下问题： UIApplication 会因为某种原因，在用户不感知的情况下被唤起，进程进入 running 状态，但停留在 iOS 的 background 状态 每次冷启动都会执行- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:，但未必进入前台 在 didFinishLaunchingWithOptions 中进行大量 UI 和网络请求等操作是不合理 post-main优化思路和建议 整理拆分启动项，以启动项为粒度进行测量 启动项执行尽量在背景线程 启动的过程 CPU 占用较高，占用主线程会导致卡顿，耗时延长，用户体验不佳 启动项并发执行 启动项延迟执行 当 CPU 时间片跑满时，使用多线程并发不能提高性能，反而会因为频繁的线程上下文切换，造成 overhead 耗时增长 尽可能将启动项延迟执行，在时间轴上平滑，降低 CPU 利用率峰值 启动项分组 -didFinishLaunchingWithOptions 只执行必要的核心启动项 其他启动项，在首次调用-applicationDidBecomeActive:后执行 二、精细化策略 1. 交互优化 通过技术的实现手段，我们可以从客观上减少启动的绝对耗时。而从用户视角来看，对于启动是否流畅会受到很多心理因素的主观影响。因此从另一方面，我们可以从优化交互的角度提升用户体验。 避免阻塞等待 我们都希望用户可以尽快地使用 App，不要出现流失。但在快消费的时代，用户的耐心是极其有限的。 因此，如果有理由需要用户进行等待，就应该注意尽量避免产品流程是阻塞的。即使有更充足的理由必须让用户在阻塞状态原地等待，也应该给用户提供可响应的交互。 例如，在 T2 欢迎/广告页阶段，为了避免用户阻塞等待，应该提供明显的「跳过」按钮，允许用户进行跳过操作。 如果非要用户在这个阶段等待不可，也可以花一些小心思提供可响应的交互，比如点击触发视觉的变化等，不要让用户除了等待无事可做。 增加视觉信息量 增加屏幕上视图的信息量提供给用户消费，转移其注意力，降低用户对等待的感受。 例如，在 T1 闪屏页阶段，用户处于阻塞等待的状态，无法跳过。而且闪屏页是系统渲染的静态视图，我们无法提供动态响应。那么，我们可以通过在静态视图上提供更多信息量，给等待中的用户消费。 主观感受对比如下图： 合理的动态提示 合适的动画 事实上，早期在部分高性能 Android 设备上，App 的启动比同水平 iDevice 要快。但由于 iOS 设计了符合神经认知学的交互动画，使得主观感受到的时间缩短。 动画是否「合适」，关键在于对场景的选择和数量的把握。一个常见的动画耗时约为 0.25s，对于启动流程来说，已经可以解决或掩盖不少问题了。 合适的提示信息 好的交互体验和产品流程，至少应该是符合用户预期的。给以合适的动态提示，让用户知道此刻使用的 App 正在发生什么，可以极大地提升用户体验。 例如在 T2 广告页阶段，广告需要占时 3 秒钟的时间。交互上建议给与广告消失的倒计时提示： 一方面，倒计时提示可以有动态 loading 的视觉效果，展现 App 的良好运行； 另一方面，倒计时可以让用户安心，主观上耗时减少，情绪上不至于焦虑和退出。 2.基于场景的启动会话 根据对启动过程的定义，我们可以列举出一些启动的「起点」和「终点」，比如： 启动触发点： 点击 App 图标正常启动 初次安装 点击 PUSH 进入 应用间跳转 3DTouch Siri 唤起 其他 启动终点--目标页： 应用首页 指定的落地页 可以看出，启动的起点和终点多种多样，而对于启动流程的设定，很多都是和业务场景强相关的，比如： 初次安装需要进入装机引导流程 正常启动需要展示广告 PUSH 进入可以不展示广告，直达落地页 其他 如何才能维护这些复杂的启动关系，提高业务承载能力呢？我们的优化思路是基于场景创建启动会话： 由启动参数和其他条件确定启动场景 根据启动场景创建具体的启动会话 启动会话接管之后的启动流程 3.启动广告曝光和缓存策略 广告曝光主要流程为：请求广告接口 —> 准备广告素材 —> 展示广告页，进行曝光。 在准备广告素材环节，我们会判断广告素材是否命中缓存。如果命中则直接使用缓存，这样可以明显缩短广告加载的时间。如果没有命中，则开始下载广告素材。当广告素材超过设定的准备时长，则此次曝光不显示。 通过以往数据量化分析，我们发现通常情况下，广告未曝光的主要原因是由于广告素材准备超时，且素材体积和广告曝光率是负相关的。为了保证广告的曝光率，我们应该尽量减少广告素材的体积，并且提高广告素材缓存的命中率。 下面分别介绍下我们的启动广告预缓存策略和启动广告曝光策略。 启动广告预缓存策略 广告素材接口和广告曝光接口分离 在可能的合适时机，下载广告素材 ​​​​​​例如后台启动，后台刷新等 尽可能地提前下发广告素材 拉长广告素材投放的时间窗口 常见地可提前半月下发广告素材 对于「双十一等大促活动，应尽早地下发素材 启动广告曝光策略 分级的广告曝光QoS策略 ​​​​​​​若业务许可，可对广告优先级进行分级 对于低优先级，应用 cache-only 的曝光策略 对于普通优先级，应用 max-wait 的曝光策略 对于高优先级，应用 max-retry 的曝光策略 灵活的曝光时机选择 通常我们仅在首次进入前台时，进行广告曝光，但这有一定的缺陷： 启动耗时长了，用户体验差，启动流失率高 对于当日只有一次启动且启动流失的用户，丢了这个 DAU 我们可以在 App 首次进入前台，和热启动切回前台时选择时机，进行有策略的曝光 可依据策略，在首启时不展示广告页，提升用户体验，DAU，减少启动流失 可在 App 切回时展示，提升广告曝光 PV，和曝光率。 由于 App 之前已经启动，此时大概率已经缓存了广告素材 由于 App 一次生命周期存在多次切回前台，曝光 PV 可以得到提升 根据马蜂窝 App 的统计分析，在激进策略下可提升曝光 PV 约 4 倍 三、合理利用平台机制 iOS 经过多年的迭代，提供了很多智能的平台机制。合理利用这些机制，可以强化 App 的功能和性能。 1.内存保活 我们已经讨论了冷启动和热启动的区别： 冷启动是进程并不存在的状态，一切需要从 0 开始。 热启动是指进程在内存中（iOS 不支持 SWAP），此时可能处于 background 的 running 状态或 suspend 状态，用户唤起进去前台。 热启动可以极大地减少 T1 闪屏页时间，从而减少启动耗时。 因此，我们应该尽量增加热启动概率，并且尽量减少 App 在后台被系统回收的概率。 iOS App 生命周期中关于系统内回收策略如下： App 进入后台后，进程会活跃一段时间后，会被操作系统挂起，进入 suspend 状态。除非在 info.plist 指定进入后台即退出。 前台运行的 App 拥有内存的优先使用权 当前台的 App 需要更多物理内存时，系统根据一定策略，将一部分挂起的 App 进行释放 系统优先选择占用内存多的 App 进行释放 优化思路： App 进入后台时，应该将内存资源竟可能的释放，尽量在内存中保活 尤其对于可重得的图片，文件等资源进行释放 对于可持久化的非重要内存，也可做持久化后释放 对于线上，应利用后台进程激活状态，加强对后台内存使用的监控 2.后台拉起 iOS 系统提供了一些机制，可以帮助我们实现在用户不感知的情况下拉起 App。合适的拉起策略，可以优化 App 性能和功能表现，比如提升当日首启热启动的概率；在后台准备更新一些数据，如更新 PUSH token、准备启动广告素材等。 iOS 常见的后台拉起机制包括： Background-fetch 后台刷新 需要权限 在某特定时机拉起，智能策略 PUSH 静默推送 远端推送 aps 中指定 "content-available = 1" App 实现相关处理方法 地理围栏 后台网络任务 NSURLBackgroundSession VOIP 等其他 使用后台机制时，有以下几点需要注意： 常见的后台机制需要 entitlement 声明和用户授权 部分节能模式会使部分拉起机制失效，导致节能量模式不可用 拉起策略参考用户意图，用户主动杀死 App，会使部分拉起机制失效 正常进入后台，该 App 会向系统应用「AppSwitcher」注册，并受其管理 如果用户主动杀死 App，该 App 不会向「AppSwitcher」注册 后台拉起时，主要从 AppSwitcher 的注册列表选择 App 进行操作。例如，后台刷新会根据某种策略排序，依此拉起 AppSwitcher 中注册的部分 App 批量拉起会导致服务端接口压力过大 例如使用 PUSH 拉起，则短时间内可能有数千万的 App 被拉起，此时接口请求不亚于一次针对服务端的 DDOS 攻击，需要整理和优化 四、结构化定制 页面栈/树优化 App 通过页面进行组织，在启动过程中，我们需要构建根页面栈。 由上分析我们知道，App 存在后台拉起，我们建议在首次进入前台时才进行页面渲染操作。但另一方面，根页面栈是 App 的基本结构，应该作为核心启动流程。因此我们提出以下解决方案： 涉及启动的页面，如首页、落地页等，应将页面栈创建、数据请求、页面渲染分离 在核心启动流程 (didFinishLaunch) 创建核心页面栈 在即将进入前台时，异步请求数据 在目标页即将展示时，进行渲染 例如，在广告页消失前的 1s，通知首页进行渲染，如下图 由于目标页可能和 T2 等启动阶段重叠，应特别注意页面加载的性能问题，避免交叉影响 0x3结语 经过团队 3 个月的持续优化治理，马蜂窝 iOS App 的启动优化取得了一些成果： 启动耗时：约 3.6s，减少约 50% PV启动流失率：降低约 30% 启动广告曝光率：大幅提升 ios App 的启动治理乃至性能管理，是一个长期且艰巨的过程，需要各位开发同学具备良好的对平台和对代码性能的理解意识。其次，性能问题也常常是一个复杂的系统性问题，需要严谨地分析和推理，在此感谢支持以上工作的马蜂窝数据分析师。最后，这项工作需要建立完善的性能监控机制，持续跟踪，主动解决。 OneMore Thing 我们计划于近期将马蜂窝 iOS 的启动框架开源，欢迎持续关注马蜂窝公众号动态。期待和大家交流。 本文作者：许旻昊，马蜂窝 iOS 研发技术专家。 （马蜂窝技术原创内容，转载务必注明出处保存文末二维码图片，谢谢配合。） 关注马蜂窝技术公众号，找到更多你需要的内容
2019-05-10
优秀的个人博客,低调大师

始于阿里，回归社区｜阿里巴巴的开源之路

破土而出的生命力，源自理想主义者心底对技术的信念。 开源曾经帮助 Redhat 在传统软件市场奠定了其行业地位。无独有偶，作为云计算时代的赶超者，谷歌也拿起了开源的武器，试图打乱 AWS 和 Azure 的节奏。 目前，这一策略似乎正在奏效。 如今云原生技术正席卷全球，云原生基金会在去年 KubeCon +CloudNativeCon NA 的现场宣布： 其正在孵化的项目已达 14 个，入驻的厂家或产品已超过 300 家，并吸引了 2.2 万开发者参与项目代码贡献，其明星产品 Kubenetes 的 GitHub 上 Authors 和 Issues 量已排行开源领域的第二名。而 Kubenetes 正是 Google 开源的一个容器编排引擎。 今年，KubeCon + CloudNativeCon 首次来到中国。 在2018 KubeC
2018-11-15
优秀的个人博客,低调大师

麦肯锡：物联网遭过度吹嘘 市场应回归理性

研究机构麦肯锡(McKinsey)近日出了一份物联网发展专业报告，指出物联网进展比预期慢，其中尤以工业部门对物联网应用的部署的步伐较缓慢。其中，半导体企业可以通过新技术和商业模式来说明加速物联网的发展。 报告指出，物联网处于早期创新阶段，缺乏一致的标准和类似的挑战经验，但短短几年，已有大量智能设备具有通过网络或云端无缝通信的能力，其中包括自动调节温度的恒温器和可以通知车间主管机器状况的生产线传感器，以及车联网如自动驾驶、无人驾驶等。 值得注意的是，市场上存在着一些对物联网的发展潜力过份吹嘘的成分，尽管物联网将对社会产生革命性影响，同时也指出，要实现物联网带来的利好以及物联网应用的广泛采用可能需要比预期更长的时间。 目前消费者比以往任何时候都更加关注物联网，平均每人拥有4个可进行云端通信的物联网设备。从全球来看，每一秒就有127台新设备连接到网络。 报告预计，到2025年物联网的经济影响价值将达每年3.9万亿美元至11.1万亿美元。物联网连接范围将涵盖不同环境中装置，包括工厂、城市、零售和人类本身。 物联网也受益于增强连接性的基础设施的改进。例如，现在仅有20%的全球人口被低功耗广域网(LPWAN)覆盖，从而允许连接设备之间的长距离通信，同时优化成本和功耗需求。 但到2022年，LPWAN将覆盖100%人口，促进更加集成化的物联网解决方案的开发。例如，用于扫描和检测周围环境的激光雷达传感器对自动驾驶非常重要。过去8年，其价格已经下降了10倍以上，预计在未来2年下降幅度超过65倍。 然而报告认为，物联网在工业部门的增长速度低于预期。工业部门对物联网应用的部署的步伐较缓慢，因为企业往往受到资本周期、组织惯性以及能够开发和部署物联网解决方案的人才短缺等问题的限制。 麦肯锡调查了包括公用事业部门、离散制造业、石油天然气、矿业、电讯、科技媒体、医疗保健和制药业等100多位领导。结果显示多数企业仅在有限的范围内采用物联网技术。大多数受访者说，企业部署仍然在停留在“概念验证”阶段，尚未开始大规模项目实施。 此外，企业领导者在做出重要决策维护计划或自动化程序相关的决策时，较少考虑物联网传感器的信息，重要原因是缺乏物联网数据分析人员。对于当前许多半导体企业而言，跨入物联网是未来持续增长很关键的一点。 对半导体公司来说，物联网视频和音频信号源的重要性越来越高，可能会将硬件与端到端解决方案结合起来进行分析和控制，例如分析识别面孔的应用、更紧密集成的硬件和软件产品、优化设备、网络和云端的传输、高效处理和分析的运算能力等。 物联网与视频和音讯馈送相关的成本正在下降，传感器成本可低于2美元。此外，5G网络飞速发展以及云存储成本的持续下降将继续鼓励开发人员发现视频和音讯的新用途。 半导体公司有机会进一步、更快的定义物联网未来架构。尤其专注于与视频和音频传感器相关的产品，因为这些物联网相关应用数量正在不断增长并产生了大量的数据。 当前的物联网趋势尽管仍有不确定性，然而物联网有望成为半导体公司的主要增长动力。尽管物联网采用率上升速度比预期的要慢，但这不应该是悲观的原因，因为代表许多物联网新技术商机正崛起。 本文转自d1net（转载）
2017-07-02
优秀的个人博客,低调大师

慕尼黑市IT负责人：回归Windows不是技术原因

【大咖・来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》 慕尼黑市计划放弃已用多年的 Linux，到 2021 年重新投入 Windows 的怀抱。慕尼黑市 IT 负责人 Karl-Heinz Schneider 却表示根本没有技术上的理由要转回 Windows，对于城市做出此决定表示惊讶。 Schneider 说慕尼黑已经解决了与运行在 LiMux(基于 Ubuntu)上的业务线软件相关和与外界交换文档的兼容性问题。这些兼容性问题正是被科罗拉多州立大学的政客引用为是慕尼黑需要改变操作系统、放弃 LibreOffice 和其他开源软件以重新使用 Windows 和 Microsoft Office 的一个主要理由。 他指出已经通过在需要使用 Office 文档与外部组织合作的工作站点上提供 MS Office 解决了兼容性和互操作性问题，使用 LiMux 和 LibreOffice 不再存在大的技术问题。 回顾在上个月的理事会对 LiMux 的未来进行投票时，CSU 的成员 Kristina Frank 曾表示，该操作系统已不适合继续使用。 “德国和全世界的大多数工作场所都在运行其他系统，Linux 可能是许多用户的正确选择，但它不是慕尼黑的。我们的 LiMux 系统从根本上就不是很高效、直观，并且经常出现问题，比如常规的兼容性问题”，她说。 不过 IT 负责人这次的说法呼应了慕尼黑绿党和自由软件欧洲基金会对于抛弃 LiMux 的批评，两个组织认为 LiMux 是慕尼黑 IT 结构性和组织问题的替罪羊。
2017-03-13

资源下载

更多资源
腾讯云软件源

腾讯云软件源

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

时间: 2026-08-21 大小: 1MB 下载: 10次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-08-21 大小: 189MB 下载: 7次
Sublime Text

Sublime Text

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

时间: 2026-08-21 大小: 9.84MB 下载: 40次
WebStorm

WebStorm

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

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册