$push_ios = XingeApp::PushAllIos(accessID,secret,$content,XingeApp::IOSENV_PROD);11
創(chuàng)新互聯(lián)公司擁有十載成都網(wǎng)站建設(shè)工作經(jīng)驗(yàn),為各大企業(yè)提供成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作服務(wù)，對(duì)于網(wǎng)頁設(shè)計(jì)、PC網(wǎng)站建設(shè)（電腦版網(wǎng)站建設(shè)）、成都App定制開發(fā)、wap網(wǎng)站建設(shè)（手機(jī)版網(wǎng)站建設(shè)）、程序開發(fā)、網(wǎng)站優(yōu)化（SEO優(yōu)化）、微網(wǎng)站、域名注冊(cè)等，憑借多年來在互聯(lián)網(wǎng)的打拼，我們?cè)诨ヂ?lián)網(wǎng)網(wǎng)站建設(shè)行業(yè)積累了很多網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、網(wǎng)絡(luò)營銷經(jīng)驗(yàn)，集策劃、開發(fā)、設(shè)計(jì)、營銷、管理等網(wǎng)站化運(yùn)作于一體，具備承接各種規(guī)模類型的網(wǎng)站建設(shè)項(xiàng)目的能力。
我推送的時(shí)候設(shè)置的環(huán)境是發(fā)布環(huán)境的，而app還沒有正式上線，應(yīng)該使用IOSENV_DEV
IOSENV_PROD 表示推送生產(chǎn)環(huán)境； IOSENV_DEV 表示推送開發(fā)環(huán)境。
推送包括兩種形式和兩種方法。兩種方法包括api推送（即后臺(tái)推送）和極光web控制臺(tái)推送。
兩種形式指的是推送包含推送通知以及推送消息，注意：通知會(huì)在蘋果通知中心顯示，但是消息并不會(huì)走apns，即app在后臺(tái)或者未運(yùn)行時(shí)不會(huì)以通知的形式顯示到手機(jī)頁面上，但是每次app啟動(dòng)并運(yùn)行的時(shí)候會(huì)通過回調(diào)方法調(diào)用獲得推送消息。
往往需要針對(duì)個(gè)人推送，這里需要用到極光推送中的別名，或者標(biāo)簽。其原理是用戶在登陸成功時(shí)，通過用戶唯一身份ID進(jìn)行別名或者標(biāo)簽注冊(cè)，在下次需要針對(duì)個(gè)人推送時(shí)，增加通過別名或者標(biāo)簽推送。
極光推送作為較成熟的推送平臺(tái)，通過集成基礎(chǔ)操作。為客戶端以及服務(wù)端節(jié)省了大量時(shí)間來實(shí)現(xiàn)推送效果。
就iOS端來說要注意整體流程，首先，iOS端推送時(shí)分為兩個(gè)狀態(tài)，開發(fā)環(huán)境與生產(chǎn)環(huán)境，每個(gè)環(huán)境在app development里應(yīng)做好相應(yīng)的證書并導(dǎo)出（極光集成時(shí)需要用到p12文件），開發(fā)環(huán)境與生產(chǎn)環(huán)境需要在極光控制臺(tái)設(shè)置。
極光推送個(gè)性化推送滿足用戶多種推送需要,有效提升用戶體驗(yàn),利用大數(shù)據(jù)人工智能技術(shù),實(shí)現(xiàn)智能用戶分群,提升消息點(diǎn)擊率,推送安全包確保推送內(nèi)容準(zhǔn)確,拒絕運(yùn)營事故。
其實(shí)也沒有什么本質(zhì)的區(qū)別，都是一種通知形式，系統(tǒng)的推送可能會(huì)更效率一些，調(diào)用的SDK函數(shù)可能和普通的應(yīng)用程序不一樣。。
App推送消息是我們常見的一種app消息提醒方式。
我們的實(shí)現(xiàn)需要第三方的支持，實(shí)現(xiàn)方式是后臺(tái)通過接口將Push請(qǐng)求發(fā)送至第三方，第三方實(shí)現(xiàn)在App所在設(shè)備上的推送。
在與推送平臺(tái)交互時(shí)，后臺(tái)需要向第三方發(fā)送兩部分信息，推送目標(biāo)終端標(biāo)示+推送內(nèi)容
APP推送需要定位目標(biāo)終端，也就是說要給那臺(tái)設(shè)備進(jìn)行推送，
簡單的情況下，單設(shè)備推送，我們需要拿到一個(gè)終端ID的概念，用于定位目標(biāo)設(shè)備，
注：不同渠道中使用的單設(shè)備ID方式也不盡相同，以下用TokenID來表示這個(gè)終端ID的概念。
而實(shí)際推送渠道中往往還有自定義的功能，比如通過打標(biāo)簽的方式將TokenID進(jìn)行劃分，達(dá)到批量差異化的效果。
即指通過API接口參數(shù)的定義終端上收到的Push消息的內(nèi)容和格式。
其中IOS的推送消息在展示上區(qū)別于安卓的一點(diǎn)是沒有title，title的部分只能是默認(rèn)的APP名稱，而安卓的部分雖然默認(rèn)值也是APP名稱，但是也支持自定義title。
通過上述的處理邏輯可得知，后端首先需要登記客戶端的TokenId，然后保持TokenID的有效性更新，然后在需要發(fā)送APP推送時(shí)拿到用戶的有效TokenID，
然后使用TokenID和已有的內(nèi)容信息通過API與三方Push服務(wù)交互，完成推送。
即后端的實(shí)現(xiàn)分為兩部分：
1、TokenID的登記
2、App Push API的調(diào)用
注：以下示例中有兩個(gè)元素為本項(xiàng)目的特殊情況：
其中product_id是因?yàn)楫?dāng)前項(xiàng)目中客戶端同時(shí)有多個(gè)版本，不同版本需要推送獨(dú)立處理，但在同一張表內(nèi)統(tǒng)一記登記；
而login_id跟member_id同時(shí)存在是因?yàn)楫?dāng)前系統(tǒng)中存在共享賬戶的情況，一般賬號(hào)賬戶一對(duì)一的情況login_id和member_id是綁定的，不需要同時(shí)重復(fù)登記。
pre
/ ============================================================== /
/* Table: sys_app_push_token */
/ ============================================================== /
create table sys_app_push_token
(
record_id int(11) not null auto_increment,
login_id int(11),
member_id int(11),
push_token varchar(200),
visit_device int(4) comment '3:Android;4:IOS',
product_id varchar(20) default '0' comment '',
push_channel int(4) default 1 comment '1：IOS信鴿,2：華為,3：小米,4：極光',
nstatus int(4) not null default 0 comment '狀態(tài)：0：申請(qǐng)中；1：生效；2：失效；3：刪除；4：歷史記錄',
create_userid int(11) not null default 0,
create_time varchar(20) character set utf8 not null default "",
edit_userid int(11) not null default 0,
edit_time varchar(20) character set utf8 not null default "",
this_remark text,
description text,
create_ordernum varchar(30) character set utf8 comment '記錄創(chuàng)建時(shí)的流水號(hào)',
last_ordernum varchar(30) character set utf8 comment '記錄最后一次編輯時(shí)的流水號(hào)',
primary key (record_id)
)
ENGINE=InnoDB
DEFAULT CHARACTERSET=utf8
COLLATE=utf8_general_ci
auto_increment=10000
row_format=COMPACT;
alter table sys_app_push_token comment 'app推送token表';
/ ============================================================== /
/* Index: Index_1 */
/ ============================================================== /
create index Index_1 on sys_app_push_token
(
record_id
);
/pre
注：其中，推送渠道絕對(duì)在做Push時(shí)使用哪家API，參數(shù)的判定交由客戶端進(jìn)行處理，后端直接登記判定結(jié)果。
pre
@Transactional(readOnly=false)
publicbooleanuploadMemberPushTokenEnt(TrainVansContext trainVansContext) {
try{
//check already data
trainVansContext.getTrainVansRequest().put("login_id", TrainVansUtils.getMV(trainVansContext.getTrainVansRequest(),"login_login_id"));
// get All memberRelation
trainVansContext.getTrainVansRequest().put("relation_type", TrainVansUtils.getMV(trainVansContext.getTrainVansRequest(),"visit_role"));
List memberRelationList = SpringContextHandler.getBean(MemberService.class).getRelateMemberListByLoginId(trainVansContext);
for(Map memberRelateMap : memberRelationList){
//
trainVansContext.getTrainVansRequest().put("member_id", TrainVansUtils.getMV(memberRelateMap,"member_id"));
Map tokenMap = SpringContextHandler.getBean(AppPushService.class).getPushTokenMapByLoginMap(trainVansContext.getTrainVansRequest());
//disable already data
if(tokenMap !=null){
if(!TrainVansUtils.getMV(tokenMap,"push_token").equals(TrainVansUtils.getMV(trainVansContext.getTrainVansRequest(),"push_token"))){
//
trainVansContext.getTrainVansRequest().put("record_id", TrainVansUtils.getMV(tokenMap,"record_id"));
if(!SpringContextHandler.getBean(AppPushService.class).updateDiabledThePushToken(trainVansContext)){
thrownewRuntimeException("TranVans_Operate_Exception");
}
//insert new data
if(!SpringContextHandler.getBean(AppPushService.class).insertPushTokenRecord(trainVansContext)){
thrownewRuntimeException("TranVans_Operate_Exception");
}
}
}else{
//insert new data
if(!SpringContextHandler.getBean(AppPushService.class).insertPushTokenRecord(trainVansContext)){
thrownewRuntimeException("TranVans_Operate_Exception");
}
}
}
returntrue;
}catch(Exception e) {
TrainVansUtils.setRetInfo(trainVansContext,"10005001","Register TokenID Error");
e.printStackTrace();
thrownewRuntimeException("TranVans_Operate_Exception");
}
}
/pre
注：方法外部有一個(gè)關(guān)于對(duì)應(yīng)本賬號(hào)的對(duì)賬戶列表的遍歷，遍歷中的處理部分為TokenID的登記處理操作。
推送渠道：
APP推送不僅僅要求在APP打開狀態(tài)時(shí)或者后臺(tái)運(yùn)行時(shí)進(jìn)行消息推送，更多的場景是在移動(dòng)終端關(guān)閉APP的場景下進(jìn)行消息推送，
渠道的優(yōu)劣無非在于兩個(gè)維度，送達(dá)率和送達(dá)效率。
其中安卓推送的渠道較為雜亂，其中華為和小米提供的PUSH服務(wù)對(duì)于自平臺(tái)的移動(dòng)終端支持的較為完善，而沒有廠商提供PUSH服務(wù)的終端只能通過
第三方服務(wù)來進(jìn)行對(duì)接。
對(duì)于現(xiàn)有的這些渠道進(jìn)行如下總結(jié)：
1、IOS：信鴿推送，這個(gè)推送在我門公司中經(jīng)歷了三個(gè)項(xiàng)目，推送效果穩(wěn)定。API接入也方便，是IOS端的不二選擇。
2、Android-華為：華為自平臺(tái)。
3、Android-小米：小米自平臺(tái)。
4、Android-其他：目前使用的是“極光推送”。在理想狀態(tài)下送達(dá)率和送達(dá)效率表現(xiàn)很好，但并不如以上三家渠道穩(wěn)定。
在進(jìn)行調(diào)用時(shí)可根據(jù)之前定義的push_channel分發(fā)給各自的渠道，各渠道的具體對(duì)接請(qǐng)各自查看官網(wǎng)，API都很完善。
APP PUSH的定義為在手機(jī)終端鎖屏狀態(tài)下通知欄展示或在操作前臺(tái)頂端彈出的消息通知，點(diǎn)擊后可喚起對(duì)應(yīng)的APP，并在APP內(nèi)跳轉(zhuǎn)到指定頁面。
push消息是通知用戶，引導(dǎo)用戶進(jìn)行參與活動(dòng)、購買產(chǎn)品的重要手段，而且PUSH消息也可以引導(dǎo)用戶查看消息，喚起APP提高日活，是一塊重要的流量。
從應(yīng)用的功能來劃分，主要分為三類應(yīng)用，第一類是IM類APP，如微信、QQ等；第二類是新聞資訊類，如華爾街見聞等；其余暫歸為為工具類，比如支付寶、美團(tuán)等。
每種類型APP對(duì)PUSH的需求也不同，IM類APP追求實(shí)時(shí)、穩(wěn)定的觸達(dá)，此類APP一般通過自己的長連接進(jìn)行消息推送，保證用戶在收到消息的時(shí)候能夠?qū)崟r(shí)地接收消息消息。另外，一些安卓廠商也會(huì)給予頭部APP的進(jìn)程一定保護(hù)，對(duì)相關(guān)的進(jìn)程納入白名單，在清理進(jìn)程的時(shí)候予以忽略。
新聞資訊類的APP與工具類APP的PUSH推送機(jī)制基本一致，僅在頻率控制上有差異，新聞資訊類由于新聞資訊較多，需要將突發(fā)新聞及時(shí)推送給用戶。
由于目前工具類的APP占大多數(shù)，本文將主要講解工具類APP的常見推送機(jī)制。
PUSH消息在消息系統(tǒng)創(chuàng)建好后進(jìn)入發(fā)送階段，服務(wù)端需要根據(jù)用戶終端信息進(jìn)行路由，如果是IOS系統(tǒng)，那么會(huì)調(diào)用蘋果自身的推送通知服務(wù)（APNs）,如果用戶的手機(jī)是安卓系統(tǒng)，那么根據(jù)不同的廠商去調(diào)用不同的廠商SDK。
對(duì)于不同的系統(tǒng)版本，支持的消息展示形式也是不同，比如IOS10之后，當(dāng)APP在前臺(tái)時(shí)，是否通知欄展示；此樣式可以根據(jù)產(chǎn)品需求來選擇，有服務(wù)端傳輸相應(yīng)通知方式的值即可。如果用戶的手機(jī)非五大廠商內(nèi)的手機(jī)，可以通過自己搭建的長連接或者使用第三方服務(wù)進(jìn)行推送。
如果不是自己直接對(duì)接廠商通道，那么內(nèi)部的服務(wù)端可能無需做過多較為復(fù)雜繁瑣的開發(fā)工作，通過接入第三方消息推送平臺(tái)來實(shí)現(xiàn)消息的推送，比如信鴿、個(gè)推等。多數(shù)的通道會(huì)將消息是否成功推送到客戶端SDK的回執(zhí)數(shù)據(jù)反饋給發(fā)送方，需要提供回調(diào)地址。
4.1 推送通道
通道類型一般分為三類：廠商通道、第三方推送服務(wù)平臺(tái)、長連接。
廠商通道是手機(jī)終端廠商推出的推送服務(wù)，通過接入廠商SDK，內(nèi)部服務(wù)端可以將消息推送到手機(jī)系統(tǒng)的服務(wù)端,再下發(fā)至客戶端內(nèi)部的廠商SDK，由操作系統(tǒng)進(jìn)行相應(yīng)展示，點(diǎn)擊后喚起相應(yīng)APP，這樣可以避免APP進(jìn)程被殺死后消息無法觸達(dá)用戶，因此觸達(dá)率較高。
第三方推送平臺(tái)是推送服務(wù)公司自己搭建相關(guān)的消息服務(wù)。并且各個(gè)APP使用了同一個(gè)平臺(tái)的推送服務(wù)時(shí)，客戶端都是集成同一個(gè)第三方推送平臺(tái)的SDK，因此形成了一個(gè)推送聯(lián)盟，當(dāng)聯(lián)盟中的其中一個(gè)APP的消息進(jìn)程沒有被殺死的時(shí)候，其他的APP也可以利用進(jìn)行通知用戶，形成了相互喚起，提高觸達(dá)率。
經(jīng)過一些場景的測試，相互喚起的成功率并不是很高，需謹(jǐn)慎結(jié)合自身場景評(píng)估。為了提高觸達(dá)率，第三方推送平臺(tái)也會(huì)集成各大廠商的SDK進(jìn)行推送。
長連接就是建立手機(jī)與服務(wù)端的一條鏈路進(jìn)行消息數(shù)據(jù)推送，通過長連接也可以進(jìn)行APP狀態(tài)監(jiān)控，但完全由長連接推送且保證觸達(dá)的穩(wěn)定，需要投入的研發(fā)資源較多,且需盡量避免自己的長連接進(jìn)程不要被操作系統(tǒng)殺死。
4.2 優(yōu)劣勢對(duì)比
APP push功能的搭建需要依據(jù)產(chǎn)品自身的情況和公司可投入的資源成本為主，在不同的階段應(yīng)該追逐不同的目標(biāo)。
5.1 推送賬號(hào)
推送時(shí)客戶端的PUSH SDK均會(huì)根據(jù)用戶的設(shè)備號(hào)生成一個(gè)對(duì)應(yīng)關(guān)系的TOKEN。
在SDK內(nèi)部，如果使用的是第三方推送服務(wù)，則去第三方的SDK注冊(cè)；如果是廠商，則去商城SDK注冊(cè)；如果使用自己長連接，則去自己的SDK進(jìn)行注冊(cè)，作為后續(xù)推送的標(biāo)識(shí)用戶的唯一ID。
5.2 消息路由
消息路主要見上述推送流程的講解，此處主要講解根據(jù)不同的業(yè)務(wù)場景，可能會(huì)定向推送給不同版本APP的用戶。因此服務(wù)端在通道能力路由的時(shí)候，不僅需要能夠區(qū)分通道，還要進(jìn)一步能夠針對(duì)用戶的手機(jī)終端進(jìn)行更加精細(xì)化的差異推送。
此外，消息通道并一定是100%穩(wěn)定，如果下游通道出現(xiàn)問題，服務(wù)端需能夠?qū)⒂捎谕ǖ绬栴}導(dǎo)致的消息路由到備用通道去發(fā)送，以保證業(yè)務(wù)穩(wěn)定觸達(dá)。
5.3 全量推送
一般來說，對(duì)于公司內(nèi)部運(yùn)營或公司的相關(guān)數(shù)據(jù)均是以產(chǎn)品的customer id為準(zhǔn)，用戶數(shù)據(jù)系統(tǒng)對(duì)接消息系統(tǒng)時(shí)也多為customer id，因此需建立customer id與推送TOKEN的關(guān)系，便于運(yùn)營針對(duì)用戶進(jìn)行推送。但對(duì)于一些場景會(huì)需要針對(duì)未登錄的用戶也進(jìn)行推送，即全量推送；比如突發(fā)重大新聞資訊、大促等活動(dòng)，所以運(yùn)營系統(tǒng)需要提供全量推送功能，針對(duì)所有TOKEN進(jìn)行推送。
上報(bào)數(shù)據(jù)包括觸達(dá) 點(diǎn)擊 關(guān)閉 退出 注冊(cè)等數(shù)據(jù)。
對(duì)于所有方式的觸達(dá)消息，都離不開觸達(dá)與點(diǎn)擊，觸達(dá)的數(shù)據(jù)通過廠商的需要廠商回調(diào)上報(bào)，點(diǎn)擊數(shù)據(jù)可以由SDK上報(bào)服務(wù)端。
對(duì)于push的關(guān)閉，也是需要進(jìn)行考量的，來評(píng)估push是否過度發(fā)送，打擾到了用戶。關(guān)閉數(shù)據(jù)有兩部分，一部分為app內(nèi)部的關(guān)閉，sdk直接上報(bào)給服務(wù)端即可；另一部分為用戶在手機(jī)操作系統(tǒng)上關(guān)閉了對(duì)應(yīng)app的push，需要APP在前臺(tái)時(shí)，sdk調(diào)用手機(jī)終端相關(guān)方法獲取該用戶是否關(guān)閉了系統(tǒng)通知，然后上報(bào)至服務(wù)端。
注冊(cè)數(shù)據(jù)即用戶首次啟動(dòng)APP時(shí)，去相關(guān)sdk注冊(cè)token。
用戶退出賬號(hào)時(shí)，sdk需要上報(bào)服務(wù)端，解除token與customer id的綁定關(guān)系。
7.1 強(qiáng)提醒 不留痕
push由于是app自己的通知渠道，是運(yùn)營的一個(gè)重要工具。
如果用戶未關(guān)閉PUSH通知的話，push可以從通知欄彈出進(jìn)行消息顯示，具有一定的強(qiáng)提醒性，但PUSH點(diǎn)擊跳轉(zhuǎn)后便消失，沒有痕跡，因此針對(duì)于重點(diǎn)的通知消息，需要在APP內(nèi)設(shè)置消息中心，在PUSH的同時(shí)留下通知記錄。
7.2 消息樣式
對(duì)于各家PUSH來說，一些營銷消息會(huì)加入EMOJI表情來吸引用戶點(diǎn)擊，這也是一個(gè)吸引用戶點(diǎn)擊的一個(gè)小方法，只要服務(wù)支持傳輸約定好的EMOJI碼就可以了。
目前安卓系統(tǒng)也支持富媒體推送，推送包含圖片、語音等形式，對(duì)于資訊類的APP可以增加縮略圖，吸引用戶點(diǎn)擊。目前來看，語音場景還有點(diǎn)挖掘。
7.3 IOS和安卓
由于APP是基于手機(jī)操作系統(tǒng)，因此對(duì)于IOS和安卓的推送的流程及功能基本相同，只不過細(xì)節(jié)和方法上略有不同，且國內(nèi)安卓產(chǎn)商都在安卓系統(tǒng)上進(jìn)行了一定改造，導(dǎo)致國內(nèi)安卓廠商標(biāo)準(zhǔn)各不相同，需要開發(fā)同學(xué)仔細(xì)對(duì)接各個(gè)廠商。
觸達(dá)率的提升需要從消息創(chuàng)建到實(shí)際通知到用戶的建立完整流程，細(xì)化每一個(gè)交互環(huán)節(jié)，發(fā)現(xiàn)影響觸達(dá)率的主要瓶頸，并針對(duì)性地進(jìn)行解決或優(yōu)化方案。
除此之外，未采用廠商通道的消息也可以采用自己的長連接和其他推送平臺(tái)服務(wù)同時(shí)多條推送，在客戶端的SDK內(nèi)增加針對(duì)同一罅隙流水號(hào)的去重，這樣可以也可以提高一部分消息的觸達(dá)率。
重慶分公司
重慶分公司
