Cho tới tuần này, cách duy nhất để tôi biết ứng dụng của tôi bị sập là có ai đó nhắn cho tôi. Mà phần lớn mọi người không nhắn. Họ mở lại ứng dụng, và nếu nó sập thêm lần nữa thì họ thôi không mở nữa. Phía API thì đã có giám sát: mọi log mức ERROR đều được đẩy vào một kênh chat của đội. Nhưng một lần sập trên điện thoại thì không để lại dấu vết gì ở bất cứ chỗ nào tôi nhìn thấy được.

Thật ra ứng dụng đã có sẵn một cơ chế báo lỗi. Mỗi khi ứng dụng hiện một thông báo lỗi cho người dùng, nó gửi nội dung thông báo đó lên một endpoint nhỏ của API. Máy chủ ghi lại ở mức ERROR, nên lỗi đó cũng tới được kênh chat. Tôi thêm cơ chế này sau một lần thao tác xoá thực ra đã thành công, nhưng dòng đó vẫn nằm trong danh sách; người dùng bấm vào lần nữa và nhận được thông báo “No Item matches the given query”. Phía máy chủ chỉ ghi hai lỗi 404 bình thường và không báo gì cả. Cơ chế đó bao quát được những lỗi mà ứng dụng bắt được và hiện ra cho người dùng. Còn sập ứng dụng (crash) thì khác hẳn: chính đoạn JavaScript lẽ ra sẽ gửi báo cáo lại là thứ vừa chết.

Cách sửa hiển nhiên là dùng Sentry. Tôi rất thích SDK của Sentry; nhờ nó mà báo cáo sự cố trên React Native gần như là bài toán đã có lời giải. Điều tôi không muốn là thêm một nhà cung cấp nữa giữ dữ liệu người dùng, thêm một dòng trong chính sách quyền riêng tư, và thêm một hoá đơn cho một thứ mà với quy mô của chúng tôi thì nhiều lắm cũng chỉ vài báo cáo mỗi ngày. Vì vậy tôi giữ SDK và thay phần dịch vụ: DSN của ứng dụng trỏ về API của chính chúng tôi, và một phần nhỏ trong ứng dụng Django ở đó nhận những gì SDK gửi lên, gom nhóm, gửi cảnh báo và lưu lại.

Bài này kể cách hệ thống đó hoạt động, và cách tôi kiểm tra để chắc rằng một lần sập gốc (native crash) thật sự đi được tới máy chủ.

Mẹo với DSN

#

Một DSN của Sentry có dạng https://<public-key>@<host>/<project-id>. SDK biến nó thành một yêu cầu POST tới https://<host>/api/<project-id>/envelope/, với khoá nằm trong header X-Sentry-Auth. Không có chi tiết nào trong đó gắn riêng với sentry.io. Vì vậy DSN được đóng gói sẵn trong ứng dụng là:

https://<CRASH_REPORT_KEY>@api.example.com/1

và phía Django có một route khớp đúng với địa chỉ mà SDK sẽ gọi:

path("api/<int:project_id>/envelope/", crash_envelope, name="crash_envelope"),

Khoá này nằm trong mọi bản build của ứng dụng, nên nó không phải bí mật. Nó tồn tại vì hai lý do: nếu một ngày endpoint bắt đầu hứng rác thì tôi có thể đổi khoá, và nếu máy chủ chưa cấu hình khoá thì endpoint sẽ từ chối tất cả thay vì nhận bừa mọi thứ:

def crash_envelope(request, project_id):
    expected = settings.CRASH_REPORT_KEY
    if not expected:
        return Response({"detail": "Crash reporting is not configured"}, status=503)
    if not hmac.compare_digest(_key(request).encode(), expected.encode()):
        return Response({"detail": "Unknown key"}, status=401)
    ...

Hàm _key đọc giá trị sentry_key= trong header X-Sentry-Auth; nếu không có thì lấy từ query string, vì một số SDK đặt khoá ở đó.

SDK gửi gì lên: envelope

#

Định dạng truyền dữ liệu của Sentry là envelope: một dòng JSON làm header, sau đó là bao nhiêu mục (item) cũng được, mỗi mục gồm một dòng JSON header rồi tới phần nội dung (payload). Nếu header của mục có trường length thì payload dài đúng bằng số byte đó; nếu không thì payload kéo dài tới ký tự xuống dòng kế tiếp.

{"event_id":"9ec79c33...","dsn":"https://...@api.example.com/1"}
{"type":"event","length":4123}
{ ...the event JSON, 4123 bytes... }
{"type":"client_report"}
{"timestamp":1791400000.5,"discarded_events":[]}

Có hai chi tiết khiến tôi vấp:

• SDK gốc (native) nén gzip phần thân yêu cầu, còn SDK JavaScript thì không. Một lỗi JS mà @sentry/react-native bắt được sẽ tới dưới dạng văn bản thường, trong khi một lần sập gốc từ sentry-cocoa hoặc sentry-android tới kèm Content-Encoding: gzip. Bộ giải mã xử lý được gzip, deflate có bọc zlib và deflate thô, và dừng giải nén ở mức 1MB, vì một sự kiện sập chỉ nặng vài kilobyte, thứ gì lớn hơn thế thì không phải báo cáo sự cố.
• Payload có tiền tố độ dài có thể chứa ký tự xuống dòng. Nếu bạn tách theo \n thì sẽ làm hỏng mọi sự kiện mà SDK gốc gửi lên. Khi có length thì bắt buộc phải tôn trọng nó.

Bộ phân tích cú pháp (parser) khá ngắn. Nó chỉ giữ các mục event; session, transaction, tệp đính kèm và client report đều được nhận rồi bỏ đi.

Trả lời theo cách SDK hiểu được

#

Phần này quan trọng hơn tôi tưởng. SDK giữ một hàng đợi trên đĩa và gửi lại bất cứ thứ gì nó không chắc là đã tới nơi, nên câu trả lời của máy chủ quyết định SDK có tiếp tục thử lại hay không:

• 200 khi đã lưu, hoặc khi cố ý bỏ đi. Nếu tôi trả 4xx cho một mục session, SDK sẽ giữ nó lại và thử gửi mãi mãi.
• 429 kèm Retry-After khi bị giới hạn tần suất. Endpoint có giới hạn theo từng IP (120 lần mỗi giờ), vì một chiếc điện thoại bị sập liên tục sẽ gửi một báo cáo mỗi lần khởi động, và SDK lùi lại khi gặp 429 đúng như mình mong.
• 400 cho envelope sai định dạng, ghi log ở mức cảnh báo (warning) chứ không phải lỗi: một báo cáo hỏng chỉ cho biết có một client đang hỏng, và báo cáo tốt tiếp theo sẽ nói cái gì đã sập.

SDK cũng gửi lại cùng một sự kiện nếu nó không chắc lần gửi đầu đã tới nơi, nên event_id có ràng buộc duy nhất (unique constraint) và một bản trùng lặp sẽ được bỏ qua lặng lẽ.

Gom nhóm khi không có source map

#

Đây là chỗ một bộ nhận tự viết phải đưa ra lựa chọn mà Sentry vốn làm sẵn cho bạn. Sentry gom nhóm các lần sập theo stack trace. Nhưng bundle Hermes ở bản phát hành đã bị rút gọn (minify), nên tên các frame chỉ còn một chữ cái và vị trí dòng/cột thay đổi sau mỗi lần build. Nếu gom theo frame, cùng một lỗi sẽ mở ra một issue mới ở mỗi bản phát hành.

Khi chưa có source map (phần cuối bài sẽ nói thêm), thứ ổn định nhất trong một lỗi JavaScript là kiểu lỗi và thông điệp lỗi. Vì vậy dấu vân tay (fingerprint) là kiểu exception cộng với thông điệp, trong đó những phần thay đổi giữa các lần xuất hiện được che đi:

_MASKS = [
    (re.compile(r"0x[0-9a-fA-F]+"), "<addr>"),
    (re.compile(r"\b[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\b"), "<uuid>"),
    (re.compile(r"\b[0-9a-fA-F]{16,}\b"), "<hex>"),
    (re.compile(r"\d+"), "<n>"),
]

Cannot read property 'title' of undefined (reading index 3) và (reading index 17) sẽ thành cùng một issue. Nếu SDK tự gửi kèm fingerprint mà không có {{ default }} bên trong thì giá trị đó được ưu tiên, nhờ vậy tôi có thể ép cách gom nhóm từ phía client khi cách mặc định chưa đúng. Sự kiện nào không có exception thì dùng thông điệp log đã che làm dấu vân tay, còn nếu không có cả hai thì dùng frame đầu tiên thuộc mã của ứng dụng (in-app). Với một lần sập do tín hiệu (signal) ở tầng gốc, thông điệp thường kiểu Signal 6, Code 0, nên các lần sập này được gom theo tín hiệu. Cách đó hơi thô, nhưng trung thực cho tới khi có giải mã ký hiệu (symbolication).

Cảnh báo mà không làm ngập kênh

#

Mỗi dấu vân tay ứng với một issue, và mỗi báo cáo được lưu thành một sự kiện nằm dưới issue đó. Issue chỉ ghi log ở mức ERROR (đó là thứ cảnh báo trên kênh chat lắng nghe) đúng trong những trường hợp sau:

• một issue mới
• một issue đã đánh dấu xử lý xong (resolved) nhưng quay lại, khi đó issue được mở lại
• lần xuất hiện thứ 10, 100, 1.000 và 10.000

Một lần lặp lại bình thường chỉ tăng bộ đếm. Issue bị đánh dấu ignored vẫn tiếp tục được đếm nhưng không bao giờ cảnh báo. Cộng thêm giới hạn tần suất riêng của handler gửi lên kênh chat, một vòng lặp sập trên một bản phát hành lỗi chỉ hiện ra thành vài tin nhắn chứ không thành một bức tường chữ.

Dung lượng lưu trữ cũng được giới hạn theo cùng cách: mỗi issue chỉ giữ 50 sự kiện gần nhất và xoá các sự kiện cũ hơn khi có sự kiện mới. Điều này làm hỏng biểu đồ đầu tiên của tôi, vì 50 sự kiện không thể cho bạn biết tuần trước lỗi đó xảy ra bao nhiêu lần. Vì vậy mỗi issue giữ thêm số đếm theo từng ngày trong 90 ngày, được cập nhật trong cùng giao dịch (transaction) với bộ đếm. Biểu đồ vẽ từ các số đếm này; các sự kiện chỉ để đọc chi tiết.

Nếu bạn tự làm một hệ thống như vậy, có hai tình huống tranh chấp (race) nhỏ đáng xử lý. Khi một lần sập hoàn toàn mới xảy ra trên nhiều điện thoại cùng lúc, hai báo cáo có thể cùng cố tạo issue, nên hãy đặt ràng buộc duy nhất cho dấu vân tay và để báo cáo chậm chân hơn đọc lại dòng đã có. Ngoài ra, khung 90 ngày nên tính từ ngày hôm nay theo đồng hồ của máy chủ, chứ không tính từ báo cáo mới nhất, vì một chiếc điện thoại cài sai đồng hồ có thể ghi ngày cho báo cáo là bất kỳ ngày nào, kể cả năm sau.

Payload bị giới hạn ở 128KB. Sự kiện nào vượt quá thì bị bỏ breadcrumb và siêu dữ liệu gỡ lỗi (debug metadata) trước; nếu vẫn còn quá lớn thì chỉ giữ exception, thông điệp, phiên bản phát hành và nền tảng, kèm một dấu đánh dấu để tôi biết nó đã bị cắt.

Lọc bỏ dữ liệu cá nhân

#

SDK chạy với sendDefaultPii: false, nên về nguyên tắc không có địa chỉ IP, cookie hay nội dung yêu cầu nào được gửi lên. Máy chủ không dựa vào điều đó: trước khi lưu bất cứ thứ gì, nó chỉ giữ id và username trong user và bỏ hẳn request, phòng khi một phiên bản SDK hoặc một thiết lập sau này bắt đầu gửi chúng.

Kiểm thử trên thiết bị thật làm lộ ra thêm hai thứ cần loại bỏ:

• Breadcrumb ghi lại URL đầy đủ, kể cả query string. Các yêu cầu tìm kiếm của ứng dụng đặt từ khoá ngay trong query string, nên một lần sập ngay sau khi tìm kiếm sẽ lưu luôn từ khoá người dùng đã gõ. Giờ máy chủ cắt mọi URL trong breadcrumb tại dấu ?.
• Breadcrumb từ console mang theo nguyên các đối số đã truyền vào console.log, mà đó có thể là bất kỳ object nào ứng dụng tình cờ ghi log. Phần văn bản thông điệp được giữ (vì nó hữu ích), còn các đối số thì bị bỏ.

Tôi chỉ phát hiện ra hai điều đó khi nhìn vào một báo cáo thật, và đó cũng là lý do chính cho phần tiếp theo.

Phía client

#

Trong ứng dụng, mọi thứ đều đi qua một module nhỏ duy nhất, cùng lý do với việc tôi bọc SDK cập nhật qua mạng (OTA) lại: một bundle OTA cũng chạy trên các bản build được tạo ra trước khi module gốc tồn tại. Một câu import * as Sentry from "@sentry/react-native" ở cấp cao nhất trên bản build không có RNSentry sẽ ném lỗi ngay khi import, và kết quả là màn hình trắng. Vì vậy SDK được nạp lười (lazy require), và chỉ sau khi đã kiểm tra module gốc thực sự có mặt:

import { NativeModules, Platform, TurboModuleRegistry } from "react-native";
import Constants from "expo-constants";

const DSN = process.env.EXPO_PUBLIC_CRASH_DSN;

function nativeModulePresent(): boolean {
  try {
    return Boolean(TurboModuleRegistry.get("RNSentry") ?? NativeModules.RNSentry);
  } catch {
    return false;
  }
}

export function initCrashReporting(): boolean {
  if (!DSN || Platform.OS === "web" || !nativeModulePresent()) return false;
  const Sentry = require("@sentry/react-native");
  Sentry.init({
    dsn: DSN,
    release: Constants.expoConfig?.version ?? "unknown",
    sendDefaultPii: false,
    tracesSampleRate: 0,
    enableAutoSessionTracking: false,
    // ...turn off the other tracing options the same way
    maxBreadcrumbs: 50,
    beforeSend(event) { /* tag the OTA bundle */ return event; },
  });
  return true;
}

Chỉ báo lỗi. Máy chủ không lưu trace, session, profile hay bản ghi phát lại (replay), nên không tính năng nào trong số đó được bật. Không có DSN (khi phát triển, khi chạy kiểm thử E2E) thì SDK không bao giờ khởi động. Các cấu hình build (build profile) đặt sẵn DSN và một môi trường (staging hoặc production), nên cả hai loại bản build đều báo về cùng một endpoint mà vẫn phân biệt được với nhau. Người dùng đã đăng nhập được gắn bằng ID tài khoản, không bao giờ bằng tên hay email.

Các error boundary cần được gọi báo lỗi một cách tường minh. ErrorBoundary gốc của Expo Router bắt lỗi khi render và hiện màn hình của riêng nó, nên lỗi đó không bao giờ tới được handler toàn cục mà SDK móc vào. Cách sửa là một lớp bọc nhỏ: gọi captureException trong một useEffect rồi render boundary của router như cũ, dùng chung cho cả boundary gốc lẫn boundary của từng route. Lời gọi được đặt trong effect chứ không nằm trong hàm render, để nó chỉ báo một lần thay vì báo lại sau mỗi lần render lại. Component gốc cũng được bọc bằng Sentry.wrap, và nếu việc bọc ném lỗi thì quay về dùng component trần.

Trên web có một phiên bản .web.ts của module, trong đó mọi hàm đều bị tắt. Metro chọn tệp theo nền tảng, nên SDK hoàn toàn không lọt vào bundle web. Ứng dụng web vốn không có module gốc nào để SDK chạy trên đó.

Chứng minh một lần sập gốc thật sự về tới nơi

#

Các unit test gửi những envelope viết tay, tức là chỉ chứng minh parser xử lý được thứ mà tôi nghĩ SDK sẽ gửi. Hai ngày sau khi phát hành, trên production chưa có báo cáo sự cố nào. Lúc đó mới có ba người cập nhật, nên con số 0 là hợp lý, nhưng nhìn từ phía máy chủ thì “chưa ai bị sập” và “báo cáo sập không về tới” trông giống hệt nhau. Tôi muốn thấy một báo cáo thật.

Vì vậy tôi build một bản Release cho simulator, với DSN trỏ về một Django chạy cục bộ ở cổng 8000 cùng một khoá dùng một lần:

EXPO_PUBLIC_CRASH_DSN=http://localcrashtestkey0000@localhost:8000/1 \
EXPO_PUBLIC_CRASH_ENVIRONMENT=local-verify \
xcodebuild -workspace ios/MyApp.xcworkspace -scheme MyApp -configuration Release \
  -destination 'platform=iOS Simulator,id=<udid>' -derivedDataPath /tmp/iosbuild

(Dùng Release chứ không phải Debug: bản Debug có liên kết dev launcher và hoạt động khác đi, còn Release mới là thứ người dùng thật sự chạy.) Sau đó tôi cài, mở ứng dụng, chờ vài giây, rồi giết tiến trình theo đúng cách một lỗi thật sẽ làm:

xcrun simctl install booted /tmp/iosbuild/Build/Products/Release-iphonesimulator/MyApp.app
xcrun simctl launch booted com.example.myapp      # prints the pid
kill -ABRT <pid>

Ứng dụng trong simulator là các tiến trình macOS bình thường, nên tín hiệu tới được handler của SentryCrash y như trên thiết bị thật. Handler ghi báo cáo xuống đĩa; trong lúc tiến trình đang chết thì không có gì được gửi đi. Ở lần khởi động tiếp theo, SDK tìm thấy báo cáo đó và gửi lên. Tôi mở lại ứng dụng, và một giây sau nhật ký mạng của simulator cho thấy có kết nối tới :8000.

Rồi trong log của Django chẳng có gì, khiến tôi bối rối mất một phút: ở mức log tôi đang đặt, máy chủ phát triển chỉ ghi lại các phản hồi không phải 2xx. Nhưng trong cơ sở dữ liệu thì có:

SIGABRT: Signal 6, Code 0 | cocoa 1.4.0 iOS 27.1 iPhone19,4 handled=False
received 09:19:53, crashed 09:19:38
contexts: app, device, os, ota_updates, trace · 24 breadcrumbs

Mười lăm giây từ lúc sập tới lúc được lưu, mà phần lớn thời gian đó là tôi mở lại ứng dụng. Và chính việc nhìn vào payload thật đã dạy tôi những điều mà kiểm thử không thể:

• ID người dùng không phải ID tài khoản. Bản build thử nghiệm không thật sự đăng nhập, nên sentry-cocoa dùng ID riêng cho từng lượt cài đặt của nó. Điều này đáng biết, và đáng ghi vào phần lưu ý quyền riêng tư: một báo cáo mang ID tài khoản nếu bạn đã đăng nhập, và một ID cài đặt ngẫu nhiên nếu chưa.
• Không có múi giờ. Tôi đã cho rằng sẽ có context về ngôn ngữ và vùng (culture). Context thiết bị có locale, bộ nhớ, kích thước màn hình, chế độ tiết kiệm pin và phiên bản kernel, nhưng không có múi giờ.
• Sập gốc bỏ qua beforeSend. Hàm beforeSend phía JS của tôi gắn thêm tag ota ghi bundle OTA đang chạy, nhưng một lần sập gốc được SDK gốc lắp ráp ở lần khởi động sau và không bao giờ đi qua hook JS này. Muốn gắn tag cho sập gốc thì phải đặt tag trên scope bằng setTag ngay khi biết bundle, để nó được đồng bộ xuống tầng gốc.
• Breadcrumb cho thấy ứng dụng đang làm gì. Cảnh báo trên console, vòng đời của view controller, và các lệnh gọi HTTP, kể cả các yêu cầu của chính SDK phân tích (analytics) tới endpoint thu thập dữ liệu của nó. Đó là lời nhắc tốt về việc ứng dụng còn nói chuyện với những ai khác. Và các URL có kèm query string, đó là cách tôi phát hiện ra vấn đề từ khoá tìm kiếm ở trên.

Đọc báo cáo

#

Báo cáo được đọc trong trang quản trị Django, trên một trang issue mô phỏng đại khái theo Sentry: phần đầu có các con số đếm và các nút Resolve / Ignore / Reopen, tiếp theo là biểu đồ cột theo ngày, tỷ lệ theo phiên bản phát hành, hệ điều hành, thiết bị và bundle OTA, rồi tới từng sự kiện một với exception, các frame (frame của ứng dụng được tô nổi, frame của thư viện được thu gọn), breadcrumb và context thiết bị. Không cần thêm thư viện phụ thuộc nào.

Trong lúc làm trang này có một chỗ phải sửa: với một lần sập gốc, frame “thủ phạm” (culprit) là đường dẫn của tệp thực thi trên thiết bị, trong đó có một UUID riêng cho mỗi lượt cài đặt, nên cùng một lần sập lại trông khác nhau trên mỗi điện thoại. Giờ nó chỉ hiện địa chỉ và tên tệp thực thi, kiểu 0x1000a1b2c (MyApp).

Chính sách quyền riêng tư, toàn bộ

#

Báo cáo sự cố gần như chắc chắn là thông tin cá nhân: một ID tài khoản, một mẫu điện thoại, và những gì một người đã làm trong phút cuối trước khi ứng dụng sập. Vì vậy chính sách quyền riêng tư cần thêm một đoạn. Viết cho đàng hoàng nghĩa là phải nói chính xác một báo cáo mang theo những gì, nên tôi liệt kê dựa trên payload vừa xem: lỗi, phiên bản ứng dụng và bản cập nhật OTA, mẫu điện thoại, hệ điều hành và ngôn ngữ, bộ nhớ trống và kích thước màn hình, vài chục bước gần nhất (các màn hình, địa chỉ web đã bỏ mọi thứ sau dấu ?, các dòng log của chính ứng dụng), và ID tài khoản hoặc một ID cài đặt ngẫu nhiên. Chính sách cũng nói rõ báo cáo được gửi về máy chủ của chúng tôi, không gửi tới Sentry hay bất kỳ công ty báo cáo sự cố nào khác. Thời hạn lưu giữ có một dòng riêng trong bảng: 50 báo cáo gần nhất cho mỗi vấn đề, cộng với số đếm theo ngày trong 90 ngày.

Một khi đã đối chiếu một đoạn với mã nguồn, thật khó mà không đối chiếu phần còn lại. Và chính sách hiện có không đứng vững. Trang xoá tài khoản ghi rằng token thông báo đẩy (push notification) và passkey bị xoá ngay khi bạn đóng tài khoản, và log máy chủ sẽ biến mất trong vòng 90 ngày. Không điều nào trong số đó đúng. Đóng tài khoản sẽ gỡ liên kết các phương thức đăng nhập và ẩn danh hoá hồ sơ, nhưng token thông báo đẩy và passkey vẫn còn đó cho tới khi có người xoá bằng tay, và kho lưu log hiện chưa có hạn xoá. Vì vậy toàn bộ chính sách được viết lại dựa trên bản kiểm kê những gì mã nguồn thực sự làm, và những dòng đó giờ ghi “chưa được xoá tự động; hãy email cho chúng tôi”. Nghe kém yên tâm hơn, nhưng đúng sự thật.

Giờ repo có hẳn một quy tắc cho việc này: chính sách mô tả những gì mã nguồn làm, chứ không phải những gì chúng tôi dự định, và mọi thay đổi khiến dữ liệu cá nhân được thu thập, gửi đi hay lưu giữ ở một chỗ mới đều phải cập nhật chính sách trong cùng commit. Việc cập nhật đó bao gồm cả màn hình tóm tắt trong ứng dụng, trang xoá tài khoản, và các biểu mẫu quyền riêng tư trên cửa hàng ứng dụng, vốn chỉ nằm trong bảng điều khiển của cửa hàng. Báo cáo sự cố chính là thay đổi khiến tôi phải viết quy tắc đó ra.

Còn thiếu gì

#

Giải mã ký hiệu (symbolication). Đây là khoảng trống thật sự, và là thứ duy nhất sentry.io làm mà tôi chưa thay thế được. Stack của JavaScript thì đã bị rút gọn, còn của mã gốc thì chưa được giải mã ký hiệu:

• JavaScript: các frame trỏ vào bundle Hermes. Muốn sửa thì phải giữ source map Hermes đã ghép (composed) cho mọi bản build lên cửa hàng và mọi bundle OTA, đánh khoá theo phiên bản phát hành và bundle, rồi áp vào các frame JS khi render trang. Đó là phần làm tiếp theo, vì phần lớn các lần sập của chúng tôi sẽ là JavaScript.
• iOS gốc: địa chỉ lệnh cần dSYM của bản build.
• Android: frame Java bị R8 làm rối (obfuscate) khi bật rút gọn mã (cần mapping.txt), còn frame C++ cần ký hiệu NDK.

Còn một khoảng trống nhỏ hơn mà tôi đã nhắc ở trên: các lần sập gốc chưa mang tag OTA, vì tag này mới chỉ được đặt trong beforeSend. Đặt nó trên scope ngay khi bundle đang chạy được xác nhận chỉ mất vài dòng, nhưng tôi chưa viết.

Hiện tại, một issue cho tôi biết cái gì đã sập, trên phiên bản phát hành, bundle OTA và thiết bị nào, và người dùng đang làm gì ngay trước đó. Nó chưa cho tôi biết lỗi nằm ở đâu trong mã nguồn. Với một ứng dụng nhỏ phát hành vài lần mỗi tuần, cho tới giờ kiểu lỗi, thông điệp và breadcrumb vẫn đủ để tìm ra vấn đề.

Bộ nhận, trang quản trị và phần kiểm thử cộng lại cũng không nhiều mã, và nó không tốn thêm đồng nào ngoài chi phí của API vốn đã chạy sẵn. SDK làm phần khó nhất: bắt được lần sập trên điện thoại và gửi báo cáo đi ở lần khởi động kế tiếp.

Thời gian tôi dành cho việc gỡ lỗi nhiều đến mức khó tin. Mà lập trình viên nào chẳng thế. Dạo này phần lớn thời gian đó tôi ngồi trong Xcode và trình giả lập (Simulator), lần theo lỗi trong chính ứng dụng của mình, và có một điều tôi cứ thấy lạ mãi: Xcode đi kèm cả một kho công cụ gỡ lỗi, vậy mà gần như chẳng ai đụng tới. Dưới đây là quy trình tôi đúc kết qua nhiều năm, chỉ gồm những phần thực sự giúp tiết kiệm thời gian mỗi khi có gì đó hỏng.

Điểm dừng làm được nhiều hơn bạn nghĩ

#

Đa số chúng ta chỉ nhấp vào lề trái để đặt điểm dừng (breakpoint) rồi thôi. Nhưng thử nhấp chuột phải vào một điểm dừng xem, bạn sẽ thấy cả một menu tùy chọn, và nó thay đổi hẳn cách bạn gỡ lỗi.

Điểm dừng có điều kiện (Conditional Breakpoint)

#

Giả sử bạn có một vòng lặp xử lý 1000 phần tử, và chỉ riêng phần tử thứ 347 là trục trặc. Nếu phải dừng ở điểm dừng 346 lần trước khi tới được nó thì coi như mất toi một buổi chiều.

for i in 0..<users.count {
    processUser(users[i])  // Set breakpoint here with condition: i == 347
}

Nhấp chuột phải vào điểm dừng, thêm điều kiện i == 347, thế là Xcode chỉ dừng khi điều kiện đó đúng. Mấy điều kiện kiểu userId == "abc123" hay error != nil cũng dùng tốt y như vậy.

Điểm dừng theo ký hiệu (Symbolic Breakpoint)

#

Loại này dùng khi bạn không biết một phương thức đang được gọi từ đâu. Mở Breakpoint Navigator (Cmd+8), bấm nút +, rồi chọn “Symbolic Breakpoint”.

Muốn biết mỗi lần có view controller nào được nạp? Đặt ký hiệu là viewDidLoad, Xcode sẽ dừng lại ở từng cái một. Thấy nhiều quá? Thì thu hẹp lại: MyViewController.viewDidLoad.

Có mấy cái tôi để cố định trong mọi dự án:

• UIViewAlertForUnsatisfiableConstraints bắt các xung đột Auto Layout ngay khi chúng xảy ra
• objc_exception_throw dừng ở mọi ngoại lệ (exception) Objective-C, trước khi ứng dụng kịp bị sập (crash)
• malloc_error_break giúp tìm ra các lỗi cấp phát bộ nhớ

Điểm dừng ngoại lệ (Exception Breakpoint)

#

Đây nên là thứ đầu tiên bạn thiết lập khi tạo dự án mới. Thêm một cái (Breakpoint Navigator, + → Exception Breakpoint) là Xcode sẽ dừng ngay lúc có ngoại lệ được ném ra, chứ không phải đợi đến khi ứng dụng đã chết hẳn.

Nhờ nó mà tôi bắt được không biết bao nhiêu lỗi mở gói (unwrap) giá trị nil, nhiều hơn mức tôi muốn thừa nhận. Không có nó thì mấy lỗi này chỉ hiện ra dưới dạng những vụ sập khó hiểu trong console.

Hành động của điểm dừng (Breakpoint Action)

#

Điểm dừng không nhất thiết phải dừng chương trình. Sửa một điểm dừng, bấm “Add Action”, và bạn có thể cho nó:

• In giá trị biến ra mà không dừng: "User count: @(users.count)@"
• Tự động chạy lệnh LLDB
• Chạy shell script
• Phát âm thanh (tôi hay dùng cho những nhánh mã hiếm khi chạy tới, để biết ngay khi nó xảy ra)

Đánh dấu thêm “Automatically continue after evaluating actions” là điểm dừng biến thành một công cụ ghi nhật ký (log), không bao giờ làm gián đoạn bạn.

LLDB: những lệnh console bạn sẽ dùng thật

#

Khi chương trình dừng ở điểm dừng, cái console ở dưới cùng không chỉ để đọc nhật ký sự cố (crash log). Đó chính là LLDB, và nó hữu ích hơn bạn tưởng nhiều.

Cơ bản

#

(lldb) po user
▿ User
  - id: "123"
  - name: "John Doe"
  - email: "john@example.com"

po in đối tượng (object) ra ở dạng dễ đọc. Riêng lệnh này đã chiếm tới 90% số lần tôi dùng LLDB.

Cần chi tiết hơn thì dùng p:

(lldb) p user.name
(String) $R0 = "John Doe"

Còn muốn xem toàn bộ biến cục bộ cùng lúc:

(lldb) frame variable

Thay đổi giá trị khi chương trình đang chạy

#

LLDB thực sự đáng đồng tiền ở chỗ này: bạn sửa được giá trị biến mà không cần biên dịch lại.

(lldb) expr user.name = "Jane Doe"
(lldb) expr index = 0

Tìm ra lỗi rồi và muốn thử cách sửa mà không phải biên dịch lại? Cứ đổi giá trị biến rồi cho chương trình chạy tiếp. Tôi dùng cách này liên tục mỗi khi cần khoanh vùng các trường hợp biên (edge case).

Gọi phương thức cũng được luôn:

(lldb) po self.refreshUI()
(lldb) expr navigationController?.popViewController(animated: true)

Di chuyển trong chương trình

#

(lldb) bt              # Show the call stack
(lldb) frame select 3  # Jump to a different stack frame
(lldb) continue        # Keep running (or just 'c')
(lldb) n               # Step over (next line)
(lldb) s               # Step into function

Điểm theo dõi (Watchpoint)

#

Muốn biết khi nào một biến bị thay đổi? Đặt điểm theo dõi:

(lldb) watchpoint set variable user.isLoggedIn

Từ giờ, cứ mỗi lần giá trị đó thay đổi là chương trình dừng lại, bất kể dòng mã nào gây ra. Khi phải truy lùng những lần trạng thái bị thay đổi ngoài ý muốn thì công cụ này quý như vàng.

Console.app: công cụ gỡ lỗi ít người để ý

#

Console của Xcode dùng tạm thì ổn, cho đến khi bạn cần xem mọi thứ: nhật ký hệ thống, báo cáo sự cố (crash report), đủ cả. Những lúc đó tôi mở Console.app.

Nếu bạn đang dùng OSLog (và bạn nên dùng), Console.app cho phép tìm kiếm và lọc các nhật ký đó:

import os.log

let logger = Logger(subsystem: "com.example.app", category: "networking")

logger.info("Starting API request")
logger.debug("Request URL: \(url.absoluteString)")
logger.error("Failed to decode: \(error.localizedDescription)")

Sau đó, trong Console.app:

1. Chọn trình giả lập hoặc thiết bị đang kết nối
2. Lọc theo phân hệ (subsystem) của bạn: subsystem:com.example.app
3. Lọc theo mức độ: subsystem:com.example.app AND level:error

Với những kiểu gỡ lỗi hay làm, bạn có thể lưu sẵn biểu thức lọc (predicate). Tôi có một cái cho yêu cầu mạng, một cái cho các thao tác với cơ sở dữ liệu, và một cái chỉ hiện lỗi với cảnh báo.

Sao lại dùng OSLog thay vì print()?

#

So với việc rải print() khắp nơi thì OSLog hơn hẳn. Nhật ký có cấu trúc nên lọc được theo mức độ và danh mục. Nó đủ nhanh để việc ghi nhật ký không làm ứng dụng chậm đi. Trên môi trường production, dữ liệu nhạy cảm được tự động ẩn đi, và nhật ký vẫn còn nguyên kể cả khi ứng dụng bị sập.

print() vẫn ổn cho mấy lần kiểm tra nhanh rồi xóa. Còn thứ gì sau này bạn có thể cần xem lại thì nên ghi bằng OSLog.

Lọc nâng cao trong Console.app

#

Console.app hỗ trợ đầy đủ truy vấn bằng biểu thức lọc. Đây là mấy câu tôi dùng thường xuyên:

# All errors and faults in your app
subsystem:com.example.app AND (level:error OR level:fault)

# Network requests that failed
subsystem:com.example.app AND category:networking AND eventMessage CONTAINS "failed"

# Everything from the last 5 minutes
subsystem:com.example.app AND timestamp >= now(-5m)

Bạn cũng có thể xuất nhật ký ra để đính kèm vào báo cáo lỗi, tiện hơn nhiều so với sao chép thủ công từ console của Xcode.

Gỡ lỗi giao diện với View Debugger

#

Khi giao diện bị vỡ mà bạn không hiểu tại sao, View Debugger là cách nhanh nhất để tìm ra nguyên nhân.

Chạy ứng dụng, mở tới màn hình bị lỗi, rồi bấm nút “Debug View Hierarchy” trên thanh gỡ lỗi của Xcode (hoặc nhấn Cmd+Shift+D). Xcode sẽ hiện toàn bộ cây phân cấp view (view hierarchy) dưới dạng 3D, tách ra từng lớp.

Xoay qua xoay lại một chút là vấn đề lộ ra ngay:

• View bị vẽ nằm phía sau view khác
• View nằm tít ngoài màn hình
• View có kích thước bằng 0
• Toàn bộ chuỗi ràng buộc (constraint) của view bạn đang chọn

Tôi từng nhờ nó mà tìm ra những cái nút vô hình nuốt mất sự kiện chạm, những nhãn bị vẽ ở kích thước 0x0, và có lần là một tấm ảnh lỡ tay rộng tới 10,000 pixel.

Gỡ lỗi Auto Layout

#

Trong cây phân cấp view, biểu tượng cảnh báo màu tím nghĩa là đang có xung đột ràng buộc. Nhấp vào đó, Xcode sẽ chỉ rõ những ràng buộc nào đang “đánh nhau”.

Hãy đặt định danh (identifier) cho ràng buộc:

heightConstraint.identifier = "ProfileImageHeight"

Khi ràng buộc bị vỡ, thông báo lỗi sẽ hiện "ProfileImageHeight" thay vì một địa chỉ bộ nhớ, và lúc đó nhật ký mới thực sự đọc được.

Bạn cũng có thể in cây ràng buộc ra từ LLDB:

(lldb) po view.hasAmbiguousLayout
(lldb) po view._autolayoutTrace()

Những tính năng của trình giả lập giúp tiết kiệm thời gian

#

Làm chậm hoạt ảnh (Slow Animations)

#

Debug → Slow Animations làm mọi thứ chạy chậm lại còn 1/10. Rất hợp để xem trong một hiệu ứng chuyển cảnh thực sự đang xảy ra chuyện gì, hoặc tìm hiểu vì sao một hoạt ảnh trông sai sai.

Giả lập cảnh báo bộ nhớ

#

Debug → Simulate Memory Warning giúp bạn kiểm tra xem ứng dụng xoay xở ra sao khi thiếu bộ nhớ. Tôi đã tìm ra khá nhiều lỗi liên quan đến bộ nhớ đệm (cache) ảnh theo cách này: mọi thứ vẫn chạy ổn, cho tới khi cảnh báo được phát ra, và tự dưng toàn bộ ảnh biến mất sạch.

Network Link Conditioner

#

Xcode → Open Developer Tools → Network Link Conditioner

Công cụ này giả lập mạng 3G, LTE, mạng mất gói nhiều, hoặc mất kết nối hoàn toàn. Nếu bạn từng gặp một yêu cầu API chạy ngon lành trên WiFi nhưng lại hết thời gian chờ (timeout) khi dùng 4G, thì đây là cách để tái hiện lỗi đó.

Tôi luôn để sẵn một cấu hình tên “Bad Network”, với độ trễ 500ms và tỉ lệ mất gói 10%. Nhờ nó mà lộ ra những lỗi hết thời gian chờ và lỗi ở trạng thái đang tải, loại lỗi bạn sẽ không bao giờ thấy khi ngồi dùng WiFi tốc độ cao ở văn phòng.

Ghi đè thanh trạng thái

#

Nhấp chuột phải vào thanh trạng thái (status bar) trong trình giả lập là bạn ghi đè được giờ, mức pin, cường độ sóng và tên nhà mạng. Rất tiện khi cần chụp ảnh màn hình đồng nhất, hoặc muốn kiểm tra giao diện trông thế nào ở các mức pin khác nhau.

Giả lập vị trí

#

Debug → Location cho phép giả lập các vị trí khác nhau mà không cần rời khỏi bàn làm việc: tọa độ tùy chọn, đi bộ trong thành phố, hay lái xe trên cao tốc. Rất hữu ích khi làm các tính năng dựa trên vị trí, hoặc khi gặp những lỗi chỉ xuất hiện ở một số khu vực nhất định.

Gỡ lỗi bộ nhớ

#

Debug Memory Graph

#

Bấm nút Debug Memory Graph (Cmd+Shift+M), Xcode sẽ hiện ra mọi đối tượng đang nằm trong bộ nhớ, quan hệ giữa chúng, và phần bạn thực sự quan tâm: đối tượng nào đang bị rò rỉ bộ nhớ (memory leak).

Dấu chấm than màu tím nghĩa là có rò rỉ. Nhấp vào là bạn thấy ngay vòng tham chiếu (retain cycle).

Đây là kiểu rò rỉ tôi gặp nhiều nhất:

class ViewController: UIViewController {
    var onComplete: (() -> Void)?

    func setupHandler() {
        onComplete = {
            self.dismiss(animated: true)  // ❌ Captures self strongly
        }
    }
}

Cách sửa là dùng weak self:

onComplete = { [weak self] in
    self?.dismiss(animated: true)  // ✓ No retain cycle
}

Delegate cũng phải khai báo weak:

weak var delegate: ManagerDelegate?  // Not just 'var'

Instruments

#

Khi cần điều tra bộ nhớ nghiêm túc, hãy dùng Instruments (Product → Profile, hoặc Cmd+I).

Công cụ Allocations trong Instruments cho bạn thấy từng lần cấp phát đối tượng, bộ nhớ tăng lên theo thời gian ra sao, lớp nào đang ngốn nhiều bộ nhớ nhất, kèm stack trace cho biết mỗi lần cấp phát xảy ra ở đâu.

Tôi thường tìm ba thứ: bộ nhớ tăng đều theo thời gian (nhiều khả năng là rò rỉ), những lần cấp phát lớn bất thường (mình vừa nạp cả 1000 tấm ảnh một lúc à?), và những đối tượng lẽ ra đã phải được giải phóng nhưng vẫn còn đó.

Bấm đánh dấu generation (nút hình lá cờ nhỏ) trước và sau một thao tác để xem thứ gì vẫn còn nằm lại trong bộ nhớ khi đáng lẽ phải được giải phóng.

Đo hiệu năng

#

Time Profiler

#

Product → Profile → Time Profiler. Bấm ghi, thực hiện đúng thao tác đang chậm trong ứng dụng, rồi đọc cây lời gọi hàm (call tree).

Sắp xếp theo “Self Weight” để tìm điểm nghẽn (bottleneck). Hàm nào có self weight tới 40% thì đó chính là chỗ thời gian của bạn đang bị ngốn.

Có lần tôi phát hiện một hàm phân tích JSON bị gọi tới 1000 lần mỗi giây. Chuyển nó sang hàng đợi chạy nền (background queue) xong là giao diện hết giật ngay.

Main Thread Checker

#

Xcode tự động phát hiện những chỗ cập nhật giao diện từ luồng nền (background thread). Nếu bạn thấy dòng này:

Main Thread Checker: UI API called on a background thread: -[UILabel setText:]

thì nghĩa là bạn đã viết kiểu như thế này:

URLSession.shared.dataTask(with: url) { data, response, error in
    self.label.text = "Loaded"  // ❌ Crash!
}

Sửa lại như sau:

URLSession.shared.dataTask(with: url) { data, response, error in
    DispatchQueue.main.async {
        self.label.text = "Loaded"  // ✓
    }
}

Chẩn đoán khi chạy (Runtime Diagnostics)

#

Vào Edit Scheme → Run → Diagnostics. Ở đây có một loạt ô đánh dấu, mỗi ô bắt được những lỗi mà tự tay bạn sẽ không bao giờ tìm ra.

Address Sanitizer

#

Công cụ này tìm lỗi hỏng bộ nhớ: use-after-free, tràn bộ đệm (buffer overflow), rò rỉ bộ nhớ. Nó làm ứng dụng chậm đi 2-3 lần, nhưng bù lại bắt được những lỗi gần như không thể lần ra bằng cách nào khác. Tôi bật nó mỗi khi đi săn những vụ sập lúc có lúc không.

Thread Sanitizer

#

Thread Sanitizer bắt lỗi tranh chấp dữ liệu (data race) và các lỗi liên quan đến luồng (thread). Bạn chỉ cần bật lên, chạy ứng dụng và dùng như bình thường; nếu trong mã có tình trạng tranh chấp (race condition), nó sẽ tìm ra.

Không thể chạy Address Sanitizer và Thread Sanitizer cùng lúc, nên khi gặp một vụ sập có biểu hiện kỳ quặc, tôi bật luân phiên từng cái một.

Zombie Objects

#

Tùy chọn này bắt các thông điệp (message) được gửi tới đối tượng đã bị giải phóng. Khi bật lên, Xcode sẽ báo chính xác lúc nào bạn đang đụng vào vùng nhớ đã được giải phóng:

*** -[MyViewController viewDidLoad]: message sent to deallocated instance 0x600001234000

Đừng để nó bật thường trực. Zombie Objects ngăn đối tượng bị giải phóng, nên bộ nhớ cứ thế tăng mãi. Nhưng để khoanh vùng một lỗi use-after-free cụ thể thì nó rất tuyệt.

Những tình huống hay gặp

#

Ứng dụng bị sập ngay khi mở

#

Trước hết hãy thêm điểm dừng ngoại lệ; thường thì thế là bắt được luôn.

Nếu vẫn chưa ra, mấy “nghi phạm quen mặt” là: thiếu khóa (key) trong Info.plist, ép mở gói (force-unwrap) optional trong phần mã khởi tạo, hoặc cơ chế tiêm phụ thuộc (dependency injection) bị lỗi.

Giao diện không cập nhật

#

Lần. Nào. Cũng. Vậy. Nguyên nhân chỉ nằm trong mấy trường hợp sau:

1. Việc cập nhật không chạy trên luồng chính (main thread)
2. Outlet chưa được nối
3. View thực ra không hiển thị (kiểm tra bằng po view.window trong LLDB; nếu kết quả là nil thì view không nằm trong cây phân cấp)

Còn nếu là table view hay collection view: bạn quên gọi reloadData() rồi.

Ứng dụng bị sập vì cảnh báo bộ nhớ

#

Dùng Allocations trong Instruments để xem thứ gì đang giữ bộ nhớ. Thường là ảnh nằm trong bộ nhớ đệm mà không bao giờ được nhả ra, view controller không chịu giải phóng (vòng tham chiếu), hoặc một mảng hay dictionary nào đó cứ phình to mãi.

Hãy giả lập cảnh báo bộ nhớ trong trình giả lập để kiểm tra phần mã dọn dẹp của bạn.

Những vụ sập khó hiểu

#

Bật Sanitizer lên. Sập lúc có lúc không thường là do luồng, nên hãy chạy với Thread Sanitizer. Còn sập bên trong framework của hệ thống thì thường là do hỏng bộ nhớ, nên chạy với Address Sanitizer.

Những vụ sập không tái hiện được

#

Khi vụ sập xảy ra trên điện thoại của người khác, thường thì báo cáo sự cố vẫn còn lưu lại ở đâu đó. Với các bản build TestFlight và App Store, Organizer của Xcode (Window → Organizer → Crashes) thu thập báo cáo sự cố từ những người dùng đồng ý chia sẻ dữ liệu phân tích, và báo cáo đã được giải mã ký hiệu (symbolicate) sẵn nếu tệp dSYM được tải lên cùng bản build. Còn với máy của người kiểm thử, báo cáo nằm ngay trên thiết bị, trong Settings → Privacy & Security → Analytics & Improvements → Analytics Data, dưới dạng các tệp .ips có tên bắt đầu bằng tên ứng dụng, và họ có thể gửi cho bạn qua AirDrop. Hãy bắt đầu từ stack trace của luồng bị sập, rồi lần lượt đối chiếu với các tình huống ở trên.

Gỡ lỗi bản cập nhật OTA trong trình giả lập

#

Ứng dụng của tôi có phát hành bản cập nhật qua mạng (OTA), và trình giả lập là nơi dễ nhất để gỡ lỗi toàn bộ luồng cập nhật đó.

Việc đầu tiên tôi làm là theo dõi lưu lượng mạng. Mở Console.app, lọc theo phân hệ của ứng dụng, bạn sẽ thấy các yêu cầu và phản hồi của tệp manifest theo thời gian thực: tiêu đề (header) nào được gửi đi, máy chủ trả về cái gì, rõ ràng từng thứ.

Tiếp theo, tôi cố tình làm cho mạng tệ đi. Network Link Conditioner cho bạn thấy luồng cập nhật xoay xở ra sao khi kết nối chậm và mất gói. Ứng dụng có bị treo không? Có hiện biểu tượng đang tải không? Có chuyển sang phương án dự phòng êm ái không?

Quanh bước kiểm tra cập nhật, tôi ghi nhật ký mọi thứ: lúc bắt đầu kiểm tra, lúc phát hiện có bản mới, lúc bắt đầu tải xuống, và lúc gói (bundle) mới được nạp.

import os.log

let logger = Logger(subsystem: "com.example.app", category: "updates")

logger.info("Checking for updates...")
let update = try await Updates.checkForUpdateAsync()
logger.info("Update available: \(update.isAvailable)")

Cuối cùng, bạn nên kiểm tra riêng endpoint manifest. Dùng curl gọi nó với đúng những tiêu đề mà ứng dụng gửi đi:

curl -H "expo-protocol-version: 1" \
     -H "expo-platform: ios" \
     -H "expo-runtime-version: 1.0.0" \
     https://updates.example.com/manifest

Làm vậy để chắc chắn máy chủ đang trả về đúng dữ liệu, trước khi bạn lao vào đào bới phía máy khách.

Công cụ bên thứ ba

#

Charles Proxy / Proxyman

#

Hai công cụ này cho bạn xem toàn bộ lưu lượng mạng, sửa yêu cầu và phản hồi, và thử các tình huống lỗi. Gỡ lỗi API mà thiếu chúng thì rất khổ.

Proxyman có giao diện đẹp hơn Charles và dùng trên macOS thấy tự nhiên hơn. Tôi chuyển sang từ năm ngoái và chưa một lần muốn quay lại.

Reveal

#

Reveal giống View Debugger của Xcode nhưng mạnh hơn. Nó chạy được trên máy thật mà không cần kết nối với Xcode, nên rất hợp để truy lỗi bố cục ngay trên máy của người kiểm thử (tester).

Trình giả lập hay máy thật

#

Phần lớn việc gỡ lỗi tôi làm trên trình giả lập, vì nó nhanh: không cần cáp, không cần ký ứng dụng (code signing), không phải chờ cài đặt. Nhưng trình giả lập thực chất là một bản iOS chạy trên bộ xử lý của máy Mac, dùng bộ nhớ và kết nối mạng của máy Mac, nên có những lỗi chỉ tồn tại trên điện thoại thật.

Vì vậy tôi viết và gỡ lỗi phần logic trên trình giả lập, còn trước mỗi lần phát hành thì chạy ứng dụng trên chiếc iPhone cũ nhất mà tôi vẫn còn hỗ trợ. Hiệu năng, tình trạng thiếu bộ nhớ và bất cứ thứ gì đụng tới phần cứng thì chưa chạy trên máy thật là coi như chưa thực sự được kiểm thử.

Chạy ứng dụng trên máy thật

#

Cắm iPhone vào máy Mac, chọn nó làm thiết bị chạy (run destination), rồi chọn team trong mục Signing & Capabilities (nếu chỉ chạy trên điện thoại của chính bạn thì một Apple ID miễn phí là đủ). Từ iOS 16 trở đi, điện thoại còn phải bật Developer Mode trong Settings → Privacy & Security, và lần đầu bật thì máy sẽ khởi động lại. Bật xong, ngay trong Settings → Developer của điện thoại cũng có Network Link Conditioner, với đúng những cấu hình mạng kém giống như trên máy Mac.

Gỡ lỗi không dây

#

Cắm máy vào Mac qua cáp USB một lần, vào Window → Devices and Simulators, đánh dấu “Connect via network”, rồi rút cáp ra. Chỉ cần máy và Mac dùng chung mạng WiFi là máy vẫn hiện trong Xcode.

Device Console

#

Window → Devices and Simulators → Open Console. Ở đây hiện đủ mọi thứ: nhật ký hệ thống, nhật ký của ứng dụng, báo cáo sự cố. Chi tiết hơn console của Xcode rất nhiều.

Mỗi khi người kiểm thử báo “ứng dụng bị sập”, tôi luôn nhờ họ cắm máy vào để lấy nhật ký console. Rất hay gặp trường hợp có sẵn một lỗi ở cấp hệ thống nằm ngay đó, giải thích được toàn bộ câu chuyện.

Tôi thực sự làm gì khi gỡ lỗi

#

1. Thêm điểm dừng ngoại lệ nếu chưa có
2. Tái hiện lỗi
3. Đặt điểm dừng gần chỗ tôi nghi là đang sai
4. Kiểm tra giá trị bằng po trong LLDB
5. Sửa giá trị biến để thử cách sửa mà không cần biên dịch lại
6. Xem cây phân cấp view nếu lỗi liên quan đến giao diện
7. Phân tích hiệu năng (profile) bằng Instruments nếu lỗi liên quan đến hiệu năng
8. Bật Sanitizer nếu lỗi liên quan đến bộ nhớ hoặc luồng

Bí quyết là đi ngược từ triệu chứng. Sập? Điểm dừng ngoại lệ. Chậm? Time Profiler. Bộ nhớ? Instruments. Giao diện kỳ cục? View Debugger.

Những mẹo tôi ước mình biết sớm hơn

#

Hãy dùng assertion. Chúng bắt được lỗi logic trước khi lỗi đó kịp gây hậu quả thật:

assert(users.count > 0, "Users array should never be empty here")

Commit trước khi bắt đầu gỡ lỗi. Một khi đã sửa lung tung để thử các giả thuyết, bạn sẽ cần một điểm sạch sẽ để quay về.

Gỡ lỗi xong thì xóa mấy lệnh print đi, hoặc ít nhất bọc chúng trong #if DEBUG. Nhật ký gỡ lỗi cũ để lại chỉ làm cho lỗi tiếp theo khó thấy hơn.

Học LLDB cho tử tế. Nhanh hơn nhiều so với việc biên dịch lại ứng dụng hai mươi lần.

Và nhớ rằng trình giả lập không phải điện thoại thật. Lỗi chỉ xuất hiện trên máy thật thì gần như lúc nào cũng là do luồng hoặc bộ nhớ. Hoặc do hiệu năng, vì trình giả lập chạy bằng CPU của máy Mac chứ không phải chip iPhone thật.

Những công cụ tôi luôn để mở

#

• Xcode, tất nhiên rồi
• Console.app, lọc sẵn theo phân hệ của ứng dụng
• Proxyman để gỡ lỗi mạng
• Instruments, khi mọi chuyện bắt đầu nghiêm trọng

Không có công cụ nào lo được hết mọi thứ. View Debugger không tìm ra rò rỉ bộ nhớ, Instruments cũng không gỡ được xung đột Auto Layout, nên phần lớn kỹ năng nằm ở chỗ chọn đúng công cụ cho đúng triệu chứng. Cái này thì chỉ có làm nhiều mới quen: dính vòng tham chiếu đủ nhiều lần rồi, chỉ cần liếc stack trace là bạn đã “ngửi” ra nó. Gỡ lỗi chẳng bao giờ thực sự vui, nhưng ít ra nó sẽ không còn là cực hình nữa.