JIGGAG

2월 한달동안 로그

2023년 3월 1일

2월 한달동안

  • 2월이 너무 짧았다
  • 아쉬운점
    • 지난 1월의 개선할 점으로 건강관리에 신경썼더니 자투리 공부를 신경쓰지 못했다
      • 하나만 되고 둘은 안되는 슬픈 상황이지만 🙈
      • 연휴가 있던 지난달에 비해 이번달은 휴일이 적어서 그런 것 같은 느낌
  • 잘한점
    • 루틴은 계속 이어가고 있다
    • 무리한 목표 보다는 소박하지만 계속 이어갈 수 있는 목표로 조금 수정했던 것이 효과가 있었다
  • 개선할점
    • 연휴가 있어야만 시간을 투자할 수 있는건 아니니 나몰라 했던 시간들을 돌아봐야겠다
    • 합리화는 안했지만(이게 합리화인가) 소박하게 잡았던 목표들을 조금 더 소박하게 추가해본다
    • 연간 목표로 잡았던 인문학은 아직 소식이 없는데, 당근과 당근 전략을 시작해본다

반품합니다

  • 바퀴를 새로 만드는게 우리가 필요한 모양대로 더 이쁘게 잘 굴러갈 것이다
  • 이런 마음으로 시작한 바퀴의 재발명
    • 이쁘게 꾸미고 둥글둥글 잘 굴러간다
    • 그리고 기존 바퀴를 대체하는 순간
    • 별로 나아지지 않았거나 오히려 안좋은 것을 느낀다
  • 바퀴를 만들다보면 대부분은 기존 바퀴 보다 차이가 없거나 더 나빠졌을 것이다
    • 맞습니당 🙈
  • 더 좋아지기를 기대하고 만들었으나
    • 일부 좋아진 부분이 있긴 하지만
    • 나빠진 부분이 더 많다는 사실
  • 반품요청

렌더링 개선

  • 참고: 렌더링 성능 개선(2) — 합성 애니메이션 사용
  • 웹 성능 최적화는 가장 빠른 렌더링 패스를 구현하는 것이 아니다.
    • 내가 실패한 이유인 것 같다
    • 렌더링 과정은 전적으로 브라우저에서 진행되는 것으로, 렌더링 과정 자체를 개선할 수는 없다.
    • 성능 ‘개선’의 접근 방식은 렌더링 과정 자체의 개선이 아니라 과정 중 병목이 생기는 구간을 줄이는 전략으로 접근해야 한다.
  • 내가 시도한 방법은 렌더링을 빠르게 하기 위해 각 컴포넌트의 렌더 타임을 분할했다
    • 근데 그건 해결 방법이 아니라 문제가 되는 시점을 1에서 n으로 보내버린 것 같다
    • 하지만 여기서 발생한 문제로 시점을 분할해서 미뤄버렸으니 병목이 어디에 가있을지 모른다는 것이다
    • 병목이 생기는 구간을 잘게 쪼개어 분할한건 맞는 것 같은데 그럼에도 왜 실패했을까?
  • 글에서 이야기 하는 것처럼
    • 메인스레드 점유율을 낮추고자 reanimated를 최대한 사용하여 UI스레드로 분리하였다
    • 그럼에도 메인스레드가 터지는 이유는?
    • 그냥 단순 요청이 많아서?
  • 과도한 레이어 사용은 오히려 레이어 합성의 오버헤드로 인해 병목이 생길 수 있다
  • 불필요한 리렌더가 발생하는 것들을 프로파일링을 통해 최소화했다
    • 그럼에도 초기 마운트가 느린 것은 요청이 많기 때문이라 생각해서 타임을 분할한 것인데...
    • 이걸로 부족한 것은 왜일까
  • UI스레드와 메인스레드 분할해둔 것은 잘 동작했다
  • 하지만 메인스레드로 수많은 렌더 요청이 들어가면 UI스레드가 씹혔다
    • 이게 문제였던 것 같다
      • 렌더링 개선을 통해 애니메이션은 애니메이션대로 빠르게 보여주고자 했던 것인데
      • 여전히 애니메이션이 씹혔기 때문에 사용자 경험은 전혀 속도가 빨라 보이지 않았다
  • 렌더링, 애니메이션 하면 항상 따라오는
    • 리페인트 없이 합성만 하는 애니메니션을 사용하는 것 🤔
  • 리플로우를 없애고 리페인트만을 하도록 했는데, 이제 리페인트도 없애야만 한다
    • 리플로우 <<< 리페인트 <<< 컴포지션
    • 애니메이션이 필요한 경우 position: absolute로 다른 컴포넌트의 리플로우/리페인트를 최소화
  • 전에 봤던 렌더링 최적화 블로그 공유: [React] 성능최적화 3편 - 애니메이션 최적화(feat. 리플로우,리페인트,CSS)

fabric + swift

  • 기존 프로젝트는 swift로 되어있다
  • 하지만 나는 fabric을 적용하고 싶다
  • 방법은 swift를 모두 objc로 바꾸거나 fabric이 swift에서 동작하도록 설정하거나
    • 첫번째 방법 보다 아무리 생각해도 두번째 방법이 간단해보인다
  • AppDelegate랑 MainApplication만 어떻게 잘 해주면 될 것 같다
    • 여기서 어떻게 가 가장 중요한 부분인데
    • 이걸 알 수 없기에 길고 긴 죽쓰는 여정을 떠나본다
    • c++을 잘 알고 있다면 좀 더 짧은 여정이 될 수 있지만...
  • fabric 적용이 완료된 RNStarter@0.0.6 에서 맨땅에 벼락 헤딩 을 시작해본다
    • 이 프로젝트는 objc로 되어있기에 딱 좋은 환경이다
  • AppDelegate랑 MainApplication에서 sourceUrl까지는 수월하게 도달했다
    • 사실 무언가 하지는 않았다
    • 그냥 swift로 자연스럽게 변환했다
    • 그리고 빌드를 했다
    • 오????? 되는건가?????
    • 🥳
  • 그럴리없었다
    • window에 view를 띄우는건 성공했지만 여기까지는 네이티브 뷰이고
    • 그 안에 RN bundle이 떠야하는데 이게 되지 않는다
    • 분명 메트로도 연결이 되어있고 번들도 잘 만들어져있는데
  • 왜 뜨질 않는걸까?
    • 디버깅해보면 bundleURL이 잘 들어와있는 것을 확인했다
    • http://localhost:8081/index.bundle?platform=ios&dev=true&minify=false&modulesOnly=false&runModule=true&app=com.jiggag.rnstarter
  • 준비물은 다 있는데 서로 연결이 되지 않는다
    • c++로 구성된 주소와 내가 swift로 넘겨준 주소가 다를 수 있을까?
    • 서로 다른 곳을 바라보고 있으니 매칭이 되지 않는다라고 추측해보았다
    • 보내는 곳에서 받으려는 곳으로 통역이 필요할지도?

애자일을 설명하라

  • 애자일이 뭐야?
  • 전혀 다른 직군의 친구에게 애자일을 설명할 수 없었다
  • 알기 쉽게 설명해주고 싶었지만 입에서 나온 한마디는 방법론이야 였다
  • 그리고나서 내가 스스로에게 설명한다면? 질문을 해보았는데, 그마저도 대답할 수 없었다
  • 추상적인 느낌이라고 하지만 뜬구름을 둥둥 느낌이였다
  • 그건 제대로 이해하지 못했기 때문이다 (항상 그렇듯 이것은 데자뷰)
  • 스프린트, 사이클, 피드백... 이런 단어들이 둥둥 떠오르는데
  • 이걸 설명할 수 없던 것은 꼬리를 물고 그 단어들을 다시 물어본다면 이어서 설명해줄 자신이 없었기 때문이다
  • 그리고나서 며칠 뒤 읽은 책에서 우연히 이러한 상황을 의미하는 문장이 있었는데, 이걸 정리하면
  • 나에게 익숙한 단어들로 두루뭉실 설명하려고 했다
    • 하지만 그 단어들도 또 다른 익숙한 단어들로 포장할 수 밖에 없었다
  • 제대로 알고 있다는 것은 눈높이에 따라 적합한 설명을 할 수 있어야하는데...