6995人阅读
& && &&& 又一扫盲篇，好吧，我想大多数人已经清楚频率与架构那个更加有主导作用，这就好像单反中像素与光圈那个重要一样,因为安桌不能像苹果那么不在意硬件，里程碑与3gs就是个很好的例子，硬件几乎相同，可3gs就是牛比的流畅，本文就是希望大家能够多多了解cpu架构的重要性。话又说回来本文与其说扫盲，不如说对其有更深入的理解，希望大家成为大师级人物。。。。
首先声明一下，近来时间不是很充裕，本文断断续续写了两三天，又因为这个涵盖的知识太多，而本人目前仍只是高中生，大多数的参数都是我百度之的。所以，如有雷同，算我抄你吧。那些专业术语看不懂无视之吧，本人只是拿来做参考，在每段最后有自己的看法。还有若参数或结语有误，欢迎指出，切勿喷之。
首先大家得有个概念，并不是cpu越高，其性能越好，如desire的1ghz就被desire z的800mhz秒杀，下面会为大家展示各种cpu规格，相对而言，本人认为在这一块做得最好的属棒子的三星了。
话说今年诺基亚出了款500，号称1ghz的cpu，一些人以为诺基亚终于发力了，是这样么，看看它的架构吧,是ARM11，基于ARMv6的，iphone从一代到四代都是基于ARMv7的（3GS与4更是基于它的升级版cortexa8的），什么概念呢？要知道ARMv7架构是在ARMv6架构的基础上诞生的。该架构采用了Thumb-2技术，Thumb-2技术是在ARM的Thumb代码压缩技术的基础上发展起来的，并且保持了对现存ARM解决方案的完整的代码兼容性。Thumb-2技术比纯32位代码少使用
31％的内存，减小了系统开销。同时能够提供比已有的基于Thumb技术的解决方案高出38％的性能。ARMv7架构还采用了NEON技术，将DSP和媒体处理能力提高了近4倍，并支持改良的浮点运算，满足下一代3D图形、游戏物理应用以及传统嵌入式控制应用的需求。此外，ARMv7还支持改良的运行环境，以迎合不断增加的JIT(Just
In Time)和DAC(DynamicAdaptive Compilation)技术的使用。专业语术牛比哄哄，不过对比也是有的，大家可以问身边有n97和ip一代的朋友来对比一下，同样400多mhz性能完全不一样啊。
又说回安桌，安桌大多数产品都是基于v7的，可虽说同样基于v7,但不同的厂商，不同规格，cpu的差距还是很明显的。
& &&&高通:正如开始提到的desire,用的是高通一代cpu,貌似现在高通把它所有的cpu名字都简化了，desire,
n1就是s1代，dhd ds dz is为s2代，ss为s3代。
& && & S1是65纳米处理器，属于第一代基础型CPU，速度为1GHz；
　　S2则为45纳米制程，拥有1.4GHz主频，支持720p视频摄录，对杜比5.1声道音频和3D等也一并支持；
　　S3则是双核版本的S2，主频达到1.5GHz，其最大特点是开始支持1080p视频录制和的物理分辨率，同时多任务和游戏性能也得到进一步增强；
　　S4则是今年要发布的领军产品四核产品，采用28纳米制程，主频达到2.5GHz，这也就是之前被称为Krait的新型顶级处理器。
　　啊，s4...这让本人的笔本情何以堪那！！
& && & 三星:蜂鸟处理器
基于Fastcore嵌入式核心的Intrinsity的Coretex-A8处理器周期精确存储平衡。当大多数ARM处理器内核同时执行合成静态逻辑以及编译静态存储器的时候，通过有效申请Intrinsity的Fast14 NDL技术持有权，作为Cortex-A8 RTL核心时序关键路径上的宏，蜂鸟处理器同时在三星45nm低功耗处理技术下便可以出色地达到1GHz的时钟速率。NDL提供多米诺逻辑与静态逻辑之间的低反应转换，可以允许NDL完整的应用于一个标准的元件合成设计。NDL提供的单元速度比静态逻辑的单元速度提高25%-50%。
高效合成流程将构建蜂鸟处理器的门级架构，该高效合成流程可创造出具备最佳时序和功率的静态逻辑。这一流程可将标准单元放置在最小化线路延迟和最大化速度的位置上。高度自动化的Vt和单元选择流程将在平衡功率的同时选择最佳速度路径。最后，一种包含自动化和优化路径选择，驱动及重新缓冲在内的高性能的物理设计一体化流程，将被用于生成最终的设计。
i9000与iphone4都是这款cpu的变形款，ip自己做了优化，a4处理器和蜂鸟本质上没什么区别，而i9000把gpu变频叠加了，多边形输出为90mt/s,iphone4只有28mt/s哦，而高通s2也不过45mt/s哪！！，虽然写入路径没那么大，可潜力是无限的啊，貌似超频后跑分也能达到70mt/s啊！！蜂鸟实力可见一斑啊。。
& && &&&猎户座处理器，这款处理器采用了三星的45nm低功耗制程技术，并采用了两个1GHz ARM Cortex A9核心，每个核心拥有32KB数据缓存和32KB指令缓存，芯片组还配有1MB的二级缓存来优化处理性能，并提供更快的多任务处理切换速度。此外猎户座的内存接口和总线架构还支持密集型的多媒体应用，包括全高清视频播放和高速3D游戏运行。
猎户座的芯片中还集成了新的硬件加速器，包括支持录制、播放1080P 30fps高清视频的编/解码器，增强的图形处理单元还将提供高于三星上一代产品5倍的3D图形性能。这里的上一代产品指的是Galaxy
S中使用的蜂鸟处理器。
知道3d性能高5倍于蜂鸟的概念么，接近xbox了，可虽说如此，可目前（i9100）能用的游戏软件还是不多，很多大型安桌游戏都不能玩啊。。但在这款cpu带动下，i9100可以说有着毫无拖泥带水的界面，目前来看，可能会成为如前任的蜂鸟一样的神器啊。。。
关于德州仪器与英伟达的下次再详解~~~~~
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：149145次
积分：1666
积分：1666
排名：千里之外
转载：143篇
评论：14条
(2)(1)(9)(19)(17)(7)(2)(10)(46)(35)&&&&& 在分析内存优化的过程中，其中一个最重要的是我们如何查看cpu的占用率和内存的占用率呢，这在一定程度上很重要，经过查询资料，研究了一下，暂时了解到大概有以下几种方式，如果哪位高手有更好的办法，或者文中描述有错误，还望高手在下面留言，非常感谢！
&&& & 一、 通过eclipse，ADT开发工具的DDMS来查看(Heap)
&&&&&&&& 在&Devices&窗口中选择模拟器中的一个需要查看的程序，从工具条中选&Update heap&按钮，给这个程序设置上&heap Updates&，然后在Heap视图中点击Cause GC就可以实时显示这个程序的一些内存和cpu的使用情况了。
然后就会出现如下界面：
说明： a) 点击&Cause GC&按钮相当于向虚拟机请求了一次gc操作； b) 当内存使用信息第一次显示以后，无须再不断的点击&Cause GC&，Heap视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化； c) 内存使用信息的各项参数根据名称即可知道其意思，在此不再赘述。
大致解析如下：
这个就是当前应用的内存占用，allocated 是已经分配的内存 free是空闲内存，
heap size 是虚拟机分配的 不是固定值 heap& size 的最大值跟手机相关的
有网友说，
一般看1byte的大部分就是图片占用的
如何判断应用是否有内存泄漏的可能性呢？
& 如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap视图中部有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是&Total Size&，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断： a) 不断的操作当前应用，同时注意观察data object的Total Size值； b) 正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对 象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平； c) 反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大， & 直到到达一个上限后导致进程被kill掉。 d) 此处已system_process进程为例，在我的测试环境中system_process进程所占用的内存的data object的Total Size正常情况下会稳定在2.2~2.8之间，而当其值超过3.55后进程就会被kill。
在如下的位置：
二、通过linux命令来查看&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
常用的命令有
ps 是看进程的
top命令是看占用率的
3.获取最大内存的方法 &&&&&&& ActivityManager am = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE); &&&&&&& am.getMemoryClass(); 这个是最大内存，如果超过这个内存就OOM了
---------------------------------------
内存耗用：VSS/RSS/PSS/USS 的介绍
VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）
一般来说内存占用大小有如下规律：VSS &= RSS &= PSS &= USS
The aim of this post is to provide information that will assist in interpreting memory reports from various tools so the true memory usage for Linux processes and the system can be determined.
Android has a tool called procrank (/system/xbin/procrank), which lists out the memory usage of Linux processes in order from highest to lowest usage. The sizes reported per process are VSS, RSS, PSS, and USS.
For the sake of simplicity in this description, memory will be expressed in terms of pages, rather than bytes. Linux systems like ours manage memory in 4096 byte pages at the lowest level.
VSS (reported as VSZ from ps) is the total accessible address space of a process. This size also includes memory that may not be resident in RAM like mallocs that have been allocated but not written to. VSS is of very little use for determing real memory usage of a process.
RSS is the total memory actually held in RAM for a process. RSS can be misleading, because it reports the total all of the shared libraries that the process uses, even though a shared library is only loaded into memory once regardless of how many processes use it. RSS is not an accurate representation of the memory usage for a single process.
PSS differs from RSS in that it reports the proportional size of its shared libraries, i.e. if three processes all use a shared library that has 30 pages, that library will only contribute 10 pages to the PSS that is reported for each of the three processes. PSS is a very useful number because when the PSS for all processes in the system are summed together, that is a good representation for the total memory usage in the system. When a process is killed, the shared libraries that contributed to its PSS will be proportionally distributed to the PSS totals for the remaining processes still using that library. In this way PSS can be slightly misleading, because when a process is killed, PSS does not accurately represent the memory returned to the overall system.
USS is the total private memory for a process, i.e. that memory that is completely unique to that process. USS is an extremely useful number because it indicates the true incremental cost of running a particular process. When a process is killed, the USS is the total memory that is actually returned to the system. USS is the best number to watch when initially suspicious of memory leaks in a process.
For systems that have Python available, there is also a nice tool called smem that will report memory statistics including all of these categories.
# procrank procrank PID&&&&& Vss&&&&& Rss&&&&& Pss&&&&& Uss cmdline 481&& 31536K&& 30936K&& 14337K&&& 9956K system_server 475&& 26128K&& 26128K&& 10046K&&& 5992K zygote 526&& 25108K&& 25108K&&& 9225K&&& 5384K android.process.acore 523&& 22388K&& 22388K&&& 7166K&&& 3432K com.android.phone 574&& 21632K&& 21632K&&& 6109K&&& 2468K com.android.settings 521&& 20816K&& 20816K&&& 6050K&&& 2776K jp.co.omronsoft.openwnn 474&&& 3304K&&& 3304K&&& 1097K&&&& 624K /system/bin/mediaserver 37&&&& 304K&&&& 304K&&&& 289K&&&& 288K /sbin/adbd 29&&&& 720K&&&& 720K&&&& 261K&&&& 212K /system/bin/rild 601&&&& 412K&&&& 412K&&&& 225K&&&& 216K procrank && 1&&&& 204K&&&& 204K&&&& 185K&&&& 184K /init 35&&&& 388K&&&& 388K&&&& 182K&&&& 172K /system/bin/qemud 284&&&& 384K&&&& 384K&&&& 160K&&&& 148K top 27&&&& 376K&&&& 376K&&&& 148K&&&& 136K /system/bin/vold 261&&&& 332K&&&& 332K&&&& 123K&&&& 112K logcat 33&&&& 396K&&&& 396K&&&& 105K&&&&& 80K /system/bin/keystore 32&&&& 316K&&&& 316K&&&& 100K&&&&& 88K /system/bin/installd 269&&&& 328K&&&& 328K&&&&& 95K&&&&& 72K /system/bin/sh 26&&&& 280K&&&& 280K&&&&& 93K&&&&& 84K /system/bin/servicemanager 45&&&& 304K&&&& 304K&&&&& 91K&&&&& 80K /system/bin/qemu-props 34&&&& 324K&&&& 324K&&&&& 91K&&&&& 68K /system/bin/sh 260&&&& 324K&&&& 324K&&&&& 91K&&&&& 68K /system/bin/sh 600&&&& 324K&&&& 324K&&&&& 91K&&&&& 68K /system/bin/sh 25&&&& 308K&&&& 308K&&&&& 88K&&&&& 68K /system/bin/sh 28&&&& 232K&&&& 232K&&&&& 67K&&&&& 60K /system/bin/debuggerd #
阅读(...) 评论()