测试理论知识手机存储培训

手机存储用例解析（2013/5/06）关键词：挂载、分区、内存泄露、分区状态错误四、多次点击USB开关后，出现无响应S1上跟存储相关的原理、现象和问题七、手机上的应用接二连三的崩溃六、桌面上应用图标显示灰色，点击后提示未安装八、手机用几天后就自动重启了一、号称8G、16G的存储空间只剩下5.77G和13G二、打开USB存储经常弹出的确认窗体九、无法开机，变砖了三、手机使用时间长了之后系统变慢了五、应用是怎么从SD卡移动到内置存储的智能手机的内置存储一、智能手机的ROM和RAMROM：ReadOnly

Memory，可擦写的系统盘符，用来存放系统所需要的文件，如data、META-IN、system、boot.img。RAM：

RandomAccessMemory，手机的内存，系统工作时需要进行调度的空间。读写速度高，内存越大，与系统进行交互时所需要调度的空间就越大。EMMC：EmbeddedMultiMediaCard，封装中集成了一个控制器，它提供标准接口并管理闪存。S1用的是EMMC解决方案。外置存储：TF卡（MicroSD）智能手机存储的简单工作原理二、简单的工作原理内存（RAM）：硬件设备数据调度的港口EMMC的控制：NANDFlash+控制器+标准封装接口挂载（Mount）：将一个设备（通常是存储设备）挂接到一个已存在的目录上（android手机上这个目录名一般为mnt/）卸载（Unmount）：将已挂接的存储设备和目录脱离U盘模式（MassStorage）：

massstorage是USB协议中的一部分，

USB从设备连接到USBHost设备上，并能够执行文件的传输S1案例分析案例一.存储容量和宣传的不符，谁偷了我的存储空间？原因：根据EMMC的提供的解决方案，对整个存储进行了分区，分为系统盘符、SD卡存储盘符、内部存储空间。存储的计算方式(存储厂商和系统识别的标准不同)：1G=10亿个字节，而系统所能识别的是（8*0.9313=7.45G）1000000000/1024byte/1024kb/1024mb=0.9313G通过adbshelldf命令可查看当前分区下的存储分配，其中/mnt/sdcard占用了5.77G,Data占用了1G，system和cache分别占用了319M和125M，还有一些其他的分区占用200多M，一共加起来就是7.45G左右。内存为1G，实际在手机上显示的只有165M+489M=654M，少了380M左右的内存。其实占用385M空间的是tmpfs，linux下的一种临时文件系统。

S1案例分析案例二：1.打开USB存储时经常弹出的确认窗体原因：后台正在运行的程序里的文件正在SD卡上（如文件管理器扫描SD卡，应用中心下载的同时打开USB存储）S1案例分析案例三：APP2SD（将应用移动到SD卡上）背景：

2.2版本以前的系统，Android手机的软件为了安全性和稳定性都是默认安装到手机制定存储空间里目的：为了节省空间，把安装在制定分区的应用移到空间容量更大的SD卡上程序安装的原理：例如UC浏览器.apk，安装过程如下，1、首先会将UC浏览器.apk重命名为com.ucmobile.apk后复制到/data/app目录下2、将com.ucmobile.apk包里的class.dex文件解压到/data/Dalvik-Cache目录下3、在/data/data目录下创建com.ucmobile目录，将com.ucmobile.apk包里的Lib（有的APK无此文件）下对应的.so文件复制到.ucmobile/lib目录下，UC浏览器使用产生的缓存、书签、设置等数据都存放在.ucmobile下APP2SD原理

官方的app2sd：只把/data/app目录下的apk移动至SD卡下，且需要软件自身支持安装在内存卡上才可以，也就是说用官方的app2sd，要把程序安装在内存卡上，并不是我们使用者说了算，而是软件开发者说了算。移动至SD卡后，使用U盘模式的同时不能使用该应用民间app2sd：把当前SD卡里划分出一个linux所能识别的ext格式的分区，将/data/app等移动到ext分区后创建链接替代。移动app时将/data/app、/data/Dalvik-Cache、/data/data都移到内存卡的EXT分区。当使用U盘模式时，仍然可以使用移动到SD卡上的应用。S1案例分析案例四：多次点击USB开关后，出现无响应，甚至出现重启。可能导致该问题的原因：1.EMMC控制芯片出问题2.STE的解决方案对于USB驱动支持不够好3.Framework上层堵塞，导致Systemserver异常后进行重启。S1案例分析S1案例分析

USB驱动

上层操作界面点击打开USB存储按钮android标准库调用PackageManager,MountService等进行UI更新，通知已打开成功，StorageNotification可能发生的问题点如下：1.UI没及时更新2.Framework层堵塞，导致无响应4.硬件设备损坏，底层出错，导致上层无法获取正确信息3.Framework层出错，导致提示出错Application层Framework层Libraries层LinuxKernel层打开USB流程Android各层级————————————————S1案例分析检查当前USB状态进行卸载手机SD卡盘符的操作（Unmount）MountUnmountingUnmountingUnmountedUnmountedSharedS1案例分析衍生案例1：点击USB存储按钮了，没有反应，但是U盘模式已经开启了可能的原因：上层UI更新出错，未及时进行更新衍生案例2：点击USB存储按钮，一直处于等待界面可能的原因：Framework层出错，卸载分区没有成功衍生案例3：移动到SD卡上的某些应用无法启动可能的原因：该程序调用JNI，而安装到SD卡上后没有调用权限导致无法启动衍生案例4：插上USB线后没有提示已接入设备可能的原因：1)USB线坏了2)手机端USB接口处坏了衍生案例5：安装在SD卡上的应用重启后显示android默认图标，且无法启动可能原因：手机在重启时需要重新挂载SD卡，这是安装在SD卡上的程序会进行权限的申请，库文件的调用等操作，此时若系统没处理好此处的逻辑，很容易发生该问题S1案例分析案例五：桌面图标显示灰色，点击后提示未安装原因:

安装多个应用后(大于50)，开启关闭U盘模式或重启之后，桌面程序会去读取应用安装的列表，此时存储应用的分区出错导致桌面读取到了错误的数据，反映在桌面上就是无法正常显示图标。S1案例分析案例六：使用一段时间后系统自动重启原因：内存泄露--使用了内存（RAM）却没有进行释放。导致S1自动重启的一个原因锁屏时有内存泄露，在多次进行锁屏解锁操作后较容易出现。内存泄露的查看方法：参照啄木鸟知识库—>Android手机测试中阶—>MAT内存泄露检测Android系统上的内存泄露：程序调用的非代码本身的类导致的内存溢出，如调用androidframework层已封装好的类，而该类不包含在java和android的回收机制中。S1案例分析案例七：手机应用连续自动崩溃原因：系统Data分区状态错误，正常情况下应该是读写（RW），而出错时状态为只读（RO）分析引起只读的一些思路：1.理解Data分区的作用，进入Data分区可以看到他里面包含的文件app、data、adm.sqlite、davlik-cache等。App是安装在手机内置存储的apk的文件夹，data文件夹下是系统内应用的package存放的路径，adm.sqlite提供应用于数据库的交互，davilk-cache提供虚拟机缓存空间。出现data分区只读可能是某项操作引起的分区保护，把分区状态转换成了只读。2.基于以上推出以下复现场景：1.）安装较大的应用的同时进行短信发送、电话拨出、短信联系人添加删除等操作。2.）或进行数据库、安装apk时进行断电操作S1案例分析案例八：手机变砖原因：EMMC系统分区损坏，导致无法通过boot.img进行开机存储模式的用例分析1）反复断电重启（检查EM