iHuby
点此从AppStore下载：id492236906
new features：
# 和谁在一起页面添加首字母快速索引和最近在一起的的好友列表
# 脚印发布页和评论页支持自动草稿保存
# 可设置脚印推送消息是否需要声音提醒
# 脚印主页和评论页文字内容中的http链接可点，并可在内置浏览器中浏览
# 二级评论页面支持长按复制内容
# 脚印列表预览图加载时也显示等待的菊花转和进度指示
# 预览图加载过程中的默认背景图使用圆弧灰度渐变(程序实现,不用静态图)
# 获取视频图片文件时支持断点下载，节约用户流量
# 发送中的脚印可以取消发送
optimize：
# 查看其它人的好友都必须是双向好友
# 时钟12/24h制跟随用户系统设置
# 时钟动画滚动结束后再做下一个动画
# 提升视频下载成功率，更节约流量
# 从push点击进入的页面不进行页面叠加
# 多条tips是关于同一个脚印的评论，从首页下方点击tips进入时，进入该条脚印的评论页面，不进入动态
# 优化脚印列表的滚动性能
# 优化时钟滚动和时针位置，以及时钟区文本显示
New features:
1、从服务端快速同步脚印到新浪/腾讯微博/开心/人人网
2、提高图片质量：WiFi下优先获720×960图片展现,在3G下优先只获取512宽度图，节约用户流量
3、视频本地下载完成后再播放，用户可保存为本地视频
4、在评论页面显示签到小地图，点击地图还可以获取路线信息
5、增强GPS自动定位准确性判断
6、新用户注册时候有更多漂亮的随机封面
7、主页/脚印头像可点击，多人时头像可切换显示和点击
8、评论页面人名可点击选择
9、 Retina屏幕下实时滤镜也对应提高一倍分辨率
10、 设置页面添加用户反馈通道
Optimize:
1、优化主页进入评论页面滚动位置以及发送输入文字效果
2、优化脚印发布页面点击和长按手势处理逻辑
3、改进起床/睡觉动画
4、优化签到地点搜索体验
5、优化监测到动态更新通知提示，避免用户重复处理
6、优化全屏查看图片/视频切换到脚印列表时候的动画效果
7、优化脚印Logo和脚印被看过的的文字效果
8、自动签到类型的脚印，需post到服务端成功后才在UI上显示
9、全屏下观看视频完成时，自动切换回到脚印列表
Bugs fixed
1、Fixed：有时点击首页导航条后，脚印列表不能快速滚动返回顶部
2、Fixed：视频播放完成切换到脚印列表时，声音停止过慢
3、Fixed：全屏模式下双指捏合图片放大时不能移动
4、Fixed: 好友对删除后的脚印留表情或评论时未做正确处理
[...]
引子：
前两天看到一篇Blog讲“如何避免思维的误区”，其中有一部分是讲“随机谬误模型”，并举了Apple的iPod播放器产品为例：
Ipod除了绚丽的外观，还有一项领先的功能，就是“真正的随机播放功能”。Apple通过完全随机的算法，向用户即时运算出下一首随机播放的歌曲。但是不久Apple就接到了客户的投诉，投诉的内容是Apple所谓随机播放功能有问题，理由是它有时会连续播放同一首歌。
我们的大脑再一次欺骗了我们。我们误把“随机”当做了“不同”。例如我们在电脑中安装一个模拟随机数字的程序，如果它连续给出了3个不同的数字，我们会认为这是正确的；而如果它连续给出3个相同的数字，我们一定会惊呼，“软件是不是错了，我要的可是随机数字呀！”
Ipod故事的最后结局是，Jobs只好要求程序员修改了程序，让它不再随机，从而避免连续推荐相同的歌曲，而广大用户却认为Ipod终于“随机”了。
有意思的是，2011年初 ifanr写了一篇Blog“ 从随机播放算法看 iPod 的细节之美”，文中赞叹了一把 iPod 产品设计的的这个“随机播放”细节之美，但该文的评论中有网友吐槽作者拍苹果马屁没拍到点，理由是很多其它产品多都已经是这样做了，Apple这样的设计没什么好赞叹的，也有部分网友认为随机就是要真正的随机，一个产品不要去干涉随机。
那么真正的故事究竟是怎么样的呢？是Apple不得不因为用户的抱怨而修改产品的程序算法，还是Apple在产品设计的时候就已经有考虑了这个细节呢？
虽然我不是iPod所有版本历史的见证者或体验者，在“如何避免思维的误区”这篇Blog又没有给出其例举的iPod故事的相关引用出处，会不会又是“青蛙”好事者为了说明自己的理论而编造的“青蛙沸水弹跳”故事？
我决定深究一下，相信 google 会给我答案。
1、先Google “ipod user complain not really random” 找到一个网页 “iPod Shuffle: Randomness ”；
其中讨论了iPod的随机算法，最早的时间是2005年，有提到用户一直有抱怨其随机算法。
2、这是一篇2005年介绍 iTunes5 产品发布的文章： http://betanews.com/2005/09/07/apple-introduces-itunes-5/ ；
此文提到iPod产品针对iTunes Shuffle特性的用户反馈，改进了产品特性，称之为“Smart Shuffle”，并引用了steve jobs的一句话： “Smart Shuffle 减少了随机，但用起来却更像随机” ；嗯，就是乔爷这句话，是不是很有 paradox（悖论） [...]
User Interface Design Patterns
http://ui-patterns.com/
Mobile UI Patterns
http://mobile-patterns.com/
iOS UI Patterns
http://pttrns.com/
Interaction patterns that can help you design Android apps
http://www.androidpatterns.com/
1、 首先明确：
iPhone 3G/3GS 屏幕像素分辨率是 320×480 ;
iPhone4、iPod Touch4 屏幕像素分辨率 640×960。
2、为了兼容 iOS 4.0 之前的程序也能在 iOS 4 上运行，苹果设计了一个逻辑分辨率单位 point ，在 iPhone3 上 1个 Point 相当于 1个pixel ; 而 iPhone4 上1个 point 就相当于4个 pixel；因此所有的iPhone、iPod Touch 设备的 Point 分辨率都是 320×480 ，也就是逻辑分辨率都一致，保证了App不需要修改也能正常的在高像素分辨率上运行，只是原来App中的图片会被拉升后显示，影响美观，没有发挥retina的优势。
3、iOS App设计和开发人员要做什么？
1）App 的图标设计，发布到Store的App必须同时提供高清Size的App Icon（在原来基础上都要对应提供一份高清版本），参考Apple官方文档。
2) 代码中引用的静态UI 图片素材，也是提供两份，一份低像素分辨率，一份高分辨率使用。
比如：原来App素材包有个 [...]
TWUI
https://github.com/twitter/twui
作者参考 iOS UIkit 框架设计机制（通过CoreAnimation实现GPU加速绘制），为Mac设计了一套类似的UI Framework，而且这个项目是twitter官方发布的，目前项目还在alpha阶段，并且正在移植到twitter for Mac应用中。
参考: http://engineering.twitter.com/2011/07/starting-today-twitter-is-offering-twui.html
nimbus
https://github.com/jverkoey/nimbus
由于Three20的复杂性，同时又缺失文档，于是作者重写了类似Three20的可重用框架代码，但是作者先确定文档规范，然后才实现特性，保证框架简单易用，从而加快 iOS 应用开发。
chameleon
这个框架的目标比较大，试图把整个iOS UIKit 对应在Mac实现一遍，完全遵照Apple发布文档中公开的类和方法，不会采用任何private API。如果采用这套框架，iOS 应用开发者无需改动很多代码，可以很轻松的把 iOS App移植到Mac上。
（话说从lion发布的更新特性来看，也许Apple官方在将来自己会提供一套类似 iOS 的Mac UIKit，方便App Developer快速开发跨桌面和移动平台的应用）
cooliris-toolkit
http://code.google.com/p/cooliris-toolkit/
cooliris公司为 iOS 平台开发了不少应用，他们发布的这套 toolkit 几乎就是一个大杂烩了，包含了一系列可加速 iOS App 开发不同功能特性的 Objective-C 类实现，这套toolkit实现了很多不同的特性，同时保证不同特性实现尽量独立，减少依赖。
iOS 开发中的一个重要部分就是关于内存的使用管理，用的不好就容易就产生内存泄露或内存错误访问，造成软件的崩溃，影响产品的使用和用户体验。在团队协调开发中也整理过了一些开发规范，正好看到国外的一篇开发博客文章“10-iphone-memory-management-tips”，其重要列表部分我翻译并整理一下。
一些重要的背景知识点：
iPhone3G只有128M RAM内存,至少有一半是要留给操作系统；也即大概只有很小的40M内存左右留给了应用程序… 另外请记住，即使你开发的应用只使用了3M内存的时候，也有可能收到系统的内存警告通知。（Huby注:3GS内存总大小是256M,应用程序能使用大概不到80M；而iPhone4的内存大小是512M，应用程序能使用大概180M左右。而Apple对一个App设定的限额一般是20M） iPhone 不使用垃圾回收机制，即使Objective-C 2.0中有垃圾回收机制可使用(用Objective-C 2.0开发Leopard上的App可使用垃圾回收)。 内存管理的基本原则是：任何一处对象只要调用了 [ alloc | retain | copy ]一次，就必须在代码某处有一一对应执行相应的 [release] 方法。 Objective-C 运行时的对象实例都是在堆(Heap)中，不允许在栈(stack)中创建实例对象;这意味着没有自动化对象,也没有智能指针对象帮你管理内存。 对象可以使用 autorelease 方法，但是要当心，这些对象必须等到他们的内存池自动释放的时候才能释放，如果内存池没有释放，其实也就相当于仍然产生了内存泄露。 iPhone没有内存交换文件(swap file),所以也就没有虚拟内存概念。当系统没有更多内存可用的时候，那么就真的是没有了。
经验总结：
要写代码处理iOS系统的内存警告通知。 尽量避免使用对象的内存自动释放机制。 使用延迟加载创建对象以及内存对象的重用机制。(注: 横向或纵向滚动列表中特别适用) 尽量避免使用UIImage的imangeNamed方法。(注:这样就等于使用了系统内存自动释放机制) 自绘Table Cell并适当重用。 重写属性的Setter方法。 小心使用委派(Delegation)机制。 使用Instruments工具优化内存使用。 使用代码静态分析工具优化代码。 启用NSZombieEnabled可发现更多内存问题。
参考资料:
Categories
Archives
huby@sina.weibo
huby@douban
huby@xiami
