之前基于 telethon 庫開發的tg采集,
原本每天采集量都很理想,后面不知道為什么突然采集量就急劇下降,達到每天8萬條消息。
后面修改了一下代碼邏輯,以及并行采集,后面還是一樣的效果,而且,還被封了一批賬號。
后面就想到,tg的客戶端是開源的,就打算基于客戶端進行二次開發
環境配置,這邊我就不多說了,也不想湊字數
說一下android客戶端解析的方式:
1:解析 包名/files/cache4.db 文件
- 這個方式解析就需要看完整個源碼,了解每種數據的解析方式,而且對版本有要求
相關連接:
https://dflab.blogspot.com/2019/01/cache4db-file-of-telegram-for-android_3.html
https://patents.google.com/patent/CN106549948B/zh
https://dflab.blogspot.com/2019/01/cache4db-file-of-telegram-for-android_3.html
https://github.com/RealityNet/teleparser
2:直接在消息接收并解碼后 hook (目前我使用的是這種)
源碼位置在:TMessagesProj/src/main/java/org/telegram/tgnet/TLRPC.java
public static abstract class Update extends TLObject 這個類里面的TLdeserialize函數
(org.telegram.tgnet.TLRPC.Update#TLdeserialize)
image.png
然后判斷數據包的類型,判斷數據包是不是消息
image.png
然后消息攜帶的音視頻文件的話,可以通過
org.telegram.messenger.FileLoader#getPathToMessage獲取
消息怎么解析,就需要你們自己來動手了。
還有不想監聽的話,可以設置一個定時任務
//獲取cache4.db的數據庫對象
MessagesController instance = MessagesController.getInstance(UserConfig.selectedAccount);
SQLiteDatabase database = instance.getMessagesStorage().getDatabase();
// 查看消息表(這段代碼是直接在tg里面拷貝過來,不一定復制就能用,這里只是給一個參考)
SQLiteCursor replyCursor = database.queryFinalized(String.format(Locale.US, "SELECT data, mid, date, uid FROM messages "));
while (replyCursor.next()) {
NativeByteBuffer data = replyCursor.byteBufferValue(0);
if (data != null) {
TLRPC.Message message = TLRPC.Message.TLdeserialize(data, data.readInt32(false), false);
message.readAttachPath(data, getUserConfig().clientUserId);
data.reuse();
message.id = replyCursor.intValue(1);
message.date = replyCursor.intValue(2);
message.dialog_id = replyCursor.longValue(3);
addUsersAndChatsFromMessage(message, usersToLoad, chatsToLoad);
TLRPC.Message owner = replyMessageOwners.get(message.dialog_id);
if (owner != null) {
owner.replyMessage = message;
message.dialog_id = owner.dialog_id;
}
}
}
replyCursor.dispose();