Firebase Performance: nó là gì, các chỉ số và cách theo dõi

Firebase Performance Monitoring là gì

Firebase Performance Monitoring là một SDK và nền tảng đám mây để thu thập, tổng hợp và trực quan hóa các chỉ số hiệu suất ứng dụng di động. SDK được nhúng vào ứng dụng và tự động đo lường các điểm chính: vòng đời Activity (Android) hoặc ViewController (iOS), yêu cầu mạng qua URLSession (iOS) hoặc OkHttp (Android) và các lệnh gọi hệ thống. Dữ liệu thu thập được gửi đến máy chủ Firebase, nơi chúng được tổng hợp theo phiên bản ứng dụng, thiết bị, quốc gia và các thuộc tính khác.

Kiến trúc của Performance SDK được xây dựng dựa trên nguyên tắc chi phí tối thiểu: việc đo lường chỉ thêm không quá 1–2% vào thời gian thực thi của các thao tác được đo. Dữ liệu được thu thập không đồng bộ và được đệm trên thiết bị trước khi gửi, loại bỏ mọi tác động đến hiệu suất của luồng UI. Dữ liệu được gửi theo lịch trình (mặc định 30 phút một lần) hoặc khi bộ đệm đạt 100 KB.

Sự khác biệt chính giữa Firebase Performance và các công cụ phân tích của Android Studio (CPU Profiler) hoặc Xcode Instruments là giám sát sản xuất. Firebase Performance thu thập dữ liệu từ các thiết bị thực tế của người dùng, không chỉ từ thiết bị nhà phát triển. Điều này cho phép phát hiện các vấn đề chỉ xảy ra trên các mẫu máy cụ thể, phiên bản OS hoặc ở các khu vực cụ thể — những vấn đề không thể tái tạo trong môi trường kiểm soát.

Cách SDK thu thập dữ liệu mà không thay đổi mã

Đo lường tự động là tính năng chính của Firebase Performance. Đối với Android, SDK tự động đăng ký ActivityLifecycleCallbacks và đo thời gian giữa onCreate và onResume (thời gian kết xuất màn hình). Đối với iOS, nó swizzle các phương thức viewDidLoad và viewDidAppear. Các yêu cầu mạng được chặn ở cấp OkHttpInterceptor (Android) hoặc NSURLProtocol (iOS). Nhà phát triển không cần thêm các lệnh gọi start/stop cho các chỉ số tiêu chuẩn.

Bật và tắt Performance SDK được quản lý thông qua plugin Google Services (Android) hoặc Info.plist (iOS). Để gỡ lỗi, bạn có thể bật ghi log chi tiết của Performance SDK, hiển thị các chỉ số nào đang được thu thập và gửi. Trong sản xuất, nên giữ ghi log ở mức cảnh báo để tránh làm lộn xộn log với thông tin không cần thiết. Đối với các dự án trên Flutter hoặc React Native, việc đo lường tự động có thể bị hạn chế — xem chi tiết trong phần ví dụ mã.

Giới hạn miễn phí và giá cả

Firebase Performance có sẵn trên gói Spark miễn phí không giới hạn về số lượng trace hoặc khối lượng dữ liệu. Gói Blaze trả phí cũng không tính phí cho Performance Monitoring — đây là một trong số ít dịch vụ Firebase hoàn toàn miễn phí trên cả hai gói. Chỉ có một giới hạn: dữ liệu được lưu trữ trong 30 ngày (trên Spark) và tối đa 365 ngày (trên Blaze). Để phân tích dài hạn, hãy xuất dữ liệu qua BigQuery export.

Không mất phí làm cho Firebase Performance trở thành lựa chọn lý tưởng cho mọi dự án — từ nguyên mẫu đến ứng dụng doanh nghiệp với hàng triệu người dùng. Chi phí duy nhất là lưu lượng gửi đi của Performance SDK, nhưng nó không đáng kể so với các thao tác mạng khác của ứng dụng (dưới 1 MB mỗi tháng cho mỗi thiết bị). BigQuery export tính phí lưu trữ và truy vấn, nhưng bản thân Performance SDK là miễn phí.

Các chỉ số tự động: những gì được đo mà không cần mã

Firebase Performance tự động thu thập năm loại chỉ số mà không cần một dòng mã nào: thời gian khởi động ứng dụng, yêu cầu HTTP chậm, tốc độ kết xuất màn hình, sử dụng bộ nhớ (chỉ Android) và tốc độ khung hình (chỉ Android). Các chỉ số này có sẵn trong bảng điều khiển Firebase ngay sau khi kết nối SDK và phiên làm việc đầu tiên của người dùng.

Thời gian khởi động ứng dụng — thời gian từ khi bắt đầu tiến trình đến khi UI sẵn sàng đầy đủ để tương tác. Nó được chia thành khởi động nguội (ứng dụng khởi động từ đầu) và khởi động ấm (ứng dụng tiếp tục từ trạng thái nền). Khởi động nguội bao gồm tải tệp DEX, khởi tạo trường tĩnh, gọi Application.onCreate và Activity.onCreate. Firebase tự động phân loại loại khởi động và hiển thị phân bổ thời gian cho từng loại.

Thời gian kết xuất màn hình — thời gian từ khi bắt đầu tải màn hình (onCreate đối với Android, viewDidLoad đối với iOS) đến khi màn hình sẵn sàng để tương tác (onResume, viewDidAppear). Firebase tổng hợp dữ liệu theo từng màn hình (theo tên lớp hoặc tên màn hình tùy chỉnh), cho phép xác định màn hình nào tải lâu nhất. Đối với Android, các khung hình bị bỏ qua cũng được đo — số lượng khung hình bị bỏ qua trong quá trình kết xuất màn hình (jank).

Yêu cầu mạng (HTTP/HTTPS)

Performance SDK tự động chặn và đo mọi yêu cầu HTTP/HTTPS được gửi từ ứng dụng qua URLSession, OkHttp hoặc URLConnection. Đối với mỗi yêu cầu, các thông tin sau được ghi lại: URL (đường dẫn không có tham số truy vấn vì lý do bảo mật), phương thức HTTP, mã phản hồi, kích thước phản hồi (byte), thời gian yêu cầu và tốc độ kết nối (WiFi, Di động). Dữ liệu được tổng hợp trong bảng điều khiển Yêu cầu mạng của bảng điều khiển Firebase.

Yêu cầu chậm — yêu cầu có thời gian vượt quá ngưỡng đã đặt. Theo mặc định, ngưỡng yêu cầu chậm là 4000 ms. Chỉ số này rất quan trọng để xác định các vấn đề về phía back-end: nếu sau khi cập nhật back-end, số lượng yêu cầu chậm tăng từ 1% lên 15%, đó là tín hiệu cần phân tích nhật ký máy chủ ngay lập tức. Người dùng sẽ không đợi quá 5 giây cho một phản hồi — dữ liệu Firebase cho thấy 53% người dùng đóng ứng dụng nếu một yêu cầu mất hơn 3 giây.

Hạn chế của đo lường tự động

Hạn chế iOS: trên iOS, Performance SDK không thể đo khung hình bị bỏ qua (đây là API riêng). Để đo jank trên iOS, hãy sử dụng MetricKit hoặc CADisplayLink. Ngoài ra, trên iOS, SDK không chặn các yêu cầu được thực hiện qua các trình khách HTTP bên thứ ba không sử dụng URLSession (ví dụ SwiftNIO). Đối với những trường hợp này, hãy sử dụng trace tùy chỉnh với thuộc tính HTTP.

Hạn chế Android: trên Android, đo bộ nhớ tự động chỉ khả dụng trên các thiết bị chạy Android 8.0+ (API 26+). Đối với các phiên bản cũ hơn, hãy sử dụng trace tùy chỉnh với dữ liệu thu được qua Debug.getMemoryInfo(). Ngoài ra, SDK không chặn các kết nối WebSocket — chúng yêu cầu các trace riêng biệt. Bất chấp những hạn chế này, các chỉ số tự động đáp ứng 80% nhu cầu giám sát hiệu suất.

Trace tùy chỉnh và thuộc tính HTTP

Trace tùy chỉnh là các khoảng thời gian được đặt tên mà nhà phát triển tạo thủ công để đo hiệu suất của các kịch bản cụ thể: tải feed tin tức, xử lý ảnh, đồng bộ dữ liệu, thực thi truy vấn cơ sở dữ liệu phức tạp. Trace tùy chỉnh bổ sung cho các chỉ số tự động và cho phép đo chính xác các phần mã mà nhà phát triển cho là quan trọng đối với hiệu suất.

Mỗi trace có tên (tối đa 100 ký tự) và có thể chứa tối đa 5 chỉ số tùy chỉnh — các giá trị số được ghi lại trong trace. Ví dụ, trong trace “image_processing”, bạn có thể đo các chỉ số như “original_file_size” và “processed_file_size”. Các chỉ số được hiển thị trong bảng điều khiển Firebase dưới dạng phân bố (tối thiểu, tối đa, trung bình, phân vị), cho phép phân tích không chỉ thời gian mà còn cả đặc điểm của thao tác.

Thuộc tính HTTP — một loại trace tùy chỉnh đặc biệt cho các yêu cầu mạng không bị SDK chặn tự động (ví dụ qua WebSocket hoặc thư viện bên thứ ba). Thuộc tính HTTP bao gồm URL, phương thức HTTP, mã phản hồi và kích thước phản hồi. Firebase hiển thị chúng trong phần Yêu cầu mạng cùng với các yêu cầu được thu thập tự động, cung cấp một bức tranh thống nhất về tương tác mạng.

Khi nào sử dụng trace tùy chỉnh

Trace tùy chỉnh không thể thiếu để đo: thời gian tải dữ liệu từ cơ sở dữ liệu cục bộ (Room, CoreData), thời gian tính toán phức tạp (mã hóa, nén), hiệu suất hoạt ảnh và chuyển tiếp, thời gian phản hồi của SDK bên thứ ba (bản đồ, thanh toán, phân tích). Đối với mỗi kịch bản như vậy, hãy tạo một trace, bọc mã được đo trong start/stop và thêm các thuộc tính để phân khúc sau này.

Đừng lạm dụng trace tùy chỉnh. Mỗi trace làm tăng mức tiêu thụ pin và lưu lượng. Nên không có quá 10–15 trace hoạt động trong phiên bản sản xuất của ứng dụng. Để gỡ lỗi, bạn có thể thêm nhiều trace hơn, nhưng trước khi phát hành, hãy tắt các trace dư thừa qua Remote Config (sử dụng cờ performance_tracing_enabled). Điều này cho phép bật theo dõi chi tiết chỉ cho một số người dùng hoặc phiên được chọn.

Thuộc tính trace để phân khúc

Thuộc tính tùy chỉnh là các cặp khóa-giá trị có thể được thêm vào trace để lọc sau trong bảng điều khiển Firebase. Ví dụ, cho trace “feed_load”, bạn có thể thêm các thuộc tính như “feed_type” (main, explore, following) và “cache_status” (cold, warm). Trong bảng điều khiển, dữ liệu trace có thể được lọc theo các thuộc tính này để xác định loại feed nào tải chậm nhất.

Giới hạn: mỗi trace có thể có tối đa 5 thuộc tính tùy chỉnh. Giá trị thuộc tính là chuỗi tối đa 100 ký tự. Các thuộc tính phải được đặt trước khi bắt đầu trace; thay đổi thuộc tính sau khi bắt đầu sẽ bị bỏ qua. Giới hạn này liên quan đến hiệu suất: cố định thuộc tính sau khi bắt đầu sẽ yêu cầu đồng bộ bổ sung.

Ngưỡng hiệu suất và cảnh báo

Ngưỡng là các giá trị ranh giới có thể cấu hình cho các chỉ số, khi vượt quá Firebase Performance sẽ tạo cảnh báo. Ngưỡng được đặt trong bảng điều khiển Firebase (Performance > Thresholds) cho từng chỉ số tự động: thời gian khởi động ứng dụng (nguội/ấm), thời gian kết xuất màn hình, yêu cầu HTTP chậm, thời gian phản hồi HTTP. Bạn có thể đặt ngưỡng toàn cục cho tất cả phiên bản ứng dụng hoặc cụ thể cho các phiên bản nhất định.

Cảnh báo là các thông báo tự động mà Firebase gửi khi vượt quá ngưỡng. Cảnh báo có thể được cấu hình qua email, webhook Slack, PagerDuty hoặc Cloud Functions (để xử lý tùy chỉnh). Mỗi cảnh báo bao gồm: tên chỉ số, giá trị hiện tại, giá trị ngưỡng, phiên bản ứng dụng, phân khúc (thiết bị, quốc gia). Cảnh báo cho phép phản ứng với sự suy giảm hiệu suất trước khi nó trở nên rõ ràng đối với người dùng.

Ngưỡng được khuyến nghị theo tiêu chuẩn ngành (Google I/O 2025): khởi động nguội — dưới 2 giây, khởi động ấm — dưới 1 giây, kết xuất màn hình — dưới 500 ms, thời gian yêu cầu HTTP — dưới 3000 ms (phân vị 95), tỷ lệ yêu cầu chậm — dưới 5%. Đối với các ứng dụng có tính cạnh tranh cao (Social, Thương mại điện tử), các ngưỡng mục tiêu có thể nghiêm ngặt hơn: khởi động nguội < 1.5 giây, HTTP < 1000 ms.

Đặt ngưỡng trong bảng điều khiển Firebase

Trong bảng điều khiển Firebase, hãy đi đến phần Performance, mở tab Thresholds. Đối với mỗi chỉ số, hãy đặt giá trị ngưỡng mong muốn và tỷ lệ phần trăm người dùng sẽ bị ảnh hưởng bởi việc vượt quá. Ví dụ: \u201ccoi kh\u1edfi \u0111\u1ed9ng nguội là chậm nếu nó vượt quá 2 giây cho hơn 10% người dùng”. Firebase sẽ hiển thị các giá trị chỉ số hiện tại và lịch sử vượt quá để giúp chọn các ngưỡng thực tế.

Quan trọng: các ngưỡng không ảnh hưởng đến việc thu thập dữ liệu, chúng chỉ kiểm soát việc tạo thông báo. Nếu ngưỡng quá thấp (ví dụ khởi động nguội 1 giây, trong khi 50% thiết bị khởi động trong 3 giây), cảnh báo sẽ đến liên tục và trở thành “tiếng ồn” mà nhà phát triển sẽ ngừng chú ý. Đặt các ngưỡng dựa trên hiệu suất hiện tại, sau đó thắt chặt dần khi bạn tối ưu hóa ứng dụng.

Bảng điều khiển hiệu suất trong bảng điều khiển Firebase

Bảng điều khiển hiệu suất hiển thị các chỉ số chính dưới dạng chuỗi thời gian được phân chia theo phiên bản ứng dụng, thiết bị, quốc gia, loại kết nối và phiên bản OS. Đối với mỗi chỉ số, có sẵn: trung bình, trung vị, phân vị 95, phân vị 99. Phân vị 95 là chỉ số nhiều thông tin nhất để đánh giá hiệu suất, vì nó cho thấy ứng dụng hoạt động như thế nào trên các thiết bị yếu, bỏ qua các giá trị ngoại lệ.

Bảng điều khiển hỗ trợ so sánh phiên bản: chọn hai phiên bản ứng dụng (hiện tại và trước đó) để so sánh trực quan các chỉ số. Nếu sau khi cập nhật, phân vị 95 thời gian khởi động tăng từ 2,1 lên 3,4 giây — sự suy thoái là rõ ràng và bạn cần tìm commit đã gây ra sự chậm lại. Firebase Performance tích hợp với GitHub, GitLab và Bitbucket, cho phép liên kết các thay đổi chỉ số với các commit cụ thể.

Ví dụ mã cho Performance Monitoring

Hãy xem các ví dụ tích hợp Firebase Performance Monitoring trong ứng dụng Android bằng Kotlin. Mã minh họa việc tạo trace tùy chỉnh để đo tải feed tin tức, thêm thuộc tính HTTP cho yêu cầu không bị chặn tự động và sử dụng Trace để đo thời gian xử lý ảnh. Tất cả các ví dụ đều tính đến khả năng tắt theo dõi qua Remote Config.

Trước khi sử dụng, hãy thêm phụ thuộc: implementation("com.google.firebase:firebase-perf") qua Firebase BOM. Đối với đo lường tự động, không cần thiết lập bổ sung — SDK tự động chặn các thao tác tiêu chuẩn sau khi thêm phụ thuộc.

Trace tùy chỉnh để tải feed

Ví dụ đầu tiên — đo thời gian tải feed tin tức từ máy chủ. Trace bao bọc thao tác bất đồng bộ fetchFeed, thao tác này lấy dữ liệu từ mạng và phân tích cú pháp JSON. Các thuộc tính tùy chỉnh đã được thêm vào trace: nguồn dữ liệu (cache hoặc network) và số lượng bài viết nhận được. Điều này cho phép phân khúc dữ liệu và hiểu trong điều kiện nào feed tải chậm nhất.

suspend fun loadFeedWithTrace(source: String) {
    val trace = Firebase.performance
        .newTrace("feed_load")
    trace.putAttribute("source", source)

    try {
        trace.start()
        val feed = fetchFeed()
        trace.putMetric(
            "items_count",
            feed.size.toLong()
        )
    } finally {
        trace.stop()
    }
}

Hàm loadFeedWithTrace nhận tham số source (“cache” hoặc “network”), được sử dụng làm thuộc tính trace. Sau khi hoàn thành thao tác bất đồng bộ, trace dừng lại trong khối finally, đảm bảo dừng ngay cả khi có ngoại lệ. Chỉ số items_count cho phép phân tích số lượng bài viết ảnh hưởng đến thời gian tải như thế nào. Trong bảng điều khiển Firebase, bạn có thể lọc các trace theo thuộc tính source và thấy rằng tải từ mạng chậm hơn 3 lần so với cache.

Thuộc tính HTTP cho yêu cầu không tiêu chuẩn

Ví dụ thứ hai — thuộc tính HTTP cho yêu cầu được thực hiện qua WebSocket (không bị chặn tự động). Lớp HttpMetric được sử dụng, cho phép đăng ký thủ công một yêu cầu URL, phương thức của nó, mã phản hồi và kích thước. Firebase sẽ hiển thị yêu cầu này trong phần Yêu cầu mạng cùng với các yêu cầu bị chặn tự động.

suspend fun sendWithHttpMetric() {
    val metric = Firebase.performance
        .newHttpMetric(
            "https://api.example.com/data",
            FirebasePerformance.HttpMethod.POST
        )
    metric.start()

    try {
        val response = webSocketSend()
        metric.setHttpResponseCode(response.code)
        metric.setRequestPayloadSize(1024)
        metric.setResponsePayloadSize(
            response.body.length.toLong()
        )
    } finally {
        metric.stop()
    }
}

Trong ví dụ, sendWithHttpMetric sử dụng newHttpMetric để đăng ký một lệnh gọi HTTP không tiêu chuẩn. SDK không chặn nó tự động, vì vậy nhà phát triển đặt URL, phương thức, mã phản hồi và kích thước một cách thủ công. Điều quan trọng là đặt URL không có tham số truy vấn (vì lý do bảo mật và tổng hợp) — nghĩa là /data, không phải /data?token=abc. Firebase tự động nhóm các mẫu URL giống nhau.

Đo thời gian xử lý ảnh

Ví dụ thứ ba minh họa việc đo thời gian xử lý ảnh (nén, thay đổi kích thước) bằng trace tùy chỉnh. Trong trường hợp này, trace bao bọc một thao tác đồng bộ, nhưng trong sản xuất hãy sử dụng coroutines hoặc RxJava để tránh chặn luồng UI.

fun compressImage(bitmap: Bitmap): ByteArray {
    val trace = Firebase.performance
        .newTrace("image_compression")
    trace.putAttribute(
        "format", "JPEG"
    )
    trace.start()

    val stream = ByteArrayOutputStream()
    bitmap.compress(
        Bitmap.CompressFormat.JPEG, 80, stream
    )
    val result = stream.toByteArray()
    trace.putMetric(
        "output_size_kb",
        result.size / 1024.toLong()
    )
    trace.stop()
    return result
}

Hàm compressImage đo thời gian nén ảnh thành JPEG với chất lượng 80%. Thuộc tính format cho phép so sánh thời gian nén JPEG với WebP trong tương lai. Chỉ số output_size_kb cho thấy hiệu quả nén. Trong bảng điều khiển Firebase, bạn có thể thấy phân bổ: trên các thiết bị yếu (Android giá rẻ), việc nén mất nhiều thời gian hơn 4 lần so với các thiết bị cao cấp, đây có thể là nguyên nhân gây ra sự chậm trễ khi tải ảnh lên máy chủ.

Cách cải thiện hiệu suất dựa trên dữ liệu

Firebase Performance cung cấp dữ liệu nhưng không đưa ra các giải pháp có sẵn. Phân tích các chỉ số đòi hỏi phải hiểu các nguyên nhân điển hình của sự suy giảm hiệu suất đối với từng chỉ số. Hãy xem các mô hình suy giảm chính và cách chẩn đoán chúng bằng dữ liệu Performance Monitoring. Cách tiếp cận: tìm bất thường trong chỉ số → kiểm tra nguyên nhân điển hình → áp dụng tối ưu hóa → kiểm tra kết quả sau một tuần.

Khởi động nguội chậm (> 2 giây): nguyên nhân — khởi tạo SDK nặng trong Application.onCreate (phân tích, báo cáo sự cố, SDK bản đồ), tải tài nguyên lớn (phông chữ, chủ đề), các thao tác đồng bộ trên luồng chính khi khởi động. Giải pháp: khởi tạo SDK lười biếng, tải tài nguyên trễ, sử dụng API SplashScreen (Android 12+) để hiển thị placeholder trong khi khởi tạo. Firebase Performance sẽ hiển thị phiên bản ứng dụng nào bắt đầu chậm hơn — hãy kiểm tra những phụ thuộc nào đã được thêm hoặc cập nhật.

Kết xuất màn hình chậm (> 500 ms): nguyên nhân — hệ phân cấp View phức tạp (ConstraintLayout lồng nhau, nhiều Fragment), tải dữ liệu trong luồng UI (mạng hoặc đĩa), các thao tác vẽ nặng (ảnh lớn, View tùy chỉnh). Giải pháp: tối ưu hóa hệ phân cấp bố cục (Layout Inspector trong Android Studio), chuyển dữ liệu sang luồng nền, lưu cache ảnh qua Glide hoặc Coil. Sử dụng bộ lọc Kết xuất màn hình trong Firebase để tìm màn hình chậm nhất và tối ưu hóa nó trước.

Tối ưu hóa yêu cầu mạng

Yêu cầu HTTP chậm (> 3 giây): nguyên nhân — máy chủ chậm, tải trọng lớn, thiếu bộ nhớ cache, giao thức không tối ưu (HTTP/1.1 thay vì HTTP/2), phân giải DNS. Giải pháp: kiểm tra phía máy chủ (thời gian hoạt động, độ trễ), giảm kích thước phản hồi (phân trang, GraphQL, protobuf thay vì JSON), bật bộ nhớ cache qua tiêu đề HTTP (Cache-Control), sử dụng OkHttp Interceptor để thêm thời gian chờ và logic thử lại.

Firebase Performance hiển thị phân bổ thời gian yêu cầu: phân giải DNS, bắt tay TCP, bắt tay TLS, gửi yêu cầu, nhận phản hồi. Nếu phần lớn thời gian dành cho DNS — hãy sử dụng tải trước DNS (OkHttp DNS-over-HTTPS). Nếu cho TLS — sử dụng tiếp tục phiên và điều chỉnh bộ mã hóa. Nếu cho nhận phản hồi — kiểm tra kích thước phản hồi và tốc độ mạng của người dùng. Dữ liệu Firebase cho phép xác định vấn đề ở cấp độ giao thức, thay vì chỉ nói “yêu cầu chậm”.

Tích hợp Remote Config để tắt theo dõi

Đối với sản xuất, nên thêm cờ Remote Config performance_tracing_enabled, cho phép từ xa tắt các trace tùy chỉnh. Nếu Firebase Performance SDK phía máy khách tạo quá nhiều dữ liệu hoặc ảnh hưởng đến hiệu suất (trên các thiết bị yếu), bạn có thể tắt trace cho tất cả người dùng, chỉ để lại các chỉ số tự động, vốn có chi phí tối thiểu.

Ví dụ logic: khi khởi động ứng dụng, hãy kiểm tra tham số Remote Config performance_tracing_enabled. Nếu false — tất cả các lệnh gọi đến Firebase.performance.newTrace() trả về một đối tượng giả không thu thập dữ liệu. Điều này được thực hiện thông qua một lớp wrapper kiểm tra cờ trước khi tạo trace. Cách tiếp cận này cho phép bật theo dõi chi tiết cho những người dùng cụ thể (người thử nghiệm beta, nhà phát triển) mà không ảnh hưởng đến toàn bộ khán giả.