查看: 7060|回复: 29
[胶水四核?还是app没为四核优化]攻克rk3188+retina~浏览器~翻页滚屏fps流畅度低的问题
本帖最后由 bbb0 于
23:40 编辑
肩并肩使用
A31四核a7+sgx544MP2双核GPU+retina (以某道N90fhd四核)
rk3188四核a9+mali400单核GPU mp4四管线+retina&&(以某道N90fhd四核RK)
最明显的感受，就是rk3188使用蓝球球浏览器，上hao123-&sina,sohu,qq,163首页实在太卡了
某达的V972,V971,V973搭载SDK2.0固件出厂，然后最近又出了满意度极高的SDK3.0固件以后，这个差距进一步拉大了。。
另外3dmark for android游戏fps跑分，a31+也比rk36的分数高1/3左右。。。
那么rk3188到底是不是根本是个胶水四核，一般application.apk只能调用到双核？？还是因为app.apk没有为四核优化，所以性能只有rk3066的水平呢？
我们用两个工具来研究这个问题：
工具一：平板设置－开发选项－显示CPU使用状况在右上角，右上角三个数字依次显示最近1分钟，5分钟，15分钟的CPU占用
1.0就是1个核心占满，2.0就是2个核心占满，3.0就是3个核心占满，4.0就是4个核心占满
工具二：百度&fps meter&，下载一个fps meter.apk安装，(root)启动，然后start service，就会在屏幕角上显示目前操作fps水平
下面来依次看每个浏览器的表现。。。我们的基本要求如下
1. 浏览器去 ，电脑版网页，然后打开sina, sohu, qq, 163，滚屏比较流畅
2. 浏览器去 ，电脑版网页，然后打开youku，首页的社会新闻和原创超清视频，播放比较流畅
3. 浏览器可以看 .cn/news/，就是ipad版本sina新闻，滚屏比较流畅
4. 假如网页广告比较严重的影响了载入速度，和滚屏翻页的流畅度，能不能去广告
5. 论坛内嵌flash视频的播放，以imp3评测帖子为例
6. 最好用一个浏览器解决所有问题
基于sxzh PD800 rk3188四核A9+2GBram+retina IPS，聚划算的2000台als M33基本上也适用
[22pm更新] 浏览器比拼结果如下
单选投票, 共有 10 人参与投票
70.00% (7)
30.00% (3)
您所在的用户组没有投票权限
本帖最后由 RKB 于
18:58 编辑
ARM的IC没有两个DIE连一起的说法……
而且胶水也只是个概念最后还是看实际表现，“胶水四核”Core 2 Quad Q6600照样秒杀&原生四核”AMD Phenom X4全系列.
&&不好意思插楼了
LZ还是分析出了问题，某些贴牌厂急于推出产品，RK3188+Retina屏的板子装着Android4.1.1的固件就上市了。俺记得RK3188刚出来的时候就有人说过，Android4.1.1只是临时用用的，真正发挥出3188的威力要等4.2
根据LZ的分析，篮球浏览器卡是因为只用到两个核心。也就是说软件对多线程优化的时候只考虑到了双核，没有按四核来处理并发问题。的确4.1.1系统以前一直是RK3066在用，很可能有些地方没改过来。低分辨率设备上用两个核心或许完全够用，而到这样的高分辨率上就悲剧了。
而安卓4.2.2版的固件则没有这个问题，我的机器上打开新浪首页（电脑版）右上角显示如下，也不卡。
1.jpg (240.1 KB, 下载次数: 5)
18:57 上传
唉什么时候某些贴牌厂才能成熟一点，多去考虑一下用户体验，少吹牛（类似以前单核时代&1.5GHZ主频“这样完全在骗人的事情少做），用心做好产品。不然以后中端的用户真的只能去买三星的了
本帖最后由 bbb0 于
18:47 编辑
下面来依次看每个浏览器的表现。。。我们的基本要求如下
1. 浏览器去 ，电脑版网页，然后打开sina, sohu, qq, 163，滚屏比较流畅
2. 浏览器去 ，电脑版网页，然后打开youku，首页的社会新闻和原创超清视频，播放比较流畅
3. 浏览器可以看 .cn/news/，就是ipad版本sina新闻，滚屏比较流畅
4. 假如网页广告比较严重的影响了载入速度，和滚屏翻页的流畅度，能不能去广告
5. 论坛内嵌flash视频的播放，以imp3评测帖子为例
6. 最好用一个浏览器解决所有问题，载入速度问题，浏览字号排版问题
首先是rk3066+andr4.1固件上最经典的蓝球球浏览器，因为集成了
Adblock=all, flashblock(插件需要时开启)，弹窗html5视频，UserAgent=ipad(html5视频)，最小字号=16，首页=hao123，堪称全能
但是到了rk36reina上面，自带的蓝球球浏览器出现了很大的问题
1. 浏览器去 ，电脑版网页，然后打开sina, sohu, qq, 163，滚屏比较流畅
滚屏的fps，右上角显示，只有平均18fps左右，经常可以看到低于13fps的数字
而右上角的cpu占用，浏览器滚屏的情况下，是&=2.0个核心在使用
2. 浏览器去 ，电脑版网页，然后打开youku，首页的社会新闻和原创超清视频，播放比较流畅
这个问题不大，弹窗视频仍然好用，
不过默认的嵌入浏览器的html5播放器存在两个问题，一是从高清切换到超清，缓冲时间非常长，二是快进的缓冲时间比较久
而右上角的cpu占用，浏览器滚屏的情况下，是&=2.0个核心在使用
以上是UserAgent=ipad，假如UserAgent=Desktop的话，flash播放能力很强，youku专享1080p flash毫无压力
3. 浏览器可以看 .cn/news/，就是ipad版本sina新闻，滚屏比较流畅
滚屏的fps，右上角显示，只有平均18fps左右，经常可以看到低于13fps的数字
而右上角的cpu占用，浏览器滚屏的情况下，是&=2.0个核心在使用
4. 假如网页广告比较严重的影响了载入速度，和滚屏翻页的流畅度，能不能去广告
蓝球球浏览器，设置高级，Adblock policy=all，插件=需要时开启(flashblock)，这样完美去广告
5. 论坛内嵌flash视频的播放，以imp3评测帖子为例
6. 最好用一个浏览器解决所有问题，载入速度问题，浏览字号排版问题
载入速度还是不错的，sunspider跑分1500毫秒左右，跟rk3066的跑分完全相同，
而右上角的cpu占用，浏览器滚屏的情况下，是&=2.0个核心在使用
蓝球球浏览器，设置辅助功能，最小字号=16号，这样可以不改变排版，字号原地放大，效果不错
综上，蓝球球浏览器+rk36retina，网页翻页滚屏的fps太差，成为瓶颈，a31四核某达V972 sdk2.0可以20-25fps
自始至终，蓝球球浏览器右上角的cpu占用只有2.0，就是只有2个A9核心在使用而已
俺的M6貌似蓝球浏览器新浪首页滚屏一点都不卡（竖着横着都一样）。。似乎是固件优化问题吧
本帖最后由 bbb0 于
19:29 编辑
bbb0 发表于
综上，蓝球球浏览器+rk36retina，网页翻页滚屏的fps太差，成为瓶颈，a31四核某达V972 sdk2.0可以20-25fps
自始至终，蓝球球浏览器右上角的cpu占用只有2.0，就是只有2个A9核心在使用而已
这是蓝球球浏览器播放youku《遍地狼烟》第一集的情况，html5，超清，播放到最后，自始至终23-30fps，右上角cpu占用2.0
右上角1.9/1.87/1.92就代表，过去一分钟内，有1.9个A9核心负载在工作
Screenshot_-19-41-48.png (825.54 KB, 下载次数: 10)
18:42 上传
这是蓝球球浏览器播放晓说,youku会员专享1080p flash的情况，flash，1080p，自始至终23-30fps，右上角cpu占用2.0
右上角2.14/1.99/1.48就代表，过去一分钟内，有2.14个A9核心负载在工作
Screenshot_-17-32-06.png (960.36 KB, 下载次数: 6)
18:42 上传
由此可见，来自rk3066的android4.1固件的蓝球球浏览器，只能调用两个A9核心，cpu占用为2.0，严重影响了网页滚屏的性能
值得一提的是，除了网页滚屏以外，其他所有性能都还是不错的。。。问题是最短边。。。。
bbb0 发表于
这是蓝球球浏览器播放youku《遍地狼烟》第一集的情况，html5，超清，播放到最后，自始至终23 ...
俺有空上个浏览网页的视频吧，直接看看真实效果
百度&fps meter&安装启动，start servi.
本帖最后由 bbb0 于
20:46 编辑
下面来依次看每个浏览器的表现。。。我们的基本要求如下
1. 浏览器去 ，电脑版网页，然后打开sina, sohu, qq, 163，滚屏比较流畅
2. 浏览器去 ，电脑版网页，然后打开youku，首页的社会新闻和原创超清视频，播放比较流畅
3. 浏览器可以看 .cn/news/，就是ipad版本sina新闻，滚屏比较流畅
4. 假如网页广告比较严重的影响了载入速度，和滚屏翻页的流畅度，能不能去广告
5. 论坛内嵌flash视频的播放，以imp3评测帖子为例
6. 最好用一个浏览器解决所有问题，载入速度问题，浏览字号排版问题
然后是黑马，andr2.3 / rk2918的sdk2.0固件上最常用的海豚浏览器...　到android4.0以后，海豚浏览器变成了渣...
海豚浏览器极速内核，在rk2918单核上面速度极慢。。。现在海豚手机浏览器(炫风版)就是之前的极速内核，效果如何呢？？
1. 浏览器去 ，电脑版网页，然后打开sina, sohu, qq, 163，滚屏比较流畅
滚屏的fps，右上角显示，有平均30fps左右，很少可以看到低于23fps的数字，任意网页，一手指就可以翻页到底
而右上角的cpu占用，打开一个多广告的页面，cpu占用轻松彪升到3.5以上，可见有四个A9核心在使用
右上角4.43/2.5/1.42就代表，过去一分钟内，有4.43个A9核心负载在工作
Screenshot_-18-58-00.png (1.01 MB, 下载次数: 0)
19:19 上传
2. 浏览器去 ，电脑版网页，然后打开youku，首页的社会新闻和原创超清视频，播放比较流畅
设为UserAgent=ipad
不过默认的嵌入浏览器的html5播放器存在两个问题，一是从高清切换到超清，缓冲时间非常长，二是快进的缓冲时间比较久
而右上角的cpu占用，浏览器滚屏的情况下，是=4.0个A9核心在使用!!!
以上是UserAgent=ipad，
假如UserAgent=Desktop的话，海豚自从andr4.1以后就盲从nexus7和ipad，不支持flash，极为脑残。。。
右上角4.32/2.59/1.62就代表，过去一分钟内，有4.32个A9核心负载在工作
Screenshot_-19-01-24.png (661.41 KB, 下载次数: 1)
19:04 上传
3. 浏览器可以看 .cn/news/，就是ipad版本sina新闻，滚屏比较流畅
滚屏的fps，右上角显示，平均30fps左右，很少可以看到低于23fps的数字
而右上角的cpu占用，浏览器滚屏的情况下，是4.0个A9核心在使用
4. 假如网页广告比较严重的影响了载入速度，和滚屏翻页的流畅度，能不能去广告
不支持去广告，另外海豚自从android4.1以后就盲从nexus7和ipad，不支持flash了，所以也就没有flashblock一说
5. 论坛内嵌flash视频的播放，以imp3评测帖子为例
无法播放，希望海豚改进flash支持
6. 最好用一个浏览器解决所有问题，载入速度问题，浏览字号排版问题
载入速度非常不错的，跟蓝球球浏览器没有差距，sunspider跑分1300毫秒左右，
而右上角的cpu占用，浏览器滚屏的情况下，是=4.0个A9核心在使用
浏览器字号从普通设为大以后，排版不变，文字原地变大，效果比蓝球球浏览器，辅助功能，字号=16要差很多
下页预读的功能，当UserAgent=ipad的时候，访问bbs.imp3.net是电脑版，可以自动读取下一页的内容，
当翻页到网页底部，继续向上翻页，就可拖出下面一页的东西来，挺方便的
综上，海豚手机浏览器炫风版极速内核+rk36retina，网页翻页滚屏的fps有30，流畅度极好
自始至终，海豚浏览器右上角的cpu占用有4.0，就是有4个A9核心在使用，可见海豚手机浏览器炫风版极速内核为四核优化了
网页流畅度，fps=30，极好，cpu占用是4.0个A9核心
网页载入速度，极好，跟蓝球球一样，sunspider=1300毫秒
youku网页视频，fps=25，满意，cpu占用是4.0个A9核心
去广告功能，没有
flash支持，没有，无法支持论坛评测贴的内嵌flash
排版，差，看网页新闻的时候，载入完毕字体会自动放大，字大到夸张，然后设定字号=大一号，排版就乱了。。
特色滚屏功能，网页浮动翻页键，支持；；音量键翻页，支持；；任务栏的音量+/-虚拟键翻页，也支持。。。牛b
3b总是发投票贴。
3D总的帖子总是很有深度的呀，先拜读了！
我看不懂 但是我说 我的318+2048比我的A31+2048看网友快多了 浏览器是uchd
我看不懂 但是我说 我的318+2048比我的A31+2048看网友快多了 浏览器是uchd
本帖最后由 bbb0 于
12:49 编辑
下面来依次看每个浏览器的表现。。。我们的基本要求如下
1. 浏览器去 ，电脑版网页，然后打开sina, sohu, qq, 163，滚屏比较流畅
2. 浏览器去 ，电脑版网页，然后打开youku，首页的社会新闻和原创超清视频，播放比较流畅
3. 浏览器可以看 .cn/news/，就是ipad版本sina新闻，滚屏比较流畅
4. 假如网页广告比较严重的影响了载入速度，和滚屏翻页的流畅度，能不能去广告
5. 论坛内嵌flash视频的播放，以imp3评测帖子为例
6. 最好用一个浏览器解决所有问题，载入速度问题，浏览字号排版问题
然后是旧情人。。。
我去年买了Ｎ台rk3066后，非常失望，然后看了一台同城的rk2918+andr4.0.4，验货时发现ba1du浏览器极好, 就买了刷成4.1
ba1du浏览器手机版，设置里面下载并开启“T5极速内核&
1. 浏览器去 ，电脑版网页，然后打开sina, sohu, qq, 163，滚屏比较流畅
滚屏fps，右上角显示有平均25fps左右，很少可以看到低于18fps的数字，滚屏速度均匀，不像海豚一手指就飞出去很多
而右上角的cpu占用，打开一个多广告的页面，cpu占用轻松彪升到3.5以上，可见有四个A9核心在使用
右上角4.03/2.62/1.57就代表，过去一分钟内，有4.03个A9核心负载在工作
Screenshot_-19-48-54.png (822 KB, 下载次数: 10)
19:51 上传
2. 浏览器去 ，电脑版网页，然后打开youku，首页的社会新闻和原创超清视频，播放比较流畅
不支持UserAgent=ipad，只支持UserAgent=Desktop，但设置里面支持”优先用ｈｔｍｌ５播放“
这样打开优酷网页视频，是调用外部播放器播放，如图。。问题：一是超清，缓冲时间非常长，二是快进的缓冲时间比较久
右上角3.56/2.98/1.9就代表，过去一分钟内，有3.56个A9核心负载在工作
Screenshot_-19-57-42.png (516.67 KB, 下载次数: 7)
20:02 上传
外部播放器，可以选择&ES媒体播放器&，或&(RK)视频播放器&，后者&(RK)视频播放器&，支持弹窗视频，也就是蓝球球效果
UserAgent=Desktop，对于非&优先用html5播放&的网站，比如非youku之类的网站，支持flash播放，效果ok
但是bbs.imp3.net的评测贴，打开flash会导致页面reload。。。页面定位到别处去了，所以还是看不了
3. 浏览器可以看 .cn/news/，就是ipad版本sina新闻，滚屏比较流畅
滚屏的fps，右上角显示，平均25fps左右，很少可以看到低于18fps的数字
而右上角的cpu占用，浏览器滚屏的情况下，是4.0个A9核心在使用
4. 假如网页广告比较严重的影响了载入速度，和滚屏翻页的流畅度，能不能去广告
特色！！百度&adblock android&下载，需要root，然后启动adblock for android独立程序，勾上enable adblock
然后用ba1du手机浏览器，T5极速内核，打开一个广告比较多的网页，结果发现广告全部没有了！！
试验下来，对ba1du手机浏览器(T5极速内核)，还有对kbo的浏览器，adblock for android有效，
对蓝球球，chrome和海豚无效，且必须关闭adblock for android(底部工具栏，多任务按键，然后横向划出，杀掉adblock进程)
Screenshot_-20-15-41.png (150.03 KB, 下载次数: 6)
20:16 上传
[后来的备注] 测试条件是禁用或卸载了chrome浏览器。然后安装的ba1du浏览器，这种情况下android adbock独立模块有效
5. 论坛内嵌flash视频的播放，以imp3评测帖子为例
对于youku，设置高级，勾上优先使用html5播放的话，自动调用外部播放器播放
对于其他网站，支持flash播放，但是论坛多图＋ｆｌａｓｈ的评测贴，开启ｆｌａｓｈ会导致排版重排，光标跑到别处
6. 最好用一个浏览器解决所有问题，载入速度问题，浏览字号排版问题
载入速度比较的糟糕，一般都要10秒钟才可以载入，sunspider跑分2500毫秒左右，
而右上角的cpu占用，浏览器滚屏的情况下，是=4.0个A9核心在使用
浏览器字号从普通设为大以后，排版不变，文字也不变，对于高分辨率＋密集排版，字号太小影响阅读
下页预读的功能，底部工具栏自动可以提示下页预读加载完毕，然后按下&&&就可以预读完毕
综上，ba1du手机浏览器T5极速内核+rk36retina，网页翻页滚屏的fps有25，流畅度不错
自始至终，海豚浏览器右上角的cpu占用有4.0，就是有4个A9核心在使用，可见ba1du手机浏览器 T5极速内核为四核优化了
网页流畅度，fps=25，不错，cpu占用是4.0个A9核心
网页载入速度，十秒钟，比较慢，比较不能忍
youku网页视频，fps=25，满意，调用外部播放器播放html5，调用(RK)视频播放器的话，还支持弹窗html5超清视频
去广告功能，超强，可以跟adblock for android独立软件一起用，广告全干掉！flashblock，支持点击后开始播放flash
flash支持，对youku等视频网站，优先播放html5视频，对其他网站，支持flash；；但是论坛多图＋ｆｌａｓｈ一播放就reload
排版比海豚手机浏览器炫风版极速内核规整，网页新闻支持(+)放大字体，类似pdf阅读效果，但不支持原地放大字号，字太小
特色功能，网页浮动翻页键，支持；；音量键翻页，不支持；；任务栏的音量+/-虚拟键翻页，不支持。。
特色功能，支持adblock for android独立软件。。。下页预读很不错，跟ucweb有的一拼
缺点，网页载入慢，不支持排版不变，字号原地变大，字太小；；论坛多图+flash，一播放flash页面就重新加载
下面来依次看每个浏览器的表现。。。我们的基本要求如下
1. 浏览器去 ，电脑版网页，然后打开sina, sohu, qq, 163，滚屏比较流畅
2. 浏览器去 ，电脑版网页，然后打开youku，首页的社会新闻和原创超清视频，播放比较流畅
3. 浏览器可以看 .cn/news/，就是ipad版本sina新闻，滚屏比较流畅
4. 假如网页广告比较严重的影响了载入速度，和滚屏翻页的流畅度，能不能去广告
5. 论坛内嵌flash视频的播放，以imp3评测帖子为例
6. 最好用一个浏览器解决所有问题，载入速度问题，浏览字号排版问题
最后，但不是最糟糕
andr4.1上面的chrome，因为一直不支持flash，所以被唾弃被抛弃，不过这倒反过来逼youku给UA=android4.1标配html5视频
百度&chrome android&，下载最新版，安装
1. 浏览器去 ，电脑版网页，然后打开sina, sohu, qq, 163，滚屏比较流畅
滚屏fps，右上角显示有平均20fps左右，很少可以看到低于13fps的数字，滚屏速度均匀，但是阻力大，翻页慢
而右上角的cpu占用，打开一个多广告的页面，cpu占用轻松彪升到5.0以上，可见有四个A9核心在使用
右上角5.27/2.73/1.64就代表，过去一分钟内，有5.27个A9核心负载在工作
Screenshot_-20-32-33.png (513.38 KB, 下载次数: 5)
20:37 上传
2. 浏览器去 ，电脑版网页，然后打开youku，首页的社会新闻和原创超清视频，播放比较流畅
无需修改UserAgent，因为andr4.1+chrome标准不支持flash，所以泛果粉价值观，就让youku给UA=android4.1标准提供html5
这样打开优酷网页视频，是调用外部播放器播放，如图。。问题：一是超清，缓冲时间非常长，二是快进的缓冲时间比较久
3. 浏览器可以看 .cn/news/，就是ipad版本sina新闻，滚屏比较流畅
滚屏的fps，右上角显示，平均20fps左右，很少可以看到低于13fps的数字，但是阻力大，翻页慢
而右上角的cpu占用，浏览器滚屏的情况下，是4.0个A9核心在使用
4. 假如网页广告比较严重的影响了载入速度，和滚屏翻页的流畅度，能不能去广告
百度&adblock android&下载，不支持chrome for android，而且必须按下任务栏多任务键，彻底退出adblock才行
5. 论坛内嵌flash视频的播放，以imp3评测帖子为例
不支持论坛内嵌flash播放
6. 最好用一个浏览器解决所有问题，载入速度问题，浏览字号排版问题
载入速度似乎并不慢，但是载入以后花5秒钟渲染，结果都要10秒钟才可以载入，sunspider跑分3300毫秒左右，
而右上角的cpu占用，浏览器滚屏的情况下，是=4.0个A9核心在使用
综上，chrome浏览器android最新版+rk36retina，网页翻页滚屏的fps有20，但滚屏阻力大
自始至终，海豚浏览器右上角的cpu占用有4.0，就是有4个A9核心在使用，可见chrome浏览器android最新版为四核优化了
网页流畅度，fps=20，滚屏阻力大，cpu占用是4.0个A9核心
网页载入速度，不错，但渲染需要额外5秒，一共加载十秒钟
youku网页视频，fps=25，满意，调用浏览器内嵌html5播放器，超清，快进缓冲比较慢
去广告功能，没有
flash支持，没有
楼主，我有买过3188的，但后来退了，关键就是页面划动时文字会模糊一下然后清晰，这是最受不了的，请问你介绍的这些浏览器中哪个会象IPAD3或者4代一样，流畅地上下拖动网页呢？
rk就是这样,4.0.4不会模糊
本帖最后由 bbb0 于
21:25 编辑
另外还有一个可能已经为四核A9优化的浏览器－－天天浏览器＋天天播放器
因为某为的K3V2就是四核A9，而且蜜pad也已经是0w屏幕像素了，所以天天浏览器没有理由不为四核A9优化
实测下来是这样的，网页滚屏平均25fps，很少低于18fps，但cpu占用 含下页预读进程最多2.5个A9核心，貌似还没为4核优化
天天浏览器最后的版本是V3.6正式版 () (之后又出了仅限andr2.3的T9内核，看来某为是针对低端市场了。。。)
V3.6, V3.5版本在rk3188我这个平板上有问题，启动后只能打开一个网站，再开第二个网站就开不了了
可以跟adblock for android独立程序配合。。另外没有测试过qq手机浏览器
本帖最后由 bbb0 于
22:03 编辑
综上所述，rk3188四核A9，假如希望浏览器流畅翻页，翻页滚屏fps=25-30的话，可以选择
rk36_浏览器比拼.PNG (16.7 KB, 下载次数: 10)
22:03 上传
1. 海豚手机浏览器炫风版（极速内核），滚屏翻页30fps
2. ba1du手机浏览器(T5极速内核)+adblock for android独立程序(需要root)，滚屏翻页25fps
二选一作为主打，
前者优点是载入快，字大，能看优酷html5，但不支持flash；后者载入慢，优点是不会因字大搞乱排版，支持去广告，支持flash
这两个浏览器假如不看论坛多图+内嵌flash的评测贴里面的flash视频的话，其他网页需求，基本上都可以满足
蓝球球浏览器在andr4.1下面没有为四核A9优化，只能调用4核A9里的双核A9，所以机能跟rk3066一样...驱动吃力
但是这并不代表四核A9就没用了，因为这时开一个弹窗视频的话，cpu占用就会2.0 -& 3.0，总之多2个核心能防止卡S界面UI
A31因为把两个A7封装成一个核心，所以相当于高能/高频双核，反而在andr4.1蓝球球浏览器只能调用双核时候,a31表现会好
从最新版chrome浏览器V27 for android来看，可以充分调用四核A9，fps平均可以达到20fps+，但滚屏滑动阻力较大
rk3188四核A9+蓝球球浏览器+andr4.1+retina，网页滚屏翻页fps&15的现象，是蓝球球没为四核优化的暂时现象
建议暂时出一个分辨率下调到的固件版本(需要重新编译内核分辨率参数)，或者直接推出新的支持四核的浏览器
否则可以预期的结果是，在andr4.1下面打开蓝球球浏览器，实际上是在使用rk3066驱动，滚屏翻页当然会很卡...
22:02 上传
点击文件名下载附件
23.96 KB, 下载次数: 429
本帖最后由 bbb0 于
22:46 编辑
另外一个提示，
rk3188+蓝球球浏览器+retina,只能调用双核A9，
实际是在用rk3066双核驱动，浏览器滚屏翻页的流畅度，只有rk8+蓝球球浏览器fps的1/4这个问题
只是暂时现象，所以假如有小白参加了聚划算999rmb的als M33，然后忍不了要转卖的话，30天机700rmb可以入手...大家懂的
因为无论海豚手机浏览器炫风版(极速内核),还是ba1du手机浏览器(T5极速内核)，都能做到30fps/25fps无压力，调用4个a9核心
rk2918双核+蓝球球浏览器+fps
rk3066双核+蓝球球浏览器+fps (rk2918的三倍)
rk3066双核+蓝球球浏览器+fps(分辨率四倍，流畅度1/4)
rk3188四核+蓝球球浏览器(只能用到双核)+=rk3066双核+蓝球球浏览器+fps (只能用到双核a9，rk3188当rk3066用)
rk3188四核+海豚或ba1du浏览器+fps (可以用到四核a9，比上面流畅度fps高一倍)
然后....rk3188是鲁大师击败99%手机cpu的哦 (包括galaxy note2, galaxy s3 i9300)... 研究到此结束，封贴~
貌似没有UC浏览器？总之楼主很用心了，感谢分享，最珍贵的就是这种细致的使用感受
uc中转,去广告强,论坛模式强,3g上网专用
再次说明我说过程序有屌丝程序和高富帅程序 区别在于自动调用核心和进程
客观　包容　敏锐　专业
iMP3.net 随身数码影音
推广合作：139
莫凡配件：135
All Rights Reserved.苹果发布15英寸Retina MBP固件1.1更新
日 08:33&&&编译：&& 作者:叶亮&&
　　 泡泡网笔记本频道3月15日 Retina
SMC升级1.1刚刚发布，最新固件补丁解决了当用户使用独立显卡玩高端游戏时出现的帧数下降现象，还修正了从睡眠状态唤醒时和PowerNap相关Bug。SMC 1.1升级补丁只有504kb，最低系统要求为OS X 10.7.5或10.8.2。(）
　　 上周有报道称最新Retina MacBook Pro的风扇速度有问题，有用户发现f风扇速度会异常的高，问题可能出现在新加入的闪迪上。这次的补丁修正了这个问题。
　　 苹果上个月再次更新了Retina MacBook Pro，加入了更快的并降低了价格。新型号跑分测试要比旧型号快3-5%，价格还有便宜200美元。■
产品定位：轻薄 CPU：Intel 酷睿i7 3740QM 处理器主频：2.7睿频至3.7Ghz 内存：16GB(8GB×2) 显卡类型：双显卡切换(独立/…… 硬盘：512GB 显卡：NVIDIA GeForce GT 650M(独立……
扯扯车精品文章推荐小站会根据您的关注，为您发现更多，
看到喜欢的小站就马上关注吧！
下一站，你会遇见谁的梦想？
【白树】一眼就喜欢的画
麦当劳理论
當我與同事們無法決定今天中午要吃什麼的時候，我玩了一個小把戲：我推薦了麥當勞。這時候有趣的事情發生了，所有人一致認為我們根本不該把麥當勞納入午餐的選項之一，於是更好的選項就陸續出現了，Magic!這就像是用最爛的主意破冰之後，討論才真正開始，人們突然之間就會變得非常有創造力，我把這稱作為麥當勞理論──「人們會為了要否決爛主意而受到激勵，產生好的靈感。」我在工作上很常使用這種「技巧」。專案總是有許多不同的開始方式，有時是因為你得到了一份正式的提案，有時是因為你聽到一些傳言而決定早點開始進行計畫，或是有一個點子在心中縈繞了數個月或數年後你決定告訴你的團隊。無論如何，創意性的工作是沒有固定流程的，但是我相信所有致力於創意工作的人們都同意一件事：「跨出第二步永遠都比第一步來的容易」。美國小說家 Anne Lamott 提倡「shitty first drafts」，Nike 告訴我們「Just Do It」，而我則推薦了麥當勞以讓人們產生更好的點子，這些都是相同的道理，都在說跨出第一步並不如我們所認為的那麼困難。有次我收到一封賈伯斯的信，信中就只有一個字：「Go!」。全身心的投入，去做就對了，別想太多。下次當你有一個想法在腦中徘徊不去時，鼓起勇氣叫你內心批評的聲音閉嘴，然後找一枝筆和一張紙，把想法給寫下來或畫出來。你也許會認為「但我沒有時間去做這個！」、「這想法聽起來有點蠢」或是「也許我該先上網找一下有沒有──停！閉嘴就是了！別再繼續摧毀自己。相同的道理也能用在團隊工作上，下次當你進入一個專案早期階段的討論時，找個白板來，然後就直接在上面丟出一些想法。雖然這些想法可能會很蠢沒錯，但這是一件好事！麥當勞理論告訴我們的就是這將能讓團隊進入狀況。其實這需要近乎瘋狂的勇氣、瘋狂的專注、瘋狂蠻幹的毅力，努力一段時間後才能消除心中那些無法控制的懷疑聲音，然後真正的「前進」。但這的確是可能的，你所需要的就是開始做、打破第一個障礙然後讓事情上軌道。這並不是那種可以在腦中就完成的事情，你必須寫下來、畫下來、做出來，然後修改它。如果你還是不確定要怎麼開始，那就畫出幾個想法的雛形，並用一些標籤來註記，例如「這可能很瘋狂，但如果我們能&&」，然後試著讓這些草圖朝著你想解決的問題更近一步。這就像魔法一樣，當你把一些想法呈現在白板上，不可思議的事情就發生了。房間內的其他人會看見你的想法，然後也跟著提供他們的想法，或修飾你的想法。過了 15 分鐘、30 分鐘、一個小時後，整個計畫就有進展了。事情就是這樣完成的。&
Objective-C中的meta-class isa
(转载自http://blog.csdn.net/yohohohoho/article/details/6735543)
&讨论Objective-C的一个奇怪的概念 meta-class在Objective-C中的每个类，都有它自己相关的meta-class，但因为你很少直接使用meta-class,所以显得很神秘。
在运行时建立一个类下面的代码在运行时创建一个NSError新的子类，并添加一个方法到里面：&
Class&newClass&=&&
&&&&objc_allocateClassPair([NSError&class],&&RuntimeErrorSubclass&,&0);&&
class_addMethod(newClass,&@selector(report),&(IMP)ReportFunction,&&v@:&);&&
objc_registerClassPair(newClass);&&
&添加的这个方法用ReportFunction函数名作为它的实现，实现定义在下面&
void&ReportFunction(id&self,&SEL&_cmd)&&
&&&&NSLog(@&This&object&is&%p.&,&self);&&
&&&&NSLog(@&Class&is&%@,&and&super&is&%@.&,&[self&class],&[self&superclass]);&&
&&&&Class&currentClass&=&[self&class];&&
&&&&for&(int&i&=&1;&i&&&5;&i++)&&
&&&&&&&&NSLog(@&Following&the&isa&pointer&%d&times&gives&%p&,&i,&currentClass);&&
&&&&&&&&currentClass&=&object_getClass(currentClass);&&
&&&&NSLog(@&NSObject&s&class&is&%p&,&[NSObject&class]);&&
&&&&NSLog(@&NSObject&s&meta&class&is&%p&,&object_getClass([NSObject&class]));&&
&表面上，这都很简单。在运行时创建一个新类，只需要3步1)为 class pair分配存储空间 (使用objc_allocateClassPair)2)增加需要的方法和ivars(使用class_addMethod来添加方法)3) 注册这个类，以便它能被别人使用(objc_registerClassPair)&现在的问题是，什么是class pair, 函数objc_allocateClassPair只返回一个值:the class那么pair的另外一半在哪里呢？你可能已经猜到另外一般就是meta-class(也就是本文的主题）
一个数据结构需要哪些东西才能成为一个对象每个对象都有一个类，这是一个基本的面向对象的概念。在Objective-C中，任何数据结构，如果在正确的位置有一个指向类的指针，就能被视为一个对象。在Objective-C中，一个对象的类，由它的isa指针决定。这个isa指针指向 对象的类。事实上，一个对象的基本定义是这样的:&
typedef&struct&objc_object&{&&
&&&&Class&&&
&&&这就是说，任何以一个指向Class结构的指针开始的结构，都能被当作objc_object对象最重要的特性，就是你可以给它们发送消息：&
[@"stringValue"&&
&&&&writeToFile:@"/file.txt"&atomically:YES&encoding:NSUTF8StringEncoding&error:NULL];&&
&&当你发送消息给一个Objective-C对象时（比如这里的NSCFString), 运行时(runtime) 通过对象的isa指针得到对象的Class(这里是NSCFString类），而Class里含有那些可以应用这个类的所有对象上的所有方法的列表，以及指向superclass的指针。运行时通过类的方法列表和超类，来发现一个能同消息选择子匹配的方法（上面的例子中，就是在NSString类中的writeToFile:atomically:encoding:error方法）。要点就是：类定义了那些消息，你只能发送那些已经定义好的消息给它的对象&
什么是meta-class现在，你可能已经知道，在Objective-C中，一个类也是一个对象。这意味着，你也可以发送消息给一个类&
NSStringEncoding&defaultStringEncoding&=&[NSString&defaultStringEncoding];&&
&&在这种情况下， defaultStringEncoding被发送给NSString类在Objective-C 中，每个类，都是一个对象。也就是说，类结构也必须以isa指针开始，这样，它才同objc_object结构二进制兼容在结构里的第2个项目，必须是superclass的指针（如果是基类，没有父类的话，设置为nil)&定义一个类，有很多不同的方式，依赖于你的运行时版本而不同，但他们都以 isa开始，然后后面接着superclass&
typedef&struct&objc_class&*C&&
struct&objc_class&{&&
&&&&Class&&&
&&&&Class&super_&&
&&&&/*&followed&by&runtime&specific&details&&*/&&
&&为了让我们调用类的一个方法，类的isa指针必须指向一个类结构，并且，类结构必须含有我们能在该类上调用的方法列表这就导致了一个meta-class的定义:meta-class是一个类对象的类简单地说，当你发送一条消息给一个对象时，这条消息会在对象的类的方法列表里查找当你发送一条消息给一个类时，就会在类的meta-class的方法列表理查找消息meta-class是必不可少的，因为它存储了一个类的类 方法。每个类都必须只有唯一的meta-class,因为每个类都只可能有一个唯一的类方法列表。&&
meta-class的类又是什么呢？meta-class，跟 类一样，它也是一个对象。这意味着，你也可以在它上面调用方法。自然地，这意味这，它也必须有一个类。所有的meta-class都使用基类的meta-class(在它们的继承体系中，最顶层的类的meta-class)作为它们自己的类。这意味着，所有从NSObject继承来的类，它们的meta-class都将NSObject的meta-class作为自己的类遵循这个规则，所有的meta-class使用基类的meta-class作为它们自己的类，任何base meta-class都将是它自己的类（它们的isa指针指向它们自己）。也就是说，在 NSObject的meta-class的isa指针将指向它自己（它是自己的一个实例）&类和 meta-class的继承同样的方式，类用super_class 指针指向超类，meta-class使用它自己的super_class指向 类的super-class的meta-class巧合地是，基类的meta-class设置它的 super_class 为基类自己。
/blog/archive//objc_explain_Classes_and_metaclasses.html
用实验来验证我们的想法为了确认这些情况，我们看看ReportFunctional的输出。 这个函数的目的是 追踪isa指针，并记录在哪里找到的它。为了运行ReportFunction，我们需要建立这个动态创建的类的实例，然后调用它的report方法&
id&instanceOfNewClass&=&&
&&&&[[newClass&alloc]&initWithDomain:@&someDomain&&code:0&userInfo:nil];&&
[instanceOfNewClass&performSelector:@selector(report)];&&
[instanceOfNewClass&release];&&
&&因为没有report方法的声明，我使用performSelector:来调用它，所以编译不会给出什么警告&ReportFunction将遍历isa指针，告诉我们那些对象被当成类，meta-class，以及meta-class的类 来使用&取得一个对象的类：ReportFunction将使用object_getClass来追踪isa指针， 因为isa指针是类的一个被保护的成员（你不能直接访问其他类的isa指针）ReportFunction不使用类方法来实现这个，因为调用一个类对象的类方法，将不会返回meta-class. 而是再次返回这个类（所以[NSString class]将返回NSString类，而不是NSString的meta-class)&&结论:meta-class是类对象的类。每个类都有它自己唯一的meta-class(因为每个类都有它自己唯一的方法列表）/2010/01/what-is-meta-class-in-objective-c.html&
BOOL / bool / Boolean / NSCFBoolean(转载自/bool/)
Written by Mattt Thompson on Apr 8th, 2013
We've talked before about the&. This week, our attention turns to another fundamental matter: Truth.Truth.&Vēritās. The entire charter of Philosophy is founded upon the pursuit of it, and yet its exact meaning and implications still elude us. Does truth exist independently, or is it defined contingently against falsity? Can a proposition be at once both true&and&false? Is there absolute truth in anything, or is everything relative?Once again, encoding our logical universe into the cold, calculating bytecode of computers forces us to deal with these questions one way or another. And as you'll see from our discussion of boolean types in Objective-C and its kin, truth is indeed stranger than fiction.Objective-C defines&BOOL&to encode truth value. It is a&typedef&of a&signed char, with the macros&YES&and&NO&to represent true and false, respectively.Boolean values are used in conditionals, such as&if&or&while&statements, to conditionally perform logic or repeat execution. When evaluating a conditional statement, the value&0&is considered "false", while any other value is considered "true". Because&NULL&and&nil&are defined as&0, conditional statements on these nonexistent values are also evaluated as "false".
In Objective-C, use the&BOOL&type for parameters, properties, and instance variables dealing with truth values. When assigning literal values, use the&YES&and&NO&macros.The Wrong Answer to the Wrong QuestionNovice programmers often include an equality operator when evaluating conditionals:
if ([a isEqual:b] == YES) { ... }
Not only is this unnecessary, but depending on the left-hand value, it may also cause unexpected results, as described in the&:
static BOOL different (int a, int b) { return a - b; }
An overly clever C programmer might take some satisfaction in the simplicity of this approach: indeed, two integers are equal if and only if their difference is&0.However, because of the reality of&BOOL&being&typedef'd as a&signed char, this will not behave as expected:
if (different(11, 10) == YES) { printf ("11 != 10\n"); } else { printf ("11 == 10\n"); } if (different(10, 11) == YES) { printf ("10 != 11\n"); } else { printf ("10 == 11\n"); } if (different(512, 256) == YES) { printf ("512 != 256\n"); } else { printf ("512 == 256\n"); }
This evaluates to:
11 != 10 10 == 11 512 == 256
Now,&, but Objective-C don't suffer fools gladly.Deriving truth value directly from an arithmetic operation is never a good idea. Like the sentence, it may be grammatical (after all,&BOOL&is a&signed charlike any other, so it&could&be treated as a number), but it doesn't make sense semantically. Instead, use the result of the&==&operator, or cast values into booleans with the&!&(or&!!) operator.The Truth About&NSNumber&and&BOOLPop quiz: what is the output of the following expression?
NSLog(@"%@", [@(YES) class]);
The answer:
__NSCFBoolean
Wait, what?All this time, we've been lead to believe that&NSNumber&&primitives into an object representation. Any other integer- or float-derived&NSNumber&object shows its class to be__NSCFNumber. What gives?
NSCFBoolean&is a private class in the&NSNumber&. It is a bridge to the&, which is used to wrap boolean values for Core Foundation property lists and collections.CFBoolean&defines the constants&kCFBooleanTrue&and&kCFBooleanFalse. BecauseCFNumberRef&and&CFBooleanRef&are different types in Core Foundation, it makes sense that they are represented by different bridging classes in&NSNumber.For most people, boolean values and boxed objects "just work", and don't really care what goes into making the sausage. But here at NSHipster, we're all about sausages.So, to recap, here is a table of all of the truth types and values in Objective-C:
NameTypedefHeaderTrue ValueFalse Value
BOOLsigned charobjc.hYESNO
bool_Bool&(int)stdbool.htruefalse
Booleanunsigned charMacTypes.hTRUEFALSE
NSNumber__NSCFBooleanFoundation.h@(YES)@(NO)
CFBooleanRefstructCoreFoundation.hkCFBooleanTruekCFBooleanFalse
Migrating your code to Objective-C ARC
Recently, Apple introduced several new developer stuff including Xcode 4, ARC, LLVM Compiler 3.0 and iOS 5. From some of the questions on Stack overflow, I could understand that, most of the ARC related confusions arise due to the fact that, developers don&t know if &ABC& is a feature/restriction of LLVM 3.0 or iOS 5 or ARC.Retain cycles, auto-release pools, @autorelease blocks, oh man! So many new things? What am I going to do? You are right. ARC, or Objective-C Automatic Reference Counting is almost&. No really.In this post, I&ve made an attempt to demystify the air around this. Before starting, I&ll have to warn you that, this is a fairly long post. If you are too bored, Instapaper this article and read it later. But, hopefully, at the end of this, I believe, you will have a better understanding on how ARC works and be able to work around the innumerable errors it spits out when you convert your project.Having said that, let&s get started.Contents
What is ARC
Problems with the current model.
Garbage collection
Reference Counting
Automatic Reference Counting
Compiler level feature
Also a run time feature
ARC Ownership qualifiers
ARC knows more Objective-C than you
Toll-free bridging
How does ARC work internally?
ARC front end
ARC optimizer
The actual Migration using Xcode 4.2
Common ARC migration errors
Cast of Objective-C pointer to C Pointer type
performSelector may cause a leak because its selector is unknown
Receiver type "*" doesn't declare the method with selector "*"
Common workarounds that you use in ARC on code that otherwise looks normal
Capturing "*" strongly is likely to lead to a retain cycle
Avoiding early releases using __block
That last question
When should you migrate?
Where to go from here?&What is ARCARC is a feature of the new LLVM 3.0 compiler that helps you to write code without worryingmuch&about memory management. Memory management can be broadly classified into two, garbage collected and reference counted models. Before going to the details, let&s briefly discuss these two models and understand why ARC is even needed.Problems with the current model.The current memory model we use in Objective-C is manual reference counting on iOS and Garbage collection on Mac.There are certain problems with both these memory models which probably was the reason why ARC was developed.Garbage collectionGarbage collection is a higher level language feature probably introduced in Java (or technically, Java Virtual Machine) and implemented in a variety of other programming platforms including Microsoft&s Common Language Runtime. While Garbage collection worked well for higher level languages, Objective-C, which is still C under the hood, didn&t really fly high. Pointers (or rather references) in other languages like Java were actually objects that managed retain count and automatically releases itself when the count reaches zero. One of the design goals of C was to be optimized for performance and not &easy of use&. While pointer objects (read&) are great object oriented abstractions, they have an adverse effect on the performance of the code and since Objective-C was intended primarily for native programming where developers are used to use pointers, pointers within a structure, pointer to a pointer (for dereferencing a out parameter), it was just too difficult to introduce something like a smart pointer that would require a lot of mindset change from the developers who prefer a deterministic memory management model (Reference counting) over a non-deterministic memory management model (Garbage collection). Nevertheless, GC (Generational GC) was introduced in Objective-C 2.0 for Mac. While Generational GC doesn&t suffer from &Stop the world& issues like the mark and sweep alogrithm, they don&t collect every released variable and an occasional mark and sweep collection is still needed.Reference CountingThe memory management model used in iOS is called as reference counting model, or more precisely, manual reference counting.In manual reference counting model, you as a developer, have to deallocate every object you allocated. When you don&t do this, you either leak memory or over release it, causing a crash. While that counting sounds easy, Most of the memory leaks happen when you transfer ownership of objects across scope boundaries. That&s a creator method that allocates an object for you and expects the caller to deallocate it. To circumvent this problem, Objective-C introduced a concept called autorelease. auto-released variables are added to the auto-release pool and are released at the end of the runloop. While this sounds too good, auto-release pools do incur an additional overhead.For example, comparing the two code blocks,
NSDictionary *dict = [[NSDictionary alloc] init];
// do something with the dictionary here
// I'm done with the dictionary, I don't need it anymore
[dict release];
// more code}
NSDictionary *dict = [NSDictionary dictionary]; // auto-released object
// do something with the dictionary here
// I'm done with the dictionary, I don't need it anymore&
// more code}
the first block is an example of optimized use of memory where as the second depends on auto-release pools. While this block of code doesn&t really incur significant memory overhead, code like these slowly adds together and makes your reference counted model heavily dependent on auto-release pools. That is, objects that you know could be deallocated, will still linger around in the auto-release pool for a little longer.Automatic Reference CountingSay hello to ARC. ARC is a compiler feature that auto inserts retain and release for you. So in the first code block of the above example, you no longer have to write the release method and ARC auto-inserts for you before compilation.
NSDictionary *dict = [[NSDictionary alloc] init];
// do something with the dictionary here
// I'm done with the dictionary, I don't need it anymore
[dict release]; // ARC inserts this code for you.
// more code}
When you create an autoreleased object, like in the second block of code, ARC compiler is clever enough not to add a release call. Sound great, so how should I go about doing this ARC thing? Just delete all release/retain codes and pray? Unfortunately, it isn&t that easy. ARC is not just some auto insert or macro expander kind of tool.&It forces you to think in terms of object graphs instead of memory allocation, retain or release.&Let&s delve a little deeper into ARC.Compiler level featureARC is a compiler level feature. I repeat. ARC IS A COMPILER LEVEL FEATURE. This means, when you use ARC, you don&t have to worry about upgrading your deployment target and so on. However, only the latest LLVM 3.0 compiler supports ARC. If you are still stuck with GCC, you are out of luck. (Meh!) Some more points that you should know about ARC are,
ARC is backward compatible with libraries and framework compiled with under non-ARC.
ARC can be used within your project on a file-by-file basis. So you can mix and match ARC code with non-ARC code.
You can also integrate ARC compiled libraries into your project that doesn&t use ARC and vice-versa.
You use a&compiler switch&to turn ARC on and off.
(The keyword here is compiler switch)
You can also set the complete target to build with ARC by default (and use non-ARC compiler only when instructed so.) This is shown in the illustration below.
The two main compiler switches that you would often use are when you build your application with a third party library that is not ARC compliant and vice versa, are
-fno-objc-arc
-fobjc-arc
-f is the switch and&no-objc-arc&and&objc-arc&are the options that you are turning on. As evident from the names, the first one turns off ARC and the second turns on.For example, if your application is ARC enabled but a third party library is not, you use the first switch&-fno-objc-arcto exclude the third party library. Conversely, if your application is not yet ARC enabled (gasp!) but the third party library you are integrating is, you use the second switch&-fobjc-arc&You add these flags to the project from the Build phases tab as shown below.Also a run time featureWait! You just told me (and repeated) that ARC is a compiler level feature? Now what? Sorry, I hear you, but, unfortunately, things aren&t that easy and it doesn&t just stop here. ARC also backs up on a runtime feature calledzero-ing weak references. Oh, damn, another keyword! I should have introduced this before. But that&s ok. We will revisit about the run-time dependency of ARC, a little later in this post.ARC Ownership qualifiersAs I showed you earlier, ARC automatically inserts releases and retains in your code in a pre-compilation step. But for ARC to know when to release your objects and when to retain them, you need to somehow tell the life of your variables. You use ownership qualifiers for that. A strong understanding of ownerships is vital to understand and use ARC properly. Once you understand this concept, you will be thinking in terms of object graphs instead of retain/release. Secondly, when you use ARC, all variables local or ivars are initialized to nil automatically for you. This means, there is little chance of having a dangling reference in your application.
__unsafe_unretained
__autoreleasingThe first qualifier, __strong, is the default and you might not even be using this explicitly. It is use to tell the ARC compiler that, the declared variable &owns& the reference. The opposite of this is __weak, which tells the ARC compiler that the declared variable doesn&t own the reference.The __weak is&synonymous&to the &assign& modifier. You normally use assign modifier for IBOutlets and delegates. Under ARC, this is replaced with __weak. However, there is a caveat. __weak requires you to deploy the app on a runtime that supports&zero-ing weak references. This includes, iOS 5 and Lion. Snow Leopard and older operating systems or iOS 4 and older operating systems don&t support zero-ing weak references. This obviously means you cannot use __weak ownership modifiers if you plan to deploy to older operating systems. Fret not. ARC includes another ownership qualifier, __unsafe_unretained that is synonymous to __weak, except that when the pointer is de-referenced, it is not set to nil, but remains dangling. A while ago, I told something about zero-ing weak references? When the runtime supports zero-ing weak references, your __weak variables are automatically set to nil when they are released. This is the only feature that requires a higher deployment target (iOS 5/Lion). Otherwise, you are good to deploy on iOS 4/Snow Leopard.A couple other important things to know about __weak vs __unsafe_unretained is that, the compiler doesn&t allow you to use __weak when your deployment target is set to a operating system that doesn&t support zero-ing weak references. The Convert to Objective-C ARC wizard uses __weak only when your deployment target supports zero-ing weak references. So if your deployment target is iOS 4, the Objective-C convert ion wizard will replace assign modifiers with __unsafe_unretained instead of __weak.The last ownership qualifier, __auto_releasing is used mostly when passing a reference to a function for writing out. You would use this in places where you normally use pointer indirection like returning a NSError object via an out parameter.Properties in your header file can also have the above ownership qualifiers except the __auto_releasing. When applied to properties, ARC automatically generates the correct code in dealloc to release them when the object dies.Lastly, and more importantly, all of ARC managed&objects&are initialized to nil when they are created. So, again, no more dangling pointers because you forgot a initialize statement. However, do note that this initialization doesn&t initialize primitive data types. So a declaration like,
might contain a garbage value for a.Whew! That&s pretty taxing. Take a break. We just started.ARC knows more Objective-C than youARC also taps into a the Objective-C language naming conventions and infers the ownership of the returned object.In Objective-C, a method that stats with any one of the following prefix,
mutableCopy and
neware considered to be transferring ownership of the returned object to the caller.This means, in your application, when you create a method, ARC automatically infers whether to return a autoreleased object or a +1 retained object from your method name. In fact, in most cases, instead of returning auto-release objects, ARC just inserts a manual release in the calling code, automatically for you. However, there is a small caveat. Let&s assume that you have a method that starts with &copy&, as in
-(NSString*) copyRightS
ARC assumes that it would transfer the ownership of the returned string to the caller and inserts a release automatically. Everything works well, if both the called method and the calling method are compiled using ARC.
But&if your &copyRightString& method is in a third party library that isn&t compiled with ARC, you will over-release the returned string. This is because, on the calling code, ARC compiler inserts a release to balance out the retain count bumped up by the &copy& method. Conversely, if the third party library is compiled with ARC and your method isn&t, you will have a memory leak. You can however override this behavior by adding one of the following attribute to your methods.
NS_RETURNS_NON_RETAINED
NS_RETURNS_RETAINEDSo your method will now look like this.
-(NSString*) copyRightString NS_RETURNS_NON_RETAINED;
You can also rename the method name to&copyrightString&(note the case) or&getCopyRightString&instead of adding an attribute. However, I wouldn&t recommend the former method as it breaks the cocoa naming conventions (prefixing a method with &get& or &set& is Java-ish)You will see methods having the NS_RETURNS_* prefixes throughout the header files in Apple&s own UIKit.framework or the foundation classes. Now that you know what happens behind the scenes and how compiler treats these decorations, you can solve crazy memory issues, like a crash when you call a&copyRightString&in your method in a third party library.With that, let&s get ready for climbing the next peak.Toll-free bridgingARC&doesn&t&manage Core Foundation objects. They say, there is no free lunch. ARC, takes it one step further. There is no free-casting between Core Foundation objects and equivalent Objective-C objects (NS* objects). Yes, that&s right. You cannot cast a Core Foundation object to an equivalent Objective-C object (NS* object) without telling ARC how to manage ownerships.Let&s now see how to specify ownership transfers when you cast a Core Foundation object.The following ownership transfer modifiers should be provided when you cast a Objective-C object to a Core Foundation object.
__bridge_retained
__bridge_transferWhen you migrate a project to ARC, you would have seen error messages like the one below.
ARC Error because of a missing bridge attribute in a Toll-free bridging codeYou might also have proceeded by accepting the suggestions provided by the LLVM compiler. But now, let&s dig deeper and understand the &why& behind it.The modifier, __bridge tells the ARC compiler that, it&s a plain simple, bridging cast. That means, you ask the ARC compiler to do nothing extra when the transfer is made. You might think, if that is the case, Apple could have made this the default choice. But it was not made probably because, it&s to preposterous to make such an assumption. Making such a bold assumption means, you would easily leak memory as there isn&t a easier way to tell when you are actually releasing a Core Foundation object unlike a Objective-C object.The second modifier, __bridge_retained is used to tell the ARC compiler that the Objective-C object should be transferred to Core Foundation by bumping the retain count by 1 and it should be treated as if it is a newly created object (as opposed to a auto-released object). You use this modifier if the method was probably named like a creation method (starting with init, copy, mutableCopy etc.,) or if you are going to release the Objective-C object inside of Core Foundation using methods like CFRelease.The last modifier, __bridge_transfer is used to tell the ARC compiler that the Core Foundation object is to be transferred to ARC with a retain count of 1. This is used if you created a Core Foundation object using one of the CF***Create methods and want the ARC compiler to handle the memory management for you. That&s you are transferring a Core Foundation object to ARC with a retain count of 1.As a side note on this, avoid using __bridge_retained and __bridge_transfer to trick the compiler to add retain and releases for you. Use it to improve your code readability and minimizing the number of manual memory management calls. (Move on if you don&t understand this line. You will start understanding this automatically when you start using this in your own code)How does ARC work internally?ARC ain&t magic, if you know how it works. But a little knowledge is a dangerous thing. Knowing how the ARC compiler works will help you more in understanding the error messages and compiler warnings spat out by it.The ARC compiler has two main parts, a front end compiler and an optimizer.ARC front endThe ARC front end compiler checks for every &owned& Objective-C object and inserts release appropriately. By owned object, I mean, an object whose ownership qualifier has been set. For example, if the &owned& object is a local variable, ARC front end compiler inserts a release at the end of the scope. This is because, by default all local variables are &strong& ly owned. If the object is a instance variable, the ARC front end compiler inserts a release statement in the dealloc method, if the ownership type is strong. For unsafe_unretained or weak ownership ARC doesn&t do anything. It also takes care of calling the [super dealloc] for you and intact ARC compiler doesn&t allow you to explicitly call dealloc.The ARC front end compiler also takes care of generating errors when it encounters a variable (local or instance) whose ownership qualifier is not set or when you explicitly calling dealloc.ARC optimizerThe function of the ARC optimizer is to optimize the retain and release statements by removing them if they are inserted multiple times by the ARC front end compiler. It is this optimizer that ensures that performance is not affected by calling retain and release multiple times.The actual Migration using Xcode 4.2Xcode 4.2 has a wizard to automatically migrate your code for use with the ARC compiler. This means, the wizard rewrites some of your code, removes calls to retain/release and removes dealloc methods and calls to [super dealloc] for you.The first step is to open your project, select Edit -& Refactor -& Convert to Objective-C ARC from the menu.
Migrating to Objective-C ARC using Xcode 4.2When you select this option, you will be asked to select a target. If you have only one target, it&s fine. If you have multiple targets in your application, you have to perform the ARC migration on every target. After you select a target, the wizard by default selects all source code files that belong to that project for ARC migration. If you are using third party libraries that are not yet ARC ready, you can uncheck those files in this step. This is illustrated in the screenshot below.
Selecting your files for ARC exclusionIn the above project, since I know that ASIHttpRequest is not yet ARC compatible, I&m selecting them and command-clicking them to show the option to uncheck all of them. When you do this, the wizard automatically adds a -fno-objc-arc compiler flag for all these files.The next step is to start the pre-checking process. The pre-checking process compiles the project and analyzes for potential problems before performing the actual migration. You might almost and always get a error message like this.
The dreaded error message!Of course, 58 errors in this screenshot is actually quite low. You should expect anywhere in the range of 300+ for a mid sized project. But fret not, they aren&t complicated at all to fix.Common ARC migration errorsThe number of errors that might prevent you from converting your project to ARC is usually high if your code is &old& or if it doesn&t adhere to Objective-C design patterns. For example, accessing a iVar. While it&s technically ok, you should almost and always use properties to access them outside of init and dealloc methods. If you have been using properties, ARC migration would be painless. If you were old skool, you have to feel the pain now. In this last section, I&ll show you the most commonly occurring errors when you migrate your project.Cast of Objective-C pointer to C Pointer typeThis error is generated because ARC doesn&t do toll-free bridging for you. As I explained before in the section, Toll-free bridging, requires the developer to explicitly specify ownership transfer qualifiers.Use the various ownership transfer qualifiers I showed you before to fix this problem.performSelector may cause a leak because its selector is unknownWe now know that Objective-C ARC compiler knows more Objective-C than you. This error message is because of that. The ARC compiler tries to identify the method family and determine whether to add a retain or release to the returned value from the caller code. This means, if your method starts with init, alloc, copy, mutableCopy or new, the ARC compiler will add a release to the calling code after the variable scope ends. Since are using a selector to call a method dynamically at runtime, ARC doesn&t really know if the method called returns a +1 retained object or a auto-released object. As such, ARC cannot reliably insert a retain or release to the returned object after its scope ends. This warning is shown to warn you of potential memory leaks.If you are sure that your code works fine without memory leaks, you can ignore this warning. To suppress this warning, you can turn off the compiler flag -Warc-performSelector-leaks warning on a line by line basis like this.
#pragma clang diagnostic push#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
[self performSelector:self.mySel]; #pragma clang diagnostic pop
Unfortunately, you cannot annotate a dynamic selector using __attribute__ ((objc_method_family(*))).Receiver type &*& doesn&t declare the method with selector &*&ARC mandates that every method you call should be declared properly. With GCC, this was a warning. But LLVM makes this step mandatory since ARC needs to accurately identify and that is why you see an error like this.
Error that you see when you don't declare a receiver typeThis error is also because of the fact that ARC needs to identify the method family to determine if it has to add a retain or release to the returned object. For example, in the above code, the method, returnMyGreatObject might return a NS_RETURNS_RETAINED. In this case, the ARC compiler has to insert a release after the returned object goes out of scope. The ARC compiler can know this only when you declare it formally. This is why, under ARC method declarations are mandatory. If you have been declaring methods formally under GCC, even when the compiler didn&t enforce (so that the code was aesthetically beautiful) you wouldn&t see this error at all. As I said before, the number of ARC migration errors is directly proportional to the quality of code you write. Fixing this error is fairly simple and all you have to do is to declare every method formally in the header file or on a private category extension.Common workarounds that you use in ARC on code that otherwise looks normalIn some cases, while using ARC, you might end up writing code that looks as if it&s written to &please& the ARC compiler rather than writing natural code. Unfortunately, nothing can be done to this and we all have to live with this. The next two sections explain when you might need to write unnecessary code like this to please the compiler.Capturing &*& strongly is likely to lead to a retain cycle
ARC and retain cyclesThe last category of warning message is shown when a retain cycle is detected in your code. An example is shown below.This code was probably leaking the request object before ARC and increasing your memory footprint. But, thanks to ARC. You now know that code like these cause retain cycles that cannot be released automatically. Circumventing a retain cycle issue almost and always ends up breaking the cycle with a weak reference.Fixing this error is fairly simple and in this case, you can get a weak reference to the request object and copy it to the block. Within the block, convert it again to a strong reference. This is illustrated below.
Workaround for ARC and retain cycle issueIn the above code block, you can also replace references to __unsafe_unretained with __weak if you are deploying to a runtime that supports zero-ing weak references.Avoiding early releases using __blockSometimes, you need an object to live till as long as the completion handler on it can live. For example, a Block based UIAlertView can call a completion handler after the user presses a button on the UIAlertView.For example,
UIAlertView *alertView = [UIAlertView alertViewWithTitle:@"Test" buttons:[NSArray arrayWithObjects:@"Ok", @"Cancel", nil] completionHandler:^(int tappedButtonIndex)
{& // do something based on the button tapped on alertView}];[alertView show];
In the above case, the alertView gets deallocated by ARC as soon as it&s shown and the call to completionHandler never gets executed (or even crashes).To prevent this, you can use the __block decoration on UIAlertView declaration and copy it inside the block like
__block UIAlertView *alertView = [UIAlertView alertViewWithTitle:@"Test" buttons:[NSArray arrayWithObjects:@"Ok", @"Cancel", nil] completionHandler:^(int tappedButtonIndex)
{& // do something based on the button tapped on alertView alertView = nil;}];[alertView show];
ARC takes care of releasing it when you nil it inside the completionHandler. You will find this pattern used a lot when you work with completionHandlers in TwTweetComposeViewController or even UIViewController presentViewController:animated:completion: methods.Of course, you should de-reference the strong pointers using __weak or __unsafe_unretained (non-zeroing weak references runtime)That last questionWhen should you migrate?
NOWThe performance benefits you get by using ARC is remarkable. Apple claims that the @autoreleasepool is over 6 times faster than NSAutoReleasePool objects used in your non-ARC code. This is because, @autoreleasepools don&t allocate objects and all it does is must bump up the pointer retain counts. Similarly, NSObjects& retain and release are optimized that you can expect a performance boost of anywhere around 2.5x. The third important performance benefit you will see is in methods that return autoreleased object. Under ARC, this variable is no longer transferred using the auto-release pool and what instead happens is a ownership transfer. Again this is upto 20x faster.Hence, don&t wait till your dependent third party frameworks are migrated to ARC. You can always exclude them and go ahead and convert your code to ARC now.Where to go from here?
WWDC 2011 & Session 322 Introduction to Automatic Reference Counting
WWDC 2011 & Session 322 Objective-C Advancements in depth
Stop: You are warned. This link is only for hard code geeks.
WWDC 2011 & Session 308 & Blocks and Grand Central Dispatch in PracticeOne last word, treat this post as a living document. I&ll be updating the last few sections on new workarounds as and when I find a fix for them.&Mugunth
on Twitter
Mixing ARC and Non-ARC Code with Static Libraries （转载自/mixing-arc-and-non-arc-code-with-static-libraries/）
One of the recent improvements introduced with Xcode 4&s new LLVM Compiler 3.0 is Automatic Reference Counting (ARC). ARC is a compiler feature that will automatically manage the traditional iOS retain/release memory management model. When you enable ARC for a project, you simply do not ever call retain or release & the compiler figures it out for you. More to the point, when using ARC you are not allowed to use the retain/release calls at all, making older code incompatible with ARC compilation settings. There are already some
out there, so I&m not going to go into the how&s and why&s of ARC itself.So What&s the Problem?Now ARC is quite the cat&s pajamas as they say, but it does have some limitations. Mainly, it&s not immediately obvious how you can make use of older code that was not written with ARC in mind. Say you create a shiny new ARC-enabled project, and then find out that a shared component you want to use, the Facebook SDK for example, isn&t yet ARC enabled and won&t compile. You have to tell the compiler which source files are ARC ready and which aren&t. There in lies the rub: you can convert your old code to use ARC for sure, as I&ll discuss below, but when you are using third party components this isn&t always practical or desirable, as you&ll have a much harder time taking updates to those libraries.I&m a big fan of using third party modules from the open source community, mostly from github. I like to keep these in git submodules so that I can easily take and contribute updates to them. Forking the code and trying to convert it to ARC for my own personal usage breaks the update/contribute cycle.What I&m going to explain in this post is how you can use non-ARC code libraries inside an ARC-based project with a minimum of fuss and bother by using a static library to separate your ARC and non-ARC code without you having to modify the older code in any way.Doing Things The Hard WayFirst, let me quickly cover some alternatives to the static library approach. In some circumstances, these approaches are reasonable and convenient. When dealing with larger code libraries however, the static library approach is a real time saver.Compiler FlagsCompiler flags to the rescue! For each source file that is non ARC compliant, add the &fno-objc-arc compiler flag. Nothing more fun then managing compiler flags. This is the way I&ve seen most ARC documentation explain how to make use of non-ARC code in an ARC project, or vice-versa. These can be set on individual files by selecting the target in Xcode, going to the Build Phases screen, and double clicking on the source files row in the Compile Sources phase. Then, enter the magic compiler flag into the box. Repeat for all your &source files. Fun, eh?Using the ARC Migration WizardIf you have a larger batch of code to use, you can use the ARC migration wizard to convert all of the code in a specific target to ARC by selecting Convert to Objective-C ARC from the Edit | Refactor menu. You&ll still probably have to clean up a few things, but this is a convenient way to port your code to ARC. The problem is that if you are doing this with a third party library, such as an SDK of a public domain component then you are making changes to the actually code. This will make things tougher in the future if you want to upgrade the library. You are also making untested changes to the code base, opening the possibility for new bugs or unexpected behavior. Using the static library approach described below, however, you can leave this code unmodified.Creating a non-ARC Static LibraryThe basic approach will be to add a second target to our project which is a static library. &This library &will hold all of our non-ARC code. The library will be built automatically with your main target and linked against it when you build, so you will not need to do anything special to build or distribute the application in this approach. A static library essentially lets you have two sets of compilation settings & one for your fancy new ARC code, and another set for all of your old code.Note: The sample project I&m talking through here is available .1. Create your Static Library TargetSelect your project file in Xcode, and click on the Add Target button at the bottom of the Project Settings screen. When prompted, select the Cocoa Touch Static Library template from the Framework and Library section and click Next.For the project name, enter whatever you want your library to be called.&In this case I&m going to call my library ArcFree, but it doesn&t really matter. Click Finish. Make sure that the &Use Automated Reference Counting& option is not selected.&This will create a second target in your project that can be built right along side the first.
Delete the sample class the wizard created (ArcFree.m, ArcFree.h) as you won&t need them. You&ll notice it creates a precompiled header file as well. This can be useful, but if you don&t think you need it you can delete it & but you&ll have to modify the target&s build settings, which have been set to look for that file.2. Verify that the Static Library is Not Using ARCNow we have to fix what I suspect is a bug in Xcode 4.2. Go to your static library target&s Build Settings and search for &automatic& so that we can take a look at the Objective-C Automatic Reference Counting setting. Despite the fact that we told Xcode that we didn&t want ARC when we created the library, it doesn&t set an override on the target so this setting is inherited from the main project. Set this to &No& for your static library.
I believe what is happening is that the Xcode wizard asks about ARC so that it can setup the target&s project file correctly, but since we are adding a target to an existing project it doesn&t actually do anything. In any case, setting this flag to No means that any files compiled as part of this target will not use ARC & they will use the classic retain/release model. Verify that the flag is set correctly.3. Link with Your Static LibraryTo use any of the classes in your static library you must link it to your main application target. This is just like adding system libraries and frameworks, just with your own static library instead of a dynamic one provided by the system.Select your main application target, then click on Build Phases and expand the Target Dependencies section. Click on the plus(+) button and select your sta}