客户端app和服务器端用UDP通信。先有一个登录的Activity，这个Activity里创建启动接收线程接收服务器的数据包。
当按了登录按钮之后发包给服务器，登陆成功跳转到MainActivity，登录Activity finish掉。这时候那个接收线程会结束掉吗，还是会一会监听端口，如果结束掉了我该怎样让他保持一直监听呢。
还是说我应该吧接收代码写在Service里，一开始就启动Service呢
这个就要看你的功能需求了，如果说你是想一直和服务器之间有一个监听UDP消息的线程作为与服务器通信的方式，那么就要准备一个一个可以开启的东西，
而不是像Activity这样有严格生命周期大部分都是需要即时回收的一类，因为回收的话如果被引用的Activity中有线程在一直运行，那么就会造成内存泄漏，
系统回收不了这个Activity所开销的资源，这部分资源就会一直保持资源占用状态，相对而言Server更适合处理这样的情景。
还有这个问题“这时候那个接收线程会结束掉吗，还是会一会监听端口，如果结束掉了我该怎样让他保持一直监听呢。”
一般情况下，结束Activity并不会结束掉在运行的线程，但这种方式是很不规范的一种，理由如上。
你可以在一开始就把Server开起来，然后在里面运行长期监听端口的UDP，然后在用户退出APP之际结束掉服务，用了再回收，养成好的习惯，app
也就更稳定了。
当Activity 进行 finish 的时候，由于垃圾回收机制，假如没有显式的引用登录Activity，该Activity的实例包括你说的udp通信的实例会很容易被回收，
此时不一定会被回收，可能你的udp还能收到信息，一旦系统触发一次垃圾回收，那么该udp通信将不再监听，处于被回收的状态。建议写入一个
优先级比较高的Service中，如果该监听比较重要，就要加入Service保活的策略，Service保活具体涉及的范围比较多，各系统版本机型多样，建议
多看保活方面的资料
关掉登录Act不会结束其中的线程.如果该线程持有登录Act的Context反而会造成内存泄漏.最好的办法绑定service到MainActivity,在这个service里处理接收线程.
这种即时通讯的线程最好保持在与程序生命周期同等的类中,比如MainActivity,或者MainActivity中的service里
使用MQTT保持长连接通讯即可
最好是开启前台Service， 这样你的UDP通信可以长时间保持也不容易造成内存泄漏等问题
把数据请求和接受都写在service里比较好