מעקב תיק נכסי קריפטו: פיתוח ל-iOS ואנדרואיד

מעקב תיקים לנכסי קריפטו: פיתוח ל-iOS ואנדרואיד

לקוחות מביאים לעיתים קרובות קוד שבו רווח והפסד מחושב כ-Timer.periodic ומופתעים מפערים. בפועל, ריבוי מטבעות, מחירים היסטוריים, צבירה ממספר בורסות וארנקים, ועדכונים בזמן אמת ללא פגיעה בסוללה הם אתגר. במשך 5 שנים, יישמנו למעלה מ-20 פרויקטים כאלה על iOS (Swift 5.9+, SwiftUI) ואנדרואיד (Kotlin, Jetpack Compose), וכן Flutter ו-React Native. אחד האתגרים המרכזיים הוא חישוב רווח לא ממומש תוך התחשבות במספר עסקאות. בואו נפרק כיצד אנו פותרים זאת.

כיצד לבחור מקור נתונים לתיק?

שלושה מקורות עיקריים נבדלים במורכבות ובטריות הנתונים. הזנה ידנית היא הפשוטה ביותר: המשתמש מזין כמות ומחיר. החיסרון הוא טריות נתונים נמוכה. ממשקי API של בורסות (Binance, OKX, Bybit) מספקים מחירים ויתרות בזמן אמת אך דורשים מפתחות קריאה בלבד. On-chain דרך Multicall מאפשר מעקב אחר כל ארנק EVM ללא מתווכים אך מכביד על RPC עם הרבה מטבעות. אנו בוחרים שילוב לפי צרכי כל פרויקט: לדוגמה, סטארטאפ עם 3 בורסות ו-5 ארנקים ירוויח מ-API + on-chain.

בעיות שאנו פותרים

טריות נתונים. הזנה ידנית פשוטה, אך מחירים משתנים כל שנייה. אנו משתמשים בסקר כל 30 שניות (CoinGecko) או WebSocket (Binance) לעדכונים בזמן אמת. ב-Flutter, web_socket_channel + BGAppRefreshTask; ב-iOS, class PnLCalculator { final _buyQueue = Queue<({double price, double quantity})>(); double _totalCost = 0; double _totalQuantity = 0; void addBuy(double price, double quantity) { _buyQueue.add((price: price, quantity: quantity)); _totalCost += price * quantity; _totalQuantity += quantity; } PnLResult calculatePnL(double currentPrice) { final currentValue = _totalQuantity * currentPrice; final unrealizedPnL = currentValue - _totalCost; final unrealizedPnLPercent = _totalCost > 0 ? (unrealizedPnL / _totalCost) * 100 : 0.0; return PnLResult( unrealizedPnL: unrealizedPnL, unrealizedPnLPercent: unrealizedPnLPercent, avgEntryPrice: _totalCost / _totalQuantity, ); } } תוך כיבוד מגבלות רקע. יישום נכון צורך לא יותר מ-3% סוללה במשך 30 דקות של שימוש פעיל.

חישוב רווח והפסד. FIFO דרך תור רכישות תוך התחשבות בכל העסקאות. קוד Dart:

class PnLCalculator {
  final _buyQueue = Queue<({double price, double quantity})>();
  double _totalCost = 0;
  double _totalQuantity = 0;

  void addBuy(double price, double quantity) {
    _buyQueue.add((price: price, quantity: quantity));
    _totalCost += price * quantity;
    _totalQuantity += quantity;
  }

  PnLResult calculatePnL(double currentPrice) {
    final currentValue = _totalQuantity * currentPrice;
    final unrealizedPnL = currentValue - _totalCost;
    final unrealizedPnLPercent = _totalCost > 0 ? (unrealizedPnL / _totalCost) * 100 : 0.0;
    return PnLResult(
      unrealizedPnL: unrealizedPnL,
      unrealizedPnLPercent: unrealizedPnLPercent,
      avgEntryPrice: _totalCost / _totalQuantity,
    );
  }
}

הצגת 50+ נכסים. תרשים עוגה מציג את 5 המובילים, עם השאר מקובצים תחת "אחר" ויכולת התעמקות. השוואה: היישום שלנו מעדכן את התרשים פי 2 מהר יותר מספריות טיפוסיות בזכות Differential Dataflow.

מדוע חישוב רווח והפסד נכון חשוב

שגיאות בחישוב מחיר רכישה ממוצע מובילות לפערים בין התיק למציאות. אנו משתמשים ב-FIFO—התקן למעקבי קריפטו. הדיוק הוא בטווח של 0.01% לכל נפח עסקאות. בפרויקט אחד, זה חסך ללקוח 40% מזמן ההתאמה עם דוחות הבורסה.

כיצד אנו עושים זאת

דוגמה: עבור אפליקציית Flutter, שילבנו הזנה ידנית, API של Binance, ו-on-chain לארנקי Ethereum דרך Multicall. מחירים מ-CoinGecko עם סקר של 30 שניות, תרשימים לפי דרישה עם מטמון TTL של שעה. תוצאה: האפליקציה רצה יציב על 90% מהמכשירים, זמן טעינת תיק ממוצע הוא 1.2 שניות. צרו קשר כדי לדון בארכיטקטורת התיק שלכם.

מה כלול בעבודה

• תיעוד לאינטגרציה וארכיטקטורה.
• גישה לריפוזיטורי, CI/CD, ובנייני בדיקה.
• הכשרת הצוות על מודול התיק.
• 6 חודשי תמיכה באינטגרציה.

טעויות אופייניות ביישום

התעלמות ממגבלות קצב של API של בורסות מובילה לקריסות אפליקציה עם 1000+ נכסים. חוסר מטמון לתרשימים היסטוריים גורם לבקשות חוזרות בכל פתיחה. עיגול שגוי במהלך המרת מטבעות מביא לפערי אגורות במסך התיק. הפתרון המוכן שלנו נמנע מאלה עם רשימת בדיקה: הזנה ידנית עם אימות, API של בורסה עם אישור קריאה בלבד, on-chain דרך Multicall, מחירים בזמן אמת, רווח והפסד FIFO, תרשים עוגה עם קיבוץ, LineChart היסטורי עם מסגרות זמן, ריבוי מטבעות, מטמון עם TTL ורענון במשיכה, טיפול בשגיאות.

השוואת גישות יישום

תהליך

1. ניתוח – קביעת מקורות, סדרי עדיפויות מטבעות, סוגי תרשימים.
2. עיצוב – ארכיטקטורת מודול (DataProvider, PriceService, PnLCalculator).
3. יישום – אינטגרציית API, on-chain, ממשק משתמש ב-SwiftUI/Jetpack Compose/Flutter.
4. בדיקות – בדיקות יחידה לרווח והפסד, בדיקות עומס עם 100+ נכסים, אימות על נתונים אמיתיים.
5. פריסה – פרסום ל-App Store ו-Google Play, הגדרת TestFlight ו-Firebase App Distribution.

הערכות לוחות זמנים

• MVP: 2–3 שבועות
• גרסה מלאה: 6–10 שבועות

העלות מחושבת בנפרד לכל פרויקט. הזמינו פיתוח מעקב תיקים עם 6 חודשי תמיכה באינטגרציה. קבלו ביקורת טכנית של הפתרון הנוכחי שלכם עם חתימת החוזה.