1.0 iOS 모듈 화의 문제점 앞에서 모듈 화 된 절차 와 흔히 볼 수 있 는 문 제 를 소 개 했 으 니 여기 서 다시 한 번 정리 하 겠 습 니 다. 업무 중 에 우리 가 새로운 프로젝트 를 시작 할 때 가장 먼저 고려 하 는 것 은 모듈 화 작업 이다. 모듈 화 작업 의 생각 은 매우 아름 답지 만 집행 과정 에서 많은 문제 에 부 딪 힐 수 있 고 이런 문제 들 은 우리 로 하여 금 업무 수행 에 어려움 을 겪 게 할 수 있다.
도구 사용 문제.iOS 의 모듈 화 는 일반적으로 cocoapods 도 구 를 사용 합 니 다. 이 도 구 는 매우 강력 하고 내용 도 풍부 합 니 다. 우 리 는 모듈 화 작업 을 완성 하려 면 개인 라 이브 러 리 를 만 들 고 podspec 파일 을 작성 하 며 자원 을 처리 하고 Podfile 파일 을 작성 하 며 로 컬 의존 도 를 구축 해 야 합 니 다.팀 원 모두 가 이 도구 에 정통 하 게 하 는 것 은 불필요 하 다.그래서 도 구 를 사용 하 는 과정 에서 해결 하기 어 려 운 문제 에 부 딪 혀 많은 시간 을 낭비 하 는 경우 가 많다.
xcode 설정 문제.xcode 설정 항목 이 소 털 처럼 많 고 많은 내용 이 직관 적 이지 않 으 므 로 우리 가 공식 문 서 를 찾 아 해결 해 야 합 니 다.그리고 이런 설정 의 수량 이 많 고 사용 하 는 빈도 가 적 기 때문에 이런 상황 이 발생 할 수 밖 에 없다. 모든 사람 이 겪 는 문 제 를 각자 시간 을 들 여 해결 한 다음 에 시간 이 지나 면 똑 같은 문 제 를 만나면 잊 어 버 리 고 시간 을 들 여 찾 아 해결 해 야 하기 때문에 자원 의 중복 낭 비 를 초래 해 야 한다.
모듈 간 의존 문제 도 （ ） 에 의존 할 때 개발 과정 에서 여러 모듈 을 동시에 수정 해 야 여러 공정 에서 전환 하 는 문제 가 발생 할 수 있 습 니 다.
규범 문 제 는 모든 사람 이 모듈 을 구축 하 는 방식 이 다 를 수 있 는데 공사 구조, 공사 설정 등 을 포함한다.이렇게 되면 서로 다른 모듈 의 차이 가 매우 클 수 있 고 크로스 모듈 개발 이나 코드 가 인수 인계 할 때 해결 하기 어 려 운 문제 가 발생 할 수 있다.
설정 의 변경 수정 은 모두 수 동 으로 수정 되 는데 가끔 은 소홀 해서 발견 하기 어 려 운 오류 가 발생 할 수 있 고 처리 해 야 할 모듈 과 의존 이 많 을 때 오류 가 발생 할 확률 도 높아진다.
2.0 자동화 도구 작성 이러한 문 제 를 해결 하기 위해 팀 이 업무 개발 에 집중 할 수 있 도록 bash 셸 을 사용 하여 구축 도 구 를 개발 하여 모듈 화 과정 에서 발생 하 는 설정 과 도구 사용 문 제 를 자동화 처리 하 는 데 사용 합 니 다. 도구 의 주 소 는 다음 과 같 습 니 다.https://github.com/hardman/AWModularization 이 자동화 도 구 를 사용 하면 다음 과 같은 능력 을 얻 을 수 있 습 니 다.
하나의 명령 으로 모듈 프로젝트 를 만 들 수 있 습 니 다. podspec 및 Podfile 파일 을 만 들 고 의존 도 를 자동 으로 설치 합 니 다. 프로젝트 는 기본적으로 정적 라 이브 러 리 를 사용 하고 Swift 와 OC
를 지원 합 니 다.
하나의 명령 으로 이전에 개 발 된 모듈 을 끌 어 올 리 고 모든 의존 도 를 설치 할 수 있다
하나의 명령 으로 자동 으로 tag 를 하고. podspec 파일 을 자동 으로 업데이트 하여 pod 서버
로 공 사 를 전송 할 수 있 습 니 다.
자체 모듈 의 목록 은 단독 git 라 이브 러 리 에 저장 되 어 모듈 에 의존 할 때 동적 으로 불 러 올 수 있 습 니 다
자체 모듈 의 의존 도 는. podspec 파일 을 통 해 local path 로 설치 되 어 있 습 니 다. 의존 하 는 모듈 도 수정 이 필요 할 때 여러 프로젝트 를 열지 않 아 도 됩 니 다
따라서 이 자동화 도 구 를 사용 하면 cocoapods 도 구 를 이해 할 필요 도 없고 그 어떠한 공사 와 도구 설정 도 처리 할 필요 도 없 으 며 업무 개발 에 집중 할 수 있 습 니 다. [주] 도 구 는 정적 라 이브 러 리 를 모듈 의 출력 파일 로 사용 합 니 다. 3.0 도구 사용 3.1 기본 사용 절차
로 컬 디 렉 터 리 에 프로젝트 클론
설정 파일 수정 열기 tools/config
modulelistgitaddress. txt: git 라 이브 러 리 를 새로 만 들 고 주 소 를 이 파일 에 저장 합 니 다. 주 소 는 git@ 로 시작 하 는 것 이 좋 습 니 다.이 git 라 이브 러 리 는 모든 자체 모듈 이름과 주 소 를 저장 하 는 데 사 용 됩 니 다.
podspecsadr. txt: git 라 이브 러 리 를 새로 만 들 고 주 소 를 이 파일 에 저장 합 니 다. 주 소 는 git@ 시작 하 는 것 이 좋 습 니 다.이 git 라 이브 러 리 가 바로 당신 의 개인 라 이브 러 리 주소 입 니 다.
podspectsname. txt: git 라 이브 러 리 의 이름 을 지어 이 파일 에 저장 합 니 다
상기 3 개 파일 은 모두 한 줄
만 있다.
dependencypodrepos. txt: 이 파일 은 app 이 의존 하 는 다른 pod repos 을 저장 합 니 다. 일반적인 상황 에서 기본 값 을 유지 하면 됩 니 다. 여러 줄 을 지원 합 니 다. 줄 마다 주 소 를 저장 합 니 다
이 설정 들 은 거의 수정 되 지 않 기 때문에 이 파일 들 을 git 라 이브 러 리 에 제출 하 는 것 을 고려 합 니 다
집행 ./create.sh -n=[ ] -b=[bundle id] -t=[s|f|r] 하면 공 사 를 만 들 수 있다.
스 크 립 트 실행 과정 에서 일부 공정 기본 정보 와 의존 하 는 모듈 을 입력 하 라 고 요구 할 수 있 습 니 다. 누락 되 지 않도록 진지 하 게 입력 하 십시오
module 프로젝트 에서 OC 의 클래스 파일 과 swift 파일 을 만 듭 니 다. OC 클래스 가 TestOC 라 고 가정 하고 swift 클래스 는 TestSwift
입 니 다.
OC 가 Swift 류 에 접근 할 수 있 도록
TestOC. m 에 import 만 추가 하면 됩 니 다.예: #import " / -Swift.h".
또한 주의해 야 할 것 은 TestSwift 류 는 반드시 Public 이 고 NSObject 에서 계승 해 야 한 다 는 것 이다.
Swift 가 OC 클래스 에 접근 할 수 있 도록
[모듈 이름]. h 이 파일 에 헤더 파일 을 도입 합 니 다.예: #import "TestOC.h".
재 xcode - build phases - [ ].h 파일 은 Public 구역
에 있어 야 합 니 다.
3.4 모듈 자원 파일 가 져 오기
모듈 이 정적 라 이브 러 리 이기 때문에 최종 적 으로 app 에 실 행 된 후에 모든 모듈 의 자원 파일 （.xcassets, .xib, .png, .jpg, .jpeg, .gif, .txt, .plist, .bundle, .zip, .car） 은 다음 과 같 습 니 다. " .bundle" 파일 에 있 습 니 다. 이 bundle 은 main bundle 의 루트 디 렉 터 리 (이것 도 모듈 이름 이 이름 을 바 꾸 지 않도록 요구 하 는 이유 중 하나 입 니 다)
그림 을 얻 기 위해 사용 할 수 있 는 UIImage.init(named: name, in: bundle, compatibleWith: nil) 방법
다른 파일 을 가 져 오 려 면 bundle 을 지정 해 야 합 니 다
개발 과정 에서 모든 자원 을 얻 으 려 면 bundle 이 필요 하 며 유사 한 UIImage.init(named:String) 방법 을 직접 사용 할 수 없습니다. 모듈 공학 내부 의 코드 라 도 안 됩 니 다
주의해 야 할 것 은 정적 라 이브 러 리 의 유닛 테스트 target 은 자원 을 얻 을 수 없다 는 것 이다
. 3.5 주의사항
모듈 명 은 중복 을 방지 해 야 한다. 같은 사유 라 이브 러 리 의 중복 을 방지 해 야 할 뿐만 아니 라 다른 pod repo 내 모듈 과 중복 되 는 것 도 방지 해 야 한다
의존 라 이브 러 리 는 순환 의존 을 발생 시 킬 수 없다. 예 를 들 어 A 의존 B, B 의존 C, C 의존 A
각 모듈 은 하나의 develop 분기 가 있 고 develop 분기 의 코드 는 항상 최신 tag 와 일치 합 니 다.push 명령 을 실행 할 때 코드 는 항상 develop 분기 에 있 습 니 다
개발 기간 (통합 테스트 전) 은 항상 로 컬 모듈 에 의존 하고 매번 통합 테스트 전에 push. sh 스 크 립 트
를 실행 합 니 다.
현재 개발 모듈 이 수정 되 고 의존 하 는 모듈 도 수정 되면 현재 모듈 이 의존 하 는 모듈 을 먼저 push 하고 마지막 으로 push 현재 모듈 을 사용 해 야 합 니 다.이 때 모듈 이 의존 하 는 모듈 의 버 전 번호 ./utils.sh [ ] upgradedependency [ ] [ ] 를 수정 하 라 는 명령 을 사용 해 야 할 수도 있 습 니 다. – 끝 -
iOS 응용 모듈 화 된 사고 및 착지 방안 (1) 모듈 의 구분 및 모듈 화 작업 절차
iOS 응용 모듈 화 된 사고 와 착지 방안 (2) 모듈 화 자동 구축 도구 의 사용
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
