一、Objective-C
成都創(chuàng)新互聯(lián)公司專注于網(wǎng)站建設(shè)|網(wǎng)頁維護(hù)|優(yōu)化|托管以及網(wǎng)絡(luò)推廣，積累了大量的網(wǎng)站設(shè)計(jì)與制作經(jīng)驗(yàn)，為許多企業(yè)提供了網(wǎng)站定制設(shè)計(jì)服務(wù)，案例作品覆蓋成都生料攪拌車等行業(yè)。能根據(jù)企業(yè)所處的行業(yè)與銷售的產(chǎn)品，結(jié)合品牌形象的塑造，量身建設(shè)品質(zhì)網(wǎng)站。
C語言是iOS開發(fā)的語言基礎(chǔ)，而Objective-C是iOS開發(fā)的標(biāo)準(zhǔn)語言，也是為眾多iphone開發(fā)工程師所公認(rèn)的標(biāo)準(zhǔn)，所以必須要掌握。內(nèi)容包括以下這些：
（1）Objective-C語言基礎(chǔ)；
（2）library，framework的制作；
（3）Runtime編程；
（4）LLVM原理和調(diào)優(yōu)。
二、操作系統(tǒng)
操作系統(tǒng)使計(jì)算機(jī)系統(tǒng)所有資源最大限度地發(fā)揮作用，提供各種形式的用戶界面，使用戶有一個(gè)好的工作環(huán)境，為其它軟件的開發(fā)提供必要的服務(wù)和相應(yīng)的接口。所以，必須對ISO操作系統(tǒng)很熟悉才行。包括以下方面的內(nèi)容：
（1）iOS內(nèi)存管理和調(diào)優(yōu)；
（2）iOS的文件系統(tǒng)和沙盒機(jī)制；
（3）iOS多線程編程（Thread，GCD，NSOperation）；
（4）iOS網(wǎng)絡(luò)和服務(wù)器編程（NSURLConnection，NSURLSession）；
（5）iOS系統(tǒng)的各種安全機(jī)制。
三、網(wǎng)絡(luò)編程
網(wǎng)絡(luò)編程是學(xué)習(xí)iOS開發(fā)必須掌握的編程技巧，涉及到Htpps、Socket編程等；在這一部分處理的規(guī)范程度，直接影響到蘋果AppStore的審核。
（1）iOS網(wǎng)絡(luò)發(fā)送機(jī)制調(diào)整和優(yōu)化（NSURLSession）；
（2）Socket編程；
（3）網(wǎng)絡(luò)傳輸中的各種保障；
（4）對傳輸協(xié)議的調(diào)整優(yōu)化。
四、數(shù)據(jù)庫持久化方案
數(shù)據(jù)庫持久化就是把數(shù)據(jù)保存到可永久保存的存儲設(shè)備中，持久化的主要應(yīng)用是將內(nèi)存中的數(shù)據(jù)存儲在關(guān)系型的數(shù)據(jù)庫中。
（1）常規(guī)持久化方案（Keychain，NSUserDefaults，Sqlite，CoreData）；
（2）數(shù)據(jù)庫的使用和設(shè)計(jì)（Sqlite）；
（3）數(shù)據(jù)結(jié)構(gòu)優(yōu)化，Sql調(diào)優(yōu)。
五、圖形圖像編程
iOS開發(fā)過程中，大部分的APP都是采用多視圖設(shè)計(jì)來完成的。所以要熟悉一些圖像的繪制：
（1）UIKit，CoreAnimation和CoreText的繪制；
（2）CoreGraphics，Quartz2D，MediaPlayer，AVFoundation；
（3）OpenGLES，GLKit，SpriteKit，SceneKit，Metal。
六、數(shù)據(jù)結(jié)構(gòu)算法
懂得基本的算法：
（1）基本的算法和數(shù)據(jù)結(jié)構(gòu)（排序搜索算法，數(shù)組，隊(duì)列）；
（2）較復(fù)雜數(shù)據(jù)結(jié)構(gòu)的靈活應(yīng)用（二叉樹，圖等）；
（3）復(fù)雜的專項(xiàng)算法（圖像識別算法，拓?fù)涠ㄎ坏龋?/p>
七、業(yè)務(wù)能力
作為一名優(yōu)秀或者說是及格的iOS程序員，必須要有一定的將功能需求轉(zhuǎn)化并實(shí)現(xiàn)的業(yè)務(wù)能力：
（1）一般性業(yè)務(wù)功能需求分析及實(shí)現(xiàn)；
（2）重要業(yè)務(wù)模塊的需求分析及實(shí)現(xiàn)；
（3）中小規(guī)模產(chǎn)品的架構(gòu)，系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)；
（4）大規(guī)模產(chǎn)品或產(chǎn)品線的架構(gòu)，系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)；
（5）平臺級產(chǎn)品的架構(gòu)，系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)。
八、安全方案
另外，還需要提供對數(shù)據(jù)安全方面有利的方案：
（1）本地?cái)?shù)據(jù)存儲安全（Keychain）；
（2）授權(quán)和身份驗(yàn)證；
（3）傳輸安全（對稱，非對稱，SSL）；
（4）App代碼安全。
九、專業(yè)素質(zhì)
作為一名iOS工程師，需要具備一定專業(yè)素質(zhì)，包括：
（1）團(tuán)隊(duì)協(xié)作能力。軟件開發(fā)要求開發(fā)參與者間有一定默契度，從事自己工作之余為其他同伴創(chuàng)造條件；
（2）溝通能力。能清晰的把你對項(xiàng)目的理解、開發(fā)中的問題等轉(zhuǎn)達(dá)給同事和用戶；
（3）強(qiáng)烈的好奇心和學(xué)習(xí)精神。IOS軟件開發(fā)的變化和創(chuàng)新幾乎是每時(shí)每刻的，優(yōu)秀的程序員要適應(yīng)和主動迎合行業(yè)變化的大環(huán)境；
（4）冷靜、細(xì)心。及時(shí)發(fā)現(xiàn)問題和判斷對策。
一、網(wǎng)絡(luò)各個(gè)協(xié)議：TCP/IP、SOCKET、HTTP等
網(wǎng)絡(luò)七層由下往上分別為物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層和應(yīng)用層。
其中物理層、數(shù)據(jù)鏈路層和網(wǎng)絡(luò)層通常被稱作媒體層，是網(wǎng)絡(luò)工程師所研究的對象；
傳輸層、會話層、表示層和應(yīng)用層則被稱作主機(jī)層，是用戶所面向和關(guān)心的內(nèi)容。
http協(xié)議對應(yīng)于應(yīng)用層
tcp協(xié)議對應(yīng)于傳輸層
ip協(xié)議對應(yīng)于網(wǎng)絡(luò)層
三者本質(zhì)上沒有可比性。 何況HTTP協(xié)議是基于TCP連接的。
TCP/IP是傳輸層協(xié)議，主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸；而HTTP是應(yīng)用層協(xié)議，主要解決如何包裝數(shù)據(jù)。
我 們在傳輸數(shù)據(jù)時(shí)，可以只使用傳輸層（TCP/IP），但是那樣的話，由于沒有應(yīng)用層，便無法識別數(shù)據(jù)內(nèi)容，如果想要使傳輸?shù)臄?shù)據(jù)有意義，則必須使用應(yīng)用層 協(xié)議，應(yīng)用層協(xié)議很多，有HTTP、FTP、TELNET等等，也可以自己定義應(yīng)用層協(xié)議。WEB使用HTTP作傳輸層協(xié)議，以封裝HTTP文本信息，然 后使用TCP/IP做傳輸層協(xié)議將它發(fā)送到網(wǎng)絡(luò)上。Socket是對TCP/IP協(xié)議的封裝，Socket本身并不是協(xié)議，而是一個(gè)調(diào)用接口（API），通過Socket，我們才能使用TCP/IP協(xié)議。
二、Http和Socket連接區(qū)別
相信不少初學(xué)手機(jī)聯(lián)網(wǎng)開發(fā)的朋友都想知道Http與Socket連接究竟有什么區(qū)別，希望通過自己的淺顯理解能對初學(xué)者有所幫助。
2.1、TCP連接
要想明白Socket連接，先要明白TCP連接。手機(jī)能夠使用聯(lián)網(wǎng)功能是因?yàn)槭謾C(jī)底層實(shí)現(xiàn)了TCP/IP協(xié)議，可以使手機(jī)終端通過無線網(wǎng)絡(luò)建立TCP連接。TCP協(xié)議可以對上層網(wǎng)絡(luò)提供接口，使上層網(wǎng)絡(luò)數(shù)據(jù)的傳輸建立在“無差別”的網(wǎng)絡(luò)之上。
建立起一個(gè)TCP連接需要經(jīng)過“三次握手”：
第一次握手：客戶端發(fā)送syn包(syn=j)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)；
第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k），即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)；
第三次握手：客戶端收到服務(wù)器的SYN＋ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。
握
手過程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下，TCP連接一旦建立，在通信雙方中的任何一方主動關(guān)閉連
接之前，TCP
連接都將被一直保持下去。斷開連接時(shí)服務(wù)器和客戶端均可以主動發(fā)起斷開TCP連接的請求，斷開過程需要經(jīng)過“四次握手”（過程就不細(xì)寫了，就是服務(wù)器和客
戶端交互，最終確定斷開）
2.2、HTTP連接
HTTP協(xié)議即超文本傳送協(xié)議(HypertextTransfer Protocol )，是Web聯(lián)網(wǎng)的基礎(chǔ)，也是手機(jī)聯(lián)網(wǎng)常用的協(xié)議之一，HTTP協(xié)議是建立在TCP協(xié)議之上的一種應(yīng)用。
HTTP連接最顯著的特點(diǎn)是客戶端發(fā)送的每次請求都需要服務(wù)器回送響應(yīng)，在請求結(jié)束后，會主動釋放連接。從建立連接到關(guān)閉連接的過程稱為“一次連接”。
1）在HTTP 1.0中，客戶端的每次請求都要求建立一次單獨(dú)的連接，在處理完本次請求后，就自動釋放連接。
2）在HTTP 1.1中則可以在一次連接中處理多個(gè)請求，并且多個(gè)請求可以重疊進(jìn)行，不需要等待一個(gè)請求結(jié)束后再發(fā)送下一個(gè)請求。
由
于HTTP在每次請求結(jié)束后都會主動釋放連接，因此HTTP連接是一種“短連接”，要保持客戶端程序的在線狀態(tài)，需要不斷地向服務(wù)器發(fā)起連接請求。通常的
做法是即時(shí)不需要獲得任何數(shù)據(jù)，客戶端也保持每隔一段固定的時(shí)間向服務(wù)器發(fā)送一次“保持連接”的請求，服務(wù)器在收到該請求后對客戶端進(jìn)行回復(fù)，表明知道客
戶端“在線”。若服務(wù)器長時(shí)間無法收到客戶端的請求，則認(rèn)為客戶端“下線”，若客戶端長時(shí)間無法收到服務(wù)器的回復(fù)，則認(rèn)為網(wǎng)絡(luò)已經(jīng)斷開。
三、SOCKET原理
3.1、套接字（socket）概念
套接字（socket）是通信的基石，是支持TCP/IP協(xié)議的網(wǎng)絡(luò)通信的基本操作單元。它是網(wǎng)絡(luò)通信過程中端點(diǎn)的抽象表示，包含進(jìn)行網(wǎng)絡(luò)通信必須的五種信息：連接使用的協(xié)議，本地主機(jī)的IP地址，本地進(jìn)程的協(xié)議端口，遠(yuǎn)地主機(jī)的IP地址，遠(yuǎn)地進(jìn)程的協(xié)議端口。
應(yīng)
用層通過傳輸層進(jìn)行數(shù)據(jù)通信時(shí)，TCP會遇到同時(shí)為多個(gè)應(yīng)用程序進(jìn)程提供并發(fā)服務(wù)的問題。多個(gè)TCP連接或多個(gè)應(yīng)用程序進(jìn)程可能需要通過同一個(gè)
TCP協(xié)議端口傳輸數(shù)據(jù)。為了區(qū)別不同的應(yīng)用程序進(jìn)程和連接，許多計(jì)算機(jī)操作系統(tǒng)為應(yīng)用程序與TCP／IP協(xié)議交互提供了套接字(Socket)接口。應(yīng)
用層可以和傳輸層通過Socket接口，區(qū)分來自不同應(yīng)用程序進(jìn)程或網(wǎng)絡(luò)連接的通信，實(shí)現(xiàn)數(shù)據(jù)傳輸?shù)牟l(fā)服務(wù)。
3.2 、建立socket連接
建立Socket連接至少需要一對套接字，其中一個(gè)運(yùn)行于客戶端，稱為ClientSocket，另一個(gè)運(yùn)行于服務(wù)器端，稱為ServerSocket。
套接字之間的連接過程分為三個(gè)步驟：服務(wù)器監(jiān)聽，客戶端請求，連接確認(rèn)。
服務(wù)器監(jiān)聽：服務(wù)器端套接字并不定位具體的客戶端套接字，而是處于等待連接的狀態(tài)，實(shí)時(shí)監(jiān)控網(wǎng)絡(luò)狀態(tài)，等待客戶端的連接請求。
客戶端請求：指客戶端的套接字提出連接請求，要連接的目標(biāo)是服務(wù)器端的套接字。為此，客戶端的套接字必須首先描述它要連接的服務(wù)器的套接字，指出服務(wù)器端套接字的地址和端口號，然后就向服務(wù)器端套接字提出連接請求。
連
接確認(rèn)：當(dāng)服務(wù)器端套接字監(jiān)聽到或者說接收到客戶端套接字的連接請求時(shí)，就響應(yīng)客戶端套接字的請求，建立一個(gè)新的線程，把服務(wù)器端套接字的描述發(fā)給客戶
端，一旦客戶端確認(rèn)了此描述，雙方就正式建立連接。而服務(wù)器端套接字繼續(xù)處于監(jiān)聽狀態(tài)，繼續(xù)接收其他客戶端套接字的連接請求。
3.3、SOCKET連接與TCP連接
創(chuàng)建Socket連接時(shí)，可以指定使用的傳輸層協(xié)議，Socket可以支持不同的傳輸層協(xié)議（TCP或UDP），當(dāng)使用TCP協(xié)議進(jìn)行連接時(shí)，該Socket連接就是一個(gè)TCP連接。
3.4、Socket連接與HTTP連接
由
于通常情況下Socket連接就是TCP連接，因此Socket連接一旦建立，通信雙方即可開始相互發(fā)送數(shù)據(jù)內(nèi)容，直到雙方連接斷開。但在實(shí)際網(wǎng)絡(luò)應(yīng)用
中，客戶端到服務(wù)器之間的通信往往需要穿越多個(gè)中間節(jié)點(diǎn)，例如路由器、網(wǎng)關(guān)、防火墻等，大部分防火墻默認(rèn)會關(guān)閉長時(shí)間處于非活躍狀態(tài)的連接而導(dǎo)致
Socket 連接斷連，因此需要通過輪詢告訴網(wǎng)絡(luò)，該連接處于活躍狀態(tài)。
而HTTP連接使用的是“請求—響應(yīng)”的方式，不僅在請求時(shí)需要先建立連接，而且需要客戶端向服務(wù)器發(fā)出請求后，服務(wù)器端才能回復(fù)數(shù)據(jù)。
很
多情況下，需要服務(wù)器端主動向客戶端推送數(shù)據(jù)，保持客戶端與服務(wù)器數(shù)據(jù)的實(shí)時(shí)與同步。此時(shí)若雙方建立的是Socket連接，服務(wù)器就可以直接將數(shù)據(jù)傳送給
客戶端；若雙方建立的是HTTP連接，則服務(wù)器需要等到客戶端發(fā)送一次請求后才能將數(shù)據(jù)傳回給客戶端，因此，客戶端定時(shí)向服務(wù)器端發(fā)送連接請求，不僅可以
保持在線，同時(shí)也是在“詢問”服務(wù)器是否有新的數(shù)據(jù)，如果有就將數(shù)據(jù)傳給客戶端。
這里我們使用Socket實(shí)現(xiàn)一個(gè)聊天室的功能，關(guān)于服務(wù)器這里的就不介紹了
@interfaceViewController (){
NSInputStream *_inputStream;//對應(yīng)輸入流
NSOutputStream *_outputStream;//對應(yīng)輸出流
}
@property (weak, nonatomic) IBOutlet NSLayoutConstraint *inputViewConstraint;
@property (weak, nonatomic) IBOutlet UITableView *tableView;
@property (nonatomic, strong) NSMutableArray *chatMsgs;//聊天消息數(shù)組
@end
懶加載這個(gè)消息數(shù)組
//從主運(yùn)行循環(huán)移除
//1.建立連接
//定義C語言輸入輸出流
//把C語言的輸入輸出流轉(zhuǎn)化成OC對象
//設(shè)置代理
//把輸入輸入流添加到主運(yùn)行循環(huán)
//不添加主運(yùn)行循環(huán) 代理有可能不工作
//打開輸入輸出流
//登錄
//發(fā)送用戶名和密碼
//在這里做的時(shí)候，只發(fā)用戶名，密碼就不用發(fā)送
//如果要登錄，發(fā)送的數(shù)據(jù)格式為 "iam:zhangsan";
//如果要發(fā)送聊天消息，數(shù)據(jù)格式為 "msg:did you have dinner";
//登錄的指令11NSString *loginStr =@"iam:zhangsan";
//把Str轉(zhuǎn)成NSData
//建立一個(gè)緩沖區(qū) 可以放1024個(gè)字節(jié)
//返回實(shí)際裝的字節(jié)數(shù)
//把字節(jié)數(shù)組轉(zhuǎn)化成字符串
//從服務(wù)器接收到的數(shù)據(jù)
//聊天信息
//刷新表格
//發(fā)送數(shù)據(jù)
//發(fā)送完數(shù)據(jù)，清空textField
//數(shù)據(jù)多，應(yīng)該往上滾動
}
//監(jiān)聽鍵盤
//獲取窗口的高度
//鍵盤結(jié)束的Frm
//獲取鍵盤結(jié)束的y值
我最近也在做后端，Python，Ruby，Node 都用了一下，最后選擇 NodeJS。
在選擇時(shí)，Ruby on Rails，Django 第一個(gè)出局，因?yàn)榭紤]到 API 應(yīng)該輕，快。
Python 曾經(jīng)用過 Flask，考慮過 Bottle。不過兩者的 Extensions 的功能都無法需求。
Ruby 的 Sinatra 是最好用的。選擇 Sinatra + Mongoid，一個(gè)星期可以搞出來（我自己的情況）。
現(xiàn)在選擇用 NodeJS 的 ExpressJS ＋ Mongoose 搭配。從 Ruby 轉(zhuǎn)成 Node，主要是因?yàn)榭瓷?NodeJS 的性能。Request per Second 的話，NodeJS 7000 左右，ExpressJS 3000 左右，Sinatra 900 左右，Ruby on Rails 300 左右。
我寫 JavaScript 都是用 CoffeeScript 寫的，所以寫起來就像寫 Ruby 或 Python 一樣，非常 Lisp。
ExpressJS 的開發(fā)也是這些框架里面，最活躍的。
用一套安全的，將來也不會被禁用的設(shè)備識別體系，就可以了。其實(shí)TalkingData早在iOS 6發(fā)布的時(shí)候就已經(jīng)開始著手研究相關(guān)解決方案了，不用UDID，不需要提取MAC地址，也不用夸應(yīng)用訪問公共剪切板，更不需要借助Safari Cookie，就可以輕松實(shí)現(xiàn)獨(dú)立設(shè)備的識別--這套體系就是TIID(TalkingData Independent ID)。目前TIID已經(jīng)可以做到不受IDFA、IDFV影響，始終保持一致，即便是用戶刷機(jī)，但只要恢復(fù)數(shù)據(jù)，即可保持TIID前后一致。唯一會導(dǎo)致TIID發(fā)生改變的情況就是用戶徹底重置設(shè)備且放棄恢復(fù)備份的數(shù)據(jù)--對于一個(gè)iOS用戶來說，這種事件的發(fā)生幾率極小，即便是更換新的設(shè)備，用戶也大多會選擇從之前的設(shè)備備份數(shù)據(jù)恢復(fù)到新設(shè)備上。
根據(jù)用戶的多少并發(fā)量等問題采用不同的解決方案。如果你只是想寫一個(gè)run起來的app和服務(wù)器端其實(shí)非常簡單。服務(wù)器端你不用過多考慮（多了你也想不到），就采用普通的網(wǎng)站接口設(shè)計(jì)就好，比如用php啊、asp.net啊等等，哪個(gè)順手用哪個(gè)。移動客戶端就用url來回傳值就好了。新浪微博這樣的服務(wù)器端設(shè)計(jì)，恐怕一個(gè)人是搞不定的，需要資深的經(jīng)驗(yàn)和很多人來一起搞。
一，iOS端開發(fā)。
如果購買成功，我們需要將憑證發(fā)送到服務(wù)器上進(jìn)行驗(yàn)證。考慮到網(wǎng)絡(luò)異常情況，iOS端的發(fā)送憑證操作應(yīng)該可以持久化，如果程序退出，崩潰或網(wǎng)絡(luò)異常，可以恢復(fù)重試。
二，服務(wù)器端開發(fā)。
服務(wù)器后臺的工作比較簡單，分為4步：
1，接收iOS端發(fā)來的購買憑證。
2，判斷憑證是否已經(jīng)存在，是否驗(yàn)證過，然后，存儲該憑證。
3，將該憑證發(fā)送到蘋果的服務(wù)器驗(yàn)證，并將驗(yàn)證結(jié)果返回給客戶端。
4，如果需要，修改用戶相應(yīng)的會員權(quán)限。
考慮到網(wǎng)絡(luò)異常的情況，服務(wù)器的驗(yàn)證應(yīng)該是一個(gè)可恢復(fù)的列隊(duì)，如果失敗了，應(yīng)該進(jìn)行重試。
重慶分公司
重慶分公司
