又删了12个人 ,节约了94M的空间！——来让做过IM应用的人帮你分析

让技术宅来辟谣

又删了12个人
,节约了94M的空间！【不要让拉黑你的人占用你的空间，您也试试吧，复制我的消息，找到微信里的设置，通用，群发助手，全选，复制粘贴消息发送就行，谁的名字变色了，删掉就行！】
已啦。

有朋友今天找我，说最近老是收到这条微信消息，被烦到不要不要的境地。
但是那么多人在发，不知道是不是真的删除几个拉黑自己的人就能节省很大空间出来？只是想到自己收到类似信息时的反感心情，又不敢轻易尝试，所以搞得自己很纠结。

正好我曾经做过类似的IM即时通讯工具，为了有理有据，那么我就从微信客户端的数据存储角度来分析这个问题。

首先鉴于微信存储的数据特征，采用SQLite数据库结合本地文件来存储本地数据，数据库为local.db,本地文件存储在document目录下的localfile文件夹中。

下面我们就来进行详细的数据库表结构分析。

1 msg表详细信息

表名：msg 备注：消息数据存储表

主键	字段名	数据类型	长度	可空	备注
是	ID	int	32	否	消息唯一id
否	m_chatId	String	64	否	聊天id
否	m_strOppositeSideName	String	64	否	发消息者名称
否	m_strMessageBody	String	256	是	消息内容
否	m_isFromSelf	Bool	2	否	是否是自己发的小
否	m_messageStatus	Int	32	否	消息状态
否	m_strTime	String	32	否	消息时间戳
否	m_oppositeChaterId	String	64	否	发送方id
否	m_contentType	Int	32	否	内容类型
否	mediaPath	String	256	是	附件路径
否	loginUserId	Int	32	否	当前用户id，对应loginUser表的id

注：每收发一条消息，均向该表中添加一条数据，如果收发的是语音、图片、小视频，则同时往localfile文件夹下存储一个附件文件，消息的mediaPath项纪录附件完整的路径。

2 contact表详细信息

表名： contact 备注：联系人信息存储表

主键	字段名	数据类型	长度	可空	备注
是	id	string	64	否	主键，微信号
否	Name	String	64	否	名称
否	City	Stirng	32	否	地区
否	HeadPic	String	256	否	头像链接
否	Sex	Bool	2	否	性别
否	Signature	String	256	是	个性签名
否	From	String	64	否	来源
否	Comments	String	64	是	备注名
否	PhoneNum1	String	11	是	备注，手机号码1
否	PhoneNum2	String	11	是	备注，手机号码2
否	PhoneNum3	String	11	是	备注，手机号码3
否	PhoneNum4	String	11	是	备注，手机号码4
否	PhoneNum5	String	11	是	备注，手机号码5
否	TagId	Int	64	是	标签id，对应tag表的主键，默认无标签
否	DescString	String	256	是	描述
否	DescPhoto	String	64	是	描述图片路径
否	IsStar	Bool	2	是	是否星标好友，默认不是
否	CanSeeMe	Bool	2	是	可以看我朋友圈，默认可看
否	SeeHis	Bool	2	是	看他朋友圈，默认可看
否	Black	Bool	2	是	加入黑名单，默认不加
否	loginUserId	Int	32	否	当前用户id，对应loginUser表的id

3 chat表详细信息

表名：chat 备注：聊天信息表

主键	字段名	数据类型	长度	可空	备注
是	id	int	32	否	主键，会话id，群聊时为生成id，单聊则为对方id
否	isTop	Bool	2	是	是否置顶，默认不置顶
否	Mute	Bool	2	是	消息免打扰，默认不开启
否	Background	String	64	是	聊天背景，默认不使用
否	isGroup	Bool	2	否	是否群聊
否	GroupName	String	32	是	群聊名称，默认前三个人名，群聊有效
否	Code	String	32	是	群二维码，群聊有效
否	Notice	String	256	是	群公告，群聊有效
否	NikeName	String	32	是	我在本群的昵称，默认用微信昵称
否	ShowNickName	Bool	2	是	显示他人在群里的昵称
否	loginUserId	Int	32	否	当前用户id，对应loginUser表的id

4 group_member表详细信息

表名：group_member 备注：群组成员表。

主键	字段名	数据类型	长度	可空	备注
是	ContactId	String	64	否	联合主键，contact表的主键
是	ChatId	int	32	否	联合主键，chat表主键
否	GroupNickName	String	32	是	用户在群聊中的昵称

5 tag 表详细信息

表名：tag 备注：标签表

主键	字段名	数据类型	长度	可空	备注
是	id	int	10	否	主键
否	Name	String	32	否	Tag名称
否	loginUserId	Int	32	否	当前用户id，对应loginUser表的id

6 loginUser表详细信息

表名： loginUser备注：登录用户信息表

主键	字段名	数据类型	长度	可空	备注
是	Account	String	32	否	账户名，主键
否	id	string	64	否	微信号
否	Name	String	64	否	名称
否	City	Stirng	32	否	地区
否	HeadPic	String	256	否	头像链接
否	Sex	Bool	2	否	性别
否	Signature	String	256	是	个性签名
否	From	String	64	否	来源
否	Comments	String	64	是	备注名

表结构分析到此结束。

怎么理解这个信息呢，针对最后一张表loginUser表，我们可以理解为这就是一张excel的表格结构定义，这个表格包含了Account、id、Name、City、HeadPic、Sex、Signature、From、Comments这么多列。每次有不通的用户登录后，该表格中就多插入一条数据。（主键表示该列的数据唯一）

也就是说没多一个联系人，则contact表多一条数据，都一条消息，则msg表多一条数据（语音、图片、小视频文件同时存入localfile文件夹中），多一个群组，则聊天表格多一条数据。

从上面分析可以看出，好友基本都是文本信息，占用空间微乎其微，而且好友数据相对固定（微信最多可加好友300人？）而真正数据膨胀的则是msg既聊天消息（微信对聊天条数并没有限制，而且聊天中的图片、表情、语音、视频一般都是兆或者几十兆的数据单位）。

所以，好友数和空间内存没有关系！
占用存储空间的不是好友，而是和好友的聊天消息！
（_本文完）

ps：清理内存的方法，设置--通用--清理储存空间--查看微信储存空间--选择删除
再ps：markdown插入表格的方法是在是坑~~~~