_3rd.png&blockId=99d3a408-b1d6-4314-bea5-a5acbcf2236f)
_3rd.png&blockId=59dafd9b-cc30-4183-a1c0-c70061075888)
[이종원]
멘토링
•
프로젝트 진행과정
◦
앱 주제
▪
케이크
▪
비트코인과 같은 주식 거래 앱
▪
결제 서비스를 붙여보고싶음
•
현실적으로 힘들 수 있음 (사업자가 필요)
▪
이번주안에 앱주제의 우선순위를 정하는것이 좋을것 같아요!
•
안드로이드 멘토 하시는 종원님 
•
Swift
◦
Struct vs Class
◦
Struct에선 값을 변경하면 직접적인 변경되는 value 값을 가져옴
◦
Class에선 레퍼런스 (참조) 주소값
◦
값 vs 참조
▪
메모리 관리 > Class는 참조가 가능하니 강한참조가 되지 않게 신경써야함!
•
메모리 누수가 발생할 수 있음
•
한쪽만 참조하고 있으면? ARC에 의해 자동으로 메모리 관리가 가능한데 서로 참조 시 강한참조가 되어서 메모리 해제가 되지 않아 Retain Count (RC)가 늘어나기 때문에!
•
RC == 참조 계수
•
메모리 누수가 발생하면? 큰 기능이 아닌데도 불구하고 앱 속도 저하 & 메모리 부족으로 앱 꺼짐
•
weak vs unowned
◦
상속해야할게 아니라면 Struct를 써라
▪
상속? 부모의 것을 자식이 물려받아 사용할 수 있음
▪
Class > 자식이 물려받으면 재정의 하지 않아도 사용할 수 있음 (중복을 줄일 수 있음)
▪
다중 상속 불가능
•
A(부모) → B(자식) → C(손자) 일때 C가 A,B 둘다 상속
◦
test()
◦
test()
◦
test()
◦
복잡성 & 모호성을 방지하기 위해
▪
Struct를 사용해야 하는 다른 원인들?
•
View → struct
•
Class를 사용해야 할때
◦
상속을 해야할때
•
Struct을 사용해야 적절할때!
◦
간단한 값들에서 캡슐화할때
◦
상속이 필요 없을때
◦
참조가 아닌 복사가 적당할 때
▪
메모리 관점에서
•
Class는 어디에 저장될까!?
◦
힙영역
▪
Heap?
•
동적 할당될 수 있는 친구
•
메모리에 잡고있는 길이가 가변적이다
◦
Stack? (값 타입)
▪
정적 할당
▪
Int, Double
◦
값 타입은 메모리에서 Stack에만 저장되고 참조 타입은 Heap에만 저장돼! (X)
▪
참조 타입
•
0x00010100d (주소값) → Stack
▪
값 타입
•
String / Struct
•
스택에? 힙에 저장?
◦
스택?
◦
String > 가변적이죠?
▪
“a”, “abd”
▪
[’a], [’a’,b’,’c’]
▪
String > Array
◦
Collection 타입
▪
Dictionary
▪
Set
▪
Array
▪
String
▪
Collection은 Struct지만 heap 영역에 저장됨
•
가변적이기에 동적으로 할당
•
주소값은 Stack에 저장
import Foundation
var green: String = "green" // struct의 인스턴스
var copyGreen: String = green
// MARK: - Stack 메모리 영역 주소 출력하는 메서드
func printStackAddress(input: inout String) {
withUnsafePointer(to: &input) { pointer in
print("Stack address is \(pointer)")
}
}
// MARK: - Heap 메모리 영역 주소 출력하는 메서드
func printHeapAddress(address input: UnsafeRawPointer) {
print(String(format: "Heap address is %p", Int(bitPattern: input)))
}
copyGreen = "copyGreen"
printStackAddress(input: &green)
printHeapAddress(address: green)
print("🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻")
printStackAddress(input: ©Green)
printHeapAddress(address: copyGreen)
Swift
복사
•
SwiftUI는 Struct인데 왜 UIKit은 Class로 뷰를 드로잉하는데?
•
View를 Struct로 생성하는 이유
◦
성능이슈
◦
UIKit에서의 클래스 뷰
▪
다양한 기능들이 이미 담겨져있는 클래스의 서브 클래스
▪
UIView
▪
“Green” 간단한 뷰를 만들때도 그 안에 담긴 다양한 많은 속성이 딸려옴
▪
크기가 커지게되죠~
◦
선언형이고 기본 제공되는 다양한 모든 뷰 컴포넌트들이 작던 크던 구조체이기때문에 자유롭게 생성할 수 있음
◦
.frame / .foregroundColor (View Modifier)
◦
Text(”green”)
▪
상속대신 ViewModifier를 사용하도록!
▪
속성을 부여해서 새로운 뷰를 만듬
▪
뷰가 아주아주 가벼워진다
▪
참조를 생각해봅시다!
•
UIKit의 클래스로 뷰를 생성하니까 다른 곳에서 참조한다면 내부값을 쉽게 변경할 여지가 있음!
•
클린한 상태가 됨 > 사이드이펙트 줌!
•
값 타입이여서 가능!
•
불변함
•
독립적이고
▪
메모리 관리 측면 효율적
•
ARC > 참조 타입 > 강한 참조 > 메모리 누수
•
Class UIKit은 참조 타입
•
인스턴스 생성 > 메모리를 잡음
•
메모리 누수
•
SwiftUI 뷰가 구조체니까 메모리 누수가 날 여지가 없음
◦
CoW로 메모리가 할당되니까!
→ 효율적으로 만들었음
