APP和服务器通讯为什么要用接口

服务器和app之间通过接口来访问，主要有2点作用。

1、app客户端太大，不利于复用。

如果没有接口，app客户端是可以直接请求数据的，这个是可以做到，但是相当于接口的全部工作在app端写了，这样会造成app端比较大。比如，访问数据库的代码，Android要写，iOS也要写，太不利于复用。高质量代码的标准是可维护、可复用、可扩展、灵活性高。所以，如果有了接口，接口就可以对数据进行封装和业务处理，然后给app端。

2、不利于数据库安全。

接口可以把关安全性。因为客户端在客户手里，可以破解，可以反编译，整个架构下，

整个客户端都是V，数据库直接暴漏出来，别人可以扫描你的数据库端口，很危险。所以一般数据库，外部是不给访问的，你只能通过接口，而接口，会要求你登

录，登录后，根据你的身份。分配身份标记，再决定你能请求多少东西，每次请求都是由接口判断一次是否合法，就是根据SessionString，也可以是

cookie。其实cookie就是SessionString的ID。即使被破解，拿到一个，也是一个用户的数据被盗，其他用户不受影响。

近期跳槽到玩加电竞，加之英雄联盟云顶之弈排位模式的推出，导致个人精力有限没有时间和心情去写相关的博客。

在Context中提供了bindService的方法

绑定服务是客户端--服务器接口中的服务器。组件和服务进行绑定后，可以发送请求、接收响应、执行进程间通信（IPC）。这里的服务器模型不同于网络C-S模型而是针对于Android应用不同的功能进行进程划分，例如提供视频播放的进程我们可以把它当做视频播放服务器，我们UI层属于客户端，客户端想要调用视频播放，需要用IPC方式通过bind服务的方式调用视频播放服务。（PS:如果大家对IPC不太熟悉可以参考我的其他文章 Android跨进程通信技术的使用及原理 ）客户端可以通过调用bindService()绑定到服务。调用时，必须提供ServiceConnection的实现，后者会监控与服务的连接及销毁。

借助bindService的机制，我们可以在主进程创建时创建一个守护进程，并监听守护进程的连接及销毁，再守护进程bindService中绑定主进程，这样即使进程因为锁屏、内存等问题杀掉后，也会被守护进程拉起，这就是Android中双进程守护的概念。当然早在PC时期，网吧的计时系统就使用了双进程守护机制，防止被恶意杀掉。

实现方式就不写了，网络上一搜一堆，这里给出一篇文章

Android 双进程守护

写的中规中矩，如果不清楚如何实现可以看一下。

谷歌官方80变更

当版本>80时，如果需要在后台启动服务需要调用startForegroundService。并且在serivce中onCreate方法必须在5秒内调用startForeground ,向通知栏发一个通知告知用户你的App正在后台运行，否则就会抛出异常

80通知适配

保活分两种：拉活、保活

拉活和保活是相辅相成的。在60版本以后的机型上，系统杀应用是按照进程组杀的，会直接导致双进程守护失效。那么因此就不使用双进程了么？

1低版本双进程守护是依然亲测好使。

2双进程守护可以和后面讲到的 账号同步、外部PUSH、JobScheduler

相结合，可以规避开系统杀进程组的问题。使双进程守护功能可以兼容高版本。

讲的有些笼统，我寻思的发Dome、写例子，但这样解决不了根本问题，只有懂得了思路，了解了什么是双进程守护，才能在开发中随机应变。只能说Android水太深，大家需要细心细心再细心。