移动平台与技术债务

摘要: 诺基亚、Palm还有RIM为什么会被干掉?其中的一个根本问题是,2000年左右,其设计是围绕着在当时是正确的假设和折衷来进行的,但这些假设和权衡却很难与5到10年后的iOS和Android抗衡。

诺基亚、Palm还有RIM为什么会被干掉?其中的一个根本问题是,2000年左右,其设计是围绕着在当时是正确的假设和折衷来进行的,但这些假设和权衡却很难与5到10年后的iOS和Android抗衡。其当时的假设是CPU和网络都很慢、内存很少,只有电阻式触屏或甚至根本就没有,为了提高电池寿命他们牺牲了性能和更丰富的体验。在2000年的时候,这些假设和权衡是正确的,但到了2007年的时候却不成立了。这意味着他们必须更换平台,而更换平台几乎意味着濒死体验,有苹果和微软为证。

那么问题来了:苹果和Google当时什么样的假设也会令他们今后的前进受阻呢?从诺基亚的S60系列/塞班手机到2007年iPhone的推出有5年的时间,但现在8年的时间过去了。我们最近看到的很多东西都可以被视为是对当时的部分权衡做出的改变。

原先的iPhone分辨率是固定的,不能运行第三方app,也不支持多任务。其原因部分是哲学上的(不管你信不信,乔布斯不想要app),部分是由于iPhone在很多方面都是MVP。但大部分都与一个问题有关,即在那样的成本和电量分配条件下,如何让一个设备实现用户想要的基本水准的体验。这个问题与诺基亚、Palm和RIM早年面临的问题是完全一样的。安全、沙盒式的多任务第三方应用不是第一代的硬件能够管理的,至少一块电池没办法撑一天。

也就是说,苹果过去几个版本一直在做的事情是,重建操作系统以便对那些折衷随着性能的提升(大概提高了50倍)进行调整。因此现在,8年之后,我们的确有了沙盒化的安全的多任务和扩展,还有iPhone和iPad都抛弃了固定分辨率。在此过程中苹果已经把引擎给换掉了,并且多少有点侥幸地取得了成功。它已经把当时所有的假设都给改了。

Android也可以看到类似的事情,其关键的权衡是开放性。Google开发/购买了一套开源的操作系统,原来只有非常基本的UX,很少的集中控制,这些在当时也是正确的权衡。结果它以前所未有的规模取得巨大成功—现在Android设备的数量已经比在用的PC还要多,是消费者PC的两倍(这个比较更有意义)。当然,这也导致了碎片化以及分化和低于标准的用户体验,并不断地有第三方(Amazon,也许还有小米和三星)试图去接管用户体验。

在2007年做出那样的权衡是正确的—你可以看看Windows Phone的替代路径。但随着时间转移这种折衷也在改变。如果你希望吸引开发者,那么碎片化就得处理,而随着OS本身变成了浏览器前面的服务的聚合层,随着用户数据变成了与原始web搜索范围一样重要的东西,Google对UX的控制就变得越来越重要了。因此,现在可以看到Google正在把Android一部分的“开放”大门关闭。通过把它自己的服务和API放进GMS(即Google Service)来确保库中更大一部分的东西拥有最新“版本”,并且更加努力地维系对UX的控制,阻止OEM变动太多。目前尚不清楚这种情况要在什么地方才能稳定下来,因为开放Android在中国的扩散以及Android OEM的动荡,但Google显然正在修正那些对“开放性”的假设。

怎么来看这些情况呢?一个办法是看看iOS和Android重合的地方—虽然他们原来各自是从不同的两端起步的,但现在大家的能力多多少少都有些趋同。苹果放松了控制,而Google却在收紧。当然了,Google和苹果各自都要分别给Android和iOS添加很多东西(从各自身上汲取灵感),正如苹果增加了云服务,而Google则重新设计了用户界面。

但他们底层的哲学依然很不一样—对于苹果来说,设备是智能的,而云是哑存储,而Google正好相反,云是智能的,而设备则是哑的眼镜。这些假设和权衡仍旧非常的根深蒂固。与此同时,智能手机的下一阶段(会是以消息app为平台以手表为统治性的界面吗?)将会再次测试所有这些假设。

时间: 2024-09-20 05:56:38

移动平台与技术债务的相关文章

消除技术债务?DevOps可以这么用!

DevOps强调开发运维过程的可度量与透明化.而通常情况下我们把软件质量分为内部质量和外部质量.所以我们应该对内部质量和外部质量分别进行度量,以便持续改进和优化软件质量. 软件的内部质量通常指代码和设计的质量.内部质量可以通过应用设计和编程达到最佳实践,也可以通过持续一致的开发和交付流程来提高. 通常,软件的外部质量是通过查看和使用软件(例如验收测试)来度量的. 比较常见的情况是,有的软件外部质量很好(所有功能都能正常使用),但是内部质量却很差(可能有糟糕的代码.不可维护的代码).从长远的角度看

技术债务(母鸡的遭遇)(转)

技术债务,是指匆忙的实现一个功能,却对现有的程序库造成了破坏(在实现的过程中污染了代码库的设计),这对于一些项目经理/客户来说就像是天书奇谈.也许他们是明白的,只是不愿意承认罢了,我估计是这样的.不管怎样,我想起来一个小故事,当下次遇到这种情况,需要向他们解释增加某些新功能的代价时,也可用讲这个故事给他们听. 一个农夫有3只母鸡.每只母鸡每天下一个蛋.农夫跟当地的一个食品店老板做生意.食品店老板每天从农夫那里买2给鸡蛋放在店里出售.一切都很好,直到有一天,食品店老板出现在农夫家里: 食品店老板:

[Android]使用MVP解决技术债务(翻译)

以下内容为原创,欢迎转载,转载请注明 来自天天博客:http://www.cnblogs.com/tiantianbyconan/p/5892671.html 使用MVP解决技术债务 原文:https://medium.com/picnic-engineering/tackling-technical-debt-with-mvp-67e805ed5103#.couu0d5i0 免责申明:这篇博客并不是讲关于怎么使用MVP的方式(上帝知道关于这些已经太多了)去写Android代码.而仅仅是我的个人

投资于质量 不再有技术债务

一个童话故事 很久以前,有个软件开发团队找到他们的经理."我们的项目有相当多的技术债务(Technical Debt),我们应该做点什么."这个团队说.他们展示了一张图(图1)来说明项目的技术债务."技术债务关系到项目质量."他们说.并展示了技术债务各部分的分解,通过静态代码分析,能发现过于复杂的代码.重复的代码和冲突."我们需要去除技术债务"他们告诉经理. 图1:SonarQube技术债务插件的结果报告 但经理困惑了:什么是技术债务?他该额外再

Habya'a(临时拼凑的组件)与技术债务

我们曾遇到过最后期限即将到来.时间非常紧迫的情况.当时,我们必须尽快修复Bug,然而其中的一个Bug特别坚韧,任我们百般努力也无可奈何!随后,我的某个同事接手了调试工作.他强行写入了一些应该从数据库中检索来获取的值--它们在系统运营的最初几个月里不会发生变化--随后--系统神奇地正常工作了! 对于这类"莫名其妙的代码",我的这位同事以非常风趣的埃及俚语称之为"Habya'a",意即临时拼凑的组件. 我同事和他的创造性俚语相仿,Ward Cunningham在1992

企业自建网络直播的完美替代:平台与技术的集合

中介交易 SEO诊断 淘宝客 云主机 技术大厅 随着网络时代的到来,各类传统企业开始搭上网络的高速列车.各种网络应用应运而生.利用互联网展开企业的产品销售和服务推广,将传统应用延伸至互联网,通过互联网挖掘产品和服务的潜在市场和用户,使得国内电子商务行业不断地发展和成熟.例如教育类电子商务的发展-----新媒体与远程教育,就是充分利用互联网信息技术产生的新型教育方式. 现代远程教育是伴随现代网路信息技术在教育中的应用而发展起来的,它是一种适合信息化社会需求的教育新模式,相对传统教育而言,现代远程教

云制造的体系结构及平台实现技术研究

云制造的体系结构及平台实现技术研究 重庆大学   马刚 本文针对开放式云制造系统的动态性和灵活性,采用服务组件技术,研究了一种新的面向服务的.组件化的云制造体系结构及其平台的实现技术.主要研究内容包括:①分析云制造系统特征及其设计原则,研究提出一种基于组件的云制造层次化体系结构.给出了该体系结构的各层业务功能及其层次关系,讨论了云制造系统的核心组件.以及相关标准和规范.②针对云制造任务和资源的多样性.异构性和复杂性,扩展OWL-S服务本体,建立云制造本体模型并给出云制造的任务及服务的形式化描述方

【阿里云资讯】阿里云入驻中信云平台 输出技术支持与云资源

[8月30日讯] 8月29日,中信集团在京发布"互联网+转型"战略,宣布将大力建设提供平台服务和数据服务的中信产业云网.              阿里云成为中信产业云网的首批入驻服务提供商之一,为中信集团互联网+转型提供技术动力. 中信产业云网+阿里云 中信产业云网通过平台服务赋能,将从中信集团内向集团外把线下实体企业互连互通,加快实体企业资源和能力的在线化和数字化,助推更多新业态的涌现.阿里云作为中信产业云网的合作伙伴,将公共云具备的弹性伸缩.海量扩展的优势延伸至中信基础设施云平台

熊猫TV,斗鱼TV等直播平台的技术架构是怎样的,服务器是怎么托管的,是托管在云服务器上吗?

问题描述 熊猫TV,斗鱼TV等直播平台的技术架构是怎样的,服务器是怎么托管的,是托管在云服务器上吗? 熊猫TV,斗鱼TV等直播平台的技术架构是怎样的,服务器是怎么托管的,是托管在云服务器上吗? 解决方案 云服务器适合"零售",如果你做这种高带宽高访问的网站,你应该托管甚至自建机房,后者可以降低成本. 至于技术架构,这个你得花大价钱雇佣架构师,哪里是随便在论坛里胡乱一问就能求来的. 解决方案二: 云服务器适合"零售",如果你做这种高带宽高访问的网站,你应该托管甚至自建