Hiệu suất App iOS: Intruments và còn hơn thế nữa

64

Người sử dụng không thích chờ đợi. Họ không (và không nên) quan tâm về ứng dụng cần gì thì mới khởi chạy, họ chỉ quan tâm đến việc hoàn thành công việc của mình càng nhanh càng tốt. Vì vậy, app của bạn phải khởi động gần như ngay lập tức và giao diện phải “mượt như bơ”. Trong thị trường phần mềm ngày càng cạnh tranh, hiệu suất ứng dụng là một trong những ưu thế chính.

Đối với 1 lập trình viên, chúng ta luôn muốn cảm thấy tự hào về ứng dụng mình làm ra. Tuy nhiên, việc tối đa hóa hiệu suất khá rắc rồi. Đa số vấn đề làm ứng dụng chạy chậm trông có vẻ khá “phi lý”. Vì vậy, nếu thiếu công cụ đo lường thích hợp, bạn khó lòng nhận ra nguyên nhân làm ứng dụng chạy chậm. Theo đó, quyết định của bạn phải dựa trên dữ liệu chi tiết. Trong bài viết này, tôi sẽ hướng dẫn bạn cách lấy dữ liệu này thông qua việc tính toán hiệu suất của ứng dụng trên nhiều phương diện. Cụ thể, các phương diện đó là:

  • CPU, GPU, bộ nhớ và & mức tiêu thụ năng lượng của ứng dụng
  • Khả năng phản hồi
  • Thời gian khởi động
  • Số liệu hiệu năng thu được từ người dùng

CPU, GPU, Bộ nhớ và Năng lượng khả dụng

Đầu tiên, bạn cần kiểm tra ứng dụng để tìm code kém hiệu quả, sử dụng CPU, GPU hoặc bộ nhớ quá mức cho phép. Apple cho ta 1 công cụ tuyệt vời để thực hiện điều này là: Instruments.Trong đó có 4 phương diện chính cần lưu ý:

  • CPU (công cụ “Time Profiler”);
  • GPU (công cụ “Core Animation”);
  • Bộ nhớ khả dụng (công cụ “Allocations”);
  • Năng lượng khả dụng (công cụ “Energy diagnostics”)

instrument

Để hiểu thêm về cách dùng Instruments lấy thông tin ứng dụng, các bạn có thể tìm xem các video của WWDC.Bạn có thể bắt đầu với một số video dưới đây:
  1. Learning Instruments;
  2. iOS Performance 1, 2, 3;
  3. Improving your app with Instruments;
  4. Advanced Graphics & Animations for iOS Apps;
  5. Profiling In-Depth;;
  6. Cocoa Touch Best Practices;
  7. iOS Performance and Power Optimization with Instruments;;
  8. Polishing Your App..
Khả năng phản hồi
Tiếp đến, cần chú ý đến khả năng phản hồi của UI, đặc biệt là khả năng xử lý cảm ứng trong main thread (luồng chính). Khi thao tác tại đây mất quá nhiều thời gian, ứng dụng của bạn đang chạy chậm. Một số thao tác, ngay cả khi không dùng CPU, vẫn mất kha khá thời gian. Nếu có nhiều call đồng bộ trong luồng chính, hãy tính toán thời gian mà các call này “ngốn mất”. Bạn có thể sử dụng logs để tính toán.
Các lập trình viên của Viber cũng có giới thiệu cách tính khác. Họ có một luồng đặc biệt theo dõi luồng chính, đảm bảo thời gian bị block không quá 0.4s.
thread
222
Bạn có thể tìm thêm thông tin trong bài thuyết trình (PDF, 7MB).
Sử dụng dữ liệu này để xác định các call tốn nhiều thời gian (0.4s giây là 1 ngưỡng vừa đủ, bạn có thể đọc thêm quyển sách này để tìm thêm thông tin) và tối ưu hóa chúng hoặc bỏ ra khỏi luồng chính
Thời gian khởi động
Tiếp theo, bạn cần đánh giá thời gian khởi động của ứng dụng. Thông thường, người dụng chỉ dành vài phút để sử dụng ứng dụng nên thời gian khởi động quá lâu sẽ làm người dùng khó chịu.Có 2 trường hợp khởi động app:
  • Khởi động lạnh: process của ứng dụng không chạy, lúc này đang được OS khởi động
  • Khởi động nguội: ứng dụng bị minimize nhưng chưa tắt hoàn toàn, lúc này đang được khôi phục từ background.
Phần này dành cho khởi động lạnh vì đây là thao tác tốn khá nhiều tài nguyên.Dưới đây là quy trình khởi động của app iOS.
33
1. Tính toán tổng thời gian dùng để khởi động:
Chúng ta nên tính toán thời gian giữa lúc bắt đầu main() đến lúc kết thúc của applicationDidBecomeActive:

Chú ý rằng khoảng thời gian này sẽ không kéo dài ngay cả khi bạn giới thiệu tính năng mới. Hãy Cố giữ thời gian khởi động lạnh dưới 1 giây.

2. Tính toán thời gian cho từng bước trong quy trình khởi động:
Không chỉ cần phải biết đến thời gian để khởi động, bạn cần biết được bước nào trong quy trình khởi động khiến app bị chậm.Các bước quan trọng nhất cần kiểm tra là:
  • -[AppDelegate application:didFinishLaunchingWithOptions:] — callback này được gọi khi hình ảnh khởi động (hoặc storyboard) hiển thị. Ngay khi app của bạn trở về từ method này, UI thực sự sẽ bắt đầu tải
  • -[UIViewController loadView] — nếu app của bạn tải 1 giao diện tùy chỉnh, đây là nơi giao diện khởi đầu
  • -[UIViewController viewDidLoad] — giao diện được tải; đến đây là bước khởi tạo cuối cùng
  • -[AppDelegate applicationDidBecomeActive:]— UI đã được khởi tạo, nhưng nó vẫn còn bị block cho đến khi callback này kết thúc. Method này cũng được call khi app phục hồi từ background
Nếu có method tốn quá nhiều thời gian, hãy tối ưu hóa nó.
3. Ước lượng thời gian khởi động “dưới áp lực”
Có một sự khác biệt lớn giữa thực tế và môi trường thử nghiệm điển hình. Trong thực tế, ứng dụng không bao giờ chạy riêng một mình nó.Người sử dụng thường chuyển đến app của bạn từ 1 app khác.
“App khác” đó có thể rất nặng.
Vì vậy việc tính toán thời gian khởi động rất quan trọng, đặc biệt trong điều kiện ứng dụng của bạn khởi động song song với hoạt động lưu trữ dữ liệu vào background của một ứng dụng khác. Việc kiểm tra đó có thể chỉ ra kết quả không ngờ được. Code, vốn hoàn toàn vô hại trước đó, có thể làm chậm app của bạn trong những điều kiện này.
4. App đã khởi động nhưng chưa dùng được
Nếu ứng dụng không dùng được, ngay cả khi đã tải UI, quá trình khởi động vẫn chưa thật sự kết thúc đâu. Dù cho UI đã tải và phản hồi, nhưng vẫn còn1 số dữ liệu cần load trước khi sử dụng được, bước này cũng tính vào quá trình khởi động.
Số liệu hiệu suất thu được từ người dùng
Bạn hoàn toàn có thể thu được tất cả các số liệu bên trên trong môi trường thử nghiệm. Chúng cần thiết, nhưng vẫn chưa đủ. Nếu ứng dụng của bạn nổi tiếng, lượng người dùng của bạn phân phối khắp toàn cầu, một số người dùng có thể có môi trường hoàn toàn khác biệt với những gì bạn dự đoán.Những điểm khác biệt đó có thể là:
  • Tốc độ kết nối;
  • phần cứng;
  • phần mềm (bản OS, Jailbreak…);
  • dung lượng bộ nhớ trống của thiết bị;
  • khác
Họ cũng có thể sử dụng app theo những cách khác nhau.Bạn có thể nhận review 1-sao với lời phàn nàn (“App của bạn quá chậm!”), thậm chí khi các số liệu bạn thu được trong thử nghiệm đều thuộc vùng an toàn.Khắc phục như thế nào?
Xác định 1 bộ số liệu về hiệu suất (KPI) và thu thập chúng từ người dùng thật. Bạn có thể sử dụng bất kì gói phân tích nào để làm điều này.Một số ví dụ về KPIs mà bạn có thể thu được từ người dùng:
  1. Tổng thời gian khởi động lạnh
  2. Tổng thời gian khởi động nguội
  3. Thời gian khởi động dành của từng giao đoạn cụ thể
  4. Thời gian dùng để download dữ liệu cần thiết từ server
  5. Số lần khi main thread bị block >400ms
  6. Số lần cảnh báo bộ nhớ
  7. Số lượng của FOOMS.
  8. Thời gian thao tác khi UI bị block hoặc không sử dụng được
Các gói phân tích sẽ cho cho phép bạn phân phối các giá trị này vào từng segment, cùng loại thiết bị, quốc gia hoặc nhà mạng. Từ đây, ta có thể thấy được người dùng ứng dụng đang gặp phải vấn đề hiệu suất nào, và cách khắc phục.
Kết luận
Như bạn thấy, việc tính toán hiệu suất không chỉ dừng lại ở khâu khởi động Instruments.app, mà còn nhiều dữ liệu giá trị khác cần ta lưu ý.Một vài cách tính toán rất nhanh và dễ sử dụng, số khác lại cần nhiều thời gian, công sức hơn. Dẫu vậy, chúng đều giúp bạn theo dõi hiệu suất ứng dụng, từ đó tìm ra và giải quyết vấn đề, giúp ứng dụng đem lại trải nghiệm càng tuyệt vời hơn.
Nguồn: IDEA via techtalk via medium