在iOS中使用icon font
作者在开发阿里数据iOS客户端时，面临着所有图标都采用传统背景图片方案带来的困境——为兼容普通屏与Retina屏，每个图标都需提供两种尺寸，大大增加了设计师的工作量。由此出发，文章探索了能否将Web上已广泛应用的icon font技术引入iOS开发，并给出了肯定的答案。 文章首先以KaushanScript字体为例，详细拆解了在iOS项目中添加并使用自定义字体的完整四步流程：导入字体文件、在.plist中注册、查找字体集名称、最终调用。掌握此原理后，作者以fontello图标库为例，进一步阐述了使用icon font的特殊之处：核心在于通过FontLab Studio等工具找到图标对应的unicode码（如“\U0000E802”），然后在代码中直接以该unicode字符串进行渲染。 这套方案不仅能轻松使用海量开源图标，更关键的是图标作为字体，其颜色、大小均可通过代码灵活控制，有效解决了多分辨率适配与设计成本问题。文章最后还提供了多个实用的图标字体库资源和示例代码，便于读者直接上手实践。
苹果信息推送服务（Apple Push Notification Service）使用总结
这篇讲的是如何在 iOS 应用中接入并实现苹果官方推送服务（APNS）。作者从 APNS 的核心概念出发，明确了它免费、但不可靠且有大小限制的特点，并梳理了其依赖硬件 token 的工作流程。 文章的重点在于配置和实现。它详细拆解了从申请开发者证书、配置 App ID 与 Provisioning Profile，到使用 OpenSSL 命令合并生成最终推送证书的每一步，特别指出了证书环节容易踩坑。随后，通过具体的 Objective-C 代码示例，演示了如何在客户端注册通知、获取设备 token，以及处理应用在不同状态下收到的推送消息。最后还附上了用 PHP 编写的简易推送测试脚本，形成了一个从配置到验证的完整闭环。 如果你正为 iOS 项目接入推送功能发愁，尤其是对复杂的证书配置步骤感到头疼，这篇实操指南能提供清晰的路线图和避坑参考。
[Android]用WebView访问证书有问题的SSL网页
这篇讲的是在Android开发中，使用WebView加载SSL证书有问题的网页时，如何绕过其默认的安全拒绝机制。核心问题在于，当网页证书过期、不正确或不被信任时，WebView会直接阻止页面加载，不像PC浏览器会弹出警告让用户选择。 要解决这个问题，关键在于重写WebViewClient的onReceivedSslError()方法。作者指出了一个极易踩坑的细节：在重写的方法里，必须直接调用handler.proceed()来忽略错误继续加载，并且**千万不要**调用super.onReceivedSslError()。这是因为父类的实现中包含了handler.cancel()，会导致加载失败，甚至可能引发段错误崩溃。 通过这个简单但实用的技巧，开发者就能让WebView加载那些因证书问题被系统拦截的网页，这在开发调试或处理特定网络环境时非常有用。
Android设计中的.9.png
这篇讲的是 Android 开发中用于适配多分辨率的特殊图片格式——.9.png。文章从解决图片拉伸变形问题的实际需求出发，对比了普通 PNG 与 .9.png 的核心差异。 作者通过图示清晰地拆解了 .9.png 文件外围的四条黑色线条：上、左边线定义可拉伸区域，下、右边线则标定内容显示区域。通过具体按钮的案例，演示了如何正确设置拉伸点以避免图形圆角或边框失真，以及如何划定内容区域让文字排版整齐。 文章还分享了一个实用技巧：若想制作一张不被拉伸的 .9.png，只需将拉伸点标注在透明像素上即可。最后，总结了输出 .9.png 的两种常用方法，并重点强调了两个易导致编译失败的关键细节——边缘像素必须纯黑或全透明，以及文件后缀名的正确格式。
从易信看大公司标配与虎口夺食
作者从网易与电信联合推出易信对抗微信这一事件出发，探讨了在即时通讯领域已被巨头牢牢把控的背景下，一个创业团队仍选择入局的意义与风险。 文章首先抛出核心困惑：在微信独大、同类产品厮杀惨烈的市场里，“小弟弟们”是否还有机会？作者通过回顾网易过往的多次尝试（如早期“泡泡”项目的兴衰、内部保密项目的无疾而终），揭示了大公司的典型打法——依靠资源与价格战进行“虎口夺食”，风险可控却难以真正创新。 文章进一步剖析了两种可能：其一，某些产品如博客、微博，即使做不成第一，也可能成为大公司生态的“标配”功能，服务于自身内容运营；其二，通过对市场进行细分（如早期网易博客的差异化路径），寻找未被完全满足的需求。然而对于关系链至上的IM产品，这条细分之路异常艰难。 对于创业团队，作者也指出一条可能的出路：若能在巨头的夹缝中成功细分市场，即便份额不大，未来也可能被大公司收购。最终，文章以一种冷静的观察者视角收尾，提出在微信如此稳健的攻势下，创新和细分都面临巨大挑战，留给读者对“红海”市场生存策略的深层思考。
创造流动的瞬间—探讨移动端交互动效设计
这篇文章从iOS 7这一标志性设计变革说起，探讨了移动端交互动效如何从“可有可无”的装饰，转变为塑造产品体验、跨越用户心中“情感阀值”的关键要素。 作者详细拆解了iOS 7中那些“创造流动的瞬间”：3D视差带来的景深、模拟现实物理运动的拟真动画、气泡碰撞的弹性效果、体现空间感的缩放与手势跟随。文章不仅停留在描述，更深入剖析了动效的五大核心作用：通过流畅过渡组织界面的时间演进、利用高效反馈减轻用户等待焦虑、增强“直接操纵”的直觉感、巧妙引导隐藏功能，以及最终升华品牌体验与情绪表达。 在此基础上，文章提出了一套实用的设计原则：顺应轻动画趋势、遵循自然运动规律、重视应用内整体动画编排、平衡效果与性能，并强调“恰到好处，服从体验”这一黄金法则。为了将这些理论落地，作者团队还实践性地开发了一款“交互动效库”工具，通过分类收录200余段视频案例，为设计师提供灵感、为开发提供参考代码，解决了动效设计在协作流程中的痛点。
[译文]关于移动Web性能的5个神话
Sencha的CEO Michael Mullany撰文回应了此前引发热议的“移动Web应用为何慢”一文，他指出该文数据虽基本正确，但解读存在偏差且忽略了更关键的图形性能。文章系统驳斥了五个关于移动Web性能的常见误解。 首先，移动Web性能瓶颈主要在于浏览器渲染优化、DOM操作和GPU加速，而非JavaScript本身。其次，过去四年超过50%的JavaScript性能提升源于软件优化，而非单纯依赖硬件升级。再者，移动浏览器性能远未停滞，不同浏览器在各自领域存在10倍以上的差距，优化空间巨大。同时，未来的硬件迭代将通过更快GPU、内存带宽和多线程并行化持续带来性能飞跃。最后，现代浏览器采用的增量垃圾收集机制已大幅改善停顿问题，垃圾回收不再是无法逾越的性能杀手。 作者结合iOS和Android设备长达四年的性能测试数据，展示了JavaScript与DOM操作性能的显著提升，这些进步远超摩尔定律预期。文章强调，优秀的开发者使用现代Web框架能够构建出体验流畅的移动应用，性能的持续进化让开发者对移动Web的未来充满信心。
arduino-蓝牙各种版本类型及费用对比
这篇讲的是Arduino项目里怎么选蓝牙模块。作者从市面上几家主要厂商如德州仪器、北欧半导体的产品线入手，梳理了蓝牙2.1+EDR、3.0和4.0（BLE）三个版本的核心差异。 蓝牙2.1+EDR是2006年后流行的经典款，胜在稳定好用；3.0的“秘密”是能借力WiFi传输，速度能快8倍；而4.0（BLE）则主打低功耗和60米传输距离，但作者也指出，它需要Android 4.3以上系统才能完整支持，对开发平台有一定要求。 除了技术对比，文章还点出了一个容易被忽略的现实问题：蓝牙BQB专利认证。作者提醒，产品若要出口欧美，这笔初次7500美元、年费5000美元的认证开销可能无法避免。不过好消息是，采用TI CC254x芯片的方案目前可以免专利费。 对于正在做无线连接的Arduino开发者，这篇文章清晰地帮你权衡了性能、功耗、兼容性与潜在的认证成本。
利用三轴加速器的计步测算方法
这篇讲的是如何让没有GPS的设备也能准确计步。目前大部分手机计步都依赖GPS，但在室内或无信号场景下就失灵了。作者提出直接利用设备内置的三轴加速器，通过分析x、y、z三轴的加速度数据来捕捉行走特征。 人的步行会在垂直和前进方向产生周期性加速度变化，轨迹近似正弦曲线。算法的核心在于对这条曲线进行峰值检测——当检测到加速度方向由正转负，即经过一个波峰时，就判定为一步。为了应对设备在手中或口袋里方向不定的问题，算法先计算三轴加速度的合矢量长度，确保无论设备怎么放都能得到稳定的曲线。 另一个关键是过滤干扰，比如手抖或故意摇晃设备产生的无效信号。文章给出了两个巧妙的过滤机制：一是设置最小步频阈值，人体最快步行频率约5Hz，间隔小于0.2秒的信号会被舍弃；二是设定加速度幅度阈值，过小的波动不计入有效步伐。 除了计步，这个基于加速度的方案还能扩展成测距、测速工具，甚至用于检测老人摔倒。它为移动健康监测提供了更灵活、不受环境限制的技术基础。
有趣的下拉刷新
这篇讲的是，一个看似普通的交互动作——下拉刷新，如何从功能性操作演变为品牌表达与创意设计的舞台。文章从Twitter获得下拉刷新专利的事件切入，梳理了这项由Tweetie创始人发明的操作如何风靡移动应用。 但作者没有停留在功能层面，而是敏锐地指出：下拉刷新已跳出基础功能，成为一种表现品牌和设计感的元素。文中将这些有趣的实践分为三类：与应用类型巧妙结合的，如拍照应用Cheeze中，下拉会唤出一只老鼠并拍照；与品牌元素深度绑定的，如Flickr的经典双色转圈、Google系产品围绕品牌色的动画、蚂蜂窝“嗡嗡”里振翅的小马蜂；以及完全结合应用整体风格进行创新的。 这篇文章带我们回溯了这个经典交互的源头，并展示了它在当下如何成为设计师的画布——一个小小的下拉手势，竟能承载如此多的巧思与品牌个性。
移动触屏的手指触发尺寸
这篇讲的是移动端设计中一个常被忽视却至关重要的细节：触摸目标的尺寸。文章从苹果、微软、诺基亚等平台各自不同的设计指南出发，指出现有建议（如44px、28×28px）普遍偏小，与用户手指的实际尺寸存在差距。 这种差距会导致用户体验上的明显问题：用户不得不频繁切换手指的按压部位，或用指尖精确定位，这降低了操作效率；当按钮过于密集时，误触邻近目标的概率也大大增加，尤其使用较宽的拇指操作时问题更甚。 作者引用麻省理工学院触摸实验室的研究数据，给出了更符合人体工学的参考值：成年人的食指平均宽度对应45-57像素，而拇指更宽，约72像素。以这些尺寸设计，既能保证操作的精准性，也能提供清晰的交互反馈，这与费茨定律中“目标越大，命中时间越短”的原则一致。 当然，文章也理性地指出，完全按照手指尺寸设计在屏幕有限的手机上并不现实。设计师需要根据屏幕空间与核心功能进行权衡，有时精简导航、减少目标数量，是比单纯放大按钮更可行的方案。
Objective-C 的对象模型
作者从自己的C++开发经验出发，对Objective-C的对象模型进行了梳理和对比。文章指出，Objective-C的消息传递语法（如`[obj message:param]`）比C++的函数调用更强调可读性，参数名称与方法名融为一体，减少了参数写错或遗漏的风险。 在类与对象的设计上，两者差异显著。Objective-C通过`@property`简化实现，并支持运行时动态绑定，使用`id`类型可以向任何对象发送消息。而C++的RTTI则更偏向静态的类型识别。作者特别提到了Objective-C独有的Category机制，它允许在不改变类内存布局的前提下，将方法拆分到不同模块中，这比C++的友元（friend）机制使用起来更为优雅。此外，协议（`@protocol`）类似于接口，但支持`@optional`方法，提供了更灵活的契约检查。 文章认为，Objective-C在基础库整合和语言扩展方式（利用`@`符号）上比C++更为简洁一致，其动态模型带来的灵活性，如今已能通过先进的编译技术弥补性能损耗。整体来看，Objective-C牺牲了部分静态确定性，换来了运行时的动态能力，试图在性能与灵活性之间找到独特平衡点。
使用xctool自动打包，测试xcode项目
这篇讲的是如何用Facebook开源的xctool命令行工具，来简化和优化Xcode项目的构建与测试流程。 作者开篇直接点明，xctool是用来替代苹果官方xcodebuild工具的利器。它的核心优势很清晰：一方面，它能像Xcode一样执行测试，但输出结果是结构化的，更适合自动化脚本解析；另一方面，它的编译输出带彩色高亮，可读性远超传统工具，能让你更快定位到构建错误。 文章随后给出了最实用的部分：通过`brew install xctool`即可轻松安装。而日常使用只需掌握三个核心命令——`archive`打包、`build`构建、`test`测试。每个命令都附带了明确的参数示例，指向工作区(.xcworkspace)和计划(Scheme)，照着替换就能立即上手。 整体来看，这篇文章为iOS开发者提供了一个清晰的“工具升级”路径。它没有停留在功能介绍，而是快速引导你完成从安装到基本使用的全过程，有效降低了尝试新技术工具的门槛。
Cocoa处理JSON转换, 兼谈计算机语言的哲学
作者从在Cocoa框架中使用NSJSONSerialization处理JSON转换时感到异常繁琐这一具体痛点出发，展开了一场关于编程语言设计哲学的讨论。他对比了Objective-C与PHP、JavaScript在核心操作上的体验差异：在PHP中，一个`json_encode()`与`json_decode()`就能直截了当完成任务；而在Cocoa中，开发者却不得不先处理NSData与字符编码的转换，并受限于顶层对象必须是数组或字典的约束。 这种对比引出了作者对“理想语言数据模型”的深层思考。他认为，字节数组（字符串）应统一且透明，数据本身是静态的，而解读方法才是赋予其意义的关键；映射表（字典）应保持“空间序”，即插入顺序即为可见顺序，这比无序的哈希表或强制的字典序对开发者更友好。他推崇像PHP和JavaScript那样，让最常用的操作（如数组操作）拥有最简洁的语法，避免为了所谓的“一致性”而让日常代码变得冗长。 文章并非单纯吐槽，而是在比较中提炼出语言设计的一些朴素原则：核心数据结构应与JSON等通用格式能自然映射，API应致力于降低常用场景的心智负担。最后，作者呼吁Cocoa开发者社区共同封装更易用的工具，并给出了一份融合类C语法、JavaScript数据模型及PHP/JS简洁API的“语言设计建议清单”。
iOS设备上高效演示APP原型的方法总结
这篇讲的是如何在iPhone上高效演示APP原型的方法对比与选择。作者从产品和设计师的实际需求出发，对比了POP、快现、Axure等多种原型工具的上手难度、功能性和效率，并重点分析了将Axure原型导入iOS设备演示的两种主流路径。 关键差异在于“Web APP模式”和“APP打开模式”。前者能生成桌面图标，还原初始体验，但依赖在线环境，存在原型信息安全顾虑。后者需要购买Atomic Web等应用，但支持离线演示，速度更快且更安全，作者个人更推荐这一方式。 文章不仅给出了工具和模式的横向对比，还深入到了具体操作细节：比如如何在Axure中设置生成参数以适配移动设备，演示时需要注意的页面命名规则，以及不同模式下的设计尺寸计算等。这些实操要点对于想要立即上手的读者非常实用，能帮助避免常见坑点，提升演示的真实感和流畅度。
移动开发之touch event篇
这篇讲的是移动端网页开发中，如何用好触控事件来优化交互体验。作者从移动设备流量已占北美网络总流量20%的背景出发，指出虽然手机浏览器能渲染桌面网页，但交互方式因缺少鼠标而大不相同。 文章核心梳理了三个基础触摸事件：`touchstart`、`touchmove`和`touchend`，并通过控制台日志演示了事件触发的顺序与包含的触摸点列表（`touches`, `targetTouches`, `changedTouches`）的区别。作者还深入探讨了几个实际开发中的关键点：如何一行代码检测浏览器触摸支持；在`touchend`中，离屏的触摸点仅存在于`changedTouches`列表；以及移动端“轻拍”如何被浏览器转化为单击事件。 特别值得一提的是，文章分析了在`touchmove`事件中使用`preventDefault()`来禁用页面默认滚动和缩放的最佳实践——这是实现诸如Canvas自由绘图等自定义手势的基础。作者通过几个可运行的Demo和截图，将抽象的事件模型变得直观可感，对需要处理多点触摸或自定义手势的前端开发者来说，是份清晰的入门与避坑指南。
微信的迭代
这是一篇关于产品迭代与市场策略的**事件复盘/观点类**文章。 这篇讲的是微信如何在早期激烈的竞争中，通过极快速的试错与迭代，最终找到核心功能并成长为国民应用。文章从战略角度回溯了微信的起点：为对抗KiK而在两个月内仓促推出的1.0版，因免费短信模式不符合国内运营商套餐环境而遇冷。随后，微信团队迅速调整，经历了1.2版图片分享的再次失利，才在2.0版押注语音通讯并初步获得市场回应。 真正的转折点发生在3.0版。在对手米聊拥有先发优势的情况下，微信没有跟风功能，而是依托资源推出了“查看附近的人”，这一LBS功能成为用户增长的爆发点，配合腾讯体系的强推，日增用户达到数十万级，迅速确立了优势。文章指出，4.0版“朋友圈”与开放平台的推出，标志着微信从通讯工具转向移动生活方式平台，彻底构筑了竞争壁垒。 作者的核心观点很清晰：没有对用户需求的精准把握和快速回正的能力，产品就可能失败；而一旦抓住核心价值，借助资源与平台化思维，则能构建难以撼动的生态。从一款功能单一的聊天工具到影响上亿用户的生活入口，这条道路的每一步都充满了对市场反应的冷静观察与果断调整。
TeamToy完全使用手册
这是一份姗姗来迟的TeamToy使用手册，作者从理念到实操完整梳理了这个为创新团队打造的效率工具。TeamToy的核心理念是“以事为核心”而非“以人为核心”，它将TODO列表设为默认界面，旨在提升团队效率而非增加干扰。文章详细阐述了其产品结构：核心功能聚焦于任务与多层次沟通，而插件体系则为项目管理、Bug追踪及各类服务整合提供了扩展空间。 技术上，TeamToy实现了全功能的接口化，并保持敏捷的更新节奏。它采用对非商业用户友好的GPL2开源协议，并强调用户可以完全自主掌控数据与部署。安装部分提供了清晰的路径：非技术团队可通过云商店快速部署，而自建服务器则需满足PHP、MySQL等特定环境要求，文中对配置文件修改等关键步骤给出了明确指引。 文章的后半部分转入“最佳实践”，以添加团队成员等操作为例，提供了具体、分步骤的图解说明。作者旨在帮助团队负责人快速建立自上而下的理解，避开常见问题，顺利启动并运用这个工具来优化协作流程。
IOS APP设计流程
这篇讲的是iOS应用从创意到上线的完整设计路径。作者将流程拆解为11个关键步骤，特别强调在App Store竞争激烈的环境下，必须首先验证创意的独特性与优化空间。 从定位开始，文章介绍了如何依据苹果的人机界面指南来确定应用特性，并通过“应用定义陈述”来聚焦核心功能。在进入视觉设计前，作者推荐先使用纸笔绘制产品草图，细致推敲使用场景与逻辑，再借助原型工具完成从低保真到高保真的演进，初期用黑白线条专注于布局与流程，后期再纠结细节。 设计阶段则提倡遵循iOS的质感仿真风格，注重简洁易用的信息呈现。文章也具体指出了ICON设计的尺寸要求与视觉一致性，并提醒开发者，若不自行编程，需制作详尽的设计指南与标注文件以供团队协作。整体流程从发散到收敛，为设计师提供了一个清晰的实操框架。
校园场景中的手机使用调研
这篇文章聚焦于一个具体而重要的研究课题：如何理解并满足大学生群体在校园场景下的手机使用需求。作者首先指出，手机的使用高度依赖场景，而在校园这个环境中，用户特征、使用上下文、应用偏好以及内容需求都呈现出独特的模式。 研究没有停留在泛泛而谈的层面，而是系统性地从多个维度展开调研。它试图厘清大学生人群的画像，深入挖掘他们在不同校园活动（如上课、课间、宿舍休息等）中的具体手机使用习惯，以及对于应用功能和内容的内在需求。文章的目的非常明确：为移动应用开发者和内容运营者提供扎实的数据参考，帮助他们设计出更贴合校园场景的产品和更精准的推荐策略。 简而言之，这篇文章为理解一个庞大且活跃的用户群体提供了场景化的分析框架和实用建议，对于从事教育科技、社交娱乐或工具类应用设计的读者来说，其中的发现或许能直接启发下一步的产品构思。