Один из самых удобных способов записать данные это использование готовых форматов, такие как JSON или YAML.
Из плюсов такого подхода стоит отметить вот что:
🔸 готовый, повсеместно используемый и поддерживаемый формат
🔸 простой и понятный файл, удобочитаемый для человека
🔸 можно легко редактировать в любом текстовом редакторе без специальных программ и библиотек
Но есть и минусы
🔹 затраты времени при записи файла (кодирование данных в нужный формат строки)
🔹 затраты времени при чтении файла (декодирование данных в Python объекты)
🔹 размер файла увеличивается из-за разметки данных (скобки, запятые, переносы, отступы...)
🔹 перед записью все данные должны быть помещены в память в полном объёме (не всегда)
🔹 при чтении необходимо считать весь файл в память и только потом декодировать данные
Если нужно писать немного данных в несколько файлов, то затраты по времени не ощутимы. Обычно это файлы конфига или какие-либо метаданные. Это отличный вариант под такие задачи.
Есть и другой поход к записи файлов - это бинарные файлы. Используется, когда данных достаточно много и никто их не собирается читать глазками😳.
🔸 очень быстрая запись
🔸 чтение значительно быстрей чем JSON, YAML итд
🔸 размер файла значительно меньше, так как нет разметки
🔸 можно записывать данные по мере поступления не загружая всё в память
🔸 можно извлечь любую часть данных независимо
Из минусов
🔹 нужно определить свой формат записи данных (если не используете готовую спецификацию определённого формата)
🔹 не получится открыть файл и визуально понять что там записано, а для чтения файла потребуется знать его спецификацию.
🔹 не так-то просто создать такой файл без специальной библиотеки
В таком виде удобно записывать большой массив любых однородных данных. Например, мониторинг валютной биржи или кэшированная анимация 3D геометрии.
(Это не означает что нельзя записать данные разного типа, просто это будет не так удобно)
Представьте себе JPG-картинку. По сути это немного мета-информации и большой массив пикселей. Тоже самое со звуком или видео файлом. Поэтому, если вы попробуете открыть картинку в текстовом редакторе вы увидите что-то вроде такого
f15d cd29 a564 4578 ...
09e2 9bc4 a696 1253 ...
84e9 4de1 3b23 c24a ...
2534 5161 28e0 709d ...
...
Это и есть записанные байтики. И для их чтения требуется определённый софт который знает что с ними делать. Под каждый тип файла.
К чему это я? Читайте в следующем посте...
#tricks#basic
🔥Альтернативы Firebase Crashlytics для Android и iOS
Crashlytics остаётся стандартом де-факто для сборка крешей приложений, но у него есть ограничения — особенно если вы хотите больше контроля над данными, гибкости или соблюдения требований безопасности. А может просто не хотите зависеть от Google решения.
Собрал альтернативы, которые вы можете использовать как замену c поддержкой Android и iOS:
👉Sentry. Одно из популярных решений на замену Crashlytics. умеет связывать ошибки с коммитами, мониторить производительность и даже хоститься локально.
👉Bugsnag — простой и надёжный инструмент для стабильных релизов.Хорошая визуализация, приоритезация проблем и интеграция с CI/CD. “Поставил — и работает”.
👉Tracer — облачное решение с хранением данных в России или можно купить self-hosted версию. Поддерживает Android и iOS, собирает краши, перформанс-метрики и работает без внешних облаков — важно для банков, финтеха и гос-приложений.
📈AppMetrica — аналитика и crash-отчёты от Яндекса.
Поддерживает Android и iOS, умеет собирать краши, ошибки и ANR прямо в отчётах аналитики. Данные хранятся в России, интеграция с другими сервисами Яндекса, SDK активно поддерживается. Хороший выбор, если уже используете AppMetrica для аналитики.
🛒Android Vitals в Google Play - стандартное решение, если вы публикуетесь в Google Play. Может собрать даже те креши, что вы не увидите при подключение решения внутри вашего приложения.
Учтите, что решения отличные от Firebase Crashlytics могут быть платными или иметь ограничения на бесплатных тарифах.
Знаете другие инструменты? Делитесь ими в комментариях.
#firebase#crashlytics
🔥Firebase Crashlytics получил MCP-сервер
В экспериментальном режиме Firebase запустили MCP-сервер для Crashlytics. Раньше, чтобы вытащить данные для анализа, нужно было настраивать экспорт в BigQuery, разбираться с Cloud Logging, писать SQL-запросы. Целый пайплайн ради того, чтобы понять что происходит со стабильностью приложения. Теперь всё это стало ощутимо проще.
Через MCP агент получает прямой доступ к данным Crashlytics: может вытащить список активных проблем с приоритетами, разобрать конкретный краш по ID со всеми стектрейсами и метаданными, получить агрегированную статистику по событиям и затронутым пользователям. Плюс умеет добавлять заметки к ишью и менять его статус прямо в ходе разговора.
Многие крашлитиковские ишью на практике достаточно простые, и агент вполне способен с ними справиться самостоятельно. Можно выстроить полный цикл: агент ночью смотрит новые крашы, разбирает их, создаёт задачи, предлагает или сразу делает фиксы, оставляет комментарии со всем контекстом. Раньше для этого не хватало именно доступа к данным мониторинга — теперь этот кусок закрыт.
🔗 Источник: firebase.google.com
#Firebase#Crashlytics#MCP#AndroidDev#Android
#swift#analysis#analytics#cocoapods#crashlytics#debug#debugger#debugging#hacktoberfest#layout_debugger#leak_detection#log#logs_analysis#networking#performance_analysis#sandbox#swift#swift6#ui#uikit#view
DebugSwift is a comprehensive toolkit that simplifies debugging for Swift iOS apps by providing real-time monitoring of network requests, performance metrics (CPU, memory, FPS), crash reports, and app resources like keychain and user defaults. It includes interface tools for visualizing layouts with grid overlays and touch indicators, plus memory leak detection and console logging. The main benefit is that you can quickly identify and fix issues during development without leaving your app—just shake your device to toggle the debug panel, making troubleshooting faster and more efficient.
https://github.com/DebugSwift/DebugSwift