$push_ios = XingeApp::PushAllIos(accessID,secret,$content,XingeApp::IOSENV_PROD);11
创新互联公司拥有十载成都网站建设工作经验,为各大企业提供成都网站设计、成都网站制作服务，对于网页设计、PC网站建设（电脑版网站建设）、成都App定制开发、wap网站建设（手机版网站建设）、程序开发、网站优化（SEO优化）、微网站、域名注册等，凭借多年来在互联网的打拼，我们在互联网网站建设行业积累了很多网站制作、网站设计、网络营销经验，集策划、开发、设计、营销、管理等网站化运作于一体，具备承接各种规模类型的网站建设项目的能力。
我推送的时候设置的环境是发布环境的，而app还没有正式上线，应该使用IOSENV_DEV
IOSENV_PROD 表示推送生产环境； IOSENV_DEV 表示推送开发环境。
推送包括两种形式和两种方法。两种方法包括api推送（即后台推送）和极光web控制台推送。
两种形式指的是推送包含推送通知以及推送消息，注意：通知会在苹果通知中心显示，但是消息并不会走apns，即app在后台或者未运行时不会以通知的形式显示到手机页面上，但是每次app启动并运行的时候会通过回调方法调用获得推送消息。
往往需要针对个人推送，这里需要用到极光推送中的别名，或者标签。其原理是用户在登陆成功时，通过用户唯一身份ID进行别名或者标签注册，在下次需要针对个人推送时，增加通过别名或者标签推送。
极光推送作为较成熟的推送平台，通过集成基础操作。为客户端以及服务端节省了大量时间来实现推送效果。
就iOS端来说要注意整体流程，首先，iOS端推送时分为两个状态，开发环境与生产环境，每个环境在app development里应做好相应的证书并导出（极光集成时需要用到p12文件），开发环境与生产环境需要在极光控制台设置。
极光推送个性化推送满足用户多种推送需要,有效提升用户体验,利用大数据人工智能技术,实现智能用户分群,提升消息点击率,推送安全包确保推送内容准确,拒绝运营事故。
其实也没有什么本质的区别，都是一种通知形式，系统的推送可能会更效率一些，调用的SDK函数可能和普通的应用程序不一样。。
App推送消息是我们常见的一种app消息提醒方式。
我们的实现需要第三方的支持，实现方式是后台通过接口将Push请求发送至第三方，第三方实现在App所在设备上的推送。
在与推送平台交互时，后台需要向第三方发送两部分信息，推送目标终端标示+推送内容
APP推送需要定位目标终端，也就是说要给那台设备进行推送，
简单的情况下，单设备推送，我们需要拿到一个终端ID的概念，用于定位目标设备，
注：不同渠道中使用的单设备ID方式也不尽相同，以下用TokenID来表示这个终端ID的概念。
而实际推送渠道中往往还有自定义的功能，比如通过打标签的方式将TokenID进行划分，达到批量差异化的效果。
即指通过API接口参数的定义终端上收到的Push消息的内容和格式。
其中IOS的推送消息在展示上区别于安卓的一点是没有title，title的部分只能是默认的APP名称，而安卓的部分虽然默认值也是APP名称，但是也支持自定义title。
通过上述的处理逻辑可得知，后端首先需要登记客户端的TokenId，然后保持TokenID的有效性更新，然后在需要发送APP推送时拿到用户的有效TokenID，
然后使用TokenID和已有的内容信息通过API与三方Push服务交互，完成推送。
即后端的实现分为两部分：
1、TokenID的登记
2、App Push API的调用
注：以下示例中有两个元素为本项目的特殊情况：
其中product_id是因为当前项目中客户端同时有多个版本，不同版本需要推送独立处理，但在同一张表内统一记登记；
而login_id跟member_id同时存在是因为当前系统中存在共享账户的情况，一般账号账户一对一的情况login_id和member_id是绑定的，不需要同时重复登记。
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 '状态：0：申请中；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 '记录创建时的流水号',
last_ordernum varchar(30) character set utf8 comment '记录最后一次编辑时的流水号',
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
注：其中，推送渠道绝对在做Push时使用哪家API，参数的判定交由客户端进行处理，后端直接登记判定结果。
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
注：方法外部有一个关于对应本账号的对账户列表的遍历，遍历中的处理部分为TokenID的登记处理操作。
推送渠道：
APP推送不仅仅要求在APP打开状态时或者后台运行时进行消息推送，更多的场景是在移动终端关闭APP的场景下进行消息推送，
渠道的优劣无非在于两个维度，送达率和送达效率。
其中安卓推送的渠道较为杂乱，其中华为和小米提供的PUSH服务对于自平台的移动终端支持的较为完善，而没有厂商提供PUSH服务的终端只能通过
第三方服务来进行对接。
对于现有的这些渠道进行如下总结：
1、IOS：信鸽推送，这个推送在我门公司中经历了三个项目，推送效果稳定。API接入也方便，是IOS端的不二选择。
2、Android-华为：华为自平台。
3、Android-小米：小米自平台。
4、Android-其他：目前使用的是“极光推送”。在理想状态下送达率和送达效率表现很好，但并不如以上三家渠道稳定。
在进行调用时可根据之前定义的push_channel分发给各自的渠道，各渠道的具体对接请各自查看官网，API都很完善。
APP PUSH的定义为在手机终端锁屏状态下通知栏展示或在操作前台顶端弹出的消息通知，点击后可唤起对应的APP，并在APP内跳转到指定页面。
push消息是通知用户，引导用户进行参与活动、购买产品的重要手段，而且PUSH消息也可以引导用户查看消息，唤起APP提高日活，是一块重要的流量。
从应用的功能来划分，主要分为三类应用，第一类是IM类APP，如微信、QQ等；第二类是新闻资讯类，如华尔街见闻等；其余暂归为为工具类，比如支付宝、美团等。
每种类型APP对PUSH的需求也不同，IM类APP追求实时、稳定的触达，此类APP一般通过自己的长连接进行消息推送，保证用户在收到消息的时候能够实时地接收消息消息。另外，一些安卓厂商也会给予头部APP的进程一定保护，对相关的进程纳入白名单，在清理进程的时候予以忽略。
新闻资讯类的APP与工具类APP的PUSH推送机制基本一致，仅在频率控制上有差异，新闻资讯类由于新闻资讯较多，需要将突发新闻及时推送给用户。
由于目前工具类的APP占大多数，本文将主要讲解工具类APP的常见推送机制。
PUSH消息在消息系统创建好后进入发送阶段，服务端需要根据用户终端信息进行路由，如果是IOS系统，那么会调用苹果自身的推送通知服务（APNs）,如果用户的手机是安卓系统，那么根据不同的厂商去调用不同的厂商SDK。
对于不同的系统版本，支持的消息展示形式也是不同，比如IOS10之后，当APP在前台时，是否通知栏展示；此样式可以根据产品需求来选择，有服务端传输相应通知方式的值即可。如果用户的手机非五大厂商内的手机，可以通过自己搭建的长连接或者使用第三方服务进行推送。
如果不是自己直接对接厂商通道，那么内部的服务端可能无需做过多较为复杂繁琐的开发工作，通过接入第三方消息推送平台来实现消息的推送，比如信鸽、个推等。多数的通道会将消息是否成功推送到客户端SDK的回执数据反馈给发送方，需要提供回调地址。
4.1 推送通道
通道类型一般分为三类：厂商通道、第三方推送服务平台、长连接。
厂商通道是手机终端厂商推出的推送服务，通过接入厂商SDK，内部服务端可以将消息推送到手机系统的服务端,再下发至客户端内部的厂商SDK，由操作系统进行相应展示，点击后唤起相应APP，这样可以避免APP进程被杀死后消息无法触达用户，因此触达率较高。
第三方推送平台是推送服务公司自己搭建相关的消息服务。并且各个APP使用了同一个平台的推送服务时，客户端都是集成同一个第三方推送平台的SDK，因此形成了一个推送联盟，当联盟中的其中一个APP的消息进程没有被杀死的时候，其他的APP也可以利用进行通知用户，形成了相互唤起，提高触达率。
经过一些场景的测试，相互唤起的成功率并不是很高，需谨慎结合自身场景评估。为了提高触达率，第三方推送平台也会集成各大厂商的SDK进行推送。
长连接就是建立手机与服务端的一条链路进行消息数据推送，通过长连接也可以进行APP状态监控，但完全由长连接推送且保证触达的稳定，需要投入的研发资源较多,且需尽量避免自己的长连接进程不要被操作系统杀死。
4.2 优劣势对比
APP push功能的搭建需要依据产品自身的情况和公司可投入的资源成本为主，在不同的阶段应该追逐不同的目标。
5.1 推送账号
推送时客户端的PUSH SDK均会根据用户的设备号生成一个对应关系的TOKEN。
在SDK内部，如果使用的是第三方推送服务，则去第三方的SDK注册；如果是厂商，则去商城SDK注册；如果使用自己长连接，则去自己的SDK进行注册，作为后续推送的标识用户的唯一ID。
5.2 消息路由
消息路主要见上述推送流程的讲解，此处主要讲解根据不同的业务场景，可能会定向推送给不同版本APP的用户。因此服务端在通道能力路由的时候，不仅需要能够区分通道，还要进一步能够针对用户的手机终端进行更加精细化的差异推送。
此外，消息通道并一定是100%稳定，如果下游通道出现问题，服务端需能够将由于通道问题导致的消息路由到备用通道去发送，以保证业务稳定触达。
5.3 全量推送
一般来说，对于公司内部运营或公司的相关数据均是以产品的customer id为准，用户数据系统对接消息系统时也多为customer id，因此需建立customer id与推送TOKEN的关系，便于运营针对用户进行推送。但对于一些场景会需要针对未登录的用户也进行推送，即全量推送；比如突发重大新闻资讯、大促等活动，所以运营系统需要提供全量推送功能，针对所有TOKEN进行推送。
上报数据包括触达 点击 关闭 退出 注册等数据。
对于所有方式的触达消息，都离不开触达与点击，触达的数据通过厂商的需要厂商回调上报，点击数据可以由SDK上报服务端。
对于push的关闭，也是需要进行考量的，来评估push是否过度发送，打扰到了用户。关闭数据有两部分，一部分为app内部的关闭，sdk直接上报给服务端即可；另一部分为用户在手机操作系统上关闭了对应app的push，需要APP在前台时，sdk调用手机终端相关方法获取该用户是否关闭了系统通知，然后上报至服务端。
注册数据即用户首次启动APP时，去相关sdk注册token。
用户退出账号时，sdk需要上报服务端，解除token与customer id的绑定关系。
7.1 强提醒 不留痕
push由于是app自己的通知渠道，是运营的一个重要工具。
如果用户未关闭PUSH通知的话，push可以从通知栏弹出进行消息显示，具有一定的强提醒性，但PUSH点击跳转后便消失，没有痕迹，因此针对于重点的通知消息，需要在APP内设置消息中心，在PUSH的同时留下通知记录。
7.2 消息样式
对于各家PUSH来说，一些营销消息会加入EMOJI表情来吸引用户点击，这也是一个吸引用户点击的一个小方法，只要服务支持传输约定好的EMOJI码就可以了。
目前安卓系统也支持富媒体推送，推送包含图片、语音等形式，对于资讯类的APP可以增加缩略图，吸引用户点击。目前来看，语音场景还有点挖掘。
7.3 IOS和安卓
由于APP是基于手机操作系统，因此对于IOS和安卓的推送的流程及功能基本相同，只不过细节和方法上略有不同，且国内安卓产商都在安卓系统上进行了一定改造，导致国内安卓厂商标准各不相同，需要开发同学仔细对接各个厂商。
触达率的提升需要从消息创建到实际通知到用户的建立完整流程，细化每一个交互环节，发现影响触达率的主要瓶颈，并针对性地进行解决或优化方案。
除此之外，未采用厂商通道的消息也可以采用自己的长连接和其他推送平台服务同时多条推送，在客户端的SDK内增加针对同一罅隙流水号的去重，这样可以也可以提高一部分消息的触达率。
