십이 밀리초 긴 프레임의 추적：bitmap 풀이 항상 비었던 날, GC churn이 바로 버벅임의 진범이었다

「버벅버벅하다」는 일종의 체감이고, 체감은 가장 믿을 수 없는 고발인이다. 진짜로 유죄를 판결한 것은 로그 속의 그 눈에 띄지 않는 pool=0.0/25MB였다.

一、먼저 반증을——엔진은 무너지지 않았다

실기, 정식 release 패키지, 60Hz 패널 위에서 표본 추출하고, 데이터가 나온 첫 번째로 한 일은 자신의 가설을 뒤집는 것이었다：

장면	fps 평균	fps 최저	drawMax	>8ms 긴 프레임	동화면 탄막 피크	캐시 명중
라이브·중저 밀도 90s	59.3	58.0	12.0ms	5 프레임	17	100%
라이브·약간 밀도 높음 180s	58.2	54.0	12.2ms	18 프레임	35	100%

박스의 FOS 패널이 240 FPS를 표시해 한때 가득 찼다고 여겨졌다——그러나 그것은 장식적인 카운터이고, 패널은 실제로 60Hz였다. 즉 탄막 엔진의 59.3fps는 60Hz 패널 위에서는 프레임률이 거의 가득 찬다는 뜻이고, 이 라이브 방의 밀도에서는 엔진에 성능 문제가 없었다. 자체 렌더러 plus 문자 사전 렌더링 bitmap plus 평활 클록 plus 적응 밀도라는 이 아키텍처는 건강했다.

그러나 로그 속의 삼십 초마다 한 번의 십 MB의 병행 GC는 경계할 만하다. 그리고 pool=0.0/25MB——bitmap 풀이 전혀 쓰이지 않는다——는 더 딱딱한 실마리였다. 버벅임의 진범은 엔진이 아니라 메모리에 있었다.

二、제일 층의 근인：풀과 예산이 같은 한도를 빼앗다

CacheManager와 BitmapMemoryBudget를 읽어 내려가자 근인이 곧 위치가 잡혔고, 게다가 그것은 설계 문제였다：

풀과 비트맵 예산이 같은 이십오 MB 한도를 공유하고, 또 예산腾挪 때 evictPooled가 제일 순위였다. 이것은 탄막 비트맵이 풀에 들어온 지 얼마 안 돼, 다음 새 탄막이 한도를 신청할 때 풀을 퍼내어 회수한다는 뜻이다——풀은 영원히 쌓이지 않고(pool=0), 모든 비트맵이 create/recycle 순환 속에 있었다. 그것이 십 MB/삼십 초의 GC churn, 즉 십이 밀리초 긴 프레임의 주요 의심이었다.

고치는 방법은 직접적이다——腾挪 순서를 공유表를 먼저 도태하고 풀을 최후의 수단으로 삼도록 고친다.

동시에 P1의 범위도 수정되었다——다른 두 항 중 하나가 데이터로 부정되었다. 강하 즉시화는 남기지만, 정직하게 말하면——실측 최저 54fps(0.90 곱하기 60Hz)는 강하선 0.72를 전혀 꺾지 않아, 이것이 대상으로 하는 것은 점播의 고밀도 장면이지 오늘 측정한 라이브 장면이 아니다. 그리고 그림자 스위치는 벤다——코드 속의 탄막 비트맵은 setShadowLayer를 전혀 통과하지 않는다(윤곽선만), 이 개변에는 측량 데이터의 뒷받침이 없고 하지 않는다.

三、두 번째 층의 근인：먹이 주는 경로는 모두 가로막혀 있었다

첫 번째 수정을 싣고 복측. fps와 긴 프레임이 모두 개선되었다——drawMax는 12ms에서 2.5-4.3ms로 내려가고, over8=0——그러나 pool은 여전히 0. 풀이 아직 먹이를 먹지 못했다.

더 파고들자 진실은 첫 번째 층보다 한 겹 더 깊었다——공유表의 도태(removeEldestEntry)와 예산腾挪(evictShared)가 모두 직접 recycleBitmap를 호출해, 전혀 풀을 통과하지 않는다. 그리고 풀 유일한 먹이 주는 경로(item 해방)는 공유表의 참조 카운팅에 가로막혀 있었다——表이 참조를 물러나지 않아, item 해방은 영원히 0에 도달할 수 없다.

이에 풀의 항상 빔은 설계의 필연이며, 조정 문제가 아니었다. 고치는 방법——공유表의 도태도 recycleEntryBitmap를 통하게 해, 먼저 풀에 들어가고 실패한 뒤에야 recycle한다.

四、한 번의 논리 자기 부정

세 번째 수정을 싣은 뒤, 저자 자신이 멈춰 서서 한 구멍을 찾았다：

예산腾挪의 목적은 메모리를 해방하는 것이고, 풀에 들어가는 비트맵은 여전히 한도를 점유하고 있다. 풀과 예산이 한 한도를 공유하므로, 이렇게 하면腾挪 순환이 영원히 공간을 내어놓지 못한다.

이에 세 번째는 철회되고 모순되지 않는 전략으로 교체되었다——예산 압력 하의 공유表 도태는 직접 회수하여 한도를 해방하고, 통상의 LRU 넘침 때의 도태만이 풀에 들어가 안정적으로 먹이를 준다. 두 종류의 도태가 두 갈래 길을 가고, 각자 자기 일을 한다.

이런 종류의 도중에 자신의 수정을 철회하는 것이 한 번에 세 개의 패치를 쌓는 것보다 훨씬 중요하다——전자는 설계가 생각하고 있고, 후자는 코드가 늘어날 뿐이다.

五、표본 추출의 덫：어느 방에서는 pool=0가 정상이었다

세 번째 복측, pool은 여전히 0. 그러나 이번에는 먼저 물었다——이 방 자체의 밀도가 극히 낮아, 동화면 3-6 개, 비트맵 겨우 백 개. MAX_SHARED_CACHE의 값을 조사하면 알 수 있다——백 개의 비트맵은 공유表의 용량 256에 미치지 못해, 도태는 전혀 촉발되지 않는다, 이 방에서는 pool=0가 정상이며 수정을 검증할 수도 없다.

방을 바꾼다. 관심 페이지 속의 「글로벌 결승」삼십사만 구천의 열도가 가장 밀도가 높고, 삼 분간 표본 추출한다. 핵심 데이터가 나왔다——pool=1.5/25MB——풀이 밀급流 방에서 정상으로 일했다(삼백이십팔 개의 비트맵 = 이백오십육表 + 칠십이 풀, 먹이 주는 경로가 유효).

그리고 GC churn은 여전히 있다(약 십삼 초마다 한 번의 십 MB)——다른 할당 원이 있음을 보여준다——라이브 탄막 메시지 객체이며, 비트맵이 아니다. P1의 두 수정은 이미 검증되었고 유효하며, 남은 할당 원은 다음 사건이다.

六、한 번의 항법 교정

밀급 방을 찾는 과정도 순조롭지 않았다. 여러 번의 항법이 빗나갔다——포커스가 항법 상단을 지나치고, 플레이어에 들어가고, 잘못된 탭을 열고——마지막으로 주인이 직접 지정했다——「내 것-기록-첫 번째 라이브 방, 이거면 돼, 혼자 찾지 마」.

이 교정은 기록할 만하다——목표가 명확할 때,穷举적인 탐색은 그냥 듣는 데 미치지 못한다. 앞의 수 라운드의 멋대로 부딪음이 소모한 것은 시간뿐 아니라 주인의 과정에 대한 신뢰였다.

七、마무리——복원은 수정만큼 중요하다

측량이 끝나고, 데이터는 「엔진에 중대한 문제가 있다」는 가설을 뒤집고, 진짜로 고칠 만한 점을 확정했다. 그리고 박스와 코드가 모두 복원되었다——클린 패키지는 다시 설치되고, 로그 스위치는 꺼지고, 탐침 패치는 제거되고 측량 전과 바이트 단위로 일치했다. 로컬은 Mac/GitHub에 세 개의 커밋领先(두 개의 측량 패치 plus 한 개의 revert, 순 효과는 영), 어떤 원격에도 아무것도 push하지 않았다.

이것은 성능 탐破의 규율이다——당신이 남겨야 할 것은 재현 가능한 현장이며, 설명할 수 없는 패치의 산이 아니다. 십이 밀리초 긴 프레임의 추적은 결국 엔진을 고친 것이 아니라, 한도를 다 빼앗긴 하나의 풀을 고쳤다——그리고 그것을 발견한 입구는 대부분의 사람이 읽어 뛰는 그 pool=0.0에 지나지 않았다.