fmdb緩存

㈠ 歐姆龍cj1w在軟體cx-programmer中的選型能選cj1h或者cj1e嗎

1.一、某些軟體運行時在任務欄列表中是不可見的，而是以進程的方式在後台運行，常見的有來電防火牆、簡訊防火牆類軟體、殺毒軟體、加密軟體等需要實時監控的軟體，因此，當然無法刪除正在運行中的軟體；二、解決方法為：1、用進程管理器查看進程表，如你能判斷哪個線程是該程序的進程，則可以關閉它，如無法判斷則可以先設臵不顯示系統進程；2、然後關閉所有的非系統進程，這樣就可以到程序管理里正常卸載軟體了。2.你好，應該是網路設置了許可權。你先去手機設置里，重新設置一下網路設置試試。和網速是沒有關系的，如果再不行，你可以換其他的手機瀏覽器使用，比如手機QQ瀏覽器就是很不錯的選擇。最新版本又增加了不少的功能，關於QQ的網站可以一鍵登錄，很方便。也增加了微信的新聞版塊。並且閱讀模式也很完善，全部可以免費閱讀，還可以一鍵緩存。你好，應該是網路設置了許可權。你先去手機設置里，重新設置一下網路設置試試。和網速是沒有關系的，如果再不行，你可以換其他的手機瀏覽器使用，比如手機QQ瀏覽器就是很不錯的選擇。最新版本又增加了不少的功能，關於QQ的網站可以一鍵登錄，很方便。也增加了微信的新聞版塊。並且閱讀模式也很完善，全部可以免費閱讀，還可以一鍵緩存。你好，應該是網路設置了許可權。你先去手機設置里，重新設置一下網路設置試試。和網速是沒有關系的，如果再不行，你可以換其他的手機瀏覽器使用，比如手機QQ瀏覽器就是很不錯的選擇。最新版本又增加了不少的功能，關於QQ的網站可以一鍵登錄，很方便。也增加了微信的新聞版塊。並且閱讀模式也很完善，全部可以免費閱讀，還可以一鍵緩存。你好，應該是網路設置了許可權。你先去手機設置里，重新設置一下網路設置試試。和網速是沒有關系的，如果再不行，你可以換其他的手機瀏覽器使用，比如手機QQ瀏覽器就是很不錯的選擇。最新版本又增加了不少的功能，關於QQ的網站可以一鍵登錄，很方便。也增加了微信的新聞版塊。並且閱讀模式也很完善，全部可以免費閱讀，還可以一鍵緩存。

㈡ Web前端開發與iOS終端開發的異同

語言
前端和終端作為面向用戶端的程序，有個共同特點：需要依賴用戶機器的運行環境，所以開發語言基本上是沒有選擇的，不像後台想用什麼就用什麼，iOS只能用Objective-C，前端只能javascript，當然iOS還可以用RubyMotion，前端還能用GWT/CoffieScript，但不是主流，用的人很少，真正用了也會多出很多麻煩。
這兩者有個有意思的對比：變數/方法命名的風格正好相反。蘋果一直鼓吹用戶體驗，寫代碼也不例外，程序命名都是用英文全稱並且要多詳細有多詳細，力求看變數和方法名就能知道是幹嘛的，例如application:didFinishLaunchingWithOptions:。而js因為每次都要從網路下載，要力求減少代碼體積，所以變數方法名是盡量用縮寫，實際上有代碼壓縮工具，無論變數名寫多長最終上線的效果是一樣的，但大家也都習慣了用短的命名，例如上述objc的application:didFinishLaunchingWithOptions:方法在js里習慣的命名是:$()。
objc與js都是動態語言，使用起來還蠻像，但objc是編譯型，速度快，很多錯誤也能在編譯過程中被發現，js是解釋型，性能依賴於解釋引擎，即使在強勁的v8引擎下性能也趕不上編譯型語言，語言太動態，變數完全沒有類型，寫起來爽，debug起來稍微費點勁。一直感覺js輕巧靈活放盪不羈充滿各種奇技淫巧，objc中規中矩沒c++ java那麼嚴肅也沒有js那麼靈活。
線程
前端開發幾乎不需要線程這個概念，瀏覽器實現上頁面HTML和CSS解析渲染可能與js不在同一個線程，但所有js代碼只執行在一條線程上，不會並發執行，也就不需要考慮各種並發編程的問題。在新的JS特性中可以創建worker任務，這樣的任務是可以另起一條線程並行執行的，但由於並不是所有瀏覽器都支持，不同線程傳遞數據各個標準定的還不一樣，使用場景也少，似乎沒有大規模用起來。對於資料庫操作/發送網路請求這樣的任務是在不同於js代碼執行線程的，不過這些都由瀏覽器管理，前端無需關心也無法影響這些線程，只需接收事件回調，不需要處理任何並發問題。
終端開發需要大量使用多線程，iOS有一條主線程，UI渲染都在這個線程，其他耗時長的邏輯或者資料庫IO/網路請求都需要自己另開線程執行，否則會佔用主線程的時間，導致界面無法響應用戶交互事件，或者渲染慢導致滾動卡頓。程序邏輯分布在多個線程里跑，需要處理好各種代碼並發執行可能帶來的數據不一致/時序錯亂之類的問題，並發也導致有些bug難以排查，一不留神就掉坑，需要適當用一些隊列/鎖保證程序的執行順序。iOS提供了一套多線程管理的方法GCD，已經把線程和隊列封裝得非常簡單易用功能強大，比其他端或後台是好很多了，但還是會花大量功夫在處理多線程問題上。
存儲
終端開發需要大量的數據存儲邏輯，手機APP不像瀏覽器，用戶打開瀏覽器必定是連著網，但打開一個APP時很可能是離線，也很可能處於網路狀況極差的移動GPRS，所以必須把之前請求回來的數據保存好。保存數據後又需要與服務端最新的數據同步，如果全量同步數據量太大，耗流量速度也慢，於是需要增量同步，需要與服務端一起制定實現增量數據返回的方案，需要處理好客戶端與服務端數據一致性的問題。當數據存儲量大結構復雜時，還需要利用好有限的內存做cache，優化各類存儲查詢性能。
前端在桌面端很少需要存儲，除非是Single Page App，不存儲自然就不需要數據更新的一系列工作，數據都是從後台取出拼接後直接顯示到頁面上，即使像微博有可以在頁面內不斷載入更多數據，數據也只存在於內存，不會持久化存儲，因為桌面端網速穩定，不計流量，所有數據可以直接從後端拿取，客戶端沒必要再做一套存儲。移動端那些做得很像原生APP的Web應用就跟終端開發一樣了，數據同樣保存到sqlite，存儲邏輯以及要處理的問題都差不多。
框架
在第三方框架上Web前端和iOS開發完全相反，Web原生弱小又十分開放，讓大量第三方框架和類庫可以施展拳腳，而iOS原生強大又十分封閉，導致第三方框架沒有多少生存空間。
瀏覽器一開始只為內容型的網頁而設計，js也只是這個網頁上能加點小特效的腳本語言，在Web應用時代跟不上發展，需要很多第三方庫和框架輔助，再加上前端開發是完全開放的領域，導致庫和框架百花齊放多如牛毛，在初期多數庫的作用集中在封裝dom操作，大家不斷重復造dom操作基礎庫的輪子，在一段時間百家爭鳴後獨尊jQuery，在有使用庫的網站中90%以上使用jq，幾乎成了個標准基礎庫。後期大家已經不再重復造這個基礎庫的輪子了，多了一些代碼組織和前端架構的框架，例如一些幫助項目模塊化的框架require.js，MVC框架backbone/angular.js等。
iOS開發蘋果已提供了完整的開發框架cocoa，而這框架在每一代系統中都在升級優化和添磚加瓦，開發模式也已經定型，第三方框架沒有多少生存空間，大量流行的開源項目是一些通用組件和庫，像網路請求庫AFNetworking，資料庫操作庫FMDB。而一些大的框架像beeFramework/ReactiveCocoa較難流行起來。
兼容
前端開發需要兼容大——量的瀏覽器，桌面的chrome，safari，ie6-ie10，firefox，以及各種套殼獵豹360等瀏覽器，移動端iOS/Android各自的瀏覽器，以及無限的不同的屏幕尺寸。看起來挺可怕，實際上也沒那麼難搞，只是拿出來嚇唬下人。桌面端chrome/safari以及各種套殼的極速模式用的都是Webkit，差異很小，firefox也大體遵從標准實現，與Webkit差別不大，舊的ie6/7就需要特別照顧，不過很多網站都不支持ie6了，移動端更是一家親，全是Webkit，除了新特性上的支持程度不一，其他差異不大。對於不同的屏幕尺寸，高端點的會用響應式布局，針對不同屏幕尺寸自適應到不同布局，一般點的桌面端定死寬度，移動端拉伸自適應寬度就搞定。
終端開發也需要兼容各種不同的系統版本和手機尺寸，Android不用說，iOS也有3.5/4/4.7/5.5/9.7英寸這些尺寸，不過兼容起來跟Web一樣挺容易，就是自適應寬度，iOS的UIKit把這些都處理好了，還有autolayout，sizeClass等高級特性可用，在尺寸上並不用花太多功夫。系統版本上iOS7為分水嶺，iOS7前後版本UI上差異比較大，需要做一些功夫兼容，不過iOS用戶更新換代很快，預計再過一兩年iOS7以下用戶就可以忽略了。
性能
終端和前端都是面向用戶的，性能優化目的都是盡快呈現內容，以及讓程序在用戶操作下流暢運行。終端主要關注的是存儲/渲染性能。當一個APP存儲數據量大，數據關系復雜時，數據查詢很容易成為性能瓶頸，需要不斷優化數據存取的效率，規劃數據IO線程，設計內存cache，利用好終端設備有限的內存，渲染上避免重復渲染，盡可能復用視圖，尋找最高效的渲染方案。
前端關注頁面載入速度，由於Web頁面的結構/樣式/程序/資源圖片都是實時請求的，要讓頁面更快呈現內容，就要優化這些請求，讓這些資源以最快速度載入下來，包括合並圖片/合並代碼減少請求數，壓縮代碼，並行請求，根據版本號緩存代碼請求，gzip壓縮，模塊/圖片懶載入等。此外跟終端一樣也關注渲染性能，遵從一些規則避免頁面reflow，避免使用CSS陰影這樣耗性能的特效，用CSS3動畫代替js等。
編譯
終端開發需要編譯的過程，把程序編譯成機器語言，再與各種庫鏈接後生成平台對應的可執行文件，最後由操作系統調度執行。在iOS終端開發中編譯和鏈接的規則蘋果已經在xcode這個開發工具上封裝好，一般開發可以不用關心，但有深層需求時還是需要跟編譯打很多交道，例如用編譯前端Clang自定義靜態代碼檢測規則，寫編譯腳本做自動化編譯和持續集成，打包生成靜態庫，根據鏈接後的可執行文件的組成優化APP體積等。
前端開發的程序則不需要編譯過程，只需要把代碼扔給瀏覽器，瀏覽器邊解析代碼邊執行。雖然js/css代碼寫完無需做任何事情瀏覽器就可以解析執行，但為了上面說的性能優化，前端代碼上線前會對所有代碼和資源文件進行處理，這些處理包括：壓縮合並js/css，合並css sprite圖，處理模塊依賴，處理代碼資源版本號，處理資源定位等。這個過程很像傳統程序的編譯，把給人看的代碼優化處理成給機器看的，並解決一些依賴關系，可以算是前端的編譯過程。像grunt.js/fis這些工具可以幫助完成這個編譯過程，通常前端編譯跟上線部署結合在一起，作為上線系統的一部分。
安全
前端和終端的安全性問題上雖然不需要像後端考慮得那麼多，但還是有些需要注意。在請求的安全上，終端和前端都一樣，用戶向後端發送的請求都需要經過層層路由，不知道在哪裡就被截獲篡改或回放了，於是需要做一些措施防禦這些情況，最常見的就是身份驗證，多是採用會過期的token形式代替用戶名密碼，防止被抓包後黑客可以永遠登陸這個賬號。數據安全要求高的會用加密傳輸，或者使用https，另外還需要看情況處理一些DNS劫持，運營商廣告植入等問題。
其他安全問題終端很少考慮，在未越獄的iOS機器上系統已經幫忙保證了整個APP運行環境的安全，而在越獄的機器下惡意程序擁有root許可權可以做任何事情，APP也難以防範。前端方面瀏覽器的特性使前端開發有幾個安全隱患，一是Web頁面上任意位置都可以動態插入js代碼，瀏覽器會無區別地執行這些代碼，二是身份驗證信息都統一保存在cookie里，三是頁面上可以隨意通過iframe嵌入其他網站的頁面。造成XSS、CSRF、cookie劫持這些攻擊手段，所以前端寫代碼時都需要考慮還這些安全問題，做好相應的防範，最簡單和重要的防範就是對所有用戶輸入輸出的內容做完整的過濾，避免頁面內被嵌入惡意代碼。
交互/開發
最後說下對這兩個領域在交互和開發上的個人感觸。以前在做Web前端時，感覺Web讓人機交互倒退了十年，交互都是硬邦邦的點擊—啪一下出來結果，滾動是一格格地刷新，很多人當時在鼓吹html5可以做出多麼炫的效果時，實際上FLASH在十年前就可以做出來了，還比最現代的瀏覽器更流暢。iPhone流行後，人機交互終於恢復了應有的水平，體驗上比Web流暢太多，指尖交互/流暢的動畫/便捷的滑動手勢/無限制的實現，主流終於恢復或超越了十年前Flash的水平。
但人機交互提升了，開發方式卻大倒退，Web的開發方式非常先進，用戶用到的都是最新版本，發現bug可以馬上上線秒修復，特別適用於互聯網環境下的快速迭代，而終端APP不行，撇開iPhone的審核不說，Android也無法做到保證用戶用的是最新的程序，用的都是傳統的客戶端更新的方式，bug的修復版無法及時給到用戶，無法一天上線幾十次，需要維護很多舊版本，開發方式倒退回Web時代以前。這都是因為移動網路不穩定以及流量有限造成的，移動端無法像桌面端瀏覽器那樣完全依賴網路，所以在移動網路穩定流量免費之前，開發方式都不會有多大變化。
另外並不看好HTML5，網路上說它可以取代APP說了三四年，到現在也沒什麼戰績，我看不到它的優勢，原生APP可以獲得更多的系統資源，更流暢的人機交互體驗，HTML5在這方面永遠比不上，而它在移動端網路和流量的限制下也無法發揮Web的開發優勢，所以它不會成為主流，只適合做一些輕量的小東西。

㈢ ios 怎麼用數據持久化鎖nt型數據

OS中的數據持久化方式，基本上有以下四種：屬性列表、對象歸檔、SQLite3和Core Data

NSUserDefaults，用於存儲配置信息
SQLite，用於存儲查詢需求較多的數據
CoreData，用於規劃應用中的對象
使用基本對象類型定製的個性化緩存方案
1.屬性列表
涉及到的主要類：NSUserDefaults,一般 [NSUserDefaults standardUserDefaults]就夠用了

@interface User : NSObject <NSCoding>
@property (nonatomic, assign) NSInteger userID;
@property (nonatomic, ) NSString *name;
@end
使用方法
1).分開存取
// 存
[[NSUserDefaults standardUserDefaults] setInteger:userID forKey:@」userID」];
[[NSUserDefaults standardUserDefaults] setObject:name forKey:@」name」];
// 取
NSInteger uId = [[[NSUserDefaults standardUserDefaults] integerValueForKey:@」userID」];
NSString* name = [[NSUserDefaults standardUserDefaults] stringForKey:@」name」];

2).按對象存取
// 存
[[NSUserDefaults standardUserDefaults] setObject:self forKey:@」user」];
// 取
User* u = [[NSUserDefaults standardUserDefaults] objectForKey」@」user」];

2.對象歸檔
要使用對象歸檔,對象必須實現NSCoding協議.大部分Object C對象都符合NSCoding協議,也可以在自定義對象中實現NSCoding協議,要實現NSCoding協議,實現兩個方法:
- (void) encodeWithCoder:(NSCoder *)encoder 與 -(void)initWithCoder:(NSCoder *)encoder
同時,建議對象也同時實現NSCopying協議,該協議允許復制對象,要實現NSCopying協議須實現 -(id)WithZone:(NSZone *)zone 方法 。
@interface User : NSObject <NSCoding>
@property (nonatomic, assign) NSInteger userID;
@property (nonatomic, ) NSString *name;
@end
@implementation User
// 以下兩個方法一定要實現，不然在調用的時候會crash
- (void)encodeWithCoder:(NSCoder *)aCoder;
{
// 這里放置需要持久化的屬性
[aCoder encodeObject:[NSNumber numberWithInteger:self.userID] forKey:@」userID」];
[aCoder encodeObject:self.name forKey:@"name"];
}
- (id)initWithCoder:(NSCoder *)aDecoder
{
if (self = [self init])
{
// 這里務必和encodeWithCoder方法裡面的內容一致，不然會讀不到數據
self.userID = [[aDecoder decodeObjectForKey:@"userID"] integerValue];
self.name = [aDecoder decodeObjectForKey:@"name"];
}
return self;
}
// 使用方法
+ (BOOL)save {
NSError *error = nil;
// 確定存儲路徑，一般是Document目錄下的文件
NSString* fileName = [self getFileName];
NSString* filePath = [self getFilePath];
if (![[NSFileManager defaultManager] createDirectoryAtPath:filePath withIntermediateDirectories:YES attributes:nil error:&error]) {
NSLog(@」創建用戶文件目錄失敗」);
return NO;
}
return [NSKeyedArchiver archiveRootObject:self toFile:[fileName:userId]];
}
@end

3.SQLite3
SQLite是一個開源的嵌入式關系資料庫，它在2000年由D. Richard Hipp發布，它的減少應用程序管理數據的開銷，SQLite可移植性好，很容易使用，很小，高效而且可靠。
SQLite嵌入到使用它的應用程序中，它們共用相同的進程空間，而不是單獨的一個進程。從外部看，它並不像一個RDBMS，但在進程內部，它卻是完整的，自包含的資料庫引擎。 嵌入式資料庫的一大好處就是在你的程序內部不需要網路配置，也不需要管理。因為客戶端和伺服器在同一進程空間運行。SQLite 的資料庫許可權只依賴於文件系統，沒有用戶帳戶的概念。SQLite 有資料庫級鎖定，沒有網路伺服器。它需要的內存，其它開銷很小，適合用於嵌入式設備。你需要做的僅僅是把它正確的編譯到你的程序。
關於SQLite的開發資料較多，這里不再細說。只是建議不直接操作SQLite庫，而是採用一些開源的第三方庫來進行操作。比如：
FMDB:https://github.com/ccgus/fmdb.git
對SQLite都做了不錯的封裝。

4.Core Data
Core Data本質上是使用SQLite保存數據，但是它不需要編寫任何SQL語句。

要使用Core Data，需要在Xcode中的數據模型編輯器中設計好各個實體以及定義好他們的屬性和關系。之後，通過操作這些對象，結合Core Data完成數據的持久化：

NSManagedObjectContext *context = [appDelegate managedObjectContext];
NSError *error;
NSString *fieldName = [NSString stringWithFormat:@"test%d", i];
UITextField *theField = [self valueForKey:fieldName];
NSFetchRequest *request = [[NSFetchRequest alloc] init];
//創 建描述語句，需求Line對象。類似於在資料庫中限定為Line表。
NSEntityDescription *entityDescription = [NSEntityDescription entityForName:@"Line" inManagedObjectContext:context];
[request setEntity:entityDescription];
//創建限制性語句，類似於SQL語句中的 where lineNum = i
NSPredicate *pred = [NSPredicate predicateWithFormat:@"(lineNum = %d)", i];
[request setPredicate:pred];
NSManagedObject *theLine = nil;
NSArray *objects = [context executeFetchRequest:request error:&error];
if (objects == nil){
NSLog(@」There was an error!」);
// Do whatever error handling is appropriate
}
if ([objects count] > 0){ //如果符合條件的object存在，則取出
theLine = [objects objectAtIndex:0];
}
else { //如果不存在，則插入一個新的.
theLine = [NSEntityDescription :@"Line"
inManagedObjectContext:context];
[theLine setValue:[NSNumber numberWithInt:i] forKey:@」lineNum」]; //設置這個object的屬性，coredata會自動將其寫入sqlite
[theLine setValue:theField.text forKey:@"lineText"];
[request release];
｝
}

下面是其取數據的過程：

Core_Data_PersistenceAppDelegate *appDelegate = [[UIApplication sharedApplication] delegate];
NSManagedObjectContext *context = [appDelegate managedObjectContext];
NSEntityDescription *entityDescription = [NSEntityDescription entityForName:@"Line"
inManagedObjectContext:context];
NSFetchRequest *request = [[NSFetchRequest alloc] init];
[request setEntity:entityDescription];
NSError *error;
NSArray *objects = [context executeFetchRequest:request error:&error];
if (objects == nil)
{
NSLog(@」There was an error!」);
// Do whatever error handling is appropriate
}
//每一個對象在CoreData中都表示為一個NSManagedObject對象(類似於資料庫表中的每一行),他的屬性通過鍵/值 方式獲取
for (NSManagedObject *oneObject in objects)
{
NSNumber *lineNum = [oneObject valueForKey:@"lineNum"];
NSString *lineText = [oneObject valueForKey:@"lineText"];
}
[request release];

㈣ 使用fmdb資料庫來緩存數據會導致什麼問題

Winter is a cold season. Though the temperature is very low,but I like it ,I can play with my frends in the playground .I think I can watch TV at home instead of walking outside .So I like winter,because I can do something which is interesting.

㈤ FMDB 怎麼計算文件大小

（一）FMDB的基本介紹
FMDB 同時兼容ARC與非ARC工程，會自動根據功臣的配置來調整相關的內存管理。
FMDB常用類：
FMDatabase：一個單一的資料庫，用於執行SQL語句
FMResultSet:執行查詢一個FMDatabase的結果集
FMDatabaseQueue:在多個線程來執行查詢和更新資料庫的數據
（二）資料庫操作：
創建資料庫
建表（創建一張表）
增（向表中插入新數據inset or replace into）
刪（刪除表中數據delete）
改 (修改資料庫中當前已有的數據update)
查（查詢語句select）
總結：資料庫增刪改等操作：除了查詢操作，FMDB資料庫操作都執行executeUpdate方法，這個方法返回BOOL型。
資料庫查詢操作： 查詢操作使用了executeQuery，並涉及到FMResultSet。
(三)代碼學習
在實際項目中一般使用databaseQueue,
創建資料庫
- (void)openDBWithFileName:(NSString *)fileName dbName:(NSString *)dbName{
//首先判斷傳入的參數
if (!fileName.length || !dbName.length) {
return;
}
//獲取文件目錄
NSArray *paths = (NSDocumentationDirectory, NSUserDomainMask, NO);
NSString *documentDirectory =[paths firstObject];
NSString *pathDirectory = nil;
if (fileName.length !=0 ) {
pathDirectory = [documentDirectory :fileName];
}
// 創建文件夾
if (![[NSFileManager defaultManager] fileExistsAtPath:pathDirectory]) {
NSError *error ;
[[NSFileManager defaultManager] createDirectoryAtPath:pathDirectory withIntermediateDirectories:YES attributes:nil error:&error];//參數YES，表示不管有沒有這個文件夾都會去創建，如果參數為no，則 只會在沒有這個文件夾的時候才會創建
if (error) {
NSLog(@"%@",[error description]);
}
}
//創建資料庫
NSString *dbPath = [pathDirectory :dbName];
if (!_dbQueue) {
NSLog(@"%@",[FMDatabaseQueue databaseQueueWithPath:dbPath]);
self.dbQueue = [FMDatabaseQueue databaseQueueWithPath:dbPath];
NSLog(@"%@__open",self.dbQueue);
}
}
插入數據

㈥ ios測試和web端測試的區別

ios測試和web端測試的區別:

一、語言
前端和終端作為面向用戶端的程序，有個共同特點：需要依賴用戶機器的運行環境，所以開發語言基本上是沒有選擇的，不像後台想用什麼就用什麼，iOS只能用object-c，前端只能javascript，當然iOS還可以用RubyMotion，前端還能用GWT/CoffieScript，但不是主流，用的人很少，真正用了也會多出很多麻煩。iOS還可以用蘋果新出的swift語言，後面可能用於取代object-c，還處於起步階段，先不討論。
objc和js這兩者有個有意思的對比：變數/方法命名的風格正好相反。蘋果一直鼓吹用戶體驗，寫代碼也不例外，程序命名都是用英文全稱並且要多詳細有多詳細，力求看變數和方法名就能知道是幹嘛的，例如application:didFinishLaunchingWithOptions:。而js因為每次都要從網路下載，要力求減少代碼體積，所以變數方法名是盡量用縮寫，實際上有代碼壓縮工具，無論變數名寫多長最終上線的效果是一樣的，但大家也都習慣了用短的命名，例如上述objc的application:didFinishLaunchingWithOptions:方法在js里習慣的命名是:$()。
objc與js都是動態語言，使用起來還蠻像，但objc是編譯型，速度快，很多錯誤也能在編譯過程中被發現，js是解釋型，性能依賴於解釋引擎，即使在強勁的v8引擎下性能也趕不上編譯型語言，語言太動態，變數完全沒有類型，寫起來爽，debug起來稍微費點勁。一直感覺js輕巧靈活放盪不羈充滿各種奇技淫巧，objc中規中矩沒c++ java那麼嚴肅也沒有js那麼靈活。

二、線程
前端開發幾乎不需要線程這個概念，瀏覽器實現上頁面HTML和CSS解析渲染可能與js不在同一個線程，但所有js代碼只執行在一條線程上，不會並發執行，也就不需要考慮各種並發編程的問題。在新的JS特性中可以創建worker任務，這樣的任務是可以另起一條線程並行執行的，但由於並不是所有瀏覽器都支持，不同線程傳遞數據各個標準定的還不一樣，使用場景也少，似乎沒有大規模用起來。對於資料庫操作/發送網路請求這樣的任務是在不同於js代碼執行線程的，不過這些都由瀏覽器管理，前端無需關心也無法影響這些線程，只需接收事件回調，不需要處理任何並發問題。
終端開發需要大量使用多線程，iOS有一條主線程，UI渲染都在這個線程，其他耗時長的邏輯或者資料庫IO/網路請求都需要自己另開線程執行，否則會佔用主線程的時間，導致界面無法響應用戶交互事件，或者渲染慢導致滾動卡頓。程序邏輯分布在多個線程里跑，需要處理好各種代碼並發執行可能帶來的數據不一致/時序錯亂之類的問題，並發也導致有些bug難以排查，一不留神就掉坑，需要適當用一些隊列/鎖保證程序的執行順序。iOS提供了一套多線程管理的方法GCD，已經把線程和隊列封裝得非常簡單易用功能強大，比其他端或後台是好很多了，但還是會花大量功夫在處理多線程問題上。

三、存儲
終端開發需要大量的數據存儲邏輯，手機APP不像瀏覽器，用戶打開瀏覽器必定是連著網，但打開一個APP時很可能是離線，也很可能處於網路狀況極差的移動GPRS，所以必須把之前請求回來的數據保存好。保存數據後又需要與服務端最新的數據同步，如果全量同步數據量太大，耗流量速度也慢，於是需要增量同步，需要與服務端一起制定實現增量數據返回的方案，需要處理好客戶端與服務端數據一致性的問題。當數據存儲量大結構復雜時，還需要利用好有限的內存做cache，優化各類存儲查詢性能。
前端在桌面端很少需要存儲，除非是one page app，不存儲自然就不需要數據更新的一系列工作，數據都是從後台取出拼接後直接顯示到頁面上，即使像微博有可以在頁面內不斷載入更多數據，數據也只存在於內存，不會持久化存儲，因為桌面端網速穩定，不計流量，所有數據可以直接從後端拿取，客戶端沒必要再做一套存儲。移動端那些做得很像原生APP的web應用就跟終端開發一樣了，數據同樣保存到SQLite，存儲邏輯以及要處理的問題都差不多。

四、框架
在第三方框架上web前端和iOS開發完全相反，web原生弱小又十分開放，讓大量第三方框架和類庫可以施展拳腳，而iOS原生強大又十分封閉，導致第三方框架沒有多少生存空間。
瀏覽器一開始只為內容型的網頁而設計，js也只是這個網頁上能加點小特效的腳本語言，在web應用時代跟不上發展，需要很多第三方庫和框架輔助，再加上前端開發是完全開放的領域，導致庫和框架百花齊放多如牛毛，在初期多數庫的作用集中在封裝dom操作，大家不斷重復造dom操作基礎庫的輪子，在一段時間百家爭鳴後獨尊jQuery，在有使用庫的網站中90%以上使用jq，幾乎成了個標准基礎庫。後期大家已經不再重復造這個基礎庫的輪子了，多了一些代碼組織和前端架構的框架，例如一些幫助項目模塊化的框架require.js，MVC框架backbone/angular.js等。
iOS開發蘋果已提供了完整的開發框架cocoa，而這框架在每一代系統中都在升級優化和添磚加瓦，開發模式也已經定型，第三方框架沒有多少生存空間，大量流行的開源項目是一些通用組件和庫，像網路請求庫AFNetworking，資料庫操作庫FMDB。而一些大的框架像beeFramework/ReactiveCocoa較難流行起來。

五、兼容
前端開發需要兼容大——量的瀏覽器，桌面的chrome，safari，ie6-ie10，firefox，以及各種套殼獵豹360等瀏覽器，移動端iOS/Android各自的瀏覽器，以及無限的不同的屏幕尺寸。看起來挺可怕，實際上也沒那麼難搞，只是拿出來嚇唬下人。桌面端chrome/safari以及各種套殼的極速模式用的都是webkit，差異很小，firefox也大體遵從標准實現，與webkit差別不大，舊的ie6/7就需要特別照顧，不過很多網站都不支持ie6了，移動端更是一家親，全是webkit，除了新特性上的支持程度不一，其他差異不大。對於不同的屏幕尺寸，高端點的會用響應式布局，針對不同屏幕尺寸自適應到不同布局，一般點的桌面端定死寬度，移動端拉伸自適應寬度就搞定。
終端開發也需要兼容各種不同的系統版本和手機尺寸，Android不用說，iOS也有3.5/4/4.7/5.5/9.7英寸這些尺寸，不過兼容起來跟web一樣挺容易，就是自適應寬度，iOS的UIKit把這些都處理好了，還有autolayout，sizeClass等高級特性可用，在尺寸上並不用花太多功夫。系統版本上iOS7為分水嶺，iOS7前後版本UI上差異比較大，需要做一些功夫兼容，不過iOS用戶更新換代很快，預計再過一兩年iOS7以下用戶就可以忽略了。

六、性能
終端和前端都是面向用戶的，性能優化目的都是盡快呈現內容，以及讓程序在用戶操作下流暢運行。終端主要關注的是存儲/渲染性能。當一個APP存儲數據量大，數據關系復雜時，數據查詢很容易成為性能瓶頸，需要不斷優化數據存取的效率，規劃數據IO線程，設計內存cache，利用好終端設備有限的內存，渲染上避免重復渲染，盡可能復用視圖，尋找最高效的渲染方案。
前端關注頁面載入速度，由於web頁面的結構/樣式/程序/資源圖片都是實時請求的，要讓頁面更快呈現內容，就要優化這些請求，讓這些資源以最快速度載入下來，包括合並圖片/合並代碼減少請求數，壓縮代碼，並行請求，根據版本號緩存代碼請求，gzip壓縮，模塊/圖片懶載入等。此外跟終端一樣也關注渲染性能，遵從一些規則避免頁面reflow，避免使用CSS陰影這樣耗性能的特效，用CSS3動畫代替js等。

七、編譯
終端開發需要編譯的過程，把程序編譯成機器語言，再與各種庫鏈接後生成平台對應的可執行文件，最後由操作系統調度執行。在iOS終端開發中編譯和鏈接的規則蘋果已經在xcode這個開發工具上封裝好，一般開發可以不用關心，但有深層需求時還是需要跟編譯打很多交道，例如用編譯前端Clang自定義靜態代碼檢測規則，寫編譯腳本做自動化編譯和持續集成，打包生成靜態庫，根據鏈接後的可執行文件的組成優化APP體積等。
前端開發的程序則不需要編譯過程，只需要把代碼扔給瀏覽器，瀏覽器邊解析代碼邊執行。雖然js/css代碼寫完無需做任何事情瀏覽器就可以解析執行，但為了上面說的性能優化，前端代碼上線前會對所有代碼和資源文件進行處理，這些處理包括：壓縮合並js/css，合並css sprite圖，處理模塊依賴，處理代碼資源版本號，處理資源定位等。這個過程很像傳統程序的編譯，把給人看的代碼優化處理成給機器看的，並解決一些依賴關系，可以算是前端的編譯過程。像grunt.js/fis這些工具可以幫助完成這個編譯過程，通常前端編譯跟上線部署結合在一起，作為上線系統的一部分。

八、安全
前端和終端的安全性問題上雖然不需要像後端考慮得那麼多，但還是有些需要注意。在請求的安全上，終端和前端都一樣，用戶向後端發送的請求都需要經過層層路由，不知道在哪裡就被截獲篡改或回放了，於是需要做一些措施防禦這些情況，最常見的就是身份驗證，多是採用會過期的token形式代替用戶名密碼，防止被抓包後黑客可以永遠登陸這個賬號。數據安全要求高的會用加密傳輸，或者使用https，另外還需要看情況處理一些DNS劫持，運營商廣告植入等問題。
其他安全問題終端很少考慮，在未越獄的iOS機器上系統已經幫忙保證了整個APP運行環境的安全，而在越獄的機器下惡意程序擁有root許可權可以做任何事情，APP也難以防範。前端方面瀏覽器的特性使前端開發有幾個安全隱患，一是web頁面上任意位置都可以動態插入js代碼，瀏覽器會無區別地執行這些代碼，二是身份驗證信息都統一保存在cookie里，三是頁面上可以隨意通過iframe嵌入其他網站的頁面。造成XSS、CSRF、cookie劫持這些攻擊手段，所以前端寫代碼時都需要考慮還這些安全問題，做好相應的防範，最簡單和重要的防範就是對所有用戶輸入輸出的內容做完整的過濾，避免頁面內被嵌入惡意代碼。

九、交互/開發
最後說下對這兩個領域在交互和開發上的個人感觸。以前在做web前端時，感覺web讓人機交互倒退了十年，交互都是硬邦邦的點擊—啪一下出來結果，滾動是一格格地刷新，很多人當時在鼓吹html5可以做出多麼炫的效果時，實際上FLASH在十年前就可以做出來了，還比最現代的瀏覽器更流暢。iPhone流行後，人機交互終於恢復了應有的水平，體驗上比web流暢太多，指尖交互/流暢的動畫/便捷的滑動手勢/無限制的實現，主流終於恢復或超越了十年前Flash的水平。
但人機交互提升了，開發方式卻大倒退，web的開發方式非常先進，用戶用到的都是最新版本，發現bug可以馬上上線秒修復，特別適用於互聯網環境下的快速迭代，而終端APP不行，撇開iPhone的審核不說，Android也無法做到保證用戶用的是最新的程序，用的都是傳統的客戶端更新的方式，bug的修復版無法及時給到用戶，無法一天上線幾十次，需要維護很多舊版本，開發方式倒退回web時代以前。這都是因為移動網路不穩定以及流量有限造成的，移動端無法像桌面端瀏覽器那樣完全依賴網路，所以在移動網路穩定流量免費之前，開發方式都不會有多大變化。
另外並不看好HTML5，網路上說它可以取代APP說了三四年，到現在也沒什麼戰績，我看不到它的優勢，原生APP可以獲得更多的系統資源，更流暢的人機交互體驗，HTML5在這方面永遠比不上，而它在移動端網路和流量的限制下也無法發揮web的開發優勢，所以它不會成為主流，只適合做一些輕量的小東西。

㈦ ios 第三方分享組件 哪個最好

網路通信
1、ASIHTTPRequest
這是一個經典的老庫，功能完全而強大，但已經停止更新很久了(iOS5.0停止更新，但是我最近看github上這個項目有新改動)。在不同iOS版本上略微有一些小問題(提醒顯示上的)，所以用的時候還是稍微修改一下比較好。
下載地址：https://github.com/pokeb/asi-http-request

2、AFNetworking
輕量級的通訊類庫，使用非常簡單。
下載地址：https://github.com/AFNetworking/AFNetworking
3、MKNetworkKit
最近做的不錯的一個通訊類庫，具有AFNetworking和ASIHTTPRequest雙方的優點，甚至功能更豐富一些，但是本人還沒有使用過。
下載地址：https://github.com/MugunthKumar/MKNetworkKit
Socket
1、CocoaAsyncSocket
CocoaAsyncSocket是用的最廣泛的socket開發庫，省略了程序員與CFNetwork接觸的時間，延長了程序員壽命。
下載地址：https://github.com/robbiehanson/CocoaAsyncSocket
2、SocketRocket
SocketRocket是Square開發的一個實現webSocket的庫，可以輕松的實現即時通信。
下載地址：https://github.com/square/SocketRocket
數據解析
1、SBJSON
SBJson的解析速度其實是比較慢的，但是不知道為什麼它卻是用的最廣的。
下載地址：

2、JSONKit
JSONKit解析速度上最接近iOS原生解析類，當然iOS5.0才開始支持原生解析，所以選擇一個庫還是很必要的。
下載地址：https://github.com/johnezang/JSONKit

3、TouchJSON
TouchJSON用的也比較廣泛.
下載地址：https://github.com/TouchCode/TouchJSON

4、json-framework
沒有用過。
下載地址：https://github.com/stig/json-framework
5、TBXML
TBXML是一套輕量級的DOM方式的XML解析類庫，有很好的性能和低內存佔用，不過它不對XML格式進行校驗，不支持XPath，並且只支持解析，不支持對XML進行修改。
下載地址：https://github.com/71squared/TBXML

6、TouchXML
TouchXML這也是一套DOM方式的XML解析類庫，支持XPath，不支持XML的修改。
下載地址：https://github.com/TouchCode/TouchXML

7、KissXML
KissXML這是一套基於TouchXML的XML解析類庫，只不過實現了支持XML的修改。
下載地址：https://github.com/robbiehanson/KissXML

8、GDataXML
GDataXML是Google開發的DOM方式XML解析類庫，支持讀取和修改XML文檔，支持XPath方式查詢。
下載地址：

第三方管理
1、fmdb
fmdb是一個資料庫管理庫，封裝了sqlite相關的sql語句，簡化資料庫操作。
下載地址：https://github.com/ccgus/fmdb
2、ssziparchive
ssziparchive與sstoolkit是同一個作者，這哥們兒簡直是個天才。
https://github.com/soffes/ssziparchive
3、ZipArchive
ZipArchive同樣是minizip的封裝。
https://github.com/mattconnolly/ZipArchive
4、Objective-Zip
Objective-Zip將Zlib和MiniZip用Objective-C進行了封裝，使用起來非常簡單。
https://github.com/flyingdolphinstudio/Objective-Zip
5、zxing
zxing是一個開源Java類庫用於解析多種格式的1D/2D條形碼。目標是能夠對QR編碼、DataMatrix、UPC的1D條形碼進行解碼。 其提供了多種平台下的客戶端。
https://github.com/zxing/zxing
6、ZBar
ZBar 是款桌面電腦用條形碼/二維碼掃描工具，支持攝像頭及圖片掃描，支持多平台包括 iPhone 手機。同時 ZBar提供了二維碼掃描的 API 開發包。
https://github.com/ZBar/ZBar
7、ObjQREncoder
ObjQREncoder 是 Objective-C 的二維碼的編碼器，用於生成二維碼圖像。
https://github.com/jverkoey/ObjQREncoder
8、OpenUDID
OpenUDID是iOS禁止使用系統UDID之後的新解決方法。
https://github.com/ylechelle/OpenUDID
9、RegexKitLite
RegexKitLite 是一個輕量級的 Objective-C 的正則表達式庫，支持 Mac OS X 和 iOS，使用ICU 庫開發。
https://github.com/wezm/RegexKitLite
10、STUtils
STUtils是一系列的工具集，包含了很多對於iOS原生類的擴展，當然也包含一個用於安全保存用戶密碼STKeyChain。
https://github.com/ldandersen/STUtils
11、scifihifi-iphone
scifihifi-iphone用於安全保存用戶密碼到keychain中。
https://github.com/ldandersen/scifihifi-iphone
12、sskeychain
sskeychain同scifihifi-iphone一樣，不過屬於輕量級。
https://github.com/soffes/sskeychain
13、SDWebImage
SDWebImage調用網站上的圖片，跟本地調用內置在應用包里的圖片一樣簡單。操作也很簡單。
https://github.com/rs/SDWebImage
14、umeng
umeng既有統計分析，也有社會化組件。但是統計分析的用戶數似乎明顯多於其社會化組件的用戶。
http://dev.umeng.com/analytics/ios/sdk-download

第三方UI
1、appirater
appirater是一個可以直接使用到任何iPhone應用中的開源類，用於提醒用戶在打開App時，對應用進行評論或打分。
下載地址：https://github.com/arashpayan/appirater
2、FDStatusBarNotifierView
FDStatusBarNotifierView 實現了在狀態欄中顯示自定義提醒信息的功能。
下載地址：https://github.com/frankdilo/FDStatusBarNotifierView
3、MTStatusBarOverlay
MTStatusBarOverlay 是一個定製的 iOS狀態欄，用於覆蓋系統默認的狀態欄。
下載地址：https://github.com/myell0w/MTStatusBarOverlay
4、iCarousel
iCarousel 是一個用來簡化在 iOS 上實現旋轉木馬時的視圖切換效果，支持 iPad，提供多種切換效果。
下載地址：https://github.com/nicklockwood/iCarousel
5、MBProgressHUD
MBProgressHUD就不多說了，偉大的菊花。
下載地址：https://github.com/jdg/MBProgressHUD
6、SVProgressHUD
SVProgressHUD是一個輕量級的菊花。
下載地址：https://github.com/samvermette/SVProgressHUD
7、MWPhotoBrowser
MWPhotoBrowser 實現了一個照片瀏覽器類似 iOS自帶的相冊應用，可顯示來自手機的圖片或者是網路圖片，可自動從網路下載圖片並進行緩存。可對圖片進行縮放等操作。
下載地址：https://github.com/mwaterfall/MWPhotoBrowser
8、ShareSDK
ShareSDK支持分享到新浪微博、微信好友、微信朋友圈、QQ好友、騰迅微博、QQ空間、人人網、開心網、豆瓣、搜狐微博、網易微博、簡訊、郵件、列印、拷貝等。但是由於這個SDK包很大，所以用的時候一定要精簡一下。下載地址：http://sharesdk.cn/Download