终端的开发，首当其冲的就是视图、动画的渲染，切换等等。用户使用 App 时最直接的体验就是这个界面好不好看，动画炫不炫，滑动流不流畅。UI就是 App 的门面，它的体验伴随着用户使用 App 的整个过程。如果UI失败，用户是不会有打开第二次的欲望的。 iOS 为开发者提供了丰富的 Framework

自 HTML5 标准正式发布之后，其得天独厚的跨平台特性吸引了众多开发者的目光。 伴随着 HTML5 的发展，JavaScript 的重要性也在逐步增加，要说现在哪门语言最火的话，那一定是 JavaScript 了。 学了JavaScript 成为全栈工程师，迎娶白富美，步入人生巅峰，想想也是醉了。

阅读提示：全文较长，预计阅读时长：20分钟 各位使用百度、谷歌或淘宝的时候，有没有注意浏览器左上角已经全部出现了一把绿色锁，这把锁表明该网站已经使用了 HTTPS 进行保护。仔细观察，会发现这些网站已经全站使用 HTTPS。同时，iOS 9 系统默认把所有的 http 请求都改为 HTTPS 请求。

接上篇->三步走起 提升 iOS 审核通过率 上篇 根据2015年的数据统计情况，并结合《苹果应用商店审核指南》，互娱 iOS 预审团队通过细分将预审工作划为3大模块：客户端资源检查、应用内容检查和提审资源检查。 在上一篇文章中，重点为大家介绍了客户端资源检查的内容，今天我们要为大家介绍的是关于应用

​ ​ ​ 2016年的第一天，各位小伙伴儿们，新年快乐~~~在过去一年里，负责 iOS 应用开发的同学们，想必已被 APP Store 的审核机制折磨心累不止。新的一年，又一轮审核即将来袭，你们做好准备了么？ 为了帮助各位 iOS 应用开发的同学免受折磨，腾讯 Bugly 特邀互娱 iOS 预审团

阅读提示：全文较长，预计阅读时间20分钟 Android 手表设计规范 为可以穿戴的 Android 手表设计应用与为手机和平板设计应用有很大的区别：不同设备有着不同的优势及劣势、不同的应用场景及人体工学考量。想要开始设计，我们应该对 Android 手表体验有个整体的认识，并且知道应用怎样融入才能

0、写在前面 本文涉及到屏幕密度的讨论，这里先要搞清楚 DisplayMetrics 的两个变量，摘录官方文档的解释： density：The logical density of the display. This is a scaling factor for the Density Indep

一. 内存泄漏的 Bug 猛增 最近在 App 进行 mokey 测试的时候检测到一些内存泄漏问题。在前天的测试中，楼主一瞬间收到了4个这样的 Bug 单，瞬间心理无比纠结，真有千万只羊驼向我奔来。 登录页面出现内存泄漏？？！！楼主的代码是如此的完美而无懈可击，这么可能出现这么多泄漏的问题？ 插播什

一、窗口的概念 在开发过程中，我们经常会遇到，各种跟窗口相关的类，或者方法。但是，在 Android 的框架设计中，到底什么是窗口？窗口跟 Android Framework 中的 Window 类又是什么关系？以手机QQ 的主界面为例，如下图所示，上面的状态栏是一个窗口，手机QQ 的主界面自然是一

0、写在前面 没抢到小马哥的红包，无心回家了，回公司写篇文章安慰下自己TT。。话说年关难过，bug 多多，时间久了难免头昏脑热，不辨朝暮，难识乾坤。。。艾玛，扯远了，话说谁没踩过坑，可视大家都是如何从坑里爬出来的呢？ 1、实现个静音的功能 话说，有那么一天， PM:『我这里有个需求，很简单很简单那种

1、Hello, Kotlin 1.1 Kotlin的身世 写了许久 Java，有没有发现其实你写了太多冗余的代码？ 后来你体验了一下 Python，有没有觉得不写分号的感觉真是超级爽？ 你虽然勤勤恳恳，可到头来却被 NullPointerException 折磨的死去活来，难道就没有受够这种日子么

Bugly平台正式推出“标签”功能，快速看穿每个异常！ 文章底部有传说中的彩蛋 前些日子在Bugly交流群上进行的需求投票结果中，有个需求得到了最高票选！究竟这个需求是什么？让大伙儿都想要？ 或许在跟进问题时，你可能碰到过这样的情况： 要将问题列表中的每个问题都看一遍，才能找到自己负责模块的问题？因

1 问题描述 做过Android开发的人都遇到过这样的问题：随着需求的变化，某些入口界面通常会出现 UI的增加、减少、内容变化、以及跳转界面发生变化等问题。每次发生变化都要手动修改代码，而入口界面通常具有未读信息提醒这样的“小红点”逻辑；一旦UI变化，“小红点”逻辑也要重新计算。如果不同的RD来维护

本人所在项目组主要负责一款Android平台产品的开发，因为用户量比较大，正式版本发布后，每天Crash次数的上报量都在几十万量级，即便是内测版，每天Crash次数的上报量也在两三千次。面对如此庞大的上报量，能否快速准确的定位问题直接关系到Crash的解决率，我们项目组在这方面做了比较多的尝试，现在

背景 当一个App发布之后，突然发现了一个严重bug需要进行紧急修复，这时候公司各方就会忙得焦头烂额：重新打包App、测试、向各个应用市场和渠道换包、提示用户升级、用户下载、覆盖安装。有时候仅仅是为了修改了一行代码，也要付出巨大的成本进行换包和重新发布。 这时候就提出一个问题：有没有办法以补丁的方式