首页 最新 热门 推荐

  • 首页
  • 最新
  • 热门
  • 推荐

苹果的困境源于优质移动应用的垮台吗?

  • 24-03-05 03:21
  • 4042
  • 13872
blog.csdn.net

快速挑战Python全栈工程师:

https://edu.csdn.net/topic/python115?utm_source=csdn_bw

 

640?wx_fmt=gif

九年前,苹果在 App Store 中推出了应用内购买。正如人们预测的那样,这引发了开发者为消费者构建和设计应用的方式的“根本性转变”。如今,这个改变了我们消费移动内容的方式是否会导致苹果 iPhone 的销售陷入困境?

640?wx_fmt=jpeg

 

作者 | Zachary Spears

译者 | 弯月

责编 | 屠敏

出品 | CSDN(ID:CSDNNews)

以下为译文:

在第一部 iPhone 推出时,还没有应用商店、没有开发工具包、也没有官方渠道可以在设备上发布应用程序。直到黑客第一次发布了 iPhone 的越狱并开始创建流氓应用之后,苹果才看到了商机并创建了 iOS 2。这个版本添加了 App Store,并为开发者提供了在移动设备上设计内容的第一条路。

 

640?wx_fmt=png

应用内购买的问题

 

十多年后的今天,App Store 看起来发生了很大变化。不久前,苹果重新设计了 App Store,同时还添加了 Stories 功能。这意味着这家科技巨头不仅认识到商店中有价值的不仅是应用,还有高质量的内容……或者人们的想法。

虽然 Stories 中展示出的许多新应用都很有趣而且值得注意,但像我这样的资深 iOS 用户已经注意到这些年来 App Store 发生了缓慢且重大的转变。过去,应用和游戏的开发者们梦想着成为下一个应用百万富翁,他们给我们带来了高质量的内容,而如今我们得到的只有残缺的内容,而这些内容的目的只是向用户推送广告和一次性的交易。

为了很好地说明开发者从优质内容创建者到快速敛财的转变过程,我以 App Store 的巨头 Gameloft(http://www.gameloft.com/en/)为例进行说明。这家公司成立于 1999 年,他们很早就开始向 App Store 发布内容。回头看看他们最初发布的应用,就会发现他们提供了很多非常棒的游戏。例如,《罪恶都市》基本上就是换汤不换药的《侠盗猎车手》。《罪恶都市》这款手游提供了一个开放的世界,2009 年的时候它还推出了许多任务和大型地图。另一个很好的例子是《近地联盟先遣队》,这款游戏支持体感控制,还于 2009 年推出了在线模式。虽然按照早期的移动标准,这些老游戏的价格不菲,但你只需支付 4.99 美元就可以玩整个游戏。没有中断,没有广告,也不需要购买额外的东西。

如今这家公司提供的游戏却有着截然不同的体验。例如,最新版的《罪恶都市》,游戏本身虽然是免费的,但是为了完成游戏中的任务,玩家必须使用游戏币。而这种游戏币包括金币和钻石,这两种东西都很难积攒。如今你可以在应用内直接购买这些游戏币,如果你花不起钱,那么将被迫观看 30 秒的广告。如下是《罪恶都市》游戏币的价格列表:

  1. 少量钻石:1.99美元

  2. 一把钻石:4.99美元

  3. 一小袋钻石:9.99美元

  4. 少量金币:1.99美元

  5. 一大袋钻石:19.99美元

  6. 爸爸的私藏珍宝:1.99美元

  7. 少量钻石:0.99美元

  8. 新手欢迎礼包:3.99美元

  9. 少量金币:1.99美元

  10. 一小袋金币:4.99美元

作为一个长期的粉丝,我在试完这个新版游戏的时候发现一点也不享受,玩家需要花费大量时间攒金币或掏钱买游戏币。如上所示,如果你花钱买游戏币,那么可以迅速成为高端玩家。我非常怀念花 4.99 美元就可以玩到游戏所有内容的日子。

像这样的游戏旨在让你付钱享受内容,这种方法非常有效。热门游戏《部落冲突》的创建者 Supercell 仅在 2015 年就赚了 9.64 亿美元。这个游戏本身是免费的,他们的赚钱方式是提供广告和应用内购买。此外,广受欢迎的射击游戏《堡垒之夜》每天仅从 iPhone 用户那里就能赚取近 200 万美元。

这些通过移动内容赚钱的方式不仅扼杀了高质量的游戏,而且也诱使许多开发人员不顾一切地迅速敛财,而不是花时间制作真正高质量的内容。长此以往,开发人员们无心再制作《机械迷城》这般优美设计精良的游戏,而是会迅速转向《龙族融合》这类眼里只有钱的游戏!如此一来,原创或引人入胜的游戏将越来越少。看看如今最流行的应用榜单,你就能清楚地看出这一点。

最糟糕的是,这一切无法自行改变。移动游戏已经成为一个蓬勃发展的行业,它在整个游戏市场占据主导地位,迄今为止它占据了该行业收入的 50% 以上。newzoo 预计,到 2021 年消费者在游戏上的支出将增长到 1801 亿美元,其中移动游戏占将近 60%。

有关这类的控诉并不罕见,这也代表着游戏社区内持续不断的战争。长期以来,游戏玩家一直说他们更喜欢付费购买游戏的模式,而不是长期的微交易。但是内容的质量下降与苹果 iPhone 的销量下降又有什么关系呢?

640?wx_fmt=jpeg

 

640?wx_fmt=png

为什么说这对苹果不利?

 

苹果制造出了非常了不起的硬件。即使你觉得自己不是苹果的粉丝,你也必须承认自个人计算革命开始以来,苹果一直是技术和设备行业的领导者。但是,如果我可以在 99 美元的安卓设备上玩到同样糟糕的游戏的话,我又为什么要购买一部精美的 iPhone 呢?

我拿 iPhone XS 和 XS Plus 新增加的增强现实功能举个例子。这项技术及其硬件非常了不起。然而,开发者社区却一致表示不感兴趣。为这样一个先进的系统设计内容是一项艰巨的工作,如果你简单地动动手指头就能赚不少钱,那么从成本与收益的角度看来,大可不必费那么大力气。

虽然在 App Store,你仍然可以找到高质量的应用和游戏,但是如果你所使用的内容只是为了向你推送一连串的广告,或者不断向你收取 0.99 美元,那么就难免让人质疑我为什么要花 999 美元购买苹果的设备?随着优质的应用和游戏越来越少,越来越难以让人相信购买这种昂贵的设备很合理。

当初开发人员在个人项目上投入大量时间,创建了像 iPad 版《爱丽丝梦游仙境》这样的传奇应用,那时为了获取这些精彩的内容和能顺畅运行这个游戏的高质量硬件,掏腰包购买这些设备是理所当然的。但是现在,开发人员提供的应用只是为了向你推送广告以快速捞钱,而同时安卓或 FireOS 这些便宜的平台也可以提供相同的内容,那么用户花重金购买 iOS 的理由又是什么呢?

 

640?wx_fmt=png

为什么似乎苹果并不关心?

 

对于这个技术巨头来说,管理应用商店从来就不是心甘情愿的。刚开始时,这份差事还不错,而且还可以根据代码的优点,为开发人员的项目提供一个公平的竞争环境。然而现在,即使引入了 Stories,苹果也未能鼓励高质量的开发。这是因为众所周知苹果向每笔应用商店的交易征收 30% 的费用。因此,无论是谁通过何种方式赚了钱,苹果都可以从中分一杯羹。只要应用赚钱,苹果就不会关心其平台上提供的内容的整体质量。

 

640?wx_fmt=png

这个问题有解决方案吗?

 

这个问题没有简单的解决方案,因为长期以来苹果基本上都在忽视应用商店内容的质量问题。依赖广告和应用内购买的经济是巨大的,许多公司赖以维持生计。

苹果需要找到一种方法来推广一次性付费的高质量内容。鼓励开发人员花时间来再次放飞他们的梦想,并点燃亿万富翁的新时代。抛开基于广告或微交易,拥抱一次性付费,购买那些优美、值得我们花时间花钱、且配得上苹果设备的内容。

我认为一个潜在有趣的解决方案是高质量的应用订阅程序和没有广告或交易的游戏。与 Netflix 的运行方式类似,但适用于移动内容。拥有明码标价模式的优质应用和游戏。

无论解决方案是什么,我都希望苹果能尽快落实。我很怀念旧式的主屏幕、有趣吸引人的应用。相信对许多读者来说,移动游戏和多产的辉煌岁月仍历历在目。

全面学python的时代,作为程序员你怎么看?

https://edu.csdn.net/topic/python115?utm_source=csdn_bw

原文:https://medium.com/@zachspears/could-the-true-cause-of-apples-woes-be-the-fall-of-quality-mobile-apps-6c509bd60b62

声明:本文为作者观点,不代表 CSDN 立场。

本文为 CSDN 翻译,如需转载,请注明来源出处。

 热 文 推 荐 

对不起,我的代码评审毁了一个程序员!

京东末位淘汰 10% 高管:稳定不是常态,淘汰才是

前端主流的 Javascript,缺失了哪些技能?

☞ 那些简历造假拿 Offer 的程序员,后来都怎么样了?

☞ 被V神点赞, 我是如何用五子棋打败以太坊排名最高的应用的? |人物志

☞ 50个最有价值的数据可视化图表(推荐收藏)

一键免费自动AI抠图,效果连PS大哥也点赞!

史上最难的一道Java面试题

 

print_r('点个好看吧!');
var_dump('点个好看吧!');
NSLog(@"点个好看吧!");
System.out.println("点个好看吧!");
console.log("点个好看吧!");
print("点个好看吧!");
printf("点个好看吧!\n");
cout << "点个好看吧!" << endl;
Console.WriteLine("点个好看吧!");
fmt.Println("点个好看吧!");
Response.Write("点个好看吧!");
alert("点个好看吧!")
echo "点个好看吧!"

640?wx_fmt=gif点击阅读原文,输入关键词,即可搜索您想要的 CSDN 文章。

640?wx_fmt=png喜欢就点击“好看”吧!

CSDN
微信公众号
成就一亿技术人

前言

在移动端开发中,屏幕适配一直是前端工程师需要解决的核心问题之一。随着前端技术的不断发展,适配方案也从最初的媒体查询、百分比布局,逐步演进到 rem 和 vw/vh 方案。本文将基于实际项目经验,详细分享我们在 new-app 项目中移动端适配方案的演进过程,对比 rem 和 vw 两种方案的优劣,并提供完整的迁移实践指南。

一、项目背景与适配需求

new-app 是一个面向移动端的 Web 应用,需要适配从 320px 到 750px 的各种移动设备屏幕。我们的设计稿基于 750px 宽度,需要实现以下目标:

  1. 元素尺寸能够根据屏幕宽度等比缩放
  2. 保持设计稿的布局比例和视觉效果
  3. 方案简单易维护,性能良好
  4. 兼容主流移动端浏览器

二、rem 适配方案详解

1. 实现原理

rem(root em)是相对于根元素字体大小的单位。rem 适配方案的核心思想是通过 JavaScript 动态计算根元素的 font-size,使得页面中的所有 rem 单位能够根据屏幕尺寸等比缩放。

javascript

复制

下载

php
代码解读
复制代码
// remConfig.js 核心实现 export default { scale: 0, install: function (win, doc) { const baseWidth = 750 // 设计稿基准宽度 const documentHTML = doc.documentElement const self = this function setRootFont() { const docWidth = documentHTML.getBoundingClientRect().width self.scale = docWidth / baseWidth // 最大缩放比例限制 if (docWidth > baseWidth) { self.scale = 0.5 } documentHTML.style.setProperty('font-size', self.scale * 100 + 'px', 'important') } setRootFont() win.addEventListener('resize', setRootFont, false) } }

2. 方案特点

  1. 基准设计:以 750px 设计稿为基准,将屏幕宽度分为 100 份(1rem = 屏幕宽度/100)
  2. 动态计算:通过 getBoundingClientRect() 获取精确的视口宽度
  3. 缩放限制:大屏幕下固定缩放比例,避免元素过大
  4. 响应式处理:监听 resize 事件,确保设备旋转时也能正确适配

3. 使用示例

在 Vue 项目中的使用方式:

javascript

复制

下载

javascript
代码解读
复制代码
// main.js import remAdapter from "./config/remConfig" remAdapter.install(window, document); // 组件中使用 <style> .container { width: 7.5rem; /* 对应设计稿750px */ height: 3.2rem; /* 对应设计稿320px */ } style>

4. 优缺点分析

优点:

  • 兼容性好,支持到 IE9+
  • 计算逻辑简单直观
  • 社区方案成熟(如 lib-flexible)

缺点:

  • 依赖 JavaScript 动态计算
  • 存在字体大小重置问题
  • 缩放时可能出现亚像素渲染问题
  • 需要额外处理 1px 边框问题

三、向 vw 适配方案的演进

随着 CSS3 的普及和浏览器支持度的提升,我们决定将项目迁移到更现代的 vw 方案。vw(viewport width)是相对于视口宽度的单位,1vw 等于视口宽度的 1%。

1. 迁移准备工作

首先在项目中添加必要依赖:

json

复制

下载

css
代码解读
复制代码
{ "devDependencies": { "postcss-px-to-viewport": "^1.1.1", "fs-extra": "^10.1.0" } }

配置 PostCSS 插件:

javascript

复制

下载

java
代码解读
复制代码
// .postcssrc.js module.exports = { plugins: { 'postcss-px-to-viewport': { viewportWidth: 750, // 设计稿宽度 viewportHeight: 1334, // 设计稿高度 unitPrecision: 2, // 转换精度 viewportUnit: 'vw', // 转换单位 selectorBlackList: [ // 忽略转换的选择器 '.ignore', '.hairlines' ], minPixelValue: 1, // 最小转换像素值 mediaQuery: false // 是否转换媒体查询中的px } } }

2. 自动化迁移方案

为了高效地将现有 rem 单位转换为 vw,我们开发了两个自动化脚本:

脚本1:rem → px

javascript

复制

下载

javascript
代码解读
复制代码
// scripts/convert-rem-to-px.js const fs = require('fs-extra'); const path = require('path'); const glob = require('glob'); function convertRemToPx(content) { // 处理普通rem单位 content = content.replace(/(\d*.?\d+)rem/g, (match, num) => { return `${parseFloat(parseFloat(num).toFixed(0))}px`; }); // 处理负值和带小数点的rem content = content.replace(/(-?\d*.?\d+)rem/g, (match, num) => { const pxValue = parseFloat((parseFloat(num) * 100).toFixed(0); return `${pxValue}px`; }); return content; } // ...文件处理逻辑

脚本2:px → vw

javascript

复制

下载

javascript
代码解读
复制代码
// scripts/convert-px-to-vw.js const fs = require('fs-extra'); const path = require('path'); const glob = require('glob'); function convertPxToVw(content) { return content.replace(/(\d*.?\d+)px/g, (match, num) => { // 跳过0px的特殊情况 if (match.includes('border: 0px') || match.includes('border:0px')) { return match; } // 750设计稿下:1px = 0.13333vw const vwValue = parseFloat((parseFloat(num) / 7.5).toFixed(2)); return `${vwValue}vw`; }); } // ...文件处理逻辑

3. 迁移执行步骤

bash

复制

下载

bash
代码解读
复制代码
# 安装依赖 npm install postcss-px-to-viewport fs-extra glob --save-dev # 执行转换 node scripts/convert-rem-to-px.js node scripts/convert-px-to-vw.js # 清理rem适配相关代码 # 1. 移除remConfig.js # 2. 删除main.js中的rem初始化代码

4. 迁移后代码示例

css

复制

下载

css
代码解读
复制代码
/* 迁移前 */ .header { height: 0.88rem; padding: 0 0.3rem; } /* 迁移后 */ .header { height: 11.73vw; /* 88/7.5 */ padding: 0 4vw; /* 30/7.5 */ }

四、方案对比与选型建议

1. 技术指标对比

特性rem 方案vw 方案
实现原理JS动态计算根字体大小原生CSS视口单位
依赖项需要JS支持纯CSS实现
兼容性IE9+IE10+(移动端基本支持)
性能较差(需要JS计算)更好(浏览器原生支持)
精确度存在舍入误差更高精度
维护成本较高(需维护JS逻辑)低(配置一次即可)
响应速度可能有样式闪烁即时响应

2. 选型建议

  1. 选择 rem 方案:

    • 需要支持老旧浏览器(如IE9)
    • 项目已有成熟的rem方案且运行良好
    • 设计师提供的设计稿尺寸不固定
  2. 选择 vw 方案:

    • 面向现代浏览器项目
    • 追求更好的性能和开发体验
    • 设计稿尺寸固定(如750px)
    • 希望减少对JavaScript的依赖
  3. 混合方案:

    • 主体布局使用vw单位
    • 小元素和边框使用px单位
    • 特殊组件使用rem单位

五、实践中的坑与解决方案

1. 常见问题

  1. 1px边框问题:

    • 问题:在高清屏上1px可能显示过粗
    • 解决方案:使用transform: scale(0.5)或媒体查询配合device-pixel-ratio
  2. 字体大小问题:

    • 问题:vw单位可能导致字体过小
    • 解决方案:使用clamp()函数限制最小最大字号

    css

    复制

    下载

    css
    代码解读
    复制代码
    body { font-size: clamp(12px, 2vw, 16px); }
  3. 第三方组件样式覆盖:

    • 问题:第三方组件使用px单位
    • 解决方案:将组件添加到selectorBlackList或使用postcss-ignore注释

2. 最佳实践

  1. 设置合理的单位精度:

    javascript

    复制

    下载

    arduino
    代码解读
    复制代码
    unitPrecision: 2 // 避免过长的小数位
  2. 处理特殊场景:

    css

    复制

    下载

    css
    代码解读
    复制代码
    /* 使用注释跳过转换 */ /* postcss-px-to-viewport-ignore-next */ .ignore-element { width: 100px; }
  3. 渐进式迁移:

    • 先迁移部分页面验证效果
    • 逐步扩大迁移范围
    • 保留回滚方案

六、总结与展望

通过本次从 rem 到 vw 的迁移实践,我们获得了以下收益:

  1. 性能提升:消除了JavaScript计算开销,页面渲染速度提升约15%
  2. 代码简化:移除了约200行适配相关代码
  3. 开发体验改善:不再需要手动计算rem值,与设计稿对应更直观
  4. 维护成本降低:适配逻辑完全由CSS处理,无需额外维护

未来,随着容器查询(@container)等新特性的普及,移动端适配可能会有更多创新方案。但就目前而言,vw方案在现代化项目中仍然是最佳选择之一。

附录

  1. Can I Use: Viewport Units
  2. PostCSS-px-to-viewport 文档
  3. 移动端适配方案对比
注:本文转载自blog.csdn.net的CSDN资讯的文章"https://blog.csdn.net/csdnnews/article/details/87899186"。版权归原作者所有,此博客不拥有其著作权,亦不承担相应法律责任。如有侵权,请联系我们删除。
复制链接
复制链接
相关推荐
发表评论
登录后才能发表评论和回复 注册

/ 登录

评论记录:

未查询到任何数据!
回复评论:

分类栏目

后端 (14832) 前端 (14280) 移动开发 (3760) 编程语言 (3851) Java (3904) Python (3298) 人工智能 (10119) AIGC (2810) 大数据 (3499) 数据库 (3945) 数据结构与算法 (3757) 音视频 (2669) 云原生 (3145) 云平台 (2965) 前沿技术 (2993) 开源 (2160) 小程序 (2860) 运维 (2533) 服务器 (2698) 操作系统 (2325) 硬件开发 (2492) 嵌入式 (2955) 微软技术 (2769) 软件工程 (2056) 测试 (2865) 网络空间安全 (2948) 网络与通信 (2797) 用户体验设计 (2592) 学习和成长 (2593) 搜索 (2744) 开发工具 (7108) 游戏 (2829) HarmonyOS (2935) 区块链 (2782) 数学 (3112) 3C硬件 (2759) 资讯 (2909) Android (4709) iOS (1850) 代码人生 (3043) 阅读 (2841)

热门文章

101
推荐
关于我们 隐私政策 免责声明 联系我们
Copyright © 2020-2025 蚁人论坛 (iYenn.com) All Rights Reserved.
Scroll to Top