6) 表情模块

匹配

以图片的名字组合其他标记符组合为 key，例如 [ ]，资源id为value，放至常量区

以正则匹配 key 的方式来判断是否有表情输入

显示

使用Spannable来将文字替换成drawable

选择页面的显示采用 GirdView + viewPager 显示

   7) 其他部分

       收藏、删除、举报，这些操作进行一次get操作，传递帖子的id给服务器，服务器处理完毕后，就做对应操作

收藏，不能重复收藏，服务器做判断，返回信息

删除，只能是帖主操作，删除成功后，返回主页刷新页面数据

       其他功能能的实现基本同上述。

   8) 优化

安装包

.so 动态库的添加，现在绝大部分手机已经支持 armeabi cpu 架构，所以只需要编译这种进去就够了，不是越多越好，越多，安装包会跟着变大！

减少不必要的库引用

内存

参照我之前的博文 内存优化

 

   9) 使用的库

　第三方

　自己派生

 

三、服务端架构概述

 

       第二部分结束得有点匆忙，我真的很想把所有的东西都写下来，如果加上我一路遇到过的 bug 及其解决方法，估计还要写两天。主要原因是，有很多我记得已经不是太清楚了。

  1，服务器

集群 

阿里云 Linux centos 6.5 操作系统，以ngnix 解析

腾讯云- - - 万象优图，只用来存放图片

MySQL 数据库，MyISAM 与 InnoDB 引擎

php 语言开发接口

2，数据库引擎

       最初的我并没有采用 InnoDB，而是所有表都是全部是 MyISAM 。改用的原因是MyISAM 不支持事务InnoDB支持事务，而且社交类APP的数据库操作过多偏向于insert、update、delete 这种操作如果涉及多表或单表互联操作的情况，为了避免数据写脏，所以使用事务。因为整个过程中若一条错误，便可以回滚到开始时的状态。

3，数据库设计

       对于数据库设计，不应该过多依赖范式，适度的冗余可以加快搜索速度，在服务器的配置还可以的情况下，可以采用冗余来解决查找慢的问题。

       常被 update 的字段，不应该出现在多张表，应该使用一张表，例如用户的名称，userName 这个肯定是会被经常改变的。否则在update数据的时候你要多张表更新！

信息提醒一张表

用户消息的查看与否以及数目在移动端的显示，需要在消息表设置加上是否查看了的字段，可以解决以下几个问题：

用户在卸载APP再安装时，不会造成查看混乱，例如之前看过的，又显示出来

在每次用户进入APP的时候，可以很好地显示出新的消息，不会造成过于复杂的逻辑代码判断

用户信息两张表

账号信息一张，存账号、密码、注册时间、ip等

基本信息一张，存签名、头像链接、背景图片链接等

4，接口

数据传输格式
json array 或 字符串

访问频繁的数据
架多一层 Redis，一定程度缓解高并发，需要服务器的内存支持

代码

未完待续……