Tự động hóa ảnh chụp màn hình: Hướng dẫn tài nguyên đầy đủ

Một lần ra mắt ứng dụng di động điển hình phát hành 6–10 ảnh chụp màn hình mỗi kích thước thiết bị, trên 4–8 kích thước thiết bị, ở 8–20 ngôn ngữ. Phép toán nhanh chóng vượt khỏi tầm kiểm soát: một lần ra mắt nhỏ là 200–800 ảnh chụp màn hình, và một lần ra mắt đa ngôn ngữ lớn có thể dễ dàng vượt 2.000. Phiên bản đầu tiên mất một tuần thiết kế. Phiên bản thứ năm, sau khi tiếp thị đã lặp trên các chú thích, cũng mất một tuần thiết kế. Có một điểm rõ ràng tại đó bất kỳ đội nào với tốc độ sản phẩm tích cực ngừng có thể theo kịp thủ công.

Tự động hóa là lối thoát duy nhất. Khi bạn có thể kết xuất toàn bộ lưới theo chương trình, bạn đánh đổi một tuần thiết kế mỗi lần phát hành lấy một công việc CI chạy trong 90 giây. Đó là điều mở khóa vòng lặp tốc độ cao nơi bạn phát hành các thay đổi UI và cập nhật store trong cùng một bản phát hành — thay vì để các ảnh chụp màn hình store vĩnh viễn tụt sau ứng dụng đang chạy một quý hoặc hơn.

Một pipeline trưởng thành có bốn thành phần chuyển động: nguồn sự thật được phiên bản hóa (định nghĩa mẫu trong Git, thường là YAML hoặc JSON), một lớp dữ liệu (các chuỗi, ảnh chụp màn hình và hình ảnh sản phẩm điền vào mẫu), một engine kết xuất (dịch vụ biến mẫu + dữ liệu thành đầu ra PNG/JPEG ở mọi kích thước cần thiết), và một đích giao hàng (App Store Connect API, Google Play Publishing API, hoặc một bucket tài sản mà đội trang giới thiệu store của bạn lấy từ đó). Mỗi lớp có thể được hoán đổi độc lập.

Các lựa chọn thiết kế thú vị xuất hiện ở các điểm nối. Bạn phiên bản hóa mẫu như thế nào? Bạn check đầu ra đã kết xuất vào repo hay tái tạo trên mỗi lần chạy CI? Bạn cache các lượt kết xuất theo hash nội dung không? Bạn xem trước thay đổi trong xét duyệt PR mà không khởi sinh một pipeline đầy đủ như thế nào? Các liên kết bên dưới đề cập từng cái này một cách sâu sắc.

Có hai phe kiến trúc trong tự động hóa ảnh chụp màn hình: dịch vụ kết xuất API lấy đặc tả mẫu và tạo đầu ra qua một engine kết xuất được quản lý, và pipeline trình duyệt headless tự xây (Puppeteer, Playwright, Cypress) chụp một trang web và xử lý hậu kết quả. Cả hai đều hoạt động; các đánh đổi là thực sự.

Pipeline trình duyệt headless linh hoạt nhưng nặng về vận hành: bạn duy trì một trang trại trình duyệt, một câu chuyện quản lý font, font dự phòng cho mọi ngôn ngữ, logic thử lại cho các lượt kết xuất thiếu ổn định và một hàng đợi. Kết xuất API chuyển toàn bộ điều đó cho một dịch vụ được tinh chỉnh cho trường hợp sử dụng ảnh chụp màn hình cụ thể. Đối với hầu hết các đội, kết xuất API nhanh hơn để thiết lập và nhanh hơn trên mỗi lượt kết xuất; trình duyệt headless là lựa chọn đúng khi ảnh chụp màn hình của bạn bao gồm các tính năng DOM hoặc CSS nặng mà một engine mẫu không thể đáp ứng.

fastlane đã là toolchain tự động hóa iOS thực tế trong hơn một thập kỷ và nó có hai lane liên quan cho ảnh chụp màn hình: action snapshot tích hợp sẵn (sử dụng XCUITests để chụp ảnh từ một simulator) và frameit (bao bọc các ảnh chụp đã ghi trong khung thiết bị). Đối với các thử nghiệm dựa trên simulator, điều này vẫn hoạt động, nhưng có hạn chế: ngữ pháp thiết kế được quyết định bởi những gì ứng dụng của bạn có thể kết xuất trong một UITest tự động, không phải bởi những gì đội tiếp thị của bạn muốn phát hành, và ngôn ngữ mẫu của frameit bị giới hạn.

Mẫu hiện đại là sử dụng fastlane làm bộ điều phối (tải lên App Store Connect, tăng phiên bản, phân phối TestFlight) và một dịch vụ kết xuất API như Screenshots.live làm nhà sản xuất các tệp ảnh chụp màn hình thực sự. fastlane có hỗ trợ plugin hạng nhất, do đó bạn có thể đặt một plugin ảnh chụp màn hình kết xuất và tải lên trong cùng một lane.

Ba mẫu hợp lý. (1) Trên mỗi push tới main: bạn tái tạo ảnh chụp màn hình một cách suy đoán, lưu chúng làm artifact build và chỉ thăng cấp chúng trên các thẻ phát hành. Phản hồi nhanh, hơi lãng phí. (2) Chỉ trên các thẻ phát hành: sạch nhất, nhưng bạn chỉ bắt được hồi quy ảnh chụp màn hình sau khi phiên bản đã bị khóa. (3) Trên một workflow chỉ ảnh chụp màn hình kích hoạt khi các tệp mẫu thay đổi: tốt nhất cho các đội có sự phân tách mạnh giữa kỹ thuật sản phẩm và tăng trưởng.

Bất kể bạn chọn mẫu nào, hãy đối xử với các tệp ảnh chụp màn hình như bất kỳ artifact được tạo ra nào khác: đừng check chúng vào Git. Nguồn sự thật sống trong các mẫu, không phải trong PNG đã kết xuất. Đây là sai lầm lớn nhất mà các đội mắc phải khi gắn tự động hóa ảnh chụp màn hình lên một repo hiện có.

Một pipeline tự động hóa hiện đại nên bao gồm kiểm tra diff điểm ảnh hoặc hash cảm nhận trên đầu ra đã kết xuất. Mục tiêu là bắt được sự cố thầm lặng: một font đã rơi xuống dự phòng, một bản dịch tràn ra, một tài sản hình ảnh trả về 404. Các công cụ như BackstopJS, Percy và Chromatic có thể được tái sử dụng cho ảnh chụp màn hình store, hoặc bạn có thể viết một công việc diff nhỏ thất bại CI khi một lượt kết xuất vượt ngưỡng.

Đây cũng là nơi tự động hóa đa ngôn ngữ trở nên thú vị: kết xuất 60 ảnh chụp màn hình thì ổn, nhưng xem xét 60 cái thủ công cho tràn văn bản là không thể. Kiểm tra trực quan tự động là điều khiến tự động hóa đa ngôn ngữ thực sự an toàn ở quy mô lớn.