1. iOS調試WebView,簡單到無門檻
近來這段時間一直在寫內嵌在App中的Html,雖然在HBuilder中可以輕易的使用各種瀏覽器輕易調試Html,但是在Xcode中想調試Html卻並不容易.Xcode的圖形調試界面只能調試原生的UI.WKWebView和UIWebView只能顯示黑屏.如下圖所示.
使用Safari瀏覽器調試WebView比較簡單無需過多的程序配置,只需點擊幾個開關按鈕即可.
首先打開模擬器或者真機設置中"Safari瀏覽器"→"高級"→"Web檢查器"的開關 如下圖所示.
然後我們打開Mac電腦的Safari瀏覽器,打開系統偏好設置(快捷鍵 commond + ,)或者如下圖所示.
點擊菜單中的"高級",然後勾選"在菜單欄中顯示"開發"菜單".方便我們進行快速的調試.
這時候真機連接上數據線.或者開啟模擬器就能在菜單欄"開發"選項中找到我們的設備或者是模擬器.
接下來我們只需要跑起我們的工程進入對應的WebView頁面即可進行調試.
調試界面如下所示.
其實以前因為WebView使用的較少,調試都是有專門的前端同事來做.所以這方面不是很了解,現在這么一弄,確實又是一大助力 感謝各位大佬查看本篇博客.如果有任何問題,歡迎批評指導
2. iOS調試Webview
HTML、JS、CSS的Web三件套，時下占據了項目的主要業務部分，原生和JS的交互必不可少，下面總結iOS調試Webview的兩種方法：
1.在手機設置里，找到Safair瀏覽器，在高級里啟用Web檢查器；
2.Mac上Safair瀏覽器，在偏好設置高級選項底部勾選「在菜單欄中顯示開發菜單」；
3.手機連接Xcode工程，操作App跳轉到JS頁面，點擊Mac上的Safair瀏覽器，在開發選項下拉菜單中，找到手機名稱對應的html頁面即可進入調試器；
( 參考鏈接 ）
1.使用brew安裝 ios-webkit-debug-proxy
brew install ios-webkit-debug-proxy
若上面的命令不有效，嘗試下面的命令安裝
brew uninstall --force libimobiledevice ios-webkit-debug-proxy
brew install --HEAD libimobiledevice ios-webkit-debug-proxy
2.安裝成功後，在終端輸入下面的命令
ios_webkit_debug_proxy -f chrome-devtools://devtools/bundled/inspector.html
若有問題，報錯Could not connect to lockdownd. Exiting.: Permission denied，可輸入下面的命令，再次嘗試
sudo chmod -R 777 /var/db/lockdown/
3.保持終端命令連接狀態，在chrome瀏覽器中打開 localhost:9221 ，點擊真機選項；
4.操作App跳轉到JS頁面，下面兩種方式均可進入調試器：
(1)在Mac的chrome中刷新頁面，選中要打開的html連接，右鍵點擊「復制鏈接地址」，新建標簽頁，在地址欄粘貼地址，按enter鍵進入；
(2)直接在谷歌瀏覽器地址欄中輸入 chrome://inspect/#devices ，點擊Target下方的inspect進入；
備註：
（1）手機上也要安裝谷歌瀏覽器，否則終端可能無法連接到真機；
（2）復制JS頁面地址時，不要用cmd+c快捷鍵，要右鍵單擊「復制鏈接地址」，然後新建標簽頁，粘貼地址打開；
總結：
兩種瀏覽器相比較，雖然Safair調試器打開方便，但容易卡住，有時無法查看JS的變數值，甚至打斷點會閃退，建議使用Google Chrome瀏覽器調試方法。
3. web iou 需要cisco 什麼格式鏡像
一般系統格式就行啊，ios格式就行。。。
4. PT、GNS3、IOU這些模擬器各有什麼優點
PT是cisco官方開發的一款純軟體 因此對硬體要求極低 支持多平台
目前安卓 windows pc mac pc以及linux都有對應版本
缺點就是功能有限 只有初級部分 比較這軟體官方定義是完成CCNA
GNS3適合CCNP人士 CCIE有點困難 資源使用問題
GNS3使用的IOS運行設備 真實度幾乎和真機一樣 而且有著圖形化界面
也支持多平台pc機windows osx linux都有 而且支持加入虛擬機在拓撲
使得實驗更佳真實 還有就是GNS3不僅支持cisco設備還支持部分其它廠商設備
說了好處 缺點就是 交換機模擬很差 要麼用3640 3725等路由器加交換機模塊
要麼就是用官方給的IOU模塊實現 用著比較蛋疼
還有就是默認IOS使用的dynamips來實現 十分浪費CPU資源 如果不計算IDIE值
很容易就掛了
IOU 目前有2種說法
一個是GNS3 IOU 是GNS3官方的二層解決方案 不過現在也能放其它設備了 通過linux來運行設備
效率和windows我是沒感到明顯區別 但是資源使用比windows低了很多
還有就是Cisco IOS on Unix，它是運行基於SPARC晶元的SUNOS系統之上的，但是不支持在X86
平台之上運行。也就是說如果你要使用真正意義上的IOU，你至少需要一個Sun小型機才行，或者你
也可以通過Simics在X86上模擬了Sparc的Solaris，但是效率可能會不盡如人意。
這個適合CCIE 構建復雜的拓撲網路 但是沒有圖形化 上手是個難事 而且從0部署也很麻煩 雖然有現成虛擬機可以下載到
5. 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的開發優勢，所以它不會成為主流，只適合做一些輕量的小東西。