思考哪里可以推到重来
这篇讲的是，作者从一次规划伦敦旅行时遇到的打车痛点出发，引出了一个有趣的思考角度。当想到用Uber来解决传统出租车服务的低效环节时，他意识到这种“推倒重来”的思考方式本身就值得被提炼。 文章的核心并不是介绍Uber这个产品，而是借其成功重塑打车行业的案例，分享了一套极具操作性的“重新思考”心法。作者总结了六个关键问题，引导我们从识别不满开始，层层深入地剖析现有流程的症结：哪里效率低下？如果优化会怎样？整个流程为何如此设计？假设完全打破障碍何在？以及最终，一个理想的重构方案应该是什么样。 这更像是一篇关于思维训练的观点分享。它鼓励我们不满足于现状，主动去发现生活中那些“不太对劲”的环节，并尝试用系统化的方式去构想更好的解决方案。对于技术人或产品思考者而言，这套从具体痛点到抽象重构的思考步骤，提供了一个非常实用的创新思维脚手架。
iOS界面响应式布局方式对比
这篇技术文章探讨了iOS开发中界面响应式布局方案的演变与对比。作者指出，早期iPhone屏幕单一，开发者普遍使用绝对定位，无需考虑动态布局问题。但随着iPad和多分辨率iPhone出现，苹果推出了Auto Layout方案。 文章重点对比了Auto Layout及其社区改进（如Masonry）与新兴框架CocoaUI的不同设计哲学。Auto Layout本质是相对布局，但官方实现代码冗长、可读性差；Masonry等库虽用更“人话”的语法简化了代码，但仍未脱离相对布局需要依赖相邻控件关系的固有缺陷。 相比之下，CocoaUI借鉴了Web的流式布局思想，主张每个控件自主完成自身布局，无需关心其他控件。文章通过代码示例直观展示，仅需一行代码即可实现Auto Layout中数十行的内边距设置。此外，CocoaUI还支持从HTML/XML文件直接加载界面并预览，进一步提升了开发效率。作者最终推荐开发者尝试CocoaUI，以更简洁直观的方式解决动态布局难题。
Android利用webView调用JavaScript
在Android混合开发中，WebView是连接Java与JavaScript的桥梁。这篇文章具体演示了实现双向调用的四个核心场景：首先是Android端如何主动执行网页脚本，只需一行代码启用JavaScript并调用`loadUrl`；接着是网页如何触发Java方法，关键在于`addJavascriptInterface`创建可交互的对象；文章进一步深入到参数传递，比如Java向JS函数传参，以及JS向Java方法传参时，需要注意参数应为final类型或使用中间变量处理。 这些示例清晰地展示了交互的基本模式。值得注意的是，自Android 4.2起，`addJavascriptInterface`方法已引入安全更新，以防止潜在漏洞。对于需要频繁进行原生与Web内容交互的开发者来说，掌握这些基础调用方式是构建复杂混合应用的第一步，能为后续的架构设计打下坚实基础。
微信webview模拟器
作者从微信webview开发调试的痛点出发：JSAPI无法调试、登录态难模拟、手机与PC开发环境难以互通。安卓模拟器方案又过于笨重。为此，他提出一个轻量级的解决方案：一个运行在Chrome浏览器中的“微信webview模拟器”插件。 这个工具的巧妙之处在于实现方式。它通过浏览器书签栏执行一段JS脚本，动态在当前页面绘制一个模拟的iPhone外壳，并用iframe加载待调试的网页。关键的一步是，利用同域策略向iframe内部注入模拟的`WeixinJSBridge`对象，并触发`WeixinJSBridgeReady`事件，从而“欺骗”网页认为自己运行在微信环境中。 效果立竿见影：开发者现在可以直接在PC上连接内网开发机或本地页面进行调试。所有JSAPI的调用参数都会在控制台清晰打印，收藏、分享到朋友圈等常用操作也模拟出了UI界面。这套方案绕开了环境与资源的限制，让微信网页调试变得像调试普通网页一样直接方便。
如何做Xcode工程的工程化管理
这篇讲的是如何系统化地管理Xcode工程，解决多人协作时常见的混乱与低效问题。作者从项目代码冲突频繁、依赖管理繁琐、多环境打包易出错等实际痛点出发，分享了一套实战经验。 核心方案分为几个层面：对于大型团队，建议用子Project或Workspace搭配多个Project来划分功能模块，这能有效降低单一project.pbxproj文件的冲突概率。第三方库统一交由CocoaPods管理，显著减少了维护成本。针对多渠道、多测试环境的需求，利用Build Configuration来区分配置，并配合创建与之对应的Scheme来管理打包和执行流程。最后，通过编写xcodebuild命令行脚本，可以一次性完成多个渠道包的构建，大幅提升效率。 整套方法围绕“降低冲突、规范流程、自动化打包”展开，作者强调了共享Scheme和命令行打包在团队协作中的实用性。这些措施将工程管理从依赖个人自觉提升到了流程化的层面，有助于在复杂项目中保持秩序。
iOS 8/Android/WP 系统设置的用户体验对比
这是一篇关于三大移动操作系统设置界面对比分析的知识点类文章。作者从屏幕空间占用、内容长度等实际维度切入，剖析了iOS 8、Android KitKat与Windows Phone 8.1在交互设计上的核心取舍。 文章指出，iOS的固定菜单与Home Button组合仅占11%屏幕空间，是最高效的方案。Android因虚拟按键占用达18%，但通过沉浸模式等方案寻求突破。而Windows Phone的系统栏占用了高达23%的屏幕，空间效率最差。在设置项结构上，iOS采用清晰的层级分类，Android依赖长列表，Windows Phone则通过横向 pivot 实现扁平化导航。 作者的结论很明确：设计不仅是美观，更是对空间、效率和复杂功能的平衡。这篇文章没有空谈理论，而是用数据和交互细节说话，为产品设计者提供了关于如何在约束条件下构建清晰信息架构的实战思路。
使用CocoaPods进行Xcode的项目依赖管理
这篇讲的是如何用CocoaPods管理Xcode项目的依赖关系。作者首先将CocoaPods类比为iOS生态中的Maven，但强调了其更大的灵活性——它不仅能管理官方仓库的库，还支持直接依赖本地库或指定的Git仓库，这一点与Gradle的思路相似。 文章接着从安装讲起，提示了Mac系统自带Ruby的便利性，并特别指出国内网络环境下安装和更新时可加上`--verbose`参数以观察进度。核心部分围绕`Podfile`展开，通过具体代码示例演示了如何声明对不同来源库的依赖。一个实用的技巧是：若项目存在多个Target，需要为每个Target单独声明依赖关系，否则配置仅对首个Target生效。 对于希望发布自定义库的开发者，文章详细解析了如何编写`PodSpec`文件。它不仅指导如何指定源文件、头文件和ARC设置，还给出了依赖`.framework`、打包资源文件以及利用`subspec`实现项目模块化的进阶示例。这些细节让文章超越了基础入门，提供了可直接参考的实战配置方案。
ios webview 相关
这篇讲的是开发者在iOS原生开发中，通过Objective-C操作WebView加载页面时遇到的两个典型“坑”及其排查过程。 第一个问题是关于携带Cookie的WebView加载。当需要传递带有HTTPOnly标记的登录Cookie时，发现NSHTTPCookie本身并不支持设置这个标记。作者的解决方案是绕开API限制，手动在请求头中拼接Set-Cookie字段，并详细演示了如何在加载前清理旧Cookie、在加载后构建并存储带有httponly标记的Cookie对象，确保了安全性和功能同时生效。 第二个问题涉及URL的细微变化。当页面内的JavaScript行为导致URL从“index.php”变为“index.php#”时，WebView的回调机制出现了异常：只会触发`shouldStartLoadWithRequest`，而不会触发`webViewDidFinishLoad`。这意味着如果开发者在此回调中管理“加载中”提示框，该弹窗可能无法自动隐藏，导致用户体验中断。文章指出了这个容易被忽略的加载状态管理时机问题。 文章最后坦言可能有更好的解决方案，并鼓励读者交流分享，体现了在复杂移动端环境中，对WebView这类“水很深”的组件进行细致调试与经验积累的重要性。
用吐槽的方式生产内容
这篇文章从网易造楼团和IT自媒体人三表的吐槽风格出发，深入探讨了“吐槽”这一表达形式如何演变为一种专业的内容生产模式。作者指出，与严肃的批判不同，吐槽式内容短小精悍、贴近受众，擅长在碎片化阅读场景中传递信息，因此被腾讯新闻哥、网易轻松一刻等移动端产品广泛采用。 文章的核心观点在于，这种看似轻松的“轻阅读”背后，实则有着相当的生产门槛。它不仅需要专业团队对信息进行提炼与再创作，更依赖于平台用户基数来支撑众包生产，形成“专业策划（PGC）+大众智慧（UGC）”的混合模式。尽管这种模式能有效吸引流量，但如何实现商业变现仍是一个待解的难题。 作者最终将吐槽式内容的兴起，视为传统门户网站在移动时代留住分散用户的一次重要尝试。在注意力日益稀缺的当下，这种用轻松姿态完成信息迁移的策略，为内容生产者提供了新的思路。
让安卓手机通过代理翻墙的方法
这篇讲的是作者为解决小米3手机无法连接Google Play商店的问题，摸索出的一套安卓手机代理翻墙方案。作者的电脑一直通过PuTTY连接海外主机建立的SOCKS v5代理正常上网，他尝试让手机通过同一局域网内的这个代理上网，却发现只有Dolphin浏览器成功，谷歌Play商店等大量应用依然无法连接。 问题的根因在于，部分安卓系统应用和商店无法识别纯SOCKS代理。作者最终找到了DeleGate这款开源工具，用一行命令将电脑上的SOCKS代理转换为HTTP代理。具体方法是在电脑端运行指令，将本地7070端口的SOCKS代理映射到8080端口的HTTP代理，然后在手机WLAN的代理设置里指向电脑IP的8080端口。 验证效果是，完成这个转换后，手机上所有应用都能正常联网，谷歌Play商店恢复了应用下载和更新功能。文章记录了从遇到问题、排查到最终找到可行解决方案的完整折腾过程。
Android桌面应用的设计探讨
The request was rejected because it was considered high risk
由「手机拍照」说开去
这篇讲的是作者从自身摄影产品的工作体验出发，重新梳理了「手机拍照」这一日常行为背后的动机与生态。文章认为，手机摄像头的演进，让影像记录从专业行为彻底融入了大众生活。 作者剖析了手机拍照的四种核心行为动机：为留住瞬间的“记录”、为社交展示的“分享与攀比”、受环境影响的“从众”，以及填补空闲的“娱乐”。其中特别分析了“自拍”风潮背后，个体（尤其是女性）对自我形象的关注与展示。 基于这些动机，文章勾勒出一条完整的移动拍照产品线：从拍照工具、图片处理到社区分享。作者指出，工具类应用（如美图秀秀、Camera360）需不断垂直化创新，而社区产品（如Instagram）则因同质化严重，需找到独特的切入点并解决粘性与增长难题。文章最后也触及了该生态在盈利模式上的普遍困境与探索。
实时监控Android设备网络封包
这篇讲的是如何让Android设备的网络抓包变得像直接在电脑上用Wireshark一样实时。作者从传统流程（先用tcpdump抓包存文件，再传回PC分析）的繁琐出发，提出了一种更高效的方案。 核心原理很巧妙：利用tcpdump生成标准libpcap格式数据，通过管道实时重定向到一个网络端口，然后在电脑端用netcat工具接收数据流，最终直接喂给Wireshark进行解析。整个过程只需在设备上执行一条包含tcpdump和netcat的指令，并在主机上设置端口转发和Wireshark读取命令即可完成。 文章具体给出了关键命令，包括需要root权限执行的部分，以及对端口设置的提醒。对于不同系统（如Mac）可能需要的额外权限（sudo）也有提及。这种方法实现了近乎实时的网络流量监控，省去了文件中转的步骤，为Android网络调试提供了更直接、高效的工具链思路。
高性能Android Canvas游戏开发
这篇讲的是如何在Android平台的移动浏览器上，为Canvas游戏开发榨取极致渲染性能。文章核心观点是：性能优化的关键，在于理解并利用Android Canvas独特的硬件加速机制——它与iOS的实现原理有根本区别。 作者首先点明，移动设备性能往往只有桌面端的十分之一，优化至关重要。但直接套用iOS的优化方案（如大量使用Off-Screen Canvas进行缓存）在Android上会适得其反。原因在于，iOS依赖IOSurface进行高效的GPU位拷贝，而Android的硬件加速Canvas底层是一个GL Texture，频繁创建多个小Canvas会造成显存碎片化，且GPU上下文切换开销巨大。 因此，文章提出了明确的优化规则：第一，必须针对Android而非iOS的机制进行优化；第二，保持网页DOM树尽可能简单，以将系统资源更多留给Canvas渲染。这些规则均建立在对底层渲染架构差异的深刻剖析之上，为开发者提供了具体、可操作的高性能Android Canvas游戏开发指南。
iOS push服务
这篇文章详细拆解了iOS推送服务的完整工作流程。作者从Provider、APNS和iPhone的三阶段交互模型入手，清晰阐述了Push通知如何从应用服务器最终抵达用户设备。 内容涵盖了从原理到实践的关键环节：包括如何将苹果的SSL证书与私钥文件，通过OpenSSL命令转换为适用于Java、PHP等服务端环境的PEM或P12格式；客户端注册推送、获取DeviceToken并处理通知的Objective-C代码示例；以及JSON格式Notification Payload的构成，明确了alert、badge、sound等字段的用法与字节限制。 文章还特别区分了开发与发布证书的用途，并附上了多种语言服务端实现的参考链接，最后简要提及了本地通知的创建方法，为开发者提供了一套从配置到实现的完整参考。
iOS设备唯一标识获取策略
这篇讲的是iOS开发中如何可靠地获取设备唯一标识。作者从苹果在iOS 7中开始屏蔽MAC地址（返回固定值02:00:00:00:00:00）这一背景出发，系统梳理了开发者曾用过的和现行的各种方案。 文章对比了UDID（已被苹果禁用）、UUID（会随App卸载而改变）、OPEN UDID（依赖其他应用存在）、以及苹果官方推荐的广告标示符IDFA（可被用户重置）和Vendor标示符IDFV（在特定条件下保持不变）等多种标识符。作者详细分析了每种方法的原理、优缺点及适用场景，例如IDFA适合广告追踪，IDFV适合同一开发商下的应用互联。 核心结论是，没有完美的单一方案。文章最终指出，一种相对稳健的做法是在应用首次启动时生成一个UUID，然后将其保存在iOS的Keychain中。Keychain数据不受App卸载影响，从而可以在应用重装后依然识别出是同一设备。这对于需要持久化用户身份（如免重复登录）的场景，提供了一个可行的折衷思路。
浅谈移动应用的广告模式
这篇讲的是移动广告如何让用户从“反感”转为“主动接受”。文章以一款名为“花钱Colormoney”的锁屏广告APP为例，它把广告图片设为锁屏壁纸，用户每次解锁就能获得几分钱的收益。作者算了一笔账：用户年收益可达324元，而广告商每天能获得高达300万次的展示和数万次点击。这种“返利”模式巧妙地将广告转化为用户收益，改变了传统广告的体验困境。 基于此，作者调研并梳理了四种体验较好的移动广告设计模式。除了常见的APP内插屏和信息流广告，文章重点分析了两种更创新的方案：一种是结合定位与海量数据的精准推送，例如苹果的iBeacon技术能在用户走进店铺时推送即时优惠；另一种就是以“花钱”为代表的返利类APP。文中还列举了雪佛兰的“Game Time”案例，它通过让用户在比赛广告时段答题赢奖，将等待时间转化为互动娱乐，并利用社交分享实现二次传播，实现了用户、品牌与平台的多赢。 文章的核心观点是，移动广告的未来在于精心的设计与价值的传递，让广告本身成为对用户有用或有趣的信息，而非单纯的干扰。
App的成本
这篇讲的是开发一款App背后隐藏的、远超想象的成本账。作者以iPhone版为例，拆解了从团队组建到运营推广的全过程。最小团队配置也需要后端、客户端、UI和产品经理各一人，但实际组建一支合格团队的时间成本极高，往往是项目最大的隐形支出。从开发到产品稳定，通常需要1-3个季度。 然而，真正的“成本无底洞”在于后续运营。作者指出，分发渠道依赖、社交传播的不确定性、产品生命周期短暂，以及大公司的快速复制，都意味着产品必须依靠持续的营销投入才能存活，这笔费用可能是初期人力成本的数倍。这种高投入、高风险的模式，迫使绝大多数应用追求“做大”，反而导致了产品同质化，抑制了市场创新。 文章最后，作者反思了行业“输不起”的创新困境，并预告将推动一系列不求商业价值、但求创意绽放的小型应用项目。这不仅是对现状的犀利剖析，也提出了另一种可能性：在追求规模之外，产品开发也可以是一场激发创造力的游戏。
手机应用/服务器开发的一些总结(二)
这篇讲的是自定义TCP socket开发中的实践经验与方案对比。作者从Android客户端和服务器端两个维度展开，重点讨论了阻塞与非阻塞socket的选型及具体实现中的“坑”。 Android端部分，作者对比了传统阻塞socket与NIO的使用差异，特别分享了NIO在实际业务中遇到的问题。例如网络断线时`finishConnect()`可能长时间阻塞，解决方案是通过`setSoTimeout`设置合理超时。同时也指出了NIO下`channel.read`不同返回值（如-1表示关闭、0表示无数据）的准确含义，这些细节对稳定开发至关重要。 Server端部分，作者分析了从Python标准库`ThreadingTCPServer`到异步框架tornado与gevent的演进。他指出，tornado的异步IO虽然性能高，但业务代码不能阻塞，使用起来有一定痛苦；而gevent则兼顾了性能与编码便利性。基于此，作者还封装了`tkola`和`gkola`两个库，采用类似Flask的装饰器风格来简化TCP server开发，并提供了清晰的代码示例。 总的来说，文章不仅梳理了不同场景下的技术选型逻辑，更分享了生产环境中的具体解决方案与开源工具，对从事移动端与服务器网络编程的开发者有较强的实用参考价值。
手机应用/服务器开发的一些总结(一)
这篇讲的是作者在Android客户端与服务器端开发中的一些实战积累，尤其聚焦于“用户数据存储”和“通信协议选择”这两个常见却关键的问题。 在通信协议部分，作者基于亲身体验，对比了四种常见方案。HTTP最简单但难以应对实时需求，尤其在移动网络下可能出现异常；WebSocket体验良好，能与现有HTTP服务器无缝结合；SocketIO虽然封装周全，但作者认为其过度兼容并不必要，且Python服务端在处理客户端断开连接时行为不符合预期；而原生Socket自定义协议灵活性最高，但开发难度也相应增大。 关于用户数据存储，作者以Django Model为例，展示了基础用户表的设计，并特别分享了一个处理联合登录（如Facebook）的技巧：不破坏原有User表结构，而是新建关联表。他建议谨慎使用外键，为未来可能的数据迁移或拆分留出余地。 作为系列文章的开篇，这篇总结没有泛泛而谈，而是通过具体的代码片段和协议优劣分析，为开发者提供了在项目初期做技术选型时的切实参考。