iOS和Android设计规范备忘表
这篇介绍了一个iOS与Android设计规范的对照表，作者认为这是目前较为清晰易用的参考资源。文章直接呈现了一个全面的对比图表，涵盖了两个平台在导航、交互、图标、排版等核心方面的设计差异。 例如，iOS的设计强调简洁和一致性，导航常置于底部，交互反馈偏向微妙动画；而Android更
标签：Android
共 139 篇相关文章
launchAnyWhere: Activity组件权限绕过漏洞解析(Google Bug 7699048 )
这篇讲的是一个影响安卓2.3至4.3版本的权限绕过漏洞——“launchAnyWhere”。作者从AccountManagerService的工作机制切入，揭示了一个严重的设计问题：当应用请求添加账户时，系统服务会调起认证应用并转发一个Intent，但这个Intent的内容完全由认证应用控制。如果请求方是系统应用（如“设置”），它就会在用户不知情的情况下，执行攻击者精心构造的Intent，从而启动任意未导出的Activity。 漏洞的巧妙之处在于其利用链非常简洁：攻击者通过特定Intent调起“设置”中的AddAccountSettings，就能让系统自动完成从触发到启动目标组件的全过程。文章列举了几个危害场景，例如绕过验证直接重置手机PIN码，或利用未导出的WebView加载恶意页面。这本质上是一个权限委托的信任链被恶意劫持的案例。 对于移动安全研究者而言，这篇文章清晰地展示了如何从一个合法的系统服务接口中，挖掘出突破进程隔离限制的攻击面。它提醒开发者，即使是系统服务的“便利”设计，也可能在无意中成为危险的权限提升通道。
近距离端详Android ART运行时库
这篇技术分析聚焦于Android平台从Dalvik虚拟机向ART运行时过渡的核心变革。文章从Google I/O大会的发布背景切入，指出传统Dalvik虚拟机在应对多核处理器、大内存等新硬件趋势时已显吃力，从而引出ART的诞生。 文章的核心，是将ART与Dalvik进行多维度对比。最关键的差异在于编译策略：ART采用预编译技术，在应用安装时一次性将字节码编译为本地机器码并存储，而Dalvik依赖于每次运行时的即时编译。这一改变带来了直接好处，例如性能测试显示代码执行效率可提升2到3倍，同时因减少了运行时编译开销而有助于延长设备续航。 另一个对比重点是垃圾回收机制。文章通过详实的日志对比了二者的表现：Dalvik的垃圾回收常导致数十甚至上百毫秒的停顿，引发明显的画面卡顿；而ART经过重新设计的垃圾收集器，能将这类停顿时间压缩到微秒级，卡顿现象得到极大改善。 文章也客观指出了ART的权衡之处，即首次安装或设备启动时的编译时间会变长，但这是用一次性的存储和时间成本，换取了应用运行期的长期性能收益。总体而言，这是一次为匹配现代硬件能力而进行的底层架构升级。
公关变局
这篇讲的是自媒体狂潮下，企业公关如何应对一场根本性的变局。作者以互联网企业为例，梳理了公关工作从只应对传统媒体，到扫描互联网信息，再到如今面对海量、偶发的自媒体批评的演变过程——核心难题是，过去那套联络机构媒体的方法论，在“人多势众”且“防不胜防”的自媒体面前已经严重失效。 为此，文章给出了四条实操建议。首先是心态转变，公关部门应从“企业的保护壳”变为“沟通管道”，主动安排产品、技术等内部专家与外部媒体人直接交流。其次是建立完善的议题管理预案，针对企业自身的“罩门”（如“996”文化）预设处理流程，避免危机中手忙脚乱、错误发言。 更重要的是，作者提出要从产品业务层面做出改变。他以腾讯在3Q大战后转向开放平台为例，指出公关能做的有限，最根本的办法是通过业务调整（如推出开放平台、建立内容分成机制）来“彻底消除那个罩门”，从而获得长久善意。最后，面对危机要保持耐心，议题管理不足时，一味求快反而可能引发更多争议点，使小事发酵。文章的结论很明确：公关不是学术问题，是必须正视自媒体力量的操作问题。
Android Wear设计指南
这篇讲的是Android Wear如何为智能手表这种“新形式”构建专属UI设计语言。作者开篇点明，可穿戴设备的交互核心围绕“建议”与“询问”两个方面展开。前者通过“上下文流”实现，用户垂直滑动查看一张张信息卡片，应用可将最相关的内容主动插入其中；后者则依赖“提示卡片”，用户通过语音“好的，Google”或上滑唤出一系列可点击的操作提示。 文章进一步阐释了贯穿设计的核心原则：设备应具备情境感知能力，做到信息呈现及时、简短且交互极简（如手势与语音），像一位懂你的私人助理，只在必要时打扰。这些原则具体落实在通知UI模式中：通知卡片需为“一瞥”而非阅读设计，优先级对应其紧迫性，允许最多三个操作按钮，并强调了图像在提供上下文信息时的作用与尺寸规范。 整篇指南清晰地描绘了如何将Android体验从手机屏幕延伸至手腕，强调通过智能、克制且直觉化的交互，让技术自然融入日常生活。
免费应用的精益分析
这篇文章从移动应用（尤其是游戏）复杂的变现模式出发，深入探讨了如何通过精益分析来理解业务。不同于简单的付费下载，通过内购、广告等组合方式盈利的模式，需要一套更精细的指标体系来导航。 作者系统梳理了开发者应关注的核心指标，从源头的下载量、应用商店位置，到关键的用户获取成本、打开率、活跃用户占比，再到最终的付费用户比例、每用户平均收益（ARPU）和用户生命周期价值（CLV）。文章特别强调了应用商店推荐（专题）的巨大推力，并以具体数据说明了其对排名和收益的显著提升。 分析中举了一个虚拟游戏的例子：月下载12300次，ARPU为3.2美元，月流失率15%，由此可算出用户生命周期约6.67个月，单个用户终身价值约21美元。这清晰地展示了如何将基础数据串联起来，计算投放回报、预估收入，从而做出更明智的决策。 最终，文章指向了一个平衡的艺术：开发者不能只盯着短期收益而设计“抢钱”机制，必须让游戏体验、参与度与付费设计协同，才能在避免用户流失的同时，实现长期、健康的增长。
巨头们的理想生意
这篇讲的是BAT在移动互联网时代的布局逻辑。作者敏锐地指出，移动互联网并非桌面的简单延伸，它动摇了巨头们过去“躺着赚钱”的高毛利模式——百度依赖的信息流广告、腾讯的游戏、阿里本质上的“卖水”模式，都面临迁移困境。文章将巨头们所有的投资收购行动，都归结于一个核心焦虑：如何在移动端找到下一个高毛利业务。 作者用了一个生动的比喻，“卖白粉的很难有卖白菜的手感”，来解释为何BAT始终做不好零售电商这类低毛利苦活。真正的转机被聚焦在支付领域。因为支付虽利薄，却直通金融这一公认的高毛利行业。于是，微信红包点燃了支付战火，双方在打车软件、地图导航等高频场景的激烈投资，本质上都是对支付入口和用户数据的争夺。 文章进一步指出，这种依赖资本运作的“结构化”竞争，一方面为创业者提供了退出或背靠大树的选择，减少了“巨头抄你怎么办”的恐惧；但另一方面，也使得颠覆性的代际更替变得困难，互联网格局趋于固化。作者最终留下一个值得玩味的循环：巨头们会持续投资试探，直到找到自己的“白粉”，届时便可能亲自下场，历史就此循环。
移动互联网系统架构十大陷阱
这篇讲的是移动互联网系统架构中常见的陷阱，作者54chen基于三年一线开发经验，梳理了十个具体问题及其解决方案。比如，早期移动网络连通性差，应用频繁掉线，根因在于运营商网络不稳定，解法是选择有“背景”的机房以确保访问。HTML5在弱网环境下性能糟糕，即使现在也存在瓶颈，建议暂缓使用。DNS解析失败会导致请求不可达，客户端可缓存多个域名和IP作为备用。运营商HTTP拦截会擅自插入广告，开发者需在header中明确声明内容类型。 App设计上要克制按钮数量，避免功能泛滥，确保核心操作一键可达。传统web引导到app的转化极其困难，不应依赖。数据同步如sqlite与mysql不一致是大麻烦，最好用统一同步机制隔离业务逻辑，或将数据逻辑完全交给客户端处理。下载渠道必须通畅，上CDN时需注意缓存限制，防止下载速度陡降。更新频率要平衡，内部开发可天天迭代，对外发布则控制在月度或季更新。此外
[Android]用WebView访问证书有问题的SSL网页
这篇讲的是在Android开发中，使用WebView加载SSL证书有问题的网页时，如何绕过其默认的安全拒绝机制。核心问题在于，当网页证书过期、不正确或不被信任时，WebView会直接阻止页面加载，不像PC浏览器会弹出警告让用户选择。 要解决这个问题，关键在于重写WebViewClient的onReceivedSslError()方法。作者指出了一个极易踩坑的细节：在重写的方法里，必须直接调用handler.proceed()来忽略错误继续加载，并且**千万不要**调用super.onReceivedSslError()。这是因为父类的实现中包含了handler.cancel()，会导致加载失败，甚至可能引发段错误崩溃。 通过这个简单但实用的技巧，开发者就能让WebView加载那些因证书问题被系统拦截的网页，这在开发调试或处理特定网络环境时非常有用。
从易信看大公司标配与虎口夺食
作者从网易与电信联合推出易信对抗微信这一事件出发，探讨了在即时通讯领域已被巨头牢牢把控的背景下，一个创业团队仍选择入局的意义与风险。 文章首先抛出核心困惑：在微信独大、同类产品厮杀惨烈的市场里，“小弟弟们”是否还有机会？作者通过回顾网易过往的多次尝试（如早期“泡泡”项目的兴衰、内部保密项目的无疾而终），揭示了大公司的典型打法——依靠资源与价格战进行“虎口夺食”，风险可控却难以真正创新。 文章进一步剖析了两种可能：其一，某些产品如博客、微博，即使做不成第一，也可能成为大公司生态的“标配”功能，服务于自身内容运营；其二，通过对市场进行细分（如早期网易博客的差异化路径），寻找未被完全满足的需求。然而对于关系链至上的IM产品，这条细分之路异常艰难。 对于创业团队，作者也指出一条可能的出路：若能在巨头的夹缝中成功细分市场，即便份额不大，未来也可能被大公司收购。最终，文章以一种冷静的观察者视角收尾，提出在微信如此稳健的攻势下，创新和细分都面临巨大挑战，留给读者对“红海”市场生存策略的深层思考。
移动开发之touch event篇
这篇讲的是移动端网页开发中，如何用好触控事件来优化交互体验。作者从移动设备流量已占北美网络总流量20%的背景出发，指出虽然手机浏览器能渲染桌面网页，但交互方式因缺少鼠标而大不相同。 文章核心梳理了三个基础触摸事件：`touchstart`、`touchmove`和`touchend`，并通过控制台日志演示了事件触发的顺序与包含的触摸点列表（`touches`, `targetTouches`, `changedTouches`）的区别。作者还深入探讨了几个实际开发中的关键点：如何一行代码检测浏览器触摸支持；在`touchend`中，离屏的触摸点仅存在于`changedTouches`列表；以及移动端“轻拍”如何被浏览器转化为单击事件。 特别值得一提的是，文章分析了在`touchmove`事件中使用`preventDefault()`来禁用页面默认滚动和缩放的最佳实践——这是实现诸如Canvas自由绘图等自定义手势的基础。作者通过几个可运行的Demo和截图，将抽象的事件模型变得直观可感，对需要处理多点触摸或自定义手势的前端开发者来说，是份清晰的入门与避坑指南。
我是这样做APP的
这篇文章以“快捷酒店管家”这款应用的开发历程为例，讲述了作者团队从无到有打造一款移动互联网产品的实战心得。文章并非罗列抽象理论，而是通过具体案例，深入分享了在产品不同阶段如何捕捉、验证并满足用户需求。 作者首先强调，成功应用的核心在于击中用户痛点。为此，团队采用了两种方法：数据分析与“答案在现场”。例如，CEO和开发人员会定期入住快捷酒店亲身体验，甚至去酒店前台观察用户状态，以此获得最直接的洞察。产品功能，如关键的“在线预订”，正是源于对用户使用旧有电话预订流程中“不爽”体验的发现与解决。 文章进一步指出，APP的成功往往不是严格规划出来的，而是被用户、市场等多方力量“推着”演进的结果。产品需要在用户反馈与商业需求间找到平衡，例如通过一个可选开关，既满足了核心用户“只看有房”的简洁需求，也兼顾了酒店方查看竞品数据的需求。 此外，作者提炼了优秀APP的三个标准：加载速度快的性能、核心功能突出的简洁性、以及充满“人情味”的交互设计。最后，文章讨论了用户运营的艺术，包括如何通过持续的产品细节更新让用户感觉“APP是活的”，甚至在必要时通过“强制升级”等方式“净化”用户队伍，以保障产品的长期健康发展。 整体而言，这是一篇源于一线实战、充满具体操作细节的产品方法论分享，对于理解移动应用如何真正贴近并服务用户具有切实的启发意义。
移动终端设计和开发类书籍推荐
这篇文章为准备投身移动互联网浪潮的前端设计师和开发者们，梳理了一份实用的书单。它没有泛泛而谈，而是将推荐分成了清晰的设计与开发两大阵营。 设计类推荐从“自然用户界面”这一核心理念出发，引用了张小龙推崇的“让用户感觉不到设计的存在”的观点。随后推荐的《触动人心》和《交互设计沉思录》则分别代表了实践导向与思想深度的两极，而《简约至上》则聚焦于交互设计的策略性思考。开发类推荐直接指向技术落地，《iOS5基础教程》和《Objective-C基础教程》被形容为帮助开发者走上“小康之路”的入门基石，而《Learning Android》则覆盖了安卓这一市场份额巨大的平台。 整体来看，这份书单的编排体现了从设计理念到工程实现的完整学习路径，每本书的推荐都紧扣其在特定领域内的经典地位或实用价值，为不同阶段、不同方向的读者提供了明确的选择参考。
移动终端开发必备知识
这篇讲的是随着移动设备激增，如何高效开发调试WebAPP。文章从厘清基础概念入手，解释了CSS像素与设备像素的区别，以及PPI/DPI如何决定屏幕的默认缩放比例，这对于理解页面在不同手机上的显示差异至关重要。 核心内容对比了三种应对安卓设备碎片化的开发方案：“简单粗暴”方案虽省事但会导致高密度屏幕失真；“极致完美”方案通过device-dpi和媒体查询实现精准适配，但需为每种分辨率编写代码；作者推荐的“合理折中”方案则针对安卓市场主流（高密度设备）进行设计，用一套代码实现大部分设备的最优显示，在效果与成本间取得了平衡。 文章还分享了实战调试技巧，重点介绍了weinre工具的使用步骤，让开发者能在电脑上远程调试手机页面，并提及了AVD模拟器、手机抓包与配host等实用方法，覆盖了从布局认知到问题排查的全流程。
新浪微博 Android SDK中OAuth2.0隐式授权部分的一个代码逻辑问题
这篇讲的是作者在开发微博登录功能时，被一个看似小却很烦人的问题困扰：自定义的回调方法，比如 onComplete 或 onCancel，会被意外调用两次。这会导致内部逻辑重复执行，白白增加了客户端与服务端的开销。 作者一开始用了一个“取巧”的方案，通过一个标志变量来防止重复执行，暂时绕过了问题。但在多处需要复用此功能时，他意识到必须从根源上解决。 于是，文章深入到新浪微博 Android SDK 的内部实现，去寻找 OAuth2.0 隐式授权流程中，导致回调被触发两次的真正原因。它会带你梳理回调的注册与调用链路，分析可能的生命周期处理不当之处。对于使用该 SDK 或接触类似授权流程的开发者来说，这不仅是一次问题排查，更是一次理解 SDK 内部机制、避免未来踩坑的实用参考。
android原生浏览器不支持httponly
这篇讲的是Android原生浏览器在安全机制上的一个关键缺失：它并不支持httponly标志。作者从一次安全事件出发，指出了这个问题的核心风险——当cookie未被httponly保护时，极易受到XSS（跨站脚本攻击）的窃取。文章深入分析了这一机制缺失的根源，即浏览器底层实现层面的疏漏，并强调了其在实际应用中的严重后果。 文中对比了主流浏览器对httponly的支持情况，凸显了Android原生环境在这一安全标准上的滞后。作者并未止步于指出问题，还为开发者提供了切实可行的规避思路，比如在服务端对敏感cookie进行更严格的管控，以及结合其他安全头（如Content-Security-Policy）构建纵深防御。 读完这篇文章，你会更清晰地意识到，在移动端Web开发中，不能想当然地依赖客户端浏览器的安全特性。对安全边界的理解必须具体到平台和实现细节，才能有效筑牢防线。
Android动画背景图自动播放的实现
在Android开发中，为网络图片加载添加loading动画很常见，但让动画自动播放却是个小麻烦。这篇文章就专门解决这个具体痛点。 作者指出，问题根因在于 `AnimationDrawable` 的 `start()` 方法不能直接写在 `onResume` 等生命周期回调里，否则动画不会自动启动。为了解决这个问题，文章详细介绍了三种经过验证的实现技巧：通过 `Runnable` 在视图挂载后启动、使用 `AsyncTask` 在后台线程触发，以及利用 `ViewTreeObserver` 的 `OnPreDrawListener` 在视图绘制前启动。每种方法都附带了清晰的代码示例。 文章还对比了网上流传的另一种利用 `onWindowFocusChanged` 的方法，并指出了其依赖焦点变化的局限性。整体来看，这是一篇聚焦于特定技术问题的实用指南，为开发者提供了多种可靠的解决方案。
移动互联网必备：各平台自助渠道打包手段公开
这篇文章从一个实际痛点出发：如何让非技术的渠道人员，自助拿到带有渠道标识的应用安装包。作者针对安卓、iOS、塞班、Windows Phone这四个主流平台，逐一拆解了它们各自的打包技术难点和对应的解决办法。 核心思路是利用各平台安装包的不同特性。例如安卓APK一旦重签就会失效，所以必须用Ant或Maven在代码编译时就注入渠道变量；iPhone的ipa包本质是zip，可以直接在包内修改或添加channel.txt文件；塞班的sis包则因为签名机制较弱，允许在包文件末尾追加字节来记录信息；WinPhone的xap包处理方式类似iPhone，但需要特别注意zip文件在不同操作系统下的分隔符差异。 文章并没有停留在理论，而是直接给出了每个平台在服务器端可以执行的简明操作指令，比如安卓用`ant -Dchannel=xxx`，非常具有实操性。对于需要频繁打包的团队来说，这些实战总结能省去不少摸索时间。
PIC那些事儿
这篇文章从作者的实际开发经历出发，讲述了在使用PIC微控制器过程中遇到的几个典型问题及其解决思路。文章首先剖析了时钟配置错误导致的程序不稳定现象，根因在于锁相环（PLL）倍频参数设置不当，使得实际CPU频率偏离设计值。作者通过示波器抓取时钟波形，并对照Microchip数据手册调整OSCCON寄存器，最终恢复了系统正常运行。另一个案例涉及中断服务例程（ISR）执行超时引发的实时性问题
为你的博客制作一个安卓客户端
这篇讲的是如何零代码将博客快速转化为一个安卓客户端应用。 作者直接推荐了AppYet.com和feed.nu这两个在线服务作为核心方案。对于希望拥有自己安卓应用但又不懂开发技术的博主来说，这是一个非常实用的路径。文章指出，这类工具的核心能力是读取博客的RSS或Atom订阅源，并将其自动封装成一个结构清晰、具备基本阅读功能的安卓应用。其中，AppYet以生成过程直接、选项丰富著称，而feed.nu则更侧重轻量和快速部署。 这类方案的本质是提供了一种“订阅源可视化”的解决方案，它解决了个人博主技术门槛高、维护原生应用成本大的痛点。整个过程不需要编写一行代码，通常只需在网站上配置好博客地址、应用图标和一些偏好设置，平台便会自动生成APK安装包供用户下载和分发。对于内容更新频繁、以文章阅读为主的博客，这无疑是一条低投入、见效快的路径。 如果你是一个希望给读者提供更沉浸式移动端体验，但团队资源有限的博客作者，不妨花几分钟了解一下这两个平台，看看它们生成的应用是否符合你的内容呈现预期。