5194人阅读
android（64）
只要是需要进行联网获取数据的APP，那么不管是版本更新，还是图片缓存，都会在本地产生缓存文件。那么，这些缓存文件到底放在什地方合适呢？系统有没有给我们提供建议的缓存位置呢？不同的缓存位置有什么不同呢？今天这篇文章就是主要来说明这个问题的。
首先，我们要知道，在Android手机里面，缓存的位置分为两类，一类是Internal Storage，即内部存储，另外一类是External Storage，即外部存储。比较老的手机，有一个手机内部存储，还有一个SD卡存储，就是分别对应这两种存储位置，因为以前的SD卡是可以扩展的，即可拆卸的，所以可以用是否可拆卸作为内外存储的分类标准。但是现在最新的设备，比如小米、锤子、华为等，都取消了可拆卸的SD卡，直接与机身焊接在一起，分为16G、32G版本，所以现在内外存储的分类不再以是否可拆卸作为标准，而是以下面的几方面作为新的标准：
内部存储：
总是可用的
这里的文件默认是只能被你的app所访问的。
当用户卸载你的app的时候，系统会把internal里面的相关文件都清除干净。
Internal是在你想确保不被用户与其他app所访问的最佳存储区域。
外部存储：
并不总是可用的，因为用户可以选择把这部分作为USB存储模式，这样就不可以访问了。
是大家都可以访问的，因此保存到这里的文件是失去访问控制权限的。
当用户卸载你的app时，系统仅仅会删除external根目录（getExternalFilesDir()）下的相关文件。
External是在你不需要严格的访问权限并且你希望这些文件能够被其他app所共享或者是允许用户通过电脑访问时的最佳存储区域。
读取内部存储不需要权限，但是读取或者是写入外部存储需要权限，在现版本里面，读权限不进行声明，也可以实现读取，但是在以后版本可能会修改，所以请务必加上，如果应用需要写入权限，那么只声明写入权限即可，不需要再声明读取权限。
下面分别说明如何获取内外存储的文件位置和区别。
一.保存到内部存储的方式
1.getFileDir() 通过此方法可以获取到你的APP内部存储的文件，路径为/data/data/pacgage_name/files
我们直接上代码进行测试：
File&file1&=&new&File(getFilesDir(),&&getFilesDir.txt&);
Log.d(&TAG&,&&file1=&&+&file1.getAbsolutePath());
&&&&&OutputStream&outputStream1&=&new&FileOutputStream(file1);
&&&&&outputStream1.write(&file&.getBytes());
&&&&&outputStream1.close();
}&catch&(Exception&e)&{
&&&&&e.printStackTrace();
运行结果如下：
02-03&07:18:04.068&&/?&D/TAG﹕&file1=/data/data/com.socks.baidudemo/files/getFilesDir.txt
2.getCacheDir() 通过此方法可以获取到你的APP内部存储的文件，路径为/data/data/package_name/cache
测试代码：
File&file2&=&new&File(getCacheDir(),&&cache.txt&);
Log.d(&TAG&,&&file2=&&+&file2.getAbsolutePath());
&&&&&OutputStream&outputStream1&=&new&FileOutputStream(file2);
&&&&&outputStream1.write(&cache&.getBytes());
&&&&&outputStream1.close();
}&catch&(Exception&e)&{
&&&&&e.printStackTrace();
运行结果如下：
02-03&07:19:31.508&&/?&D/TAG﹕&file2=/data/data/com.socks.baidudemo/cache/cache.txt
3.openFileOutput() 通过此方法，我们可以获取到一个输出流，输出流的保存路径是/data/data/package_name/files ，和getFileDir()的路径一致
测试代码如下
&&&&&OutputStream&outputStream&=&openFileOutput(&openFileOutput.txt&,&MODE_PRIVATE);
&&&&&outputStream.write(&openFileOutput&.getBytes());
&&&&&outputStream.close();
}&catch&(Exception&e)&{
&&&&&e.printStackTrace();
运行结果：
你的app的internal storage 目录是以你的app的包名作为标识存放在Android文件系统的特定目录下[data/data/com.example.xx]。 从技术上讲，如果你设置文件为可读的，那么其他app就可以读取你的internal文件。然而，其他app需要知道你的包名与文件名。若是你没有设置为可读或者可写，其他app是没有办法读写的。因此只要你使用MODE_PRIVATE ，那么这些文件就不可能被其他app所访问。
另外记住一点，内部存储在你的APP卸载的时候，会一块被删除，因此，我们可以在cache目录里面放置我们的图片缓存，而且cache与files的差别在于，如果手机的内部存储控件不够了，会自行选择cache目录进行删除，因此，不要把重要的文件放在cache文件里面，可以放置在files里面，因为这个文件只有在APP被卸载的时候才会被删除。还有要注意的一点是，如果应用程序是更新操作，内部存储不会被删除，区别于被用户手动卸载。
二.外部存储的方式
1.外部存储的状态
与内部存储不同，外部存储的容量一般较大，而且当移动设备连接到PC之后，如果我们开启USB模式与PC连接并操作文件，这个时候外部存储是处于卸载状态的，APP不能对里面的文件进行操作，所以，我们的APP的对外部存储进行操作之前，请先检查外部存储的状态。
public&boolean&isExternalStorageWritable()&{
&&&&&String&state&=&Environment.getExternalStorageState();
&&&&&if&(Environment.MEDIA_MOUNTED.equals(state))&{
&&&&&&&&&&return&true;
&&&&&return&false;
public&boolean&isExternalStorageReadable()&{
&&&&&String&state&=&Environment.getExternalStorageState();
&&&&&if&(Environment.MEDIA_MOUNTED.equals(state)&||
&&&&&&&&&&Environment.MEDIA_MOUNTED_READ_ONLY.equals(state))&{
&&&&&&&&&&return&true;
&&&&&return&false;
2.外部私有存储
从上面内部存储的介绍来看，内部存储的文件应该属于私有文件，别的APP想要访问是比较困难的，那么外部存储呢？外部存储由于容量较大，一般是我们的APP保存较大文件的不二选择，那么是不是外部存储里面的文件，所有的APP都可以随意访问呢？显然并不是这样的，在外部存储中，也存在着私有文件的概念。
就像我们在前面获取内部存储的方法一样，我们使用Context.getExternalCacheDir()和Context.getExternalFilesDir()就可以获取到外部存储的私有文件，我们以下面的代码为例
File&file3&=&new&File(getExternalCacheDir().getAbsolutePath(),&&getExternalCacheDir.txt&);
&&&&&OutputStream&outputStream1&=&new&FileOutputStream(file3);
&&&&&outputStream1.write(&getExternalCacheDir&.getBytes());
&&&&&outputStream1.close();
}&catch&(Exception&e)&{
&&&&&e.printStackTrace();
Log.d(&TAG&,&&file3=&&+&file3);
File&file4&=&new&File(getExternalFilesDir(Environment.DIRECTORY_PICTURES),&&getExternalFilesDir.txt&);
&&&&&OutputStream&outputStream1&=&new&FileOutputStream(file4);
&&&&&outputStream1.write(&getExternalFilesDir&.getBytes());
&&&&&outputStream1.close();
}&catch&(Exception&e)&{
&&&&&e.printStackTrace();
运行结果如下：
02-03&08:11:38.860&&&&/?&D/TAG﹕&file3=/storage/emulated/0/Android/data/com.socks.baidudemo/cache/getExternalCacheDir.txt
02-03&08:11:38.860&&&&/?&D/TAG﹕&file4=/storage/emulated/0/Android/data/com.socks.baidudemo/files/Pictures/getExternalFilesDir.txt
在系统中得位置如下
从上图可以看出，我们创建的私有文件的地址是/sdcard/Android/date/package_name下面，Android文件夹是隐藏文件夹，用户无法操作。
如果我们想缓存图片等比较耗空间的文件，推荐放在getExternalCacheDir()所在的文件下面，这个文件和getCacheDir()很像，都可以放缓存文件，在APP被卸载的时候，都会被系统删除，而且缓存的内容对其他APP是相对私有的。
但是，除此之外，还是有一些差别的：
Context.getExternalFilesDir()和Context.getFilesDir()也是有区别的，但是在应用卸载的时候，也是会被删除的。
3.外部公共存储
如果你的APP产生的文件不需要隐藏，即对用户是可见的，那么你可以把文件放在外部的公共存储文件下面。
我们可以通过下面的代码获取到公共存储目录
Environment.getExternalStorageDirectory()
Environment.getExternalStoragePublicDirectory()
这个方法不是Context的方法，而是Environment的两个方法，第一个方法获取到的其实是外部存储的根目录，而第二个方法获取到得则是外部存储的公共目录。其实在访问权限上是没有区别的，不同点是getExternalStoragePublicDirectory()在运行的时候，会需要你带有一个特定的参数来指定这些public的文件类型，以便于与其他public文件进行分类。参数类型包括DIRECTORY_MUSIC
或者 DIRECTORY_PICTURES. 如下:
public&File&getAlbumStorageDir(Context&context,&String&albumName)&{
&&&&&File&file&=&new&File(context.getExternalFilesDir(Environment.DIRECTORY_PICTURES),&albumName);
&&&&&if&(!file.mkdirs())&{
&&&&&&&&&&Log.e(LOG_TAG,&&Directory&not&created&);
&&&&&return&
不管你是使用 getExternalStoragePublicDirectory() 来存储可以共享的文件，还是使用 getExternalFilesDir() 来储存那些对与你的app来说是私有的文件，有一点很重要，那就是你要使用那些类似DIRECTORY_PICTURES 的API的常量。那些目录类型参数可以确保那些文件被系统正确的对待。例如，那些以DIRECTORY_RINGTONES 类型保存的文件就会被系统的media
scanner认为是ringtone而不是音乐。
下面就是这些参数对应的文件夹
之前一直对缓存文件夹乱糟糟的，经过这么已整理，感觉清楚了很多，萌萌哒 ~~~~^_^~~~
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：71021次
积分：1307
积分：1307
排名：千里之外
原创：39篇
转载：127篇
(9)(5)(1)(6)(3)(1)(5)(14)(22)(23)(11)(8)(6)(14)(5)(7)(12)(4)(5)(2)(4)
(window.slotbydup = window.slotbydup || []).push({
id: '4740881',
container: s,
size: '200,200',
display: 'inlay-fix'4193人阅读
android常用知识（8）
一、缓存机制
1、为什么要加缓存？
场景一：【等待】，在向服务器请求新的数据时。我们让用户看到什么？第一种是漂亮的等待加载页面；第二种是缓存的内容。对于第二种，用户可以对页面进行操作，等待新数据时可以查看旧数据，更具有“可操作性”与“可用性”，从而减轻了从服务器获取数据这一动作的大小和时间长短，增强了用户体验。另一方面，如果内容更新的间隔较长或者用户刷新的间隔较短，在没有缓存的情况下，很多数据我们会多次重复的向服务器获取，增加了成本。
场景二：【结果】没有联网，或者在地铁上网络太差无法加载数据时，如果留给用户一个空白页面，实在是感觉有点不负责任啊。并且很多功能在没有联网的情况下也有使用的可能性，比如：APP中的通讯录，查看一些聊天记录，通知信息，文章列表等。因为用户打开APP不一定是要看新信息，说不定是回顾老信息（或许老信息里也有用户之前没看的），所以恰当的缓存可以满足更多的用户场景。
场景三：【金钱】有一天，一个用户发现自己装了某个APP后流量用的特别快，Ta可能永远将这个APP打入冷宫了，而增加缓存正是节省流量的一个方法。虽然节省的不多或者用户也察觉不到，但是作为一个有态度的产品经理，应该多做一些思考。
2、什么是缓存？
缓存可分为如下几类：
（1）app缓存。
（2）固定缓存。
（3）可手动清理的缓存。
（4）不可手动清理的缓存。
（5）临时缓存。
其中，临时缓存常用于一个功能页面内，保存各栏目的缓存。同一个功能里会把子功能分为多个栏目进行划分，每个标签栏目下的内容在本次使用中都可保存为临时缓存，在该功能里切换栏目，不需要重新加载数据，使用缓存显示。
对于用户来说，使用时达到了无缝切换浏览，对于服务器来说，在短时间内数据很少会有更新，所以在一般情况下能满足用户的正常需求，并达到体验优秀。
临时缓存的清理机制是：退出该功能模块就清除之前的缓存。也就是说下次进入该功能模块，需要重新获取一次数据。
很多时候我们都会用到临时缓存，因为那些信息真的不是那么重要，而且不需要经常反复查看，那对于那些我们经常使用而且经常需要反复查看的信息，马海祥建议采取固定缓存，保存在本地，方便下次翻阅时不需要再一次向服务器请求数据了。
对于固定缓存又会细分为可手动清理的缓存和不可手动清理的缓存。
第一种是我们最常见的缓存，几乎所有产品都采用这种缓存方式。平时用户浏览文章、图集加载的数据就以这种形式缓存在本地，下次看回这篇文章、图集时就不需要加载了。用户也可以手动把这些缓存清理了，释放空间。
而对于某些特殊场景，例如一些相对固定的数据，我们不愿意一开始就打包进App里，这样会占太大容量，造成产品包很大，也不愿意每次进入页面都向服务器加载这些信息，那怎么办？建议的解决方法就是我们可以只加载一次就永远存在本地了，这样安装包也不会大，以后也不用加载了。
3、如何清理缓存？
一般App都会在“设置”里提供一个清理缓存的功能，一键把空间释放。除此之外，App最好要设计自动清理机制，可以通过两个维度来设计这个机制。
（1）、时间
通过设定一个固定的时间，或者根据用户使用周期灵活设定时间来清理缓存。每个产品的场景不一，用户使用频率不一，设定这个机制的时候就需要结合实际情况考虑了。
（2）、容量
一般是设定一个容量上限，采用堆栈的设计原理进行缓存清理，溢出堆栈的旧数据将自动清除。
二、加载机制
1、页面加载
方案1：单页面整体加载
这种加载比较简单，一般运用在页面内容比较单一的情况下，所以直接一次性加载完所有数据后再显示内容。其单页面加载失败的状态相对来说也比较好处理。
方案2：单页面分块加载
这种方案的特点是，能让用户逐步看到内容，在这个渐进的过程中降低用户的焦虑心理。
其中又可以分为，模块间有关联性的，先加载父内容，再加载子内容。如优酷，先把栏目加载出来，再加载各栏目的内容。
模块间没有绝对关联性的，可独自加载各自模块内容，根据请求的速度不同分别显示。这样处理有一定几率让用户在没完全刷出数据的情况下就能找到自己需要的功能，如大众点评、淘宝客户端等。
框架固定，内容更新的，可先把框架显示出来，再把各模块的数据各自加载显示，如各种iOS自带应用。
这种分模块加载的需要特别注意加载失败的状态，毕竟每个模块都提示加载失败，点击重试是很挫的一件事，可以根据信息的优先级来决定哪些数据失败了采用默认状态，哪些数据采用失败提示。
方案3：跨页面加载
父页面&子页面 or 同一app内，页面间字段可以复用的，在加载子页面时不需要重新加载新数据。
方案4：预加载
这种加载方式的特点是，在加载一个页面内容的同时，预测用户的下一步行为，并为他下一步需要使用的页面加载内容，使得他在下一步的操作中能立刻获取信息而不需要加载等待。
预加载提供给用户无缝的产品使用体验，使得用户在使用产品的过程中更直接流畅，没有被打断的感觉。
具体的例子有：
在浏览图集的时候，当看到第一张的图片时，就自动后台加载第二第三第四张图片，用户浏览完第一张图片切换到第二张时就不会有加载等待的过程。
在浏览新闻列表时，就把每篇新闻的内容在后台进行预加载，用户选择看某篇新闻时，能立刻阅读到内容。
但是这种方案也需要面临很多的问题，马海祥觉得最直接的就是流量问题，因为会自动跑掉很多用户可能根本用不上的数据流量，所以，一般情况下马海祥建议可以设定在wifi环境才采用这种加载模式。又或者设定加载规则，只把主要内容预加载，而部分次要内容可以在用户真的用到的时候才加载，例如预加载新闻正文的情况，可以只加载文本信息，图片信息等到用户进入内页才加载。这种预加载与分块加载结合的方式也普遍运用在各个场景。
另外，预加载也需要时间的，他只是不在客户端显示给用户，默默在后台运作而已，需要特殊考虑未加载完用户就使用到那些信息的情况，所以在做预加载设计时需要同时考虑另一种适合该情况的普通加载方式。
预加载需要根据具体的场景来进行设计，设定好信息优先级，综合考虑各种类型信息的具体大小流量，整体考虑预加载的方式，这些都是需要经过精心分析思考的。
随着网络环境的发展，预加载将成为以后产品普遍的加载方式，他提供给用户的无缝使用体验大大地提升了产品的可用性。
2、操作加载
除了页面的信息需要加载，页面内的操作也是需要通过给服务器发送请求记录的。
方案1：加载层
进行一个操作后，弹出模态的提示层，告知用户正在加载。采用模态的提示主要是防止用户在该过程中进行其他操作，导致当前加载出错。由于采用模态的提示，并且有可能因为网络原因导致长时间处于加载状态，建议提供一个“关闭”的操作，中止本次加载，恢复App可用状态。加载失败时可在当前浮层变换为失败提示。模态提示层是最稳妥的方式，但他会使用户在使用过程中有打断的感觉。
方案2：控件自身加载状态
这种方式是把操作加载的状态与控件的样式结合起来了，对某个控件进行操作后，控件变换为加载状态，此时控件不能重复操作。由于这种加载方式是控件的自身状态，不影响其他操作，所以用户也可以对页面进行其他操作，可能会导致同时有多个请求的情况，增加了加载失败的风险，这也算是这种方式的弊端，不过这种极端情况很少出现。请求失败后，可配合Toast提示告知用户失败的原因。
方案3：后台加载
用户在操作后，客户端立刻反馈操作成功，然后把请求放到后台与服务器交互，这一过程用户不需要了解，不需要等待，在正常情况下体验是非常棒的。
但是在极端情况下会出现一些莫名其妙的状况，由于是后台记录请求并与服务器交互，所以实际请求是否成功客户端是不说明的，全部以操作成功来显示，这就会导致用户误以为操作成功了，但实际上下次来看发现没有成功。
所以，这种加载方式是需要根据具体使用场景来权衡使用的，对于一些重要的操作，建议还是使用模态的方式加载，对于一些小操作，如点赞、订阅、关注，可采用后台加载的方式。
3、下一页加载还是当前也加载
用户进入首页，正式迈出体验的第一步，接下来迎接的就是基于用户目标的界面间跳转。完成界面的跳转，会有各种加载策略，但无论形式如何，我们都可以将其归为两大类：“下一页加载”、“当前页加载”。
（1）“下一页加载”满足了用户提前窥视的需求
我们把页面看成“点”，页面流是连接这些点的“线”，我们以“用户想买一条牛仔裤”这一场景作为案例做了简单的眼动研究，从应用启动到商品浏览再到商品确定最后进入下单页，用户所呈现的瞳孔梯次增大，即E&D&C&B&A，为了解释这一现象，通过与被试交流，我们发现相比于各种浏览，用户更期待看到他们想看到的东西。因此此时的”下一页加载“正好，满足了用户提前窥视的需求。
（2） Wait！I Need Think Think
我们以同样的方式又对“使用支付宝对手机充值”这一场景做了研究，从开始支付到二次确认支付，用户所呈现的瞳孔都比较大，即A与B近似相等，通过访谈，我们发现与“递增体验流”不同的是，当用户遇到判断逻辑的界面时，用户并非急于想看下一页面到底包含怎样的内容，而是非0即1的验证心态，即我的操作效成功了吗？因此在判断逻辑界面中，用户的内容窥视需求并不强，当然也没什么内容，要么仅是一个小小的Toast，再大一点就是一个简单的信息反馈界面（意味着“下一页加载”在这里就是个鸡肋），用户反而对非0即1的验证需求较为强烈，其中还伴随着等待结果过程中的紧张感、激动感，因此界面通过当前页加载表明系统正在努力地处理用户交代的指令迎合了用户的紧张感、激动感，直到结果显现——“处理成功”，完成了非0即1验证的满足感。
4、先加载还是先展示
当需加载的是功能时，可以先展示再加载，当需加载的是内容时，则反过来。
打开APP的第一个页面是功能，所以先展示再加载的：
随便点击一个模块（不要点菜单），下面要展示的将要是内容（商品），所以是先加载再展示的，没有加载完都不展示：
同样的，功能模块先展示后加载：
内容先加载，没加载完不展示：
两种方式各有利弊：
先展示，后加载：
优点：给用户0等待的错觉
缺点：当前数据有可能是错的，而且得等用户操作到最后一步才会发现
先加载，后展示：
优点：保证数据的质量和准确
缺点：网络不好时，造成等待
显然，功能模块对于一个产品来说是既有固定的，在短时间内几乎不会更新，所以这种数据出现错误或与当前状态不同的几率小得多，因此，可以使用先展示后加载的方式。
另一方面，内容（特别是商品数据）是最容易产生变动的，为了保证每一个消费者看到的数据都是最真实，最准确的，所以务必要先加载再展示。
三、刷新机制
1、空白页面刷新失败有提示
现在的应用都标榜以内容为中心，所以都会极力避免空白页面的出现。对于大部分的应用，最好的方法就是使用缓存，进入页面之后，先显示之前的缓存，然后再进行内容的刷新。其次，消灭空白页面的第二种方法就是提供系统推荐项进行替代。但是对于一些页面，页面内容跟用户的使用状态关系密切，无法避免会出现空白页面，这时候会使用一些引导类的提示，使得页面变得更加丰富，同时可以促进用户产生内容。
但是一些资讯类应用，比如读读日报，打开默认是空白页面，然后再加载内容（我不是很明白这种设定）。其他一些应用，比如：豆瓣一刻和MONO，每天第一次进入应用的时候也会出现空白页面。我猜想第二类应用的展示方式的原因是这样的。他们的内容推送都是严格以天为单位的，每天固定时段推送精选内容。他们会希望你每天只看并且看完当天的东西，所以一旦到了第二天，昨天的内容就是累赘了。所以每天第一次进入应用的时候会出现空白页面，象征着每天都是从新开始。此时就会对应一个“空白刷新”逻辑。
空白刷新对应的场景是这样子的：用户想要刷新出内容，并且用户知道这里可以刷出新内容，但是没有刷新成功，这时候需要给用户一个交待。所以需要提示用户。同时，提示完用户之后需要给用户一个解决方法，这就是“点击后重试”。
2、缓存页面刷新失败无提示
常见的应用比如知乎、网易新闻、好奇心日报、微信朋友圈等，这些应用都会采用缓存的形式，打开之后显示的是缓存内容，然后系统会给服务器发送请求，如果有内容更新的话就会自动更新一次内容，更新之后的内容直接覆盖当前的内容。更新失败之后是没有提示的。但是有一些应用，比如有道词典、企鹅FM、网易云音乐等，他们更新失败之后是有提示的。
我觉得这两种应用的区分点在于
应用的使用频率；
内容的时间连续性；
界面之间的关系紧密度。
比如说网易新闻，作为一个打发时间的工具，每天使用频率就会比较高，所以用户进来之后是想看看有没有更新。其次，网易新闻的内容是连续不断更新的，所以用户会知道当前显示的内容是我看看过并且处理过的。最后，新闻列表页面显示的是摘要，用户可以通过摘要快速进行判断是否要进入详情页，摘要有助于帮助用户回忆上一次的使用场景。
所以这就对应着一个这样的场景：用户只是想看看有没有更新，所以他们已经做好了“没有新内容”的心理预期，所以即使是更新不了内容，用户也不会想太多。反倒是，如果进行了错误提示，用户可能会有一种挫败感。因为他知道现在有内容，只是因为网络的原因而没有更新，他要进行的任务受到了外界因素的阻碍，由此产生一种细微的挫败感。
3、缓存页面刷新失败有提示
另一类应用，使用频率没那么高，或者内容不具备时间连续性的，又或者说当前界面无法唤起用户上一次的使用场景。那么就有必要进行率先你失败提示了。
比如说企鹅FM，音频类的应用注定使用不会那么频繁，因为通过视觉接收的信息会比通过听觉接收的信息更快更多，同时音频类对环境的要求较高（比如用耳机时要求环境不那么嘈杂，外放时要求在私人场所）。其次，此类应用都是实时推荐的，不存在时间连续性的问题，用户无法通过时间来判断内容是否被阅读过。再者，标题也无法帮你快速做出判断，你还是要进去听过才知道内容是什么。最后如果不提醒，用户进入到详情页再收到提醒，就会觉得应用浪费了用户的时间。所以，对于此类内容，刷新失败是有必要进行提醒的。
转载自/p/120nwhp.html
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：8807次
排名：千里之外
(1)(1)(8)(4)
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'IOS把图片缓存到本地的几种方法
把图片缓存到本地，在很多场景都会用到，如果是只储存文字信息，那建一个plist文件，或者就能很方便的解决问题，但是如果存图片到沙盒就没那么方便了。这里介绍两种保存图片到沙盒的方法。
一.把图片转为base64的字符串存到数据库中或者plist文件中，然后用到的时候再取出来
//获取沙盒路径，
NSString *path_sandox = NSHomeDirectory();
//创建一个存储plist文件的路径
NSString *newPath = [path_sandox stringByAppendingPathComponent:@/Documents/pic.plist];
NSMutableArray *arr = [[NSMutableArray alloc] init];
//把图片转换为Base64的字符串
NSString *image64 = [self encodeToBase64String:image];
[arr addObject:image64];
//写入plist文件
if ([arr writeToFile:newPath atomically:YES]) {
NSLog(@写入成功);
这样就存起来的，然后用到的时候再利用存储的字符串转化为图片
NSData *_decodedImageData
= [[NSData alloc] initWithBase64Encoding:image64];
UIImage *_decodedImage
= [UIImage imageWithData:_decodedImageData];
二.把图片直接保存到沙盒中，然后再把路径存储起来，等到用图片的时候先获取图片的路径，再通过路径拿到图片
//拿到图片
UIImage *image = [UIImage imageNamed:@flower.png]; NSString *path_sandox = NSHomeDirectory();
//设置一个图片的存储路径
NSString *imagePath = [path_sandox stringByAppendingString:@/Documents/flower.png];
//把图片直接保存到指定的路径（同时应该把图片的路径imagePath存起来，下次就可以直接用来取）
[UIImagePNGRepresentation(image) writeToFile:imagePath atomically:YES];
下次利用图片的地址直接来拿图片。
同时附上获取沙盒目录的代码
沙盒文件目录获取代码：
//Home目录
NSString *homeDirectory = NSHomeDirectory();
//Document目录
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *path = [paths objectAtIndex:0];
//Cache目录
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES);
NSString *path = [paths objectAtIndex:0];
//Libaray目录
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES);
NSString *path = [paths objectAtIndex:0];