『壹』 android 能否使用大数据
晕，使用大数据跟内存大小手机配置什么的有什么关系。。。看你怎么理解“使用大数据”吧，把android手机系统作为大数据系统的一部分，收集数据或者使用大数据的分析结果提供服务都是可以的，但是你要直接用android作为大数据的存储和分析系统，基本上就是比较难的了
『贰』 android 怎么读取大数据
Android读取Excel文件主要有jxl和Poi两种方法。
1.JXL
只支持2003版本的excel，即xls的文件。
当文件大于5万行的内时候，会出现OOM错误。
2.Poi
比较容流行的一套office开源代码。
可以读取2003和2007版本的excel。
但问题是，引用的Jar包太多。
会引发Android著名的65K(65536)错误。
当然现在在Stuido中有解决65K的方法了。
有待尝试。
*3.国内的橄榄办公office
读取大的excel文件会卡。。。
这还是官方的app。
『叁』 在Android中两个进程之间传输大数据，可以使用什么方式实现
1、可以用AIDL调远程服来务源
2、本地TCP或UDP
3、端-本地-端，利用缓存(很慢)
在不触发内存溢出或者是应用无响应的前提下，还是前两种方式靠谱一点，可以另外开个线程进行本地大数据的交换.
可以参考下网上关于AIDL的知识，用AIDL完全可以实现你要的功能；
如果不嫌弃麻烦，用上内容提供者也是可以的。
希望对你有所帮助。
-
『肆』 android ListView 每个item加载大量的文本滑动会出现内存溢出咋办咋办
这个设计到listview优化问题。
首先，listview必须严格按照convertView及viewHolder格式书写，这样可以基本保证数据最优。
其次，如果自定义Item中有涉及到图片等等的，一定要做图片优化。bitmap释放可以不做。
第三，尽量避免在BaseAdapter中使用static 来定义全局静态变量，这个影响很大，static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用static修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例（比如Context的情况最多），这时就要尽量避免使用了..
第四，尽量避免在ListView适配器中使用线程，因为线程产生内存泄露的主要原因在于线程生命周期的不可控制。
最后，如果上述你都做到的话，你的listview已经优化的很好了。针对你的问题，你的listview控件高度是否设置为fill_parent，因为warp会导致listview滑动中无限计算自身高度。你的文本加载是否做过线程以及多次重复加载的问题处理。你的item中变量是否多次无限生成新的内存对象等等。
『伍』 Android 接收大量数据如何避免频繁GC
GC会stop the world。会暂停程序的执行，带来延迟的代价。所以在开发中，我们不希望GC的次数过多。
本文将讨论如何在开发中改善各种细节，从而减少GC的次数。
(1)对象不用时最好显式置为 Null
一般而言,为 Null 的对象都会被作为垃圾处理,所以将不用的对象显式地设
为 Null,有利于 GC 收集器判定垃圾,从而提高了 GC 的效率。
(2)尽量少用 System.gc()
此函数建议 JVM进行主 GC,虽然只是建议而非一定,但很多情况下它会触发
主 GC,从而增加主 GC 的频率,也即增加了间歇性停顿的次数。
(3)尽量少用静态变量
静态变量属于全局变量,不会被 GC 回收,它们会一直占用内存。
(4)尽量使用 StringBuffer,而不用 String 来累加字符串
由于 String 是固定长的字符串对象,累加 String 对象时,并非在一个 String对象中扩增,而是重新创建新的 String 对象,如 Str5=Str1+Str2+Str3+Str4,这条语句执行过程中会产生多个垃圾对象,因为对次作“+”操作时都必须创建新的 String 对象,但这些过渡对象对系统来说是没有实际意义的,只会增加更多的垃圾。 避免这种情况可以改用 StringBuffer 来累加字符串,因 StringBuffer是可变长的,它在原有基础上进行扩增,不会产生中间对象
(5)分散对象创建或删除的时间
集中在短时间内大量创建新对象,特别是大对象,会导致突然需要大量内存,JVM 在面临这种情况时,只能进行主 GC,以回收内存或整合内存碎片,从而增加主 GC 的频率。
集中删除对象,道理也是一样的。 它使得突然出现了大量的垃圾对象,空闲空间必然减少,从而大大增加了下一次创建新对象时强制主 GC 的机会。
（6） 尽量少用 finalize 函数
因为它会加大 GC 的工作量， 因此尽量少用finalize 方式回收资源。
（7） 使用软引用类型
如果需要使用经常用到的图片， 可以使用软引用类型， 它可以尽可能将图片保存在内存中， 供程序调用， 而不引起 OutOfMemory。
『陆』 android 加载大量图片速度慢是什么原因，是访问sd卡慢，还是使用bitmap的时候慢
android 加载大量图片速度慢原因一般是访问sd卡慢，SD卡读取速度较慢造成的加载文件速度慢。
加载，汉语词语，字面意思是增加装载量。现多用于计算机相关领域，表示启动程序时文件或信息的载入。
位图文件(Bitmap)，扩展名可以是.bmp或者.dib。位图是Windows标准格式图形文件，它将图像定义为由点(像素)组成，每个点可以由多种色彩表示，包括2、4、8、16、24和32位色彩。例如，一幅1024×768分辨率的32位真彩图片，其所占存储字节数为:1024×768×32/8=3072KB
位图文件图像效果好，但是非压缩格式的，需要占用较大存储空间，不利于在网络上传送。jpg格式则恰好弥补了位图文件这个缺点。
『柒』 android intent跳转怎样传输大数据
在Activity或者组件之前传递信息时，一般采用intent绑定bundle的方式传值，但在使用过程中需要注意的是不要用bundle传递大容量数据：
在做项目的过程中，需要将听写界面的听写结果信息传递到听写记录界面供显示用，但是由于传递的数据量过大导致程序ANR，甚至直接报异常（传递的信息里面有bitmap转换成的byte数组、每一个词组的拼音、词语、语音信息），经过分析发现是由于bundle不能传递大容量的数据信息，在stackoverflow里面查阅发现有同行遇到类似的问题：
（1）“The size limit of Intent is still pretty low in Jelly Bean, which is somewhat lower than 1MB (around 90K), so you should always be cautious about your data length, even if your application targets only latest Android versions.”
（2）“As per my experience (sometime ago), you are able to put up to 1MB of data in a Bundleencapsulated inside Intent. I think, this restriction was valid up till Froyo or GingerBread.”
所以在通过bundle传递数据时只能传递较小的数据信息，对于在不同组件之间需要传递大容量数据的情况时，有几种替代方式可以解决不能用bundle传递这些数据的问题：
方法一：将需要传递的数据写在临时文件或者数据库中，再跳转到另外一个组件的时候再去读取这些数据信息，这种处理方式会由于读写文件较为耗时导致程序运行效率较低；
方法二：将需要传递的数据信息封装在一个静态的类中（注意当前组件和要跳转到的组件必须属于同一个进程，因为进程之间才能够共享数据），在当前组件中为类设置内容，然后再跳转到的组件中去取，这种处理方式效率很高，但是会破坏程序的独立性。
具体采用哪种替代方式取决于具体的情况，本人建议采取第二种处理方式，因为这样会大大提高程序的运行效率，至于程序的独立性，看你怎么去封装这个类了。
『捌』 android 分页列表，可以上下刷新，大数据时如何处理
大数据处理的方法为：
1、自己重写adapter，然后根据得到的屏幕大小和列表子项大小，专动属态显示固定数量的列表子项。
2、在列表子项的VIEW上进行手势识别（估计已经不能对整个屏幕进行手势识别了），只要某个子项收到滑动动作，就换屏（上下动作可识别），然后动态加载新的列表数据。
3、可以一次获取3X个子项，即屏幕只显示X个，但内存里把当前X个列表子项和上、下X个子项全缓存起来，这样滑屏会快些。
『玖』 android 客户端接收的数据量过大（几万条数据）就会抛异常如何处理
正常，客户端内存有限，数据过多导致内存溢出。
一般做法是分页，20条一页（再多客户端屏幕也显示不出来），然后翻页的时候再加载。
可以参考下网易新闻或者新浪微博客户端
『拾』 android 接口满且数据量大怎么优化
我觉得数据很大的时候需要把数据 拆分，比如 只显示 数据的标题和时间，数据其他信息可以 点击后加载，把一个大数据拆分成2个表存储，或者2次请求显示。