軟件架構:
按功能有mvc mvvm ,按照稱此 有數據層,邏輯層,展示層
iOS9新特性
臨時開啟后臺定位
iOS9新加了實時交通
WKWebView
UIAlertView 過期 iOS9使用UIAlertController
-
Multitasking (多任務視圖) (使用Size Class進行布局來支持)
- 臨時調出的滑動覆蓋
- 視頻播放的畫中畫模式
- 以及真正的同時兩個app的分割視圖
MPMoviePlayerCoontroller 過時 (不在繼續維護),使用AVKit 中的AVPlayerViewController
watchOS 2
UI Test
Swift 2
性能優化
- cell重用
- view盡量不要透明 透明控件渲染耗費的性能較大 設置opaque(不透明)為YES (原因:如果是不透明的,就不用考慮底下的視圖,如果是透明的,則需要考慮透明view底下的view)
- 異步加載網絡數據
- 不要在cellForRow...中綁定數據,在willDisplay?Cells中綁定數據
- 盡量減少cell中控件的數量
- 盡量少用 addSubview 給cell 動態添加view,可以初始化時就添加,然后通過 hidden 控制顯示
- 在 heightForRowAtIndexPath: 中盡量不要使用 cellForRowAtIndexPath: (因為heightForRowAtIndexPath調用的次數很頻繁)
- 提前計算并緩存好高度,因為heightForRowAtIndexPath:是調用最頻繁的方法之一,一定不要使用自動計算行高
- 滑動時按需加載,這個在大量圖片展示,網絡加載的時候很管用,目前的第三方框架都處理的很好了。
自己添加的view會比系統的view要小 性能會更高
設置圖片 可以用畫上去
內存優化
用SDWebImage加載jif格式文件時會在內存中緩存圖片,改用YYWebImage 問題解決。由于SD是把Gif中的圖片幀存放到數組,再進行播放,而YY加載一張播放一張釋放一張
1、Analyze,靜態分析內存泄露的方法。很簡單,在Xcode菜單欄中點擊 ”Product“ -> "Analyze",編譯完成后項目工程中可能造成內存泄露的代碼就會被標記出來,這樣我們就可以有針對性的更改代碼優化內存了。
2、使用Xcode的自帶工具Leaks,動態的檢測內存泄露。
1>在Xcode菜單欄中點擊 ”Product“ -> "Profile"(如圖1-1),彈出instruments窗口如圖1-2
2>在instruments窗口中點擊 ”Leaks“(如圖1-2),一般Leaks就開始自動檢測項目內存泄露的地方了,在此過程中可以對手機上運行的測試工程進行操作,如圖1-3,Leaks 后出現的紅色 柱形表示有內存泄露。
3>雙擊如圖1-4中出現類名,就會顯示出此類此方法中造成內存泄露的代碼了如圖1-5,然后我們就可以有針對性的優化代碼、優化內存了。
Instruments
- 使用 Allocations 來檢測內存和堆棧信息
- 使用 Leaks 檢測內存的使用情況,包括內存泄露問題
- 使用 Zombies 來檢測過早釋放的僵尸對象,通過它可以檢測出在哪里崩潰的(image lookup -a <崩潰地址>)
- 使用 Time Profiler 來檢測 CPU 內存使用情況
將來是怎么規劃的?
答:三年達到技術總監的水平
(技術總監需要做什么?:1.技術過硬 2.溝通交流,帶領團隊...)
為什么離開上家公司?
業務單一,想要更大的提升空間,
工作中遇到的難題?
1> block為空的時候,調用該block程序會崩潰(Crush)
2> 利用tableView的headerViewForSection:方法獲取headerView時一直是nil。原因應該是設置headerView時利用- (UIView *)tableView: viewForHeaderInSection:的代理方法返回的UIView應該是UITableViewHeaderFooterView類型的,很多時候被他的返回值(UIView *)誤導了。
3> 項目中需要用到循環刷新數據,利用NSTimer來實現,但是想在VC銷毀時停掉timer(就是在dealloc方法中停掉),結果發現dealloc根本不調用,原本以為是引用計數沒有減到0,可是問題不在此,而就在NSTimer這。結果在viewDidDisappear:停掉timer后就調用dealloc方法了。
4> 利用viewWithTag:尋找子View時,出現絕對性的錯誤,對象類型都不對。問題出現在設置的tag有重復,要注意的是子View在包括子View的子View的tag都不可以重復,所以建議另外創建一個文件專門設定tag,就像android中的R.java文件一樣來確保tag的唯一。
5> JS交互時,由于 JavaScriptCore 存在作用域問題 有時會獲取不到 Web 中的元素。
6> (低級錯誤)請求數據的時候,參數寫錯(由于參數都是字符串,沒有提示,容易寫錯)
堆和棧的區別?
管理方式:
對于棧來講,是由編譯器自動管理,無需我們手工控制;
對于堆來說,釋放工作是由程序員控制。(現在ARC情況,不需要手動管理內存)
地址分配:
棧是向低地址擴展(地址由高向低分配)的數據結構,是一塊連續的內存的區域。
堆是想高地址擴展(地址由低向高分配)的數據結構,是不連續的內存區域。(這是由于系統是用鏈表來存儲的空閑內存地址的,自然是不連續的,而鏈表的遍歷方向是由低地址向高地址)
分配方式:
棧有兩種分配方式:靜態分配和動態分配。靜態分配是由編譯器完成的,如局部變量的分配。動態分配由alloca函數進行分配。
堆都是動態分配的,沒有靜態分配的堆。
進程和線程的區別?
進程
:“正在運行”的應用程序(app),就是一個進程。
進程為應用程序開辟一塊獨立的內存空間。(這塊內存空間是受保護的,進程和進程之間是互不干擾的)
線程
:線程執行進程(應用程序)中的代碼。
線程是CPU調度的最小單元。
進程和線程的關系:
每一個應用程序啟動之后,都會默認/自動生成一條線程。
進程是由一個或多個線程組成的,每條線程都可以執行不同的代碼。
線程并不是越多越好,原因:
(1)開啟線程需要消耗一定的內存(默認情況下,一個線程占用512KB的棧區空間)
(2)會使應用程序增加很多代碼。代碼變多之后,程序的復雜性就會提高。
(3)CPU在多條線程之間來回切換,線程越到,CPU的負擔就越大
建議:在移動應用的開發中,一般只開3~5條線程。
XML和JSON解析?
-
XML解析:
- 方式一:(框架GDataXML)
DOM的方式解析是將XML文檔一次性加載到內存中,再進行解析。
用DOM的方式解析XML需要用到第三方框架 GDataXML - 方式二:(蘋果自帶)
SAX方式解析XML文檔:方式:將XML文檔一行一行逐行進行解析。需要設置代理,使用代理方法<NSXMLParserDelegate>
- 方式一:(框架GDataXML)
-
JSON解析:(蘋果自帶)
- NSJSONSerialization :JSON 解析器,可以直接將標準的JSON 數據解析成 OC 數據。
根據JSON最外層的類型來判斷是用數組還是用字典來接收。
[NSJSONSerialization JSONObjectWithData:data options:0 error:NULL];
- NSJSONSerialization :JSON 解析器,可以直接將標準的JSON 數據解析成 OC 數據。
IT社區
- DevDiv:移動開發社區
- 博客園
- CSDN
- 簡書
- cocoachina
- code4app
- 51CTO.com:IT技術網站,是一個為CTO、IT技術經理、開發工程師、項目管理人員...
-
mobilehub
(漠河
):里邊包含了設計、開發、測試、運營等模塊,各模塊中包含很多其他相關的網站
學習網站
- w3school:各種語言,手冊
- objccn (objc中國):一些分享文章
算法
排序算法:
- 簡單排序
- 冒泡排序
- 選擇排序
- 插入排序
- 直接插入排序
- 折半插入排序(二分插入排序)
- 快速排序,(常見)
- 堆排序
- 歸并排序,(最穩定的,即沒有太差的情況)
直接插入排序
直接插入排序
:基本思想:把待排序的紀錄按其關鍵碼值的大小逐個插入到一個已經排好序的有序序列中,直到所有的紀錄插入完為止,得到一個新的有序序列。
直接插入排序的算法思路
:
(1) 設置監視哨r[0],將待插入紀錄的值賦值給r[0];
(2) 設置開始查找的位置j;
(3) 在數組中進行搜索,搜索中將第j個紀錄后移,直至r[0].key≥r[j].key為止;
(4) 將r[0]插入r[j+1]的位置上。
折半插入
折半插入
:執行折半插入排序的前提是文件紀錄必須按順序存儲。
希爾排序法
希爾排序法
:先選定一個整數,把待排序文件中所有記錄分成個組,并對每一組內的記錄進行排序,重復上述分組和排序的工作。
堆排序
堆排序
:堆排序(Heapsort)是指利用堆積樹(堆)這種數據結構所設計的一種排序算法,它是選擇排序的一種。可以利用數組的特點快速定位指定索引的元素。堆分為大根堆和小根堆,是完全二叉樹。大根堆的要求是每個節點的值都不大于其父節點的值,即A[PARENT[i]] >= A[i]。在數組的非降序排序中,需要使用的就是大根堆,因為根據大根堆的要求可知,最大的值一定在堆頂。
歸并排序
歸并排序
:是建立在歸并操作上的一種有效的排序算法,該算法是采用分治法(Divide and Conquer)的一個非常典型的應用。將已有序的子序列合并,得到完全有序的序列;即先使每個子序列有序,再使子序列段間有序。若將兩個有序表合并成一個有序表,稱為二路歸并。
查找算法
1> 順序查找
2> 二分查找
又稱折半查找
,它是一種效率較高的查找方法。
【二分查找要求】:1.必須采用順序存儲結構2.必須按關鍵字大小有序排列。
【優缺點】折半查找法的優點是比較次數少,查找速度快,平均性能好;其缺點是要求待查表為有序表,且插入刪除困難。因此,折半查找方法適用于不經常變動而查找頻繁的有序列表。
3> 分塊查找
:
方法描述:將n個數據元素"按塊有序"劃分為m塊(m ≤ n)。每一塊中的結點不必有序,但塊與塊之間必須"按塊有序";即第1塊中任一元素的關鍵字都必須小于第2塊中任一元素的關鍵字;而第2塊中任一元素又都必須小于第3塊中的任一元素,……。
操作步驟:
step1 先選取各塊中的最大關鍵字構成一個索引表;
step2 查找分兩個部分:先對索引表進行二分查找或順序查找,以確定待查記錄在哪一塊中;然后,在已確定的塊中用順序法進行查找。
4> 哈希表查找
:設計一個函數(哈希函數, 也叫做散列函數),使得每個元素的關鍵字都與一個函數值(即數組下標)相對應,于是用這個數組單元來存儲這個元素
數據結構
常用結構:數組、鏈表、堆、棧、隊列、樹、圖、散列表
堆
堆
是一種特殊的樹形數據結構
,每個結點都有一個值。通常
我們所說的堆的數據結構
,是指二叉堆
。堆的特點是根結點的值最小(或最大),且根結點的兩個子樹也是一個堆
圖
圖
:是由結點的有窮集合V(點)和邊的集合E組成。其中,為了與樹形結構加以區別,在圖結構中常常將結點稱為頂點,邊是頂點的有序偶對,若兩個頂點之間存在一條邊,就表示這兩個頂點具有相鄰關系。
散列表
若結構中存在關鍵字和K相等的記錄,則必定在f(K)的存儲位置上。由此,不需比較便可直接取得所查記錄。稱這個對應關系f為散列函數(Hash function),按這個思想建立的表為散列表。
基本算法的思想
回溯:
回溯法
也稱試探法
,它的基本思想是:從問題的某一種狀態(初始狀態)出發,搜索從這種狀態出發所能達到的所有“狀態”,當一條路走到“盡頭”的時候(不能再前進),再后退一步或若干步,從另一種可能“狀態”出發,繼續搜索,直到所有的“路徑”(狀態)都試探過。這種不斷“前進”、不斷“回溯”尋找解的方法,就稱作“回溯法”。
遞歸:
遞歸
,就是在運行的過程中調用自己。
構成遞歸需要具備的條件:
- 子問題必須與原始問題做同樣的事,且更加簡單。
- 不能無限制的調用本身,必須有個出口,化簡為非遞歸的狀態處理。
貪心:
貪心算法
(又稱貪婪算法)是指,在對問題求解時,總是做出在當前看來是最好的選擇。也就是說,不從整體最優上加以考慮,他所做出的是在某種意義上的局部最優解。
分治:
分治算法
的基本思想是將一個規模為N的問題分解為K個規模較小的子問題,這些子問題相互獨立且與原問題性質相同。求出子問題的解,就可得到原問題的解。即一種分目標完成程序算法,簡單問題可用二分法完成。
例:給你一個裝有1 6個硬幣的袋子。1 6個硬幣中有一個是偽造的,并且那個偽造的硬幣比真的硬幣要輕一些。找出偽幣。