为什么国内的软件很臃肿,而且还没有国外的发达?

大家有没有发现,国内的很多软件普遍都比较臃肿?日常软件APP的规模变得巨大,安装包所占的空间也在增加,一个普通的网络游戏安装之后占用超过10GB的空间,如果多安装几个,手机存储根本顶不住。关键是,虽然国内软件APP的体积越来越大,但是似乎还没有国外的发达?

国内的软件为什么越来越臃肿?

国内的软件APP越来越臃肿,主要的原因有2个:

1、一个应用程序中的功能太多,涉及面越来越广,内存变大。

2、app广告多,显得眼花缭乱。

广告方面占用的内存大主要有两点,第一点是开发者没有足够的资金去开发自己的app,必须寻求商家合作,而和一些商家合作的结果就是app上面打上他们的广告;当然,还有一种选择就是开设vip接口,限制用户使用,而用户又必须开通会员才能解除app的限制。

第二点就是开发者开发app是纯粹用来接广告赚钱的,这样当然不用管用户体验,也不用管它是否臃肿了。

功能太多占用内存大的原因:用户使用过软件后通常会反馈体验,这时开发者考虑到app的发展以及其他和它竞争的app,就会不竭余力的更新软件,总想让它满足更多人的需求,想让它面面俱到。

这样一来,软件APP的内存就只会越来越臃肿了。

一般软件APP安装包体积暴增的更多是游戏和社交类APP。

一开始王者荣耀安装包也就 200MB,如今已经快 1.9GB 大,体积都快增加 10 倍之多;还有常用的 QQ,从 8MB 到 294 MB,体积直接暴增36倍;微信则从 24MB 到 237MB,体积也增加了差不多10 倍......

还有大家以为“小而美”的抖音极速版,体积从 13MB 到现在的 93MB,不知不觉的也达到了普通版的水准;至于 QQ 音乐、钉钉等 App,体积也从 10MB 到现在的 150MB 往上,可以说非常夸张!

最后,还有多御浏览器,从最初的2.64MB到如今的21MB,体积也增加将近18倍。至于UC浏览器,体积从2.54MB到现在的89MB,体积增加了35倍。毫无疑问,所有的APP安装包到后面都越来越大了。

多御浏览器体积虽然没有UC浏览器的安装包那么大,但是它的功能却十分强大,可以和UC浏览器媲美。如果手机内存不够大,需下载的APP大小不一样,功能差不多,那么用户绝大部分愿意选择安装包体积较小的那一个。因此,软件APP的安装包大小,也成为了用户考虑是否下载的一个重要因素。

为什么国内软件还没有国外的发达?

国内软件没有国外的发达,主要有2个方面的原因:

1、发展时间问题

国外软件行业蓬勃发展的时候,中国还在玩泥巴,等到国家改革开发之际,这时候的主旋律是信息化了。现在我们熟知的大型商业软件基本上都是上世纪80年代的产物,但进入新世纪,发展互联网平台科技才是潮流和趋势。

2、国内公司重商业收入,轻底层技术

因为在互联网行业做了挺久,就重点说说互联网行业中外技术差距。

我国的互联网公司大多在应用层做商业创业,底层的技术创新基本没有,我们可以做出来电商、社交、外卖、社区团购只、p2p、各种o2o,但是在底层技术上,中国互联网公司近乎集体缺席。

几种技术含量最高的软件: 操作系统(微软&苹果)、浏览器内核(谷歌)、游戏引擎、编译器QIDE、各种专业开发工具Q (CAD, PS,3DMax, Maya, Houdini),在这些领域完全看不到中国互联网公司的身影。

本质原因是研发这些东西不能赚快钱,做2C的小应用不仅省钱,火了还能躺着收钱。

在移动互联网时代,大家对手机有严重的依赖性,因为使用手机能够处理很多事情。如果想通过手机实现更多功能,就需要安装更多的APP,进一步而言大家对APP也非常依赖。

在流量为王的版本中,各大软件厂商互相争夺用户流量,为了让自己的APP更加有竞争优势,纷纷借助微信、QQ、淘宝、微博等庞大的用户与流量入口,通过塞进各种功能抢占更多的核心用户。

总而言之,国内APP因为功能越来越多,并且为了获得更大的利益,在App上打很多广告,未来APP也只会越来越大。国内的软件也因为国内公司重商业收入,轻地层技术,还有发展时间等问题,并没有得到很好的发展,以至于国内的软件没有国外的发达。

<think>好的,我现在需要回答用户的问题:为什么在开发环境中必须使用虚拟环境,特别是在使用EVO工具或其他类似场景时?用户之前已经询问过EVO在不同系统上的安装差异,现在想深入理解虚拟环境的必要性。 首先,我得回顾之前的对话内容,确保回答的一致性和连贯性。用户提到了几个引用,关于虚拟环境的创建和管理,比如使用virtualenv、conda等工具。这些引用强调了虚拟环境在管理Python项目中的作用,比如隔离依赖、避免版本冲突等。 用户的问题核心是“为什么必须使用虚拟环境”,我需要从几个方面来展开: 1. **依赖隔离**:不同项目可能需要不同版本的库,虚拟环境可以防止全局安装的库互相冲突。比如,项目A需要numpy 1.18,而项目B需要numpy 1.20,虚拟环境可以分别管理这两个版本。 2. **环境一致性**:确保项目在不同环境(开发、测试、生产)中运行一致,避免因环境差异导致的问题。例如,EVO工具可能依赖特定的matplotlib版本,虚拟环境可以锁定这些依赖。 3. **权限管理**:在Linux或macOS系统中,全局安装可能需要sudo权限,而虚拟环境允许用户在不影响系统全局环境的情况下安装包,避免权限问题。这点在用户之前的问题中提到过,尤其是在Windows中使用Anaconda时的权限处理。 4. **项目可移植性**:通过虚拟环境,可以轻松导出依赖列表(如requirements.txt),其他人或环境可以快速复现相同的配置。这对于团队协作或部署非常重要。 5. **避免污染系统环境**:全局安装过多包可能导致系统Python环境变得臃肿,难以管理。虚拟环境保持每个项目的独立性,便于维护和清理。 6. **多Python版本支持**:比如,某些项目可能需要Python 3.7,而另一个项目需要Python 3.9。虚拟环境允许在同一台机器上管理多个Python版本,而不互相干扰。这在用户之前的回答中也提到过,EVO推荐使用Python 3.8+,而旧版本可能与Python 2.7兼容,这时候虚拟环境就非常有用。 接下来,结合用户提供的引用,比如引用[1]提到虚拟环境的创建和管理,引用[2][3]讨论虚拟环境的命令和步骤,引用[4]关于conda的环境激活,这些都是支持上述观点的论据。需要将这些引用自然地融入回答中,作为理论依据或实例。 同时,用户之前的问题涉及EVO在不同系统上的安装问题,比如Windows使用Anaconda,macOS需要Xcode工具等。在回答时,可以结合这些实际案例,说明虚拟环境如何解决跨系统环境配置的问题。 可能还需要提到虚拟环境如何帮助解决EVO安装中的兼容性问题。例如,在用户之前的回答中,EVO在Windows下可能需要通过conda创建独立环境,避免与其他项目冲突,或者解决Python版本不匹配的问题。 需要确保回答结构清晰,分点列出,每个点都有具体的例子或引用支持。同时,语言要简洁,符合用户要求的“结构清晰,逐步解决问题”。 另外,用户可能对虚拟环境的具体操作感兴趣,但当前问题主要关注“为什么”而非“怎么做”,所以需要避免过多涉及操作步骤,但可以简要提及常用工具如venv、virtualenv、conda等作为例子。 最后,生成的相关问题需要与虚拟环境相关,帮助用户进一步探索,比如如何创建、管理虚拟环境,或者解决特定环境下的问题。</think>### 为什么在开发环境中必须使用虚拟环境? 在Python开发中(尤其是使用EVO工具等依赖特定环境的场景),虚拟环境是**隔离项目依赖、避免系统污染、保障环境一致性**的核心工具。以下是具体原因和实际场景分析: --- #### **一、解决依赖冲突问题(核心价值)** - **场景示例**: - EVO依赖`numpy>=1.18`和`matplotlib>=3.3`,而另一个项目可能要求`numpy==1.16`。若全局安装,版本冲突会导致程序崩溃。 - **虚拟环境作用**:为每个项目创建独立依赖空间,隔离不同版本的包[^1][^3]。 - **技术原理**: 虚拟环境通过独立的`site-packages`目录管理依赖,避免全局安装路径(如`/usr/lib/python3.8`)被污染。 --- #### **二、保障环境一致性** - **开发与部署同步**: EVO的轨迹分析可能依赖特定版本的`opencv-python`,通过虚拟环境生成`requirements.txt`,可确保测试和生产环境完全一致[^1]。 ```bash pip freeze > requirements.txt # 导出依赖清单 ``` - **跨团队协作**: 团队成员通过`requirements.txt`或`environment.yml`(conda)一键复现相同环境,避免“在我电脑上能运行”的问题[^4]。 --- #### **三、权限与系统安全** - **避免`sudo`风险**: 在Linux/macOS中,全局安装库需`sudo pip install`,可能误修改系统关键依赖(如`openssl`),而虚拟环境仅影响当前项目目录[^2]。 - **Windows权限限制**: 企业环境中用户可能无管理员权限,虚拟环境(如通过Anaconda)允许在用户目录下安装私有依赖[^4]。 --- #### **四、多版本Python共存** - **灵活切换解释器**: - EVO需Python 3.8+,而旧工具链可能依赖Python 2.7。通过`conda`可快速创建不同Python版本的环境[^4]: ```bash conda create -n evo_env python=3.8 # 专为EVO配置 conda create -n legacy_env python=2.7 # 旧项目专用 ``` --- #### **五、EVO工具的具体实践** 1. **避免系统依赖污染**: EVO的C++扩展(如`evoTools`)编译时需`python-dev`头文件,虚拟环境隔离编译过程,防止与系统Python开发包冲突[^3]。 2. **跨系统兼容性**: 在Windows中通过WSL+虚拟环境模拟Linux路径结构,解决EVO脚本的`/home/user`路径报错问题[^2]。 --- #### **六、虚拟环境工具对比** | 工具 | 适用场景 | 典型操作(以EVO为例) | |---------------|------------------------------|---------------------------------------| | **venv** | Python 3.3+原生支持 | `python -m venv evo_venv` | | **virtualenv**| 兼容Python 2/3 | `virtualenv --python=python3.8 evo_env` | | **conda** | 跨语言依赖管理(C++/Python) | `conda install -c conda-forge evo` | --- ### 总结:为什么“必须”使用? 1. **依赖隔离** ➜ 解决版本冲突(如EVO与ROS的Python 2/3兼容性问题)[^1]。 2. **环境可移植性** ➜ 通过`requirements.txt`实现“一次配置,处处运行”[^3]。 3. **系统安全** ➜ 避免权限滥用和关键依赖篡改。 --- ### 相关问题 1. 如何为EVO工具创建专用的conda虚拟环境? 2. 虚拟环境和Docker容器在环境隔离上有何区别? 3. 如何修复因虚拟环境路径错误导致的EVO执行失败?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值