推聊使用与定制高级指南
推聊从客户端到服务器端，开源了全部的源代码。所以理论上，本文的全部信息，你都可以直接解读源代码来得到。
本文的目的在于，减少开发人员熟悉推聊的时间，同时给些定制、改进的建议。
推聊是基于极光推送来做下行的聊天消息推送的。
推聊开源项目代码里默认采用我注册的极光推送的一个 AppKey。只是用于测试目的是没有问题的，正如现在你所看到：安装 apk 就可以用了。跑起来一个你自己的服务器，在客户端指定连接到你自己的这个服务器，也可以正常地聊天。
但是，如果你想要把推聊用于你的团队、社区，作为正式的沟通工具，或者集成到你自己的应用里边去，则建议你，使用你自己注册的极光推送 AppKey。
注册极光推送，请登录其官方网站：http://jpush.cn，注册开发者帐号，创建一个应用，填写你自己要用的 Android应用包名，之后取得一个 AppKey。
之后，在 Android 客户端的 AndroidManifest.xml 配置文件里，在如下的这一行，填上你新取得的 AppKey。
还有需要特别提醒注意的是：上面你创建应用时使用的包名，需要确保就是当前 Android 应用程序的包名。
在服务器端，找到这个源文件：`/src/org/pushtalk/server/Config.java，里边有如下 3 个配置项：
public static final String JPUSH_USERNAME = "pushtalk";
public static final String JPUSH_PASSWORD = "654321";
public static final String JPUSH_APPKEY = "7d431e42dfa6a6d693ac2d04";
上面这 3 个配置项都需要改到你在极光推送注册得到的相应值。
客户端与服务器端都做好上面提及的变更后，基于你自己的极光推送帐户的定制版推聊就可以正常运行起来了。这样，你也可以自己的帐户登录极光推送开发者平台，看到些定制版推聊的统计信息了。
当前的 Android 客户端，主要的聊天界面是使用 WebView 的方式实现的。也就是说，界面信息都是从服务器端拉取过来的。所以，网络不好时，界面显示必然会慢，页面响应流畅度比 Native 方式实现的差很多。
如果你想要定制推聊，你完全可以考虑自己来创建一个 Native （本地化）版本的 Android 客户端，以提高客户端体验。需要的工作量不会很大，主要体现在：
- 聊天相关的几个界面换成 Android Activity
- 相关界面的数据，需要适当地修改服务器端 Servlet，把原来输出 HTML 改成输出 JSON。
Android 客户端有一个 IS_TEST_MODE 配置项。如果为 true，则：
- 所有的的消息都会显示到通知栏
如果 IS_TEST_MODE 为 false，即正常模式，则：
- 自己发送的消息，不会显示到通知栏
- 当前你正在某个聊天频道时，这个频道过来的消息，不会显示到通知栏。因为已经在当前的聊天窗口直接显示了。
代码里默认配置是 true。请根据需要改变。
推聊服务器的性能，因其底层消息是基于极光推送的，而极光推送是专业的消息推送平台，所以消息流转方面肯定不会是问题。主要应该在两个部分：
以下分别从这两个方面描述。
Jetty 能够容纳万级同时在线么？
我还真答不出来。但是，当前的 Jetty 默认配置肯定是不行的。请参考 Jetty 相关文档，应该是可以在启动时指定一些参数，来配置 Java 内存，以提高负载。
如果发现不行，则一般的选择，就是切换到 Tomcat 了。主要的改动在于，要把 org.pushtalk.server.JettyServer 里配置的 Servlet 改到 Tomcat 里的 web.xml 里来。所有 Servlet 实现不需要改动可直接使用。
单机 Tomcat 还搞不定？ 这就超出了本文的范围了，已经不是推聊本身要去解决的问题，是架构上的事情。
推聊的数据库使用 H2，一个轻量级的 Java 内存/文件数据库。当你把推聊 Java Server 启动时，就在当前用户主目录下去找 pushtalk.h2.db 的文件。如果不存在，则创建一个新的。
这个数据库保存的只有：注册用户列表，频道列表，频道与用户之间的关系表。
本人没有做过具体、深入的测试，但根据官网的说明，估计这个数据库支撑推聊 10 万级同时在线的用户量应该没有问题。
如果有需要，你可以改进推聊的数据库实现，使用自己的的数据库，比如 Mysql。代码层面具体一点就是，自己另外写一套 org.pushtalk.server.data.TalkService 的实现。
当前的聊天记录，是这样实现的：
- 服务器端缓存，没有保存到数据库。缓存策略上，默认是：每个频道最近 7 天内的 100 条记录。
- 客户端聊天界面是 WebView实现，每次进入界面时去拉取最近的缓存。
上面的实现也是为了简化。如果你有进一步的定制化需求，可以多做些事情：
- 服务器端把聊天记录写到数据库。这对数据库的负载会提高很多。
- 或者，甚至当前客户端 WebView 实现，把聊天记录写入客户端 Web 数据库。从而不必进入一个新的聊天界面，每次去拉取全部的聊天记录，只需要拉取最近的。这可一定程度上减少网络流量、提高体验
- 或者，如果本地改成 Android Native 客户端实现，则直接在本地写 Android SQLite 数据库。这样也是需要聊天记录时，只需要拉取最新的。
推聊现在没有发送图片、语音的功能。
现有的技术架构上，是不需要做大的改变就可以新增支持的，但工作量则要增加不少。
图片、语音支持的基本原理是这样的（一般的聊天应用都是类似这样的）：
- 客户端本地拿到文件：照片或者语音文件（甚至其他附件）
- 上传文件到服务器，得到唯一的文件ID
- 把得到的文件ID，像发送文本聊天消息一样，发送到对端
- 对端客户端收到这个消息后，解析得到文件ID，从文件服务器下载拿到文件
- 客户端展示文件给用户
从上述原理来看，增加图片、语音功能，主要的工作量在两个地方：
- 客户端对文件的处理、上传、下载
- 文件服务器：更多的资源占用，更复杂的服务器逻辑
现在的用户体系，是相对简单、直观的：依赖于每个手机（或者平板）的 UDID/IMEI，不记密码，只第一次访问时填写用户名。
也就是说：不同的手机，必定是不同的用户。也不允许同名。
对于 Android 手机，有部分是无法取得 IMEI 的。针对这个问题，有几个策略，最终目的还是尽可能保证每个手机的 UDID 是不同的。具体请看 Android 客户端代码 org/pushtalk/android/utils/AndroidUtil 里 getUdid 方法。
这个用户体系是简单的，但是，不够严密。如果你想要把推聊用于非常严密的交流场景，即模仿别人的用户名是会有很大的好处的，那么，这套没有登录密码的用户体系不满足要求。你需要改进，使用标准的用户名、密码机制。