報着請教的態度，開始寫寫IOS的博客，希望大家共同學習，共同進步。。。。
自己的作圖都加上了HJC的水印。。 不是自己的作圖就沒有HJC的水印。
IOS知識點：
1、對IOS的特性有深刻理解（如對象生命周期、內存管理、協議、特性、GCD、blocks、CoreAnimation、cocoa touch框架、runtime機制 等）
2、iOS性能優化和內存優化、代碼調試和調優和相關工具(如：Instruments)、集成工具。
3、多線程、網絡通信(如http、socket、UDP)、數據持久化(常用的4種)
4、設計模式，如KVO、單例、適配器、策略、代理、工廠、、
5、界面UI（如storyboard、Nib）、各種UI控件，能自定義UI控件、UI構架
6、架構設計，熟悉第三方庫、開源組件的使用(如：sdwebimage、AFNetwork、ASI、Three20），並能開發第三方組件
7、代碼質量：Code Review、單元測試、自動化測試
8、熟悉swift
9、熟練使用Xcode開發工具，包括工程配置（如證書配置、調用第三方庫等）、熟練使用git、svn等工具
10、精通常用數據結構和算法
11、動畫：cocos2d、Unity3D
一、 app生命周期---app的5種狀態
ios app有5種狀態，分別是：
1、Not running未運行：app沒啟動或被迫終止。
2、Inactive未激活：當前應用正在前台運行，但是並不接收事件（當前或許正在執行其它代碼）。一般每當應用要從一個狀態切換到另一個不同的狀態時，中途過渡會短暫停留在此狀態。唯一在此狀態停留時間比較長的情況是：當用戶鎖屏時，或者系統提示用戶去響應某些（諸如電話來電、有未讀短信等）事件的時候。
3、Active激活：當前應用正在前台運行，並且接收事件。這是應用正在前台運行時所處的正常狀態。
4、Backgroud后台：程序在后台而且能執行代碼，大多數程序進入這個狀態后會在在這個狀態上停留一會。時間到之后會進入掛起狀態(Suspended)。經過特殊的請求后可以長期處於Backgroud狀態。
5、Suspended掛起：程序在后台不能執行代碼。系統會自動把程序變成這個狀態而且不會發出通知。當掛起時，程序還是停留在內存中的，當系統內存低時，系統就把掛起的程序清除掉，為前台程序提供更多的內存。
需要注意的一點是：對於從Not running狀態直接進入到background狀態的應用，在啟動進入到background狀態時，如果應用有界面，系統仍然會加載用戶界面文件，只是不會顯示在應用的window上面。
為了在程序中確定你的程序是進入到了foreground還是background，你可以在application:didFinishLaunchingWithOptions: 方法中檢測UIApplication類對象的applicationState屬性，如果應用進入到了foreground，則屬性值為UIApplicationStateInactive，如果進入到了background，則為UIApplicationStateBackground。
檢測示例代碼：
UIApplicationState state = [UIApplication sharedApplication].applicationState;
return (state==UIApplicationStateActive || state==UIApplicationStateInactive );
二、app生命周期---執行流程
application:didFinishLaunchingWithOptions: 這是程序啟動時調用的函數。
applicationDidBecomeActive: 應用在准備進入前台運行時執行的函數。
applicationWillResignActive: 應用當前正要從前台運行狀態離開時執行的函數。
applicationDidEnterBackground: 此時應用處在background狀態，並且沒有執行任何代碼，未來將被掛起進入suspended狀態。
applicationWillEnterForeground: 當前應用正從后台移入前台運行狀態，但是當前還沒有到Active狀態時執行的函數。
applicationWillTerminate: 當前應用即將被終止，在終止前調用的函數。如果應用當前處在suspended，此方法不會被調用。
按home鍵：
applicationWillResignActive
applicationDidEnterBackground
1、當URL請求到達時，如果你的應用沒在正在運行，則會被啟動並且移到前台運行以打開URL。
application:didFinishLaunchingWithOptions:
application:openURL:sourceApplication:
applicationDidBecomeActive
2、當URL請求到來時，如果你的應用正在background運行或被suspended，它將會被移到前台以打開URL。
從第三方分享回來：
applicationWillEnterForeground
application:openURL:sourceApplication:
applicationDidBecomeActive
支持自定義URL模式的應用，可以在應用啟動和去處理URL之前，這個過程之間指定不同的啟動畫面圖像。具體細節，請看Apple官方文檔iPhoneAppProgrammingGuide.pdf第85頁，“Providing Launch Images for Custom URL Schemes”。
3、notification，特指顯示banner方式的notification，並不會像上面的中斷一樣使當前處於active狀態的應用切換到Inactive狀態。此類通知的banner放置在你的應用窗口的上邊沿之上，所以你的應用依然處在active狀態，並且繼續像以前一樣接收touch events。但是，如果用戶拉下banner去呈現通知中心內容時，當前應用將會和上面基於警告的中斷一樣切換到inactive狀態。
在通話過程中，調整你的應用的UI：
當用戶正在接電話，並且返回你的應用繼續保持通話，此時狀態欄的高度應該增加以反應用戶正在通話的事實。相似的，當用戶結束通話時，狀態欄的高度應該縮減恢復常規高度。處理狀態欄高度變化的最好方法是使用view controllers去管理你的應用views。當狀態欄frame size改變時，view controllers會自動調整它們所管理的所有內部視圖。
如果你的應用因為某些原因而沒有使用view controllers，則你應該手動響應狀態欄frame size的變化，具體即通過注冊UIApplicationDidChangeStatusBarFrameNotification通知來實現。通知處理函數handler應該獲取狀態欄的高度並且使用這些數據來適度調整當前應用所包含視圖的高度。
4、應用切向后台background時應該做什么：
應用可以在applicationDidEnterBackground:方法中做些切向background狀態前需要做的一些准備工作，當切向background狀態時，所有的應用需要做以下事情：
（1）應用界面快照。當applicationDidEnterBackground:方法返回時，系統保存應用界面的快照，並且使用快照圖片作為轉換動畫。如果在你的應用界面中有涉及到敏感信息的視圖，則你應該在applicationDidEnterBackground:方法返回前隱藏或者修改這些視圖。
（2）保存用戶數據和應用狀態信息。所有沒有保存的改變都應該在切向background狀態前寫入磁盤以保存。這一步是必須的，因為你的應用在后台時很有可能因為多種其它原因而被很快kill掉。根據需要你可以在background thread后台線程中執行這些操作。
（3）釋放盡可能多的內存資源。
applicationDidEnterBackground:方法允許最多有5秒的時間去完成任何任務然后返回。實際中，此方法應該盡可能快的返回。如果在時間到期之后，此方法沒有返回，則應用即被kill掉，並且清除所占用的內存。如果你的應用確實需要更多的時間去執行任務，可以調用beginBackgroundTaskWithExpirationHandler:方法請求后台執行時間，然后啟動一個能長期執行任務的線程。無論你是否啟動一個執行后台任務的線程，applicationDidEnterBackground:方法都必須在5秒后退出。
注：UIApplicationDidEnterBackgroundNotification通知也會發送，以讓應用對此通知感興趣的部分知道當前應用正切向background狀態。你的應用中的對象可以使用默認的通知中心注冊這個通知。
5、前台應用在使用系統資源和硬件時 比后台應用 具有更高的優先權。當應用切向background時尤其要遵循以下幾點：
（1）不要在應用代碼中調用任何OpenGL ES的東西。
（2）在應用掛起suspended之前取消所有Bonjour相關的服務。如果你的應用不關掉這些和Bonjour相關的服務，當應用被掛起的時候，系統會自動幫你關掉這些服務。
（3）在基於網絡sockets的應用中，需要處理連接失敗的情況。當應用從后台退出恢復執行時，如果遇到sockets使用錯誤，簡單的重建socket連接即可。
（4）在切向background狀態前保存應用狀態。在低內存告警時，后台應用可能會被清除出內存以釋放空間。處於suspended狀態的應用被優先清除內存，並且在被清除前不會給出任何通知。
（5）當切向后台時，釋放所有不再需要的內存。如一個很大的內存緩存對象（比如圖像），則切入后台前，釋放所有的對這些緩存對象的引用。
（6）在被掛起前停止使用系統共享資源。使用系統共享資源（比如Address Book或Calendar Data）的應用，在被掛起前必須停止對這些共享資源的使用。你的應用在被掛起后還沒有停止對這些共享資源的使用，則應該將被kill掉。
（7）避免更新應用窗口和視圖。盡管在后台創建和操縱窗口和視圖對象並不會導致應用被kill掉，但是可以將這些工作推遲到應用返回前台時執行。
（8）響應外部附件連接和失去連接通知。針對和外部附件有通信的應用，當應用切向background狀態時，系統會發送一個disconnection通知。應用必須注冊此通知並且使用它去關掉當前的附件訪問session。當應用返回foreground時，會有一個與之匹配的通知被發送，給應用提供重新建立session的機會。
（9）切向后台時，清除行為警告相關的資源。為了在應用相互切換之間保存應用上下文，當應用切向后台時，系統並不自動dismiss action sheets(UIActionSheet)和alert views(UIAlertView)。對於運行在iOS4.0版本之前的應用，在退出時action sheets和alerts仍然被dismiss掉，以讓應用的取消處理函數有機會去運行。
（10）切向后台時，移除所有敏感視圖信息。因為系統會快照應用界面並且生成應用切換動畫，所以帶有敏感信息的視圖或窗口必須隱藏或移除。
（11）應用在后台運行時執行最少量化的工作。系統給后台運行的應用的執行時間和給前台運行的應用相比，通常非常有限。如果應用在后台播放音頻或者監測位置變化，則應用應該僅關注此任務，所有不必要的任務都應該被推遲。在后台執行時間過長的應用會被系統throttled back或者直接被kill掉。
6、后台應用的內存使用：
當手機內存即將耗盡時，系統會終止那些掛起suspended的應用以回收內存。然而那些消耗很大數量的內存同時又處於后台background運行的應用會優先被終止。
下面是一些需要回收的對象的例子：
（1）緩存的圖像對象
（2）比較大的多媒體文件或數據文件，這些文件可以從磁盤重新裝載。
（3）任何應用當前不再需要的對象，並且這些對象后面又可以很容易重新創建。
為了幫助您的應用程序，減少其內存占用，系統會自動釋放出許多幕后用於支持您的應用程序的對象。例如：
（1）釋放所有的核心動畫層的后備存儲，以避免這些層繼續在屏幕上顯示，同時又不改變當前層的屬性。並且並不釋放層對象自已。
（2）移除所有對緩存圖像的引用。（如果應用沒有對這些圖像強引用，則他們隨后即被移除內存）
（3）釋放一些系統管理的其它的數據緩存。
7、返回前台foreground
1）在應用切向前台被喚醒時處理通知隊列
如方向改變、時間改變、偏好改變、以及其它的影響應用的外觀的行為或狀態等等，系統將這些相關的通知入隊列，並且當應用恢復foreground或background重新執行代碼時，立即將這些通知發往應用。為了防止應用恢復時因為通知過多而過載，系統會合並事件並且僅傳遞一個能夠反應自從應用被掛起有網絡改變的單個通知。
具體通知合並規則如下表所示：
通知隊列典型的在任何觸控事件和用戶輸入之前被投遞向應用的主運行循環main run loop。大多數應用應該能夠足夠快的處理這些事件。然而，如果發現你的應用在從后台恢復時看起來明顯呆滯，則可以使用Instruments去確定是否是通知處理代碼正在運行而造成了延遲。
（2）從容的處理本地改變
當應用處於掛起suspended狀態時，如果用戶改變了當前語言設置，則當應用返回前台的時候可以使用NSCurrentLocalDidChaneNotification通知來強制任何包含本地敏感信息（像日期、時間、數字等等）的視圖進行更新。當然，避免本地信息相關的事件處理的最好的方法還是以那種更容易更新視圖的方式來寫更新視圖的代碼。比如：
a.使用autoupdatingCurrentLocal類方法來檢索NSLocal對象。此方法返回一個本地對象，該對象響應本地改變並且自動更新自已。所以，你不需要再去重新創建它。然后，當本地信息改變時，你的應用仍然需要去刷新那些包含本地信息的視圖。
b.無論任何時候本地信息改變時都去重新創建緩存日期或者數字格式對象。
（3）響應應用設置改變
如果應用包含被Settings應用所管理的設置，則應用應該關注NSUserDefaultsDidChangeNotification通知。
8.應用終止
如果應用將被終止時正在前台或后台運行，系統將會調用應用代理的applicationWillTerminate:方法 保存用戶數據或應用狀態信息，該方法最長運行時限為5秒，過期應用即被kill掉並且移除內存。
注：處於suspended狀態的應用被終止時不會有任何通知。但是如果應用當前正在后台background運行，則當應用要被終止時，系統會調用應用代理的applicationWillTerminate:方法。應用不可以在此方法中申請額外的后台執行時間。
9.主運行循環main run loop
UIApplication對象在應用啟動時安裝主運行循環並且使用此循環去處理事件和處理基於視圖的界面更新。該主運行循環是在應用的主線程app's main thread中運行的。以此保證所有用戶事件是按照它們被接收時的順序串行的執行。
當用戶和應用交互時，和這些交互相關的事件由系統自動產生並且借助UIKit設定的特殊端口傳遞給應用。事件在應用內部以隊列的形式存在並且一個一個的被分發到應用的主運行循環去執行。UIApplication對象是第一個接收事件的對象，並且決定需要如何處理事件。觸控事件通常被分發到應用的主窗口對象，並且最終分發到發生該觸控事件的視圖上面。其它的事件傳遞也許會經過各種各樣的應用對象而與觸控事件傳遞稍微有所不同。
在iOS應用中可以傳遞很多類型的事件。最常見的事件列在下表中：
這些事件類型中的大部分通過應用的主運行循環進行傳遞，但是還有一些並不是的。例如：accelerometer事件直接被傳遞到應用指定的accelerometer代理對像。關於系統如何處理大多數類型事件，包括touch、remote control、motion、accelerometer，以及gyroscopic事件，詳見Event Handling Guide for iOS.
一些像觸控、遠程控制類的事件，通常被應用的響應對象處理。響應對象存在於應用的任何地方。（UIApplication對象，view對象，view controller對象等等都是響應對象的例子）。大多數事件是以特定的響應對象為目標，但是也可以被傳遞給其它的響應對象（借助響應鏈），例如：一個不處理任何事件的view可以將事件傳遞給它的父view或傳遞給view controller。
發生在controls類的視圖（例如button）上的事件的處理過程和發生在其它類型的views上的觸控事件處理過程有些不一樣。因為發生在control類的對象上面的交互行為只有非常有限的幾種，因此這些交互重新打包進active message並且傳遞給合適的目標對象。 這種target-action的設計模式，使應用通過control類型的view對象去觸發一段自定義代碼的執行變得非常容易。
借鑒的文章：http://blog.csdn.net/duanyipeng/article/details/7101829