iPhone không phát tiếng ứng dụng web: chuyện nút gạt im lặng và cú chạm đầu tiên

Bản đầu tiên của các ứng dụng AppGiaiTri có âm thanh rất đầy đủ: tiếng động cơ máy bay đổi cao độ theo tốc độ, tiếng bóng chạm mặt vợt, tiếng đám đông khi ghi điểm, nhạc nền đổi theo tình huống. Trên máy tính, trên điện thoại Android, tất cả kêu đúng. Rồi một người dùng thử trên iPhone nhắn lại một câu ngắn: “Sao không có tiếng gì hết vậy?”. Bài này kể lại chúng tôi đã sai ở đâu và sửa thế nào — kể cả chỗ đến giờ vẫn là thoả hiệp.

Cái sai đầu tiên: thử trên máy mình thay vì máy người dùng

Nói thẳng: lỗi này lẽ ra phải bị bắt trước khi ai đó phải nhắn tin. Trong giai đoạn dựng, chúng tôi kiểm tra bằng trình duyệt trên máy tính và một trình duyệt chạy tự động không có màn hình. Cả hai đều phát âm thanh vô tư, vì chúng không áp những luật mà Safari trên iPhone áp. Chúng tôi đã nhầm “không lỗi trên máy thử” với “không lỗi”. Hai chuyện đó khác nhau, và khác nhau nhiều nhất đúng ở iPhone.

Âm thanh trong các ứng dụng của chúng tôi không đến từ tệp nhạc tải về. Mọi tiếng động đều được tổng hợp ngay trên máy bằng bộ xử lý âm thanh của trình duyệt (Web Audio): vài bộ dao động, vài bộ chỉnh âm lượng, ghép lại thành tiếng nổ, tiếng vợt, vòng hợp âm nền. Cách này giúp ứng dụng nhẹ, không phải tải hàng megabyte tệp âm thanh, nhưng nó đặt toàn bộ gánh nặng vào một đối tượng duy nhất gọi là “ngữ cảnh âm thanh”. Nếu ngữ cảnh đó không chạy, không có gì kêu cả.

Hai bức tường khác nhau, cùng một triệu chứng

Mất một lúc chúng tôi mới nhận ra người dùng đang gặp hai lỗi khác nhau, cùng biểu hiện là “câm”:

Cái thứ hai gây bối rối nhất: video ở ứng dụng khác vẫn kêu, sang ứng dụng của chúng tôi thì im, nên người dùng kết luận ứng dụng hỏng. Họ không sai.

Bức tường thứ nhất: không phải cú chạm nào cũng được tính

Safari chỉ cho một trang web bắt đầu phát tiếng khi việc đó xảy ra bên trong một thao tác của người dùng. Cái chúng tôi không biết — và mất thời gian nhất — là không phải sự kiện chạm nào cũng được Safari coi là thao tác của người dùng.

Bản đầu của chúng tôi mở khoá âm thanh ở sự kiện “ngón tay vừa chạm xuống” trên khung vẽ, vì đó là sự kiện mà phần điều khiển vốn đã lắng nghe. Trên Chrome, như thế là đủ. Trên Safari, sự kiện chạm xuống đó không được tính. Những sự kiện được tính là: bấm (click), nhấc ngón tay lên (touchend) và nhấn phím. Nghĩa là mã mở khoá của chúng tôi vẫn chạy, không báo lỗi gì, chỉ là ngữ cảnh âm thanh cứ nằm yên ở trạng thái “tạm dừng”.

Lỗi thứ hai trong cùng chỗ đó: menu chính, nút “Vào sân”, nút chọn màn — đều là nút giao diện thường, nằm ngoài khung vẽ. Người dùng bấm “Vào sân” là thao tác rõ ràng nhất, nhưng mã mở khoá chỉ gắn vào khung vẽ nên không bao giờ nghe thấy cú bấm đó.

Và lỗi thứ ba, ít ai để ý: nhạc nền của màn menu được gọi phát trước khi người dùng chạm bất cứ đâu. Lời gọi đó thất bại trong im lặng, và vì không ai gọi lại, nhạc nền không bao giờ lên — kể cả sau khi âm thanh đã được mở khoá.

Bức tường thứ hai: nút gạt im lặng

iPhone chia âm thanh thành hai loại. Loại “phát nội dung” như nhạc, video, podcast vẫn kêu khi gạt im lặng. Loại “âm báo, hiệu ứng” thì bị tắt theo nút gạt. Âm thanh tổng hợp của trình duyệt mặc định bị xếp vào loại thứ hai. Vậy nên với một người để máy im lặng cả ngày — rất nhiều người đi làm như vậy — ứng dụng của chúng tôi câm vĩnh viễn, không có cách nào bật lên từ bên trong ứng dụng.

Cách chúng tôi sửa, từng lớp một

Bản sửa nằm trong phần lõi dùng chung của cả năm ứng dụng, nên sửa một chỗ là cả năm cùng được. Ứng dụng Thỏ Dâu cho bé có mã riêng nên được sửa riêng, trong cùng ngày. Bản sửa gồm năm lớp, mỗi lớp chặn một đường hỏng:

1. Nghe mọi thao tác hợp lệ trên toàn trang, không chỉ trên khung vẽ. Cứ có một cú bấm, một lần nhấc ngón tay hay một lần nhấn phím ở bất kỳ đâu — kể cả nút menu — là thử mở khoá. Lắng nghe ở tầng sớm nhất để không bị phần khác của trang chặn mất.
2. Khai báo phiên âm thanh là “phát nội dung”. Các bản Safari mới cho trang web tự nhận âm thanh của mình thuộc loại phát nội dung. Khai báo xong, nút gạt im lặng không tắt tiếng ứng dụng nữa. Một dòng mã, nhưng là dòng giải quyết cái lỗi khó chịu nhất.
3. Dự phòng cho Safari cũ: ngay lần chạm đầu, phát lặp một đoạn âm thanh im lặng qua thẻ phát âm thanh thông thường. Việc này đẩy trang sang kênh phát nội dung trên những máy chưa hiểu cách khai báo ở lớp hai.
4. Phát một mẫu âm thanh rỗng dài đúng một điểm dữ liệu ngay trong thao tác mở khoá, để “đánh thức” ngữ cảnh âm thanh.
5. Nhạc nền biết chờ. Nếu có lời gọi phát nhạc khi âm thanh chưa sẵn sàng, bản nhạc được ghi vào hàng chờ thay vì bị bỏ. Khi ngữ cảnh chạy, nhạc tự lên. Thoát ứng dụng hay chuyển màn khác thì hàng chờ bị xoá, tránh chuyện nhạc cũ bất ngờ vang lên sau đó.

Thêm một chi tiết nhỏ: khi người dùng chuyển sang ứng dụng khác, chúng tôi tạm dừng âm thanh; khi quay lại thì tiếp tục. Bản đầu có viết đoạn này, nhưng lời gọi “tiếp tục” đôi khi bị Safari từ chối và ném lỗi ra ngoài. Giờ nó được bắt lại và thử lại ở lần chạm kế tiếp, thay vì làm hỏng luôn phần còn lại.

Những gì chúng tôi học được

Không lỗi không có nghĩa là chạy được

Điều nguy hiểm nhất của lỗi âm thanh trên iPhone là nó không để lại dấu vết. Không có thông báo lỗi, không có dòng đỏ nào trong nhật ký. Mã chạy trọn vẹn, chỉ là không có tiếng. Kiểm tra tự động nhìn vào nhật ký lỗi sẽ cho điểm tuyệt đối. Từ đó chúng tôi thêm một bước kiểm vào quy trình: sau mỗi lần sửa phần âm thanh, phải có người cầm iPhone thật, gạt nút im lặng, mở ứng dụng từ đầu, bấm nút menu đầu tiên và nghe.

Mọi quyết định có cái giá của nó

Khai báo “phát nội dung” nghĩa là ứng dụng vẫn kêu khi máy để im lặng. Có người sẽ thấy điều đó phiền: họ gạt im lặng chính vì không muốn điện thoại phát ra tiếng. Chúng tôi chọn như vậy vì với ứng dụng giải trí, người dùng mở ra là đang chủ động muốn trải nghiệm, và âm thanh là một nửa cảm giác. Nhưng để bù lại, hai thanh chỉnh âm thanh và nhạc trong phần cài đặt của mỗi ứng dụng luôn nằm ở chỗ dễ thấy, và được ghi nhớ cho những lần sau. Người muốn im lặng kéo về không là xong, và ứng dụng tôn trọng lựa chọn đó.

Viết cho trình duyệt khó tính nhất trước

Chrome dễ dãi, Safari trên iPhone khó tính. Viết cho Chrome rồi “vá cho Safari” thì vá mãi không hết; viết cho Safari trước thì Chrome gần như tự chạy. Lỗi nhấn giữ bị bôi xanh cả trang mà chúng tôi gặp sau đó cũng đến từ đúng thói quen xấu này.

Nếu bạn vẫn không nghe thấy gì

Nếu sau bản sửa mà máy bạn vẫn câm, hãy kiểm tra mấy khả năng sau:

• Máy đang giữ bản cũ. Ứng dụng web cất sẵn tệp trên máy để chạy khi mất mạng, nên có thể còn dùng bản trước khi sửa. Đóng hẳn ứng dụng rồi mở lại một lần là nhận bản mới.
• Chưa chạm lần nào. Màn hình đầu tiên có thể im lặng cho đến cú chạm đầu tiên — đó là luật của Safari, không ứng dụng web nào vượt qua được.
• Thanh âm lượng trong ứng dụng đang ở mức không, do lần trước tự kéo xuống.

Chúng tôi kể chuyện này không phải để khoe đã sửa xong. Chúng tôi kể vì nó cho thấy “làm xong” và “người dùng dùng được” cách nhau xa thế nào, và vì mỗi ứng dụng mới trong AppGiaiTri — từ Giao Đấu đến Không Chiến — giờ đều được thừa hưởng bản sửa này từ ngày đầu, thay vì phải dẫm lại vào đúng chỗ đó.