1 目前使用3.0 版本,支持 managed 和subscription 。

2 managed product 支持消费 ,消费后可以再次购买,也可以用于一次性购买,在自己的代码中处理逻辑,subscription 用于每月或每年订阅 。

3 首先要google上传签名过的apk , 建立managed product 和subsctiption ,设定价格,描述等信息 。

4 在发布控制台中,设置测试账号 ,测试的账号不能喝发布的账号一摸一样 ,否则不能买。

5 从apk发布控制台这个apk的public key ,贴在apk中的security.java 中。

6 重新编译上传签名的apk到发布控制台,并且要运行同样签过发布证书的的apk才能测试成功,否则会出现错误:“this version of the application is not enabled for in-app billing”

7 安全建议,不要在apk中明文显示你的public key ,至少做加密处理或从你的服务器获取。 在每次处理购买过程中,使用payload 来验证来回的相应。避免中间人攻击。

 

 

作为Android开发者中的一枚小鸟,这里结合自己的一些经历、见闻,谈谈Android产品的盈利模式。这也是必须要面对的问题,关乎团队的生存。

对于Android开发,主要分三层次:
1.应用开发

都知道的,俗称API王子。会比较多得考虑创意、盈利的问题。

2.系统开发(Framework + Native)

使用C/C++,基于NDK JNI的开发,需要对android的整体框架和codebase比较熟悉。一般国内所谓的深度定制的系统就是这个了,MIUI,点心之类的。定制一套系统UI,制作ROM等等。

3.底层开发(系统移植 、 驱动 …….)

熟悉Linux驱动开发,Linux内核结构,针对特定的硬件做移植。这类一般是个大手机厂商的开发者,像魅族、小米、HTC之类的。

这里主要探讨App开发者的生存问题,当然,也可以加入大公司,这样就好些。而作为独立中小团队来说,这却是亟待思考的问题,而且普遍反映Android开发者盈利能力弱,很多都是生活在温饱线上啊。

个人感觉,造成安卓盈利能力弱的原因主要如下:
1、Android用户先天没有付费习惯,尤其是在央央大中华(所以有些实力的团队把主要精力都投到海外了,直接略过国内用户。比如海豚,也是先在国外推广后,才转入国内的);
2、国内用户使用官方market不便;
3、Android应用优质应用占比少,鱼龙混杂;
4、的确是没有找到特别好的盈利模式啊;
5、中小团队的产品运营能力普遍较弱,所以才有了类似创新工场这类孵化。

目前,Android下中小开发者盈利模式主要以下几种:项目外包、付费下载、广告、积分、厂商内置等。

项目外包:不说了额
广告展示
传统的广告展示指开发者在应用中嵌入移动广告商的广告条。

国外广告商: admob、Millennial、InMobi、Mdot、OneRiot、Quattro、ZestAdz、Tapjoy、Mobfox。国内广告商: 万普、多盟、力美、有米、百度、易传媒、AirAD、微云、AppMedia、迪派、指点传媒、安机、哇棒、安沃、亿动、VPON、腾讯聚赢。此外还有些广告聚合提供商,如果合等。

计费方式主要有:按点击次数(CPC)、按效果计费(CPA)、按展示次数(CPM)。坑爹的主要是前两种,很多商家的广告展示是不计费的,或者单价非常非常低。但都知道很少会有人去点击什么广告的。一般来说,点击一次从几分到0.2元不等。

广告内容上,大都是有钱的公司做的产品推广。广告类型比较单一,数量也很少。我曾经用过的一个广告商,提供的总共也就7~8个,来回变。

而事实上,内嵌广告条是非常影响用户体验的,想想丁点大的屏幕还被广告占掉1/5,谁乐意。至少我是不会用嵌广告的软件的,即使迫不得已,基本也不会去点,即使点了一次,也不会有第二次。而且普遍来说,嵌入广告的应用在我手机里存活时间不长,基本用上几次,就卸了。

不过的确,在网上见有大牛,通过广告展示,赚大钱的,日入上百的开发者还是有的。比如传说中的这个“兔斯基”。

应用推荐
现在见得也比较多了,在应用的合适位置添加一个“应用推荐位”的按钮或抽屉,点击即可调出推荐列表,用户下载推荐应用,开发者即可获得收入。

积分模式
积分类似于虚拟货币,应用内部设置一些关卡、道具、高级功能或内容,用户可以用虚拟货币来购买。而虚拟货币的获得来源可以是:下载推荐应用、点击展示广告。通过这用方式,则可以促进用户对推荐应用以及广告展示的关注。

其他
还有些开发者会出版Android开发相关书籍,以此盈收。此外还可以有捐赠机制,支付宝、paypal之类的。当然,还发现一个团队这样子赚钱的:传送门。

特别的,运营很关键
浏览器可以与网站合作(类似于导航),或者比较新的海豚之类的,已经发展成平台,基于其的web应用也是与站点的合作。LBS类、团购类应用可以与线下商家建立合作关系。酒店生活类应用可以与线下多家商旅酒店合作推广,比如布丁系列产品。。。
也就是说,对于一个好的产品,运营好了,积攒一定量用户。就可以与合适的商家建立合作关系了。
应用开发的话,尽量垂直化,做好自己的一亩三分地,避免与企鹅之类的正面火拼,也就是把握自己的特色。有创意当然很好,把东西质量做好,用户体验做优,这样也有可能获得风投的青睐,然后有了资金,下面的推广运营也就好办了。

晨照の博客 CzzZ.org » 关于Android开发者盈利的思考.

1.X-prize:一个教育性的非营利性机构,旨在通过竞争驱动、促成对全人类有益的重大变革。2.Moonshot Thinking:跟 Paul Graham 提到的黑天鹅效应的概念有相似处,即突破旧观念、拥抱那些大胆而创新想法。

通过向知识产权体系开炮:用新的、众筹式的激励机制驱动“创意机器” | 36氪.

通过【译】@selector和SEL_iOS·足迹.



【译】@selector和SEL






遇到selector发现不是很明白,网上搜到的零零星星的介绍也不成体系,索性自己翻译一下,加深一下印象。原文来自官方API文档下的Selectors


Selectors


在OC中,selector有两层含义。


1、当selector在源代码中被用来指向一个对象的时候,selector可以仅仅指这个方法的名称。


2、代码编译的时候会生成一个唯一的标示符,selector也可以指向该标示符。


selectors的编译类型为SEL。所有有同样名称的方法都有同样的selector。针对某个对象(object),你可以使用selector去调用它的方法。这给Cocoa的目标-行为设计模式(the target-action design pattern,注:关于这部分在该篇API的最后进行了说明)提供了执行的基础。


Methods and Selectors


为了提高效率,在编译规则(compiled code)中一个完整的ASCII名称不被作为方法的selectors。取而代之的方法是,编译器将每一个方法的名称写到一个table中,然后跟一个唯一的标示符配对,该标示符在运行过程中会代表一个具体的方法。运行系统(runtime system)确保每一个标示符都是唯一的:没有两个selector是相同的,而且所有有同样名称的方法有同样的selector


SEL and @selector


selector编译后被指定到一种特殊的类型——SEL来与其它类型进行区分。有效的selector永远不会为0.你必须让系统给方法分配SEL标示符,自行任意分配的标示符是无效的。


你应该使用@selector()指令将方法名传递给编译的selector,而不是直接使用一个方法的全名。比如,下面的方法可以获得setWidth:height: 方法的selector,并且分配给setWidthHeight变量:




SEL setWidthHeight;


setWidthHeight = @selector(setWidth:height:);



最有效的的方式是在编译的时候调用@selector()指令给SEL变量赋值。但在有些情况下,你可能需要在运行时候将字符串转换给某个selector。你可以使用NSSelectorFromStringn函数完成这项工作:




setWidthHeight = NSSelectorFromString(aBuffer);



反着转换也是可行的。NSStringFromSelector函数可以返回某个selector的方法的名称:




NSString *method;


method = NSStringFromSelector(setWidthHeight);



Methods and Selectors


selector编译后可以识别方法名称,但不实现方法(not method implementations)。比如,对于一个类而言,它的display方法和其它同样定义了display方法的类有相同的selector。对于动态绑定和多态性而言这是必不可少的,它可以让你给不同类的接收器发送相同的方法。如果每一个执行方法都有一个selector,那么发送这条信息就跟调用了一个函数回调(function call)没什么区别了。


具有相同名称的类方法和实例方法被分配了相同的selector,单因为他们属于不同的领域,这两者之间也不会产生混淆。一个类能定义display方法,附加给一个实例方法。


Method Return and Parameter Types


通告程序(messaging routine)只能通过selector访问方法实体(method implementation),所以它用同样的selector处理所有方法 (注:这句话不理解,附原文so it treats all methods with the same selector alike)。通告程序(it)可以通过selector辨别一个方法的返回类型、以及参数的数据类型。因此,除非通告(message)是发送给静态类型的接收器,否则对于动态绑定接收器,会要求所有有同样名称方法的实例页有同样的返回类型和参数类型。(对于该规则,静态类型的接收器属于例外的原因是编译器能从类的类型了解该方法实体。)


虽然相同名称的类方法和实例方法是使用同样的selector代表的,它们可以有不同的参数类型和返回值类型。


Varying the Message at Runtime


NSObject协议中定义的 performSelector:, performSelector:withObject:,和 performSelector:withObject:withObject:方法使用SEL标示符作为它们的初始化参数。所有这三个方法(注:我很奇怪为什么是三个,但是原文就是写的三个…)直接映射到通告功能(massaging function)。例如:




[friend performSelector: @selector(gossipAbout:)


withObject: aNeighbor];



相当于




[friend gossipAbout:aNeighbor];



这些方法使应用运行时改变message成为可能,就像可以改变一个接收message的object一样。Variable names can be used in both halves of a message expression:




id helper = getTheReceiver();


SEL request = getTheSelector();


[helper performSelector:request];



在这个例子中,接收器helper在运行时候进行选择(通过一个假设的getTheReceiver函数),方法接收器页要求在运行时执行request(同样通过一个假设的getTheSelector函数)


Note:performSelector: 方法和它其它同伴的方法都返回一个类型为id的对象,如果当前执行的方法返回一个不同的类型,它应当被转换为适当的类型。(但,转换不适用于所有类型,方法应当返回一个指针或者一个指针兼容的类型)


The Target-Action Design Pattern