2016-6-17 数据库设计不应该过多依赖范式，适度的冗余可以加快搜索速度，在服务器的配置还可以的情况下，可以采用冗余来解决查找慢的问题。还一个是要选择好数据库引擎，例如 InnoDB 和 myisam 的区别。
2016-6-22 首页的帖子数据加载不适应加载内容，可以选择加载摘要，用户点击进去再单独请求，不然条数多了的话，然后每条的内容字数很多，就会在 StringBuffer append 时导致时间长达数秒！ 早前缺乏开发经验，服务器接口设计的不好之处。
2016-6-26 用户消息提醒采用极光推送API的自定义信息发送进行提示：基本思路如下图，已完成客户端，正在做服务器接口，比较冲忙，精神状态也不好，图画的有点临时，见谅！
2016-6-26 23:45补充，用户消息的查看与否以及数目在移动端的显示，应该在数据库设置时，消息表设置加上是否查看了的字段，可以解决以下几个问题：
1，用户在卸载APP再安装时，不会造成查看混乱，例如之前看过的，又显示出来；
2，在每次用户进入APP的时候，可以很好地显示出新的消息，不会造成过于复杂的逻辑代码判断。
猜想，微信的消息红点提示也可能是这种设计。
2016-6-27 数据库设计中，经常被 update 的字段，不应该出现在多张表，应该使用一张表，例如用户的名称，userName 这个肯定是会被经常改变的。否则在update数据的时候你要多张表更新！
2016-6-27晚 关于 .so 动态库的添加，现在绝大部分手机已经支持 armeabi cpu 架构，所以只需要编译这种进去就够了，不是越多越好，越多，安装包会跟着变大！
2016-7-1 补充之前的一个结论，对于用户头像这类经常会被修改的图片，如果在客户端设置了图片缓存，那么这些图片的命名不能是固定的，否则你将会无法唯一覆盖 client 端的缓存，最常见的是 imageLoader，其缓存的 key 是url，所以，对于这类图片的命名最好加上时间戳。
2016-7-5 关于 java 内存优化，不少人认为JAVA程序，因为有垃圾回收机制，应该没有内存泄露。其实如果我们一个程序中，已经不再使用某个对象，但是因为仍然有引用指向它，垃圾回收器就无法回收它，当然该对象占用的内存就无法被使用，这就造成了内存泄露。Android Studio 有个很好的内存分析工具可以助我们一臂之力。
如果您认为这篇文章还不错或者有所收获，您可以通过扫描一下下面的支付宝二维码 打赏我一杯咖啡【物质支持】，也可以点击右下角的【推荐】按钮【精神支持】，因为这两种支持都是我继续写作，分享的最大动力
、
