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的开发优势，所以它不会成为主流，只适合做一些轻量的小东西。