Let's Swift 2016

스위프트 3.0

swift는 어디로 가는가.

• Swift의 역사
  • Swift 로드맵

• Swift 3.0 훑어보기
  • 예상 발표일: 2016 말
  • Swift 언어와 개발 경험 강화
  • Swift 3.0과 이후 버전의 소스 호환성
  • API 디자인 가이드라인 => 시간나면 봐라

• Swift Evolution & 구현
  • inout 위치 수정
  • 함수 파라미터 var 삭제
  • 함수 파라미터 첫번째 label은 삭제였으나 이제는 생김
  • 튜플 파라미터
  • 디버깅 (FILE, LINE, FUUNCTION, DSO_HANDLE )언더바가 #으로 바뀜
  • Clang 임포트의 변화
  • NS가 사라짐, Value Type(NSArray, array)처럼 obj c, swift 둘다 있으면 빼지 않음
  • 변화의 방향이 무척 명확함
  • API 가이드라인 꼭 읽기!

3줄요약

• Swift 3.0 2016 발표
• Swift 많이 바뀜, 호환성 없을 수 있음
• 시간있으면 SE 읽고, 시간 없으면 Swift API 가이드라인 읽기

스위프트 개발 환경의 변화

Interface Builder, Source Editing, Saanitizer

• IB
  • 새로운 Adaptive Layout
  • Device Preview => orientation도 보이네

• Source Editing
  • SF Mono Font
  • Xcode Source Editor Extension
  • 알카트라즈 플러그인 => 번들 로딩 금지
  • 새로워진 API 문서
  • 오프라인 API 문서
  • code signing, Provisioning
  • 현재 라인 하이라이트
  • 컬러 리터럴(color Literal, #colorLiteral(red: 1, green: 1, blue: 1, alpha: 1))
  • 이미지 리터럴 UIImage(#imageLiteral(reourceName: “Screen shot”))

• Sanitizer
  • 부하가 좀 있음
  • Scheme 에서 사용
  • 런타임 시 버그 추적, Swift3, c, c++, obj c에서만 사용
  • Address, Thread, Memory Sanitizer
  • Memory Graph Debuging

• View Debuging
  • 뷰 디버깅 상태에서 상태 알려줌, hierachy
  • 오토레이아웃 디버깅 => 런타임 이슈도 잡아줌
  • 유한 상태 머신 Quick Look => 뭐지
  • 등등 좋아짐

• LLDB
  • REPL? => 무슨 용어지
  • 자동 import
  • parray, poarray
  • expr let $a = 1; print($a) => 디버그 콘솔에서 사용

• Instrument
  • 디버깅 시 더 자세한 정보
  • 시스템 트레이스
  • 타임 프로파일러

스위프트 무조건 따라하기

• Swift History
  • 크리스 레트너 2010 시작
  • 2014 WWDC 에서 1.0 등장
  • 2015 오픈소스 발표

• Swift
  • TIOBE Index 생산성 순위
  • Objective C의 미래가 밝지않다.
  • if let, guard let
  • general, protocol, property 특성이 독특함
  • protocol oriented programming!

Swift Internals

• LLVM
  • Low Level Virtual Machine
  • 2002년 크리스 레트너가 석사논문으로 내고 투자받아서 오픈소스 프로젝트
  • 2005년 애플이 지원, 컴파일러 팀으로 들어감
  • 컴파일러: 프론트엔드, 최적화기, 코드 생성기로 구성됨
  • gcc에서 Clang, LLVM으로 대체
  • 프론트엔드는 swwift파일을 읽어서 => SIL

• Swift Type System
  • Duck Type: 타입이 중요한게 아니라, quack, walk 메소드만 있으면 오리다.
  • => 스위프트는 Duck Type이 아니다. Type Strict하지만 Type 추정함.

• Type
  • HM Type System
  • Type Checker
  • Constraint를 만족하는 집합을 만들고 계산
  • Native Class Type
  • enum Type
  • struct Type

• Swift Foundation SDK

Swift Compiler

• LLVM + Chris Lattner, Talyer swift

Type System

• HM Type System + W algorithm

  Type Internals

  Swift Foundation

Cisco

Spark

https://web.ciscospark.com/

Tropo

https://www.tropo.com/

Android 개발자가 보는 Swift

• Optional
  • ??: nil less문
  • switch 로 써서 .None, .Some

• Clouser
  • Arr reduce
  • 타입이 명확할 때 생략
  • where

• Architect
  • Viper
  • View (로직은 없음)
  • Present (뷰에 대한 로직) => ViewDidLoad..
  • interact (Data에 대한 비즈니스 로직) => ex) 회원가입 로직, 로컬DB에 대한 로직
  • Entity => 네트워크, DB등의 데이터 모델 => JSON, Relm
  • router => 뷰간 전환
  • DataService => 반복되는 로직 코드
  • ViewModel (뷰에 나타나는 데이터와 1:1 매칭)

Protocol Oriented Programming

• 프로토콜
  • 기본구현: protocol + extension = protocol extension
  • 특정 타입이 할 일 지정 + 구현 한방에!
  • extension에 protocol 에서 쓸 메소드를 구현해 놓은걸 default implementation이라고 함.

• 상속의 한계
  • 상속받는 과정에서 동일한 기능을 구현하는 중복코드가 발생

• 참조 타입의 한계
  • 동적 할당과 참조 카운팅의 한계 => 자원의 소모가 큼

• Protocol
  • class: person, bird, frog, turtle, fish
  • protocol: runnable, talkable, swimable, flyable => 기능의 블럭을 가지고 각각 조립함
  • 타임라인을 나타내는 소셜네트워크 (타임라인) 을 구현하자
  • tableview Cell, CollectionView Cell에 들어갈 contents는 같다
  • Class => reference type
  • Struct => Value type
  • Shared

• Refactoring
  • Image + Video
  • extension UIImageView: ContentPresentTable()
  • extension AVPlayer: ContentPresentTable()
  • struct 에 enum으로 video, image

• Advantage

  • 모든 타입에 적용 가능
  • 제네릭과 결합하면 더욱 파급적인 효과
  • 상속의 한계 극복 => 상속체계 상관 없음
  • 상속이 불가능한 구조체에 확장 가능
  • 적은 시스템 비용 reference type cost > value type cost
  • 용이한 테스트
  • 성능상의 이득
  • protocol + extension + generic은 환상의 조합
  • 수직적 확장 => 수평적 확장

• delegate, datasource 에는 불가함 => 기본구현 불가

Swift Package Manager

• Swift Package manager

  • homebrew, cocoapods, carthage, macPorts

• 원활한 배포

  • 의존성 문제

• swift dev snapshot 다운받기

• manifest: 화물 리스트. 메타데이터를 가지고 있는 파일

• argument

• swift package list

Rx Swift

• Reactive Programming
  • data flow, propagation
  • reactive extension

• funcional reactive programming
  • (1…10).reduce(0){$0 + $1}
  • data flow

• reactiveX.org

  • observable: 비동기로 다수를 다룸

• pod try RxSwift

• validation에 사용(이메일, pw 한자 한자 칠때마다 구독해놓은 값이 변화)

• rxmarbles.com
• rxAlamofire
• rvvm
• 이규현 rvvm

스위프트 성능 이해하기

value 타입, protocol과 스위프트의 성능 최적화

• Value Semantics
  • 변수 할당 시 stack에 값 전체가 저장
  • heap을 안 쓰면서 reference counter 증가 x

• Class vs Struct

  • Class
    1. stack에 ref저장, heap에 값 저장, ref counter 증가
  • Struct
    1. stack에 실제 값 저장

• Equatable 구현

• Value Type의 장점

  • Mutable할때 Thread간의 의도하지 않은 공유로부터 안전함

• Immutable로 써도 된다.

• 성능에 영향을 ㅣ치는 3가지

  • stack VS heap
  • reference counting yes VS no
  • method dispatch: static(compile time) VS dynamic(run time)

• 힙 할당의 문제
  • 할당시 빈 곳을 찾고 관리하는 것은 복잡한 과정
  • Thread safe 해야 함 => Lock => 멈출 수도 있음

• Heap 할당 줄이기
  • struct를 이용해 value타입으로 만듬

• reference Counting
  • 변수 Copy할 때마다 증가
  • thread safety하게 실행되어야 하므로…
  • retain(), release()이 내부적으로 불림
  • ARC

• Method Dispatch (static)
  • 컴파일 시점에 메소드의 실제 코드 위치를 안다면 점프가 가능
  • 메소드 인라이닝!
  • 메소드 호출 부분에 메소드 내용을 붙여넣음

• 성능을 좋게 만드는 습관
  • final, private를 쓰는 버릇 => static하게 처리
  • dynamic 쓰지 않음
  • obj c 연동 최소화
  • Whole Module Optimization 옵션 켜라

• class
• struct
  • ref count를 줄이자.

• 용어
  • existential Container
  • VWT(value witness table)
  • copy on write

스위프트 Back End

• Kitura, Perfect, zewo, vapor
• vargrant, docker
• if let where

Realm

• Coredata / SQLite를 대체할 Realm
  • Wraper가 아님, ORM 아님, 자체 c++
  • zero copy => memory mapped file
  • result 자동으로 업데이트
  • encryption이 쉽다