信鴿推送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如果僅僅通過通知欄消息，是無法接觸到消息數據本身的。
可自定義通知提醒的樣式（包括提示樣式、提示形式如聲音等等）
所以大家可以根據不同的使用場景來對推送消息類別進行選擇了。