国内 App 市场“烂透了”?

用户界面全拷贝 离职带走程序源代码 互抄现象频现 预装模式压制创业者

4月26日,世界知识产权日,所有登录网易邮箱的用户都会看到这样一幅画面:左边一个艺术家打扮的人画出了一只叼着橄榄枝的洁白鸽子,右边一个 身上打着补丁、乞丐状的人边张望“艺术家”的作品,边在画布相同位置描出一只嘴里叼野花、眼歪鼻斜的企鹅。图上配文是:“与其山寨百分之一的灵感,不如复 制百分之百的汗水”。看来,网易与腾讯之间围绕新闻客户端抄袭的“掐架”还会继续下去。

与国内形成鲜明对比的是,国外App业态健康,团队才13个人的图片分享应用Instagram被Facebook以10亿美元收购,私人图片 分享服务Path估值也迅速上升到2.5亿美元,App开发是一门依靠创新能实现巨大利润的生意。“国内的创意型中小团队却不可能被大公司收购,后者反而 会很快山寨一个类似应用,很快你就死了。”资深iOS程序开发者、iApp4Me创始人郝培强表示。

IT时报记者 忻云

1 用户界面抄袭“分分钟搞定”

如果你在对比最近涉嫌抄袭的两个客户端后发现外观“太像了”,并且感到愤怒,那你一定是第一天踏入这个圈子的人。“微书架”App创始人许锡标对于这种UI(用户界面)设计雷同的现象早已见怪不怪。

“人家设计师辛辛苦苦设计的图片,用不了半个小时,就可以被某些别有用心的人利用。”许锡标说,他以大热的美国应用Path为例,演示了十分简 单的抄袭过程,下载Path,导出ipa文件,把ipa文件解压,就能看到Path所有的图片文件:“这些图片文件一般是png文件,直接打开是看不了 的。这时,需要再下载一个修复png的软件,批量修复一下,就能看到所有图片文件。这样就把Path的整个UI给盗了。就这么简单。”

易传媒移动互联网软件工程师小柯称,安卓应用的山寨更简单,将APK文件名改为RAR后解压,应用中的图片都在RES文件夹内,“连代码什么的都可以看到。”

Fresh-Ideas工作室的开发者王均最近就认为其作品“全国空气污染指数”安卓版中一张原创图片被某公司改也不改地直接用于另一款应用。 “那张坐标轴图片由多种色彩按特殊配色方案混搭而成,是我们团队反复琢磨的产物,相信天下不可能找到一模一样的。所以我很奇怪,下载对方应用打开图片文件 夹后,发现根本就是用我的原始图片。”怪只怪,安卓的图片太容易复制。

iApp4Me创始人郝培强说,就算初创设计者做一些加密也没有用,对方觉得你的UI好,完全可以将图片截屏。由此带来的“盗版”速度非常 快,Instagram被Facebook收购后,图片分享类应用被大为看好,Path立即成为国内山寨的下一个热点,目前已有10多个类Path应用出 现在国内市场。

软件抄袭自PC时代就有,但在移动App上如此密集地发生,主要是屏幕相对缩小后,用户体验的要求更高,通常用户下载App后首先看“应用是否 好看”,这方面的重视度远超PC端。“在PC上即使一款软件操作起来不太舒服,用鼠标也比较容易克服,软件间的差别感受没那么大。但在手机屏上一个优秀的 UI,一个舒服的按键位置对用户吸引力巨大,对复制者的诱惑也同样增长。”郝培强表示。

2 你抄我,我抄他

当你说别人抄袭的时候,自己却也成了其它应用开发者的攻击目标。螳螂捕蝉,黄雀总是在后,这不只发生在近期控诉腾讯的网易身上。

热门游戏“捕鱼达人”曾表示自己的山寨应用多达100多款,其中也包括腾讯。但这款游戏自身却也受到“抄袭”的指责。

一些游戏玩家发现在“卡通尼”等大型游艺城曾玩过一款十分相似的街机版“捕鱼游戏”。老K游戏联合创始人黄剑表示,街机上的游戏正是由该团队最 早于2009年原创,并且在2011年4月推出iOS版本,但是当时却发现20天之前触控科技已推出一款《捕鱼达人》,黄剑认为后者抄袭痕迹明显。

触控科技CEO陈昊芝针对这一质疑向记者表示:“我们从来没有不承认借鉴了这款街机游戏,但肯定是有创新的,从摇杆的操作变为触控操作,从用户需要付钱玩变成免费玩,这些都是创新。如今也有很多手机游戏来自于任天堂以往的经典游戏等,游戏的玩法没有规定不允许重复。”

不过,将街机移植到手机上,显然必须将操控方式从摇杆变为触屏,也肯定不能像大型游艺城那样要求投游戏币来玩,这些改变就是创新?黄剑并不信服:“游戏主体上基本和我们一样,鱼阵游动、用炮打鱼等基本都是我们的创意,我认为没有本质上的创新。”

同样地,卓亨最近对旗下游戏《守卫者》遭遇山寨感到十分愤怒,但也有开发者表示该公司最为知名的游戏《切水果》有山寨版《水果忍者》之嫌……

令郝培强感到失落的是,最近这一年多来,App Store中出现的让用户眼前一亮的App差不多都来自美国,在中国区这样的惊喜几乎没有。“一眼望去都是一样的东西。”郝培强说,现在的态势几乎是美国 人负责创新,中国人负责模仿,当市场已经有10多款同样模仿美国的应用时,国内开发者之间谁抄袭谁也显得很无谓,本质上是创新乏力。

艾媒咨询董事长张毅告诉记者,据之前的调查数字,国内手机游戏市场正版仅占1.4%,而山寨版则高达34.2%。在苹果iOS平台上,热门游戏 只占整体游戏数量的1.9%,山寨版占21.8%。大量游戏扎堆于跳跃、捕猎、塔防等集中的主题,缺乏突破性创意,造成彼此间除了美术设计外均十分雷同, 界定抄袭十分困难。

3 创新App的喉咙被掐住

在中国,App创新者很难自比Instagram的开发者们。一位不愿透露姓名的开发者表示,他从来没有做过被腾讯、百度等公司收购之类的美梦,只是希望自己的应用能绕开大公司主要关注的方向,获得一些不被复制的喘息时间来积累用户。

美国的App创新者被收购,而中国的中小开发者由于遭到复制,很容易死掉,一些业内人士似乎都有这样的共识。张毅表示,在美国反不正当竞争法的 实施比较成熟,抄袭者被告的几率很大,收购成了大公司传统思维的一部分。而在中国,包括之前的UC浏览器与QQ浏览器之争等都没有最终的结论:“导致许多 巨头认为复制能带来更好的成本控制。”

中国应用市场过于渠道化也是其中关键原因,开发者通过健康方式实现用户增长难度很大。比如,在水货手机刷ROM(中文操作系统)的环节,不少应 用开发者就与中间商达成协议,将应用预装在手机中。“曾经有一个用户买到手机,其中预装了6个手机浏览器。”郝培强表示。如果中小开发者的创意被更有资金 实力的公司山寨,并迅速预装于手机,随着装机量的上升很快就会在用户数量上被对方压倒,难以翻身。

另外,App Store中国区刷榜现象严重,应用排名的现状往往与创新性无关,当一些背景雄厚的雷同应用占据了推广位,消费者已很难分辨谁是原创,缺乏推广资金的中小团队产品很快就会被淹没。

黄剑说,以往推广网页版捕鱼游戏并不需要做广告,但由于iOS平台上出现大量捕鱼游戏,其每月投放广告的成本被推到200万元左右:“如果是比我们更小的团队,从一开始就会无法支撑。”

4 开发者带着源代码跳槽

困惑并不仅仅来自刚涉足这一行业的中小团队,也包括成功团队。

在国内App开发圈里,139.me是一个颇有来头的名字。它最早涉足iPhone软件原创开发,并获得百万次下载的国内团队之一。仅靠“多彩 水族箱”这款游戏,139.me每天的收入就超过1000美元。2009年时其CEO朱连兴在那些梦想挖到第一桶金的草根创业者眼中就是一夜暴富的最佳模 仿目标。

然而最近朱连兴却感到发展遭遇很大的现实问题,烦恼原因也是同样的——抄袭。

不久前139.me刚在App Store上对一款雷同应用提起了下架诉求,而对方的身份让朱连兴很痛心,因为正是从其团队中出走的员工。

2008年在河北时与朱连兴一同创业的只有两三人,他们一起经历了艰苦奋斗。“那时App创新比较单纯,因为进入者没有那么多,抄袭也没有那么 严重。”他回忆。但在2010年搬到北京后,朱连兴发现团队中一些成员接触的人变得很杂,甚至腾讯等公司的挖人电话直接打到了公司里,这个行业的诱惑变得 很大。不少被公司看好、并且已经签署协议的大学毕业生在经过长期的打磨后,却忽然因为其他公司的高薪诱惑抛下项目走了。

“一个产品到了关键阶段,主要做程序的人却跑掉了,这对我们的影响太大了。”朱连兴表示,而且年轻人带走的还有属于这个产品独特的创意文化。

更令他没有想到的是,不久前竟然有一位甘苦多年的元老在离职时将应用源代码也一并带走,并组织起自己的团队,推出类似的应用。

“这个行业很奇怪,似乎没有是非标准,也没有批评的意识。看到某一个人是从139.me这样的知名团队出来的,只看中他的经验,从来不会问他手 里的东西是怎么来的。”面对雷同的产品,朱连兴只能向App Store申诉,但提到走法律途径维权的可能,他觉得所需时间和成本太多。

“像国外开发团队那样的凝聚力似乎很难,没有规矩就没有竞争可言,这是整个行业缺乏职业操守所致。”朱连兴表示。

记者手记

监管不力导致底线失守

在你对某一款应用爱不释手时,是否想到这背后或许有不为人知的血泪史?从创意的抄袭到完全复制UI,将原创的内容改也不改就加以使用,快速吸金的浮躁心态是这个行业野蛮生长的潜在诱因,而监管不力则是底线一再失守的现实因素。

在一个新兴行业快速兴起时,法律和行业规范常常跟不上其迅速的脚步。但当与抄袭相伴的刷榜、黑卡、色情应用泛滥等不良现象集中在国内市场呈现,当一些开发者用“烂透了”这样的哀叹来形容周边氛围时,反观国外,无法不令人感到汗颜。

Oracle 为 OS X 发布 Java 开发工具

8_101115141915_1.jpg

2010年末的时候,苹果宣布终止对OS X的Java支持,当时乔布斯表示苹果的Java版本总是比Sun/Oracle发布落后,导致苹果比其他所有平台的Java版本都要老,所以继续支持没 有意义了。之后过了几周,苹果和Oracle宣布计划将Oracle的OpenJDK项目扩展对OS X系统的支持,这意味着将Java SE 7带给了Mac用户。

今天Oracle发布Java SE 7 Update 4JavaFX 2.1进一步兼容OS X系统。对于Java开发者来说,这次更新是首次为Mac OS X开放Java Development Kit(JDK开发工具)和Java FX Software Development Kit开发工具。

OpenJDK团体继续为OS X消费者版本Java SE 7进行努力(Java Runtime Environment (JRE) for Mac OS X),Oracle表示为消费者公众发布的日期被定在了2012年末。

此次Oracle/OpenJDK继续对OS X的Java支持很显然与最近针对Java的病毒Flashback有关。乔布斯当初就说OS X平台的Java总比别的平台版本低,这次又验证了。Oracle在发现了Java漏洞后在2月份就为Windows等平台发布了补丁,而Mac平台就被 忽略了,导致了60万台Mac中招的事件发生。而苹果也不得不在东窗事发之后连续发布Java补丁来亡羊补牢。

MacX.cn 编译

Javascript 编程风格

Douglas Crockford 是 Javascript 权威,Json 格式就是他的发明。

去年 11 月他有一个演讲(Youtube),谈到了好的 Javascript 编程风格是什么。

我非常推荐这个演讲,它不仅有助于学习 Javascript,而且能让你心情舒畅,因为 Crockford 讲得很幽默,时不时让听众会心一笑。

下面,我根据这个演讲和 Crockford 编写的代码规范,总结一下"Javascript 编程风格"。

所谓"编程风格"(programming style),指的是编写代码的样式规则。不同的程序员,往往有不同的编程风格。

有人说,编译器的规范叫做"语法规则"(grammar),这是程序员必须遵守的;而编译器忽略的部分,就叫"编程风格" (programming style),这是程序员可以自由选择的。这种说法不完全正确,程序员固然可以自由选择编程风格,但是好的编程风格有助于写出质量更高、错误更少、更易于 维护的程序。

所以,有一点应该明确,"编程风格"的选择不应该基于个人爱好、熟悉程度、打字工作量等因素,而要考虑如何尽量使代码清晰易读、减少出错。你选 择的,不是你喜欢的风格,而是一种能够清晰表达你的意图的风格。这一点,对于 Javascript 这种语法自由度很高、设计不完全成熟的语言尤其重要。

一、大括号的位置

绝大多数的编程语言,都用大括号({})表示区块(block)。起首的大括号的位置,有许多不同的写法

最流行的有两种。一种是起首的大括号另起一行:

block

{

}

另一种是起首的大括号跟在关键字的后面:

block {

}

一般来说,这两种写法都可以接受。但是,Javascript 要使用后一种,因为 Javascript 会自动添加句末的分号,导致一些难以察觉的错误。

return

{

key:value;

};

上面的代码的原意,是要返回一个对象,但实际上返回的是 undefined,因为 Javascript 自动在 return 语句后面添加了分号。为了避免这一类错误,需要写成下面这样:

return {

key : value;

};

因此,

规则1:表示区块起首的大括号,不要另起一行。

二、 圆括号

圆括号(parentheses)在 Javascript 中有两种作用,一种表示调用函数,另一种表示不同的值的组合(grouping)。我们可以用空格,区分这两种不同的括号。

规则2:调用函数的时候,函数名与左括号之间没有空格。

规则3:函数名与参数序列之间,没有空格。

规则4:所有其他语法元素与左括号之间,都有一个空格。

按照上面的规则,下面的写法都是不规范的:

foo (bar)

return (a+b);

if (a === 0) {…}

function foo (b) {…}

function (x) {…}

三、分号

分号表示语句的结束。大多数情况下,如果你省略了句尾的分号,Javascript 会自动添加。

var a = 1

等同于

var a = 1;

因此,有人提倡省略句尾的分号。但麻烦的是,如果下一行的第一个字元(token)是下面这五个字符之一,Javascript 将不对上一行句尾添加分号:"("、"["、"/"、"+"和"-"。

x = y

(function (){

})();

上面的代码等同于

x = y (function (){…})();

因此,

规则5:不要省略句末的分号。

四、with 语句

with 可以减少代码的书写,但是会造成混淆。

with (o) {

foo = bar;

}

上面的代码,可以有四种运行结果:

o.foo = bar;

o.foo = o.bar;

foo = bar;

foo = o.bar;

这四种结果都可能发生,取决于不同的变量是否有定义。因此,

规则6:不要使用 with 语句。

五、相等和严格相等

Javascript 有两个表示"相等"的运算符:"相等"(==)和"严格相等"(===)。

因为"相等"运算符会自动转换变量类型,造成很多意想不到的情况

0 == ”// true

1 == true // true

2 == true // false

0 == ‘0’ // true

false == ‘false’ // false

false == ‘0’ // true

" \t\r\n " == 0 // true

因此,

规则7:不要使用"相等"(==)运算符,只使用"严格相等"(===)运算符。

六、语句的合并

有些程序员追求简洁,喜欢合并不同目的的语句。比如,原来的语句是

a = b;

if (a) {…}

他喜欢写成下面这样:

if (a = b) {…}

虽然语句少了一行,但是可读性大打折扣,而且会造成误读,让别人误以为这行代码的意思是:

if (a === b){…}

另外一种情况是,有些程序员喜欢在同一行中赋值多个变量:

var a = b = 0;

他以为,这行代码等同于

var a = 0, b = 0;

实际上不是,它的真正效果是下面这样:

b = 0;

var a = b;

因此,

规则8:不要将不同目的的语句,合并成一行。

七、变量声明

Javascript 会自动将变量声明"提升"(hoist)到代码块(block)的头部。

if (!o) {

var o = {};

}

等同于

var o;

if (!o) {

o = {};

}

为了避免可能出现的问题,不如把变量声明都放在代码块的头部。

for (var i …) {…}

最好写成:

var i;

for (i …) {…,}

因此,

规则9:所有变量声明都放在函数的头部。

规则 10:所有函数都在使用之前定义。

八、全局变量

Javascript 最大的语法缺点,可能就是全局变量对于任何一个代码块,都是可读可写。这对代码的模块化和重复使用,非常不利。

规则 11:避免使用全局变量;如果不得不使用,用大写字母表示变量名,比如 UPPER_CASE。

九、new 命令

Javascript 使用 new 命令,从建构函数生成一个新对象。

var o = new myObject ();

这种做法的问题是,一旦你忘了加上 new,myObject ()内部的 this 关键字就会指向全局对象,导致所有绑定在 this 上面的变量,都变成全部变量。

规则 12:不要使用 new 命令,改用 Object.create ()命令。

如果不得不使用 new,为了防止出错,最好在视觉上把建构函数与其他函数区分开来。

规则 13:建构函数的函数名,采用首字母大写(InitialCap);其他函数名,一律首字母小写。

十、自增和自减运算符

自增(++)和自减(–)运算符,放在变量的前面或后面,返回的值不一样,很容易发生错误。

事实上,所有的++运算符都可以用"+= 1"代替。

++x

等同于

x += 1;

代码变得更清晰了。有一个很可笑的例子,某个 Javascript 函数库的源代码中出现了下面的片段:

++x;

++x;

这个程序员忘了,还有更简单、更合理的写法:

x += 2;

因此,

规则 14:不要使用自增(++)和自减(–)运算符,用+=和-=代替。

十一、区块

如果循环和判断的代码体只有一行,Javascript 允许该区块(block)省略大括号。

下面的代码

if (a) b (); c ();

原意可能是

if (a) { b (); c ();}

但是,实际效果是

if (a) { b ();} c ();

因此,

规则 15:总是使用大括号表示区块。

16 个新鲜的 CSS3 在线教程

用CSS3制作令人印象深刻的产品展示

使用jQuery和CSS3制作闪亮的旋钮控制

使用 CoffeeScript 创建一个类 iOS 的界面

使用 CSS3 制作报纸阅读

制作一个 CSS3 动画菜单

使用 jQuery 和 CSS3 制作更好的元素选择

CSS3 多级菜单,具有动画效果

制作你的第一个 Chrome 扩展

BounceBox 提示插件

色彩多样的滑动块

使用 jQuery 和 CSS3 创建一个音频播放器

CSS3和jQuery项目的模糊效果

CSS3 制作的动画按钮

CSS3 制作的圆形导航效果

创建一个卷帘菜单

制作 Photoshoot

via djdesignerlab

RSS 永生不灭

【编者按】本文作者为Swizec Teller |

本文是在看过《RSS之战》以及HackerNews上的一些激烈讨论之后有感而发,简而言之,RSS永生不灭。

RSS已死

在2009年的时候, Steve GillmorTechcrunch发了一篇文章,其中有这么一段话:

是时候完全放弃RSS选择Twitter了,RSS已不再具有价值,新闻之河已变成了新闻East River(美国纽约州东南部的海峡,位于曼哈顿岛与长岛之间,本句话寓意RSS价值不在,不值得留恋)。

这一言论激起了广泛讨论,忽然之间似乎每个人每种动物都以为RSS已死,我们应该弃它而去,Twitter将会满足我们的要求,RSS out了。

RSS真的死了吗

在2011年初的时候,RSS并没有像他们认为的那样,完全死掉。Quora上有用户问:如果RSS死了,谁来接班?其中Robert Scoble作了一个很官方的回答(当我见到他的时候,他还说我的创业想法很失败,因为一切都围绕RSS在转)。

既然说RSS死了,什么是死亡?如何定义?对于我来说,一种技术的消亡就意味着无人再有兴趣讨论这种技术,而且最具创新能力的公司也无法利用这种技术做出什么有用的东西。

这么说来,Scoble认为RSS死了,因为Google Reader对他已经毫无用处,也没有人能在RSS领域进行创新了。五个月后,Bummer写了一篇关于iPad上RSS阅读器Feedly的文章,建议 大家不要在iPad上安装Feedly。七个月前还发文声称为iPad开发RSS阅读器就是个愚蠢的做法。

RSS确实面临严峻考验

直到现在,RSS也没有完全消亡,《RSS之战》在黑客新闻上再一次引起了广泛讨论,有许多公司已经在产品中撤出RSS,他们更喜欢专用格式。

  • 苹果新一代Mac操作系统美洲狮似乎也不再支持RSS,并从Safari中,Mail中将RSS撤除。
  • 最新版本的Firefox也不再支持RSS,从原来的url栏消失。
  • Twitter也取消了为用户提供RSS新闻动态。
  • 据说Facebook曾支持过RSS,但很快就消失了,我甚至记不清,我是是否在Facebook见过它。
  • 在Chrome上根本就从未见过RSS。

难道真的RSS就要死掉了么?

其实没有那么糟糕

一种技术,三年以来大家都认为它死了,却还能激起强烈讨论,说明有某种力量在支撑着它。

曾经在Twitter上问过,是否还有人使用RSS,11个回答yes,一个很坚定的回答了no,其中一个不确定,为什么说RSS永生?很简单,它由用户力量的支撑。

在在线参与中有一个90-9-1法则,也就是有90%的内容都来自于1%的顶级参与者,如果这1%的人都是你的用户,那么你的技术是否会受到欢迎就 有保证了,这就是RSS为什么会存在,至少会存在更长一段时间的原因,因为那些分享最多的所有人中,有许多都还在使用RSS,这就是用户力量。

为什么用户还要使用RSS?

Twitter永远无法代替RSS,完全不能,Twitter太忙,我的Twitter每隔一到两分钟就会有差不读30条消息更新。如果你要关注重要消息,这不是个好的环境,不但消息短,更重要的是发出的时间太快,如果要想阅读500字以上的重要文章,更是不可能的事。

这时,RSS的优势显现出来了,在Google Reader上,可能一个小时才更新10则消息,不会很快被湮没,我可以订阅不同网站的内容,可以再左边的订阅网站中任意选择自己关心的内容,没有压力, 不会担心自己错过了什么重要消息,消息一直都在,一个星期,甚至一个月,而Twitter上的消息可能存在时间不超过一个星期。

在Google Reader里边显示的消息,虽然很长,讲的却是不同的东西,很有价值,而Twitter里边的,虽然更新速度快,但大多数消息讲的几乎都是同样的事情,围绕某件事情转发评论,一天真正发出的消息可能只有一条。

对于我这种人来说,Twitter有时让人厌烦,都是一些我不太关心的瞎扯,闲聊,分享的很多链接还不是来自web或者博客,而RSS则展示了更多的内容。

对一些普通用户来说,RSS可能是失败的,有点点复杂,有点点怪异,但对于一些重要用户,或者RSS粉丝来说,RSS永远不会死。

Via Zemanta

文/雷锋网