信鸽推送android
Ⅰ 腾讯信鸽怎么给ios和android同时推送消息
分别在ios和android设备上开启通知即可
Ⅱ Android app消息推送 百度 极光 个推 信鸽哪个好一些
这几个消息推送软件都不错，也是大家使用比较多的；但是相比较来说，极光的消息推送软件的优势都是比较明显的。具体的优势如下：1、更新及时
日指标（DAU、新增、渗透等）T+2上线，月指标（MAU、用户画像、行业分析等）T+8上线。
2、覆盖广泛
每月稳定覆盖11.5亿活跃设备，22个一级行业，206个二级行业的200万+APP。
3、功能丰富
6个子产品，30+功能模块，200+关键运营指标；18种标签大类，超过1000个用户标签。
极光提供的数据服务还可从时间、空间、客流等维度帮助零售企业实现对区域客流情况、目标人群行为特征以及区域内营销活动的效果分析，从而为商业决策提供更全面的数据支持。
Ⅲ Android开发腾讯信鸽怎么获取通知的内容
信鸽推送那里可以选择添加参数的，如果点击通知操作选的是打开应用指定页面，则这些参数可以在该指定页面的Activity的onStart()方法中获得，具体代码是：
@Override
protected void onStart() {
super.onStart();
XGPushClickedResult click = XGPushManager.onActivityStarted(this);
if (click != null) {
String customContent = click.getCustomContent();
if (customContent != null && customContent.length() != 0) {
try {
JSONObject json = new JSONObject(customContent);
url = json.getString("URL");//例如这个是你自己添加的一个参数，是传递一个URL
。。。。。。
}
Ⅳ Android 如何进行进程保活
每一个 Android 应用启动后至少对应一个进程，有的是多个进程，而且主流应用中多个
进程的应用比例较大
对于任何一个进程，我们都可以通过 adb shell ps|grep <package_name>的方式来查看
它的基本信息
Android 中的进程跟封建社会一样，分了三流九等，Android 系统把进程的划为了如下
几种（重要性从高到低），网上多位大神都详细总结过（备注：严格来说是划分了 6 种）。
场景：
1.某个进程持有一个正在与用户交互的 Activity 并且该 Activity 正处于 resume 的
状态。
2.某个进程持有一个 Service，并且该 Service 与用户正在交互的 Activity 绑定。
3.某个进程持有一个 Service，并且该 Service 调用 startForeground()方法使之位于前台运行。
4.某个进程持有一个 Service，并且该 Service 正在执行它的某个生命周期回调方法，比如 onCreate()、 onStart()或 onDestroy()。
5.某个进程持有一个 BroadcastReceiver，并且该 BroadcastReceiver 正在执行其onReceive()方法。用户正在使用的程序，一般系统是不会杀死前台进程的，除非用户强制停止应用或者系统内存不足等极端情况会杀死。
场景：
1.拥有不在前台、但仍对用户可见的 Activity（已调用 onPause()）。
2.拥有绑定到可见（或前台）Activity 的 Service
用户正在使用，看得到，但是摸不着，没有覆盖到整个屏幕,只有屏幕的一部分可见进程
不包含任何前台组件，一般系统也是不会杀死可见进程的，除非要在资源吃紧的情况下，
要保持某个或多个前台进程存活
场景
1.某个进程中运行着一个 Service 且该 Service 是通过 startService()启动的，与用户看见的界面没有直接关联。
在内存不足以维持所有前台进程和可见进程同时运行的情况下，服务进程会被杀死
场景：
在用户按了"back"或者"home"后,程序本身看不到了,但是其实还在运行的程序，
比如 Activity 调用了 onPause 方法系统可能随时终止它们，回收内存
场景：
某个进程不包含任何活跃的组件时该进程就会被置为空进程，完全没用,杀了它只有好处没坏处,第一个干它!
上面是进程的分类，进程是怎么被杀的呢？系统出于体验和性能上的考虑，app 在退到
后台时系统并不会真正的 kill 掉这个进程，而是将其缓存起来。打开的应用越多，后台缓存的进程也越多。在系统内存不足的情况下，系统开始依据自身的一套进程回收机制
来判断要 kill 掉哪些进程，以腾出内存来供给需要的 app, 这套杀进程回收内存的机制
就叫 Low Memory Killer。那这个不足怎么来规定呢，那就是内存阈值，我们可以使用
cat /sys/mole/lowmemorykiller/parameters/minfree 来查看某个手机的内存阈值。
其实系统在进程回收跟内存回收类似也是有一套严格的策略，可以
自己去了解，大概是这个样子的，oom_adj 越大，占用物理内存越多会被最先 kill 掉，OK，那么现在对于进程如何保活这个问题就转化成，如何降低 oom_adj 的值，以及如
何使得我们应用占的内存最少。
据说这个是手 Q 的进程保活方案，基本思想，系统一般是不会杀死前台进程的。所以要
使得进程常驻，我们只需要在锁屏的时候在本进程开启一个 Activity，为了欺骗用户，
让这个 Activity 的大小是 1 像素，并且透明无切换动画，在开屏幕的时候，把这个 Activity
关闭掉，所以这个就需要监听系统锁屏广播，我试过了，的确好使，如下。
如果直接启动一个 Activity，当我们按下 back 键返回桌面的时候，oom_adj 的值是 8，
上面已经提到过，这个进程在资源不够的情况下是容易被回收的。现在造一个一个像素
的 Activity。
为了做的更隐藏，最好设置一下这个 Activity 的主题，当然也无所谓了
在屏幕关闭的时候把 LiveActivity 启动起来，在开屏的时候把 LiveActivity 关闭掉，所以
要监听系统锁屏广播，以接口的形式通知 MainActivity 启动或者关闭 LiveActivity。
现在 MainActivity 改成如下
按下 back 之后，进行锁屏，现在测试一下 oom_adj 的值
果然将进程的优先级提高了。
但是还有一个问题，内存也是一个考虑的因素，内存越多会被最先 kill 掉，所以把上面
的业务逻辑放到 Service 中，而 Service 是在另外一个 进程中，在 MainActivity 开启这
个服务就行了，这样这个进程就更加的轻量，
OK，通过上面的操作，我们的应用就始终和前台进程是一样的优先级了，为了省电，
系统检测到锁屏事件后一段时间内会杀死后台进程，如果采取这种方案，就可以避免了
这个问题。但是还是有被杀掉的可能，所以我们还需要做双进程守护，关于双进程守护，
比较适合的就是 aidl 的那种方式，但是这个不是完全的靠谱，原理是 A 进程死的时候，
B 还在活着，B 可以将 A 进程拉起来，反之，B 进程死的时候，A 还活着，A 可以将 B
拉起来。所以双进程守护的前提是，系统杀进程只能一个个的去杀，如果一次性杀两个，
这种方法也是不 OK 的。
事实上
那么我们先来看看 Android5.0 以下的源码，ActivityManagerService 是如何关闭在应用
退出后清理内存的
在应用退出后，ActivityManagerService 不仅把主进程给杀死，另外把主进程所属的进
程组一并杀死，这样一来，由于子进程和主进程在同一进程组，子进程在做的事情，也
就停止了。所以在 Android5.0 以后的手机应用在进程被杀死后，要采用其他方案。
这种大部分人都了解，据说这个微信也用过的进程保活方案，移步微信 Android 客户端
后台保活经验分享，这方案实际利用了 Android 前台 service 的漏洞。
原理如下
对于 API level < 18 ：调用 startForeground(ID， new Notification())，发送空的
Notification ，图标则不会显示。
对于 API level >= 18：在需要提优先级的 service A 启动一个 InnerService，两个服务
同时 startForeground，且绑定同样的 ID。Stop 掉 InnerService ，这样通知栏图标即
被移除。
public class KeepLiveService extends Service{
public static final int NOTIFICATION_ID=0x11;
public KeepLiveService() {
}
@Override
public IBinder onBind(Intent intent){
throw new UnsupportedOperationException("Not yet implemented");
}
@Override
public void onCreate() {
super.onCreate(); //API 18 以下，直 接发 送 Notification 并 将 其 置 为 前 台
if(Build.VERSION.SDK_INT<Build.VERSION_CODES.JELLY_BEAN_MR2){
startForeground(NOTIFICATION_ID,new Notification());
} else { //API 18 以上，发送 Notification 并将其置为前台后，启动 InnerService
Notification.Builder builder=new Notification.Builder(this);
builder.setSmallIcon(R.mipmap.ic_launcher);
startForeground(NOTIFICATION_ID, builder.build());
startService(new Intent(this, InnerService.class));
}
}
public class InnerService extends Service{
@Override public IBinder onBind(Intent intent) {
return null;
}
@Override public void onCreate() {
super.onCreate(); //发送与 KeepLiveService中 ID 相同的 Notification，然后将其取消并取消自己的前台显示
Notification.Builder builder = new Notification.Builder(this);
builder.setSmallIcon(R.mipmap.ic_launcher);startForeground(NOTIFICATION_ID,
builder.build());
new Handler().postDelayed(new Runnable() {
@Override public void run() {
stopForeground(true);
NotificationManager manager = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);
manager.cancel(NOTIFICATION_ID);
stopSelf();
}
},
100);
}
}
}
在没有采取前台服务之前，启动应用，oom_adj 值是 0，按下返回键之后，变成 9（不
同 ROM 可能不一样）
相互唤醒的意思就是，假如你手机里装了支付宝、淘宝、天猫、UC 等阿里系的 app，
那么你打开任意一个阿里系的 app 后，有可能就顺便把其他阿里系的 app 给唤醒了。
这个完全有可能的。此外，开机，网络切换、拍照、拍视频时候，利用系统产生的广播
也能唤醒 app，不过 Android N 已经将这三种广播取消了。
如果应用想保活，要是 QQ，微信愿意救你也行，有多少手机上没有 QQ，微信呢？或
者像友盟，信鸽这种推送 SDK，也存在唤醒 app 的功能。
拉活方法
JobSheler是作为进程死后复活的一种手段，
native进程方式最大缺点是费电，Native
进程费电的原因是感知主进程是否存活有两种实现方式，在 Native 进程中通过死循环
或定时器，轮训判断主进程是否存活，当主进程不存活时进行拉活。其次 5.0 以上系统
不支持。 但是 JobSheler 可以替代在 Android5.0 以上 native 进程方式，这种方式即
使用户强制关闭，也能被拉起来，亲测可行。
JobSheler@TargetApi(Build.VERSION_CODES.LOLLIPOP)
public class MyJobService extends JobService {
@Override
public void onCreate() {
super.onCreate();
startJobSheler();
}
public void startJobSheler() {
try {
JobInfo.Builder builder = new JobInfo.Builder(1,new ComponentName(getPackageName(), MyJobService.class.getName()));
builder.setPeriodic(5); builder.setPersisted(true); JobScheler jobScheler =(JobScheler)
this.getSystemService(Context.JOB_SCHEDULER_SERVICE);
jobScheler.schele(builder.build());
}
catch
(Exception ex)
{ ex.printStackTrace(); } }
@Override
public boolean onStartJob(JobParameters jobParameters) {
return false;
} @Override public boolean onStopJob(JobParameters jobParameters) {
return false;
}
}
这个是系统自带的，onStartCommand 方法必须具有一个整形的返回值，这个整形的返
回值用来告诉系统在服务启动完毕后，如果被 Kill，系统将如何操作，这种方案虽然可
以，但是在某些情况 or 某些定制 ROM 上可能失效，我认为可以多做一种保保守方案。
1.START_STICKY
如果系统在 onStartCommand 返回后被销毁，系统将会重新创建服务并依次调用
onCreate 和 onStartCommand（注意：根据测试 Android2.3.3 以下版本只会调用
onCreate 根本不会调用 onStartCommand，Android4.0 可以办到），这种相当于服务
又重新启动恢复到之前的状态了）。
2.START_NOT_STICKY
如果系统在 onStartCommand 返回后被销毁，如果返回该值，则在执行完
onStartCommand 方法后如果 Service 被杀掉系统将不会重启该服务
3.START_REDELIVER_INTENT
START_STICKY 的兼容版本，不同的是其不保证服务被杀后一定能重启。
4.相比与粘性服务与系统服务捆绑更厉害一点，这个来自爱哥的研究，这里说的系统服务
很好理解，比如 NotificationListenerService，NotificationListenerService 就是一个监听
通知的服务，只要手机收到了通知，NotificationListenerService 都能监听到，即时用户
把进程杀死，也能重启，所以说要是把这个服务放到我们的进程之中，那么就可以呵呵
了
所以你的应用要是有消息推送的话，那么可以用这种方式去欺骗用户。
Ⅳ android系统的APP消息推送机制
参考文章：
http://blog.csdn.net/carson_ho/article/details/52862418
1. 主流的第三方推送平台分类
手机厂商类：小米推送、华为推送。
第三方平台类：友盟推送、极光推送、云巴（基于MQTT）
BAT大厂的平台推送：阿里云移动推送、腾讯信鸽推送、网络云推送
2. 对比其他推送方式的特点
其他推送方式还有：C2DM、轮询、SMS、MQTT协议、XMPP协议等等，相对于这些推送方式，第三方推送方式的特点分别是：
优点：
成本低
上述的推送大多数是免费的，假如自己实现则消耗过多资源（开发成本和后台管理、统计成本）
消息到达率高
如果一个手机里有多个App使用了同一家推送服务，那么这些App将共用一条消息通道，即使你家的App推送服务被杀死了，那么只要用户打开了其他集成该推送服务的App，你家的推送就能到达用户
缺点
安全性低
使用别人的服务器，所以你懂的。
服务会被杀死
由于Android系统的机制，后台推送 Service 会被各种主动的或是被动的行为给杀死，而服务一旦被杀死，意味着就接收不到推送消息。
3. 第三方推送服务方式的特点
第三方服务基本都具备免费、和到达率高的特点
那么应该如何选择呢？我们来分别看一下第三方推送各种方式的优点：
3.1 手机厂商推送
请记住一个潜规则：操作系统是不会杀死属于自己品牌的推送服务。
手机厂商的推送服务在自家的手机上属于系统级别的服务，这意味着系统不会杀死自家的推送服务
比如说，Android原生系统是不会杀死C2DM消息推送服务，MIUI系统是不会杀死小米的推送服务。
当今市场上的Android手机系统份额最高是MIUI系统，即小米（具体排名请看http://www.umindex.com/）
因为：免费、到达率高且在Android系统市场份额第一的MIUI系统上不被杀死。所以，如果要选择手机厂商的推送服务，请选择小米推送作为第三方平台实现推送服务
下面一些应用可以从侧面来证明我的推断：
腾讯新闻使用的小米推送，没有使用自己家的信鸽推送
淘宝使用了自家的阿里云推送，同时还集成了小米推送
网络视频和爱奇艺使用的是小米推送，没有用自家的网络推送
官网截图 - 集成应用：
如果希望进一步提高推送的效果，其实可以集成多个手机厂商的推送服务
比如小米渠道用小米推送，华为渠道用华为推送，但这样的实现成本会大一些
3.2 第三方平台类
请记住一个规则：推送系统会共享一条推送渠道
这意味着假设你接入了友盟推送，而恰好今日头条也接入了友盟。
有一天你的App被杀死了，但这时用户启动了今日头条，那么推送系统也就会通过共享的推送通道顺便把你推送消息送达到手机上，然后还可能把你的进程也唤醒（被“保活”了）。
所以说，关于如何选择第三方平台类的推送，推送平台的规模效应就很重要了。
那如何得知他们的规模和市场份额呢？按个人经验，主要看两点：
问内部的朋友。
看推送平台的合作客户里有哪些大的app - 参考对应官网的合作案例
3.3 BAT大厂的推送
BAT大厂其实并没有什么优势，同时谨记：
不要以为用了腾讯信鸽推送，就能占上微信的光保证你的App永远内部被杀死。
说个题外话，手机淘宝除了自家的阿里云的移动推送，同时也使用其它的第三方推送平台啊（比如友盟推送）。
4. 如何选择第三方平台推送服务？
主要从用户类别+实现成本+渠道来选择不同的使用场景
1. 如果用户群体精准（使用小米手机或华为手机居多），可以考虑只集成对应手机厂商的推送；
注意：单一的手机厂商也能工作，比如小米推送在非小米手机上当然也能工作，只不过不是系统级别的服务了，容易被杀死。
如果用户群体广泛、希望实现成本低，可以考虑只使用单一第三方平台类的推送（极光、友盟blabla，选一个规模效应最大的）
如果用户群体广泛、不在意实现成本，个人建议：
对于小米手机，使用小米推送；
对于华为手机，使用华为推送；
对于其他手机，只使用单一第三方平台类的推送（极光、友盟blabla，选一个规模效应最大的）
让不同的推送运行在各自擅长的环境里，最大化实现推送的到达率和产品的存活率
大家可以根据自己的使用场景来进行消息推送平台的选择。
5. 推送消息类别的选择
5.1 推送消息的类别
通常第三方推送平台都支持两种推送消息类型：通知栏消息和透传消息。
通知栏消息：该类消息在被送达用户的设备后，直接以系统通知栏的形式展示给用户
不会继续被传递到App
透传消息：该类消息在被送达用户的设备后，还会继续传递到App
通过回调App的某个BroadcastReceiver的形式将消息传递到App内部。然后由App决定如何处理和显示这个消息。
所以透传消息不一定会以系统通知栏的形式进行推送，由程序猿自定义
5.2 消息类别的区别与特点
二者的区别在于：透传消息在整个消息传递过程中比通知栏消息多了一步-传递到App
通知栏消息的优点：送达率高
因为透传消息在整个消息传递过程中比通知栏消息多了一步-传递到App，因此透传消息就增加一些被系统限制的概率，给系统杀死的概率就高一些，所以说，通知栏消息比透传消息应该能提供更好的送达率。
我们来看下小米推送的官方文档描述：
在一些 Android 系统(如 MIUI)中，受到系统自启动管理设置的限制,应用不能在后台自启动
在这类系统中，如果在发送消息的时候对应的应用没有被启动，透传类消息将不能顺利送达。
因此,对于对送达率要求很高的消息,建议尽量采用通知栏提醒的方式推送消息
透传消息的优点：对消息操作程度高 & 自定义程度高
提供了对消息数据的更灵活的操纵能力。
App如果仅仅通过通知栏消息，是无法接触到消息数据本身的。
可自定义通知提醒的样式（包括提示样式、提示形式如声音等等）
所以大家可以根据不同的使用场景来对推送消息类别进行选择了。