项目需求如下：
一，动态设置服务器地址（http或者socket）
分析：动态设置服务器ip和端口号，根据项目需求，这里还需要重置所有的项目资源和内存
实现思路：请求地址放置在私有的sharedperfence文件中，属于项目通用配置（appConfig），app每次启动获取一次放入内存，实现动态配置服务器地址
二，用户名，密码登录。(可以理解为 后台设置好的)
分析：一个登录界面（获取连接凭证），需要获取服务器连接密钥，这里通常都是一个http请求
实现思路：登录界面输入账号密码，保存用户凭证到sharedPerfence中，保证在重连时能够自动连接到服务器
三，接收服务器消息
分析：接收服务器消息，这里类似服务器主动推消息过来，咱们常用的实现方式包括，轮询机制，websocket长连接
实现思路：使用轮询机制，那么配合市面上的一些收款软件速度，一般可以设置在10s左右py一次，采用service中创建循环线程的方式，实现轮询
使用websocket长连接，安卓现在成熟的框架也很多，比如Java-WebSocket
四，语音播报
分析：结合整体需求，这里是需要将文字转化成语音播放出来（就不能提前放录音了）,主要在于收到的文本内容如何用语音播放出来
实现思路：语音技术的话，科大讯飞做了这么多年，可以考虑接入
第二种是，TextToSpeech的api，好像是安卓内置的
五，开机启动，常驻内存
分析：开机启动主要需要注意安卓系统默认是禁止三方软件开机自启动的，常驻内存，就是咱们常说的内存保活，网上流传了相当多各个版本的保活措施（也是这个项目唯一没法保证的地方），结合项目，这里的保活，主要是为了保证正常发出语音，所以重点是保活service
实现思路：
开机启动：设置权限android.permission.RECEIVE_BOOT_COMPLETED
注册静态广播android.intent.action.BOOT_COMPLETED
在广播中定义要启动的service
注意要给app设置自启动权限，避免无论如何都没法自启动的事情发生
内存常驻：我们要做到尽自己最大努力活下来！
1，监听全局的静态广播，比如时间更新的广播、开机广播、解锁屏、网络状态、解锁加锁亮屏暗屏（3.1版本），高版本需要应用开机后运行一次才能监听这些系统广播，目前此方案失效。可以更换思路，做APP启动后的保活（监听广播启动保活的前台服务）
2，假如应用被系统杀死，那么定时器则失效，此方案失效。JobService在5.0,5.1,6.0作用很大，7.0时候有一定影响（可以在电源管理中给APP授权）
3，双Service守护：高版本已失效，5.0起系统回收策略改成进程组。双Service方案也改成了应用被杀，任何后台Service无法正常状态运行
4，提高Service优先级： 只能一定程度上缓解Service被立马回收
六：隐藏注意事项
1) 离线消息处理：如果说在掉线重连的情况下，会有积攒的语音消息，那么如果不做处理，重连成功，接收100条语音消息，效果一定特别感人！
处理思路：建立语音任务缓存队列，取一条播放就删除一条，队列清空，播放任务停止，有新任务再重新启动播放语音
最后：这是一些我的想法，如果有任何不足或者想的不周到的地方，请大家给我留言，谢谢大家！
