安卓手机彩信发送多张图片教程

篇一：SwirlyMMS彩信收发工具使用教程

SwirlyMMS是iPhone必备的彩信收发工具，1.0版更是比以前稳定易用，下面就来说一下具体的使用方法：

1.软件启动后会进入图1所示的界面，分别列出了收件箱、发件箱、已发送和垃圾箱4项，同时右上角会出现一个绿色“m”标志，我们需要先对软件做一些设置，点击下面的锤子和扳手标志进入图2的设置界面。

图1

点击查看大图

因为使用中国移动的用户较多，所以这里只说一下移动的设置方法：在MMSC一项中填入mmsc.monternet.com，Proxy填10.0.0.172，APN填入cmwap，需要注意的是即使你已经定制了CMNET网络这里仍然要填cmwap。

图2

点击查看大图

2.接下来点击图1中最右下角的图标就可以开始编写彩信了，点击“To：”可以从电话本中选择联系人，“Subject”填入彩信的标题。下面有5个可选择的方块，第一个是从iPhone的照片中选择图片，第二个为即拍即发，第三个用来输入文字，第四个可以浏览iPhone的文件目录选择图片（图4），最后一个是发送。

图3

点击查看大图

小提示：关于如何输入中文——首先下载下面链接中的UIKit，解压后上传至

System/Library/Frameworks/UIKit.framework/UIKit覆盖原文件，然后进入设置->通用->多语言环境->键盘中将日语键盘打开才可以输入中文，但是只能输入日语所支持的汉字，不是很完美，只有安装NativeCN输入法才能完美输入中文。

点击下载日语键盘UIKit

图4

点击查看大图

OK，继续教程，以即拍即发为例：点击后会进入拍照模式（图5），点击右下角的小相机拍照，拍照完毕会出现图6的画面，“Drop”是重拍，“Pick”则是使用刚照完的图片。

图5

点击查看大图

图6

点击查看大图

点击“Pick”后我们又回到图7的界面，点击带有“Send”的方块就会看到图8的画面，代表正在发送彩信。

图7

点击查看大图

图8

点击查看大图

3.这时在收件箱里我们就可以看到刚才发出的彩信了（图9）。

图9

点击查看大图

点击进去会看到正在下载图片的画面（图10）。

图10

篇二：Android短信彩信)的发送流程图形文字解析

信息的发送

信息的发送，对于Mms应用程序来讲主要就是在信息数据库中创建并维护一条信息记录，真正的发送过程交由底层（Frameworks层）函数来处理。 总体的来讲，当信息创建完成后，对于信息通常有三个归宿，一个是放弃这个信息，也就是用户不想要此信息，一旦选择，信息将不会被保存（手动删除等）；第二个去处就是保存为草稿；最后一个去处就是发送此信息

当点击了发送后，UI层暂不会有变化，UI层要监听负责发送的各个类的回调信息和监听数据库的变化信息来更新UI。

信息发送的第一站是WorkingMessage(信息体构造和准备)，它会先处理一下信息的相关内容，比如刷新收信人（Sync Recipients）以保证都是合法收信人，把附件（Slideshow）转成可发送的彩信附件

Pdu(SendReq),makeSendReq。然后针对不同的信息类型（短信or彩信）调用不同的处理类来处理，短信和彩信构造不同的sender（短信：SmsMessageSender；彩信：MmsMessageSender）。但是，处理的流程也比较类似，都是先把消息放到一个队列中，然后启动相应的Service来处理。Service会维护信息队列，然后处理每个信息。短信是由Frameworks中的SmsManager发送出去，而彩信是通过Http协议（）发送。

短信发送

在workingMessage拿到一个要发送的消息后，做了简单处理（刷新收信人），然后就会对短信和彩信彩取不同的处理流程。

对于短信，WorkingMessage除了刷新联系人外，相关的参数收信人地址是用分号分隔的一串字符，以分号为基准转化成String数组，不会再做其他的操作。它会创建SmsMessageSender并调用其sendMessage()方法来发送信息，信息内容和所在对话的ID(thread id)在构造SmsMessageSender对象是传入的，构造完成后，直接调用其sendMessage()方法即可，接下来SmsMessageSender会处理所有的事情。

在SmsMessageSender处理之前，WorkingMessage会回调UI一次，以让UI刷新收信人编辑框和信息文本输入框。

SmsMessageSender的主要任务就是，把信息进行按收信人拆分，也就是说，短信是要给每个收信人都发一封，虽然你可能只编辑一个短信，但是当收信人不只一个时，就变成了多条短信，就要发出多条短信，要给每一个收信人都发一封短信。因此，SmsMessageSender的第一个任务就是分析收信人地址，得到收信人的个数，然后把信息按每个收信人都放入待发送的队列中。这样就得到了一个短信发送队列，短信的数目就是收信人的个数。

事实上，SmsMessageSender的工作仅此而已，当把信息都放入发送队列后，也就是写进数据库（"content://sms/queued"），然后信息的状态是正在发送中，它会发送Intent唤起SmsReceiverService来处理队列(按顺序一条一条的发送发)，它的工作就完成了，sendMessage()也就此返回。

SmsMessageSender的sendMessage()返回后，WorkingMessage会再次回调UI的接口，因为此时短信已被写入数据库，所以UI会刷新信息列表，显示刚刚的短信，这时的状态应该是正在发送中，因为是从待发送队列中拿到的。从这以后，发送流程的类不会再直接与UI进行通信，发送服务

SmsReceiverService等会直接更新数据库中短信的状态，而UI会监听数据库的变化，一旦信息数据发生变化，UI就会刷新列表中的消息，更新状态，比如将发送中变成已发送，或是标明发送失败等，而这些状态都表明发送服务在更新。（所有发送结果有RIL和Frameworks层返回的结果，更新数据库，界面刷新）SmsReceiverService，不要被其名字“虎住”，它并不只是负责接收信息，它是短信（SMS）处理的Service，负责短信的发送和接收，在得到发送短信息指令（ACTION_SEND_MESSAGE）后会从队列中读出第一个短信，然后创建SmsSingleRecipientSender对象，传入收信人地址，消息内容，所属的threadid和短信的Uri，并调用其sendMessage()发送这个短信。

SmsSingleRecipientSender是APP中Mms模块最终与frameworks接轨的类。会调用frameworks层的对外接口SmsManager的方法divideMessage()

来把短信分成适合发送的几个部分，因为可能信息过长，不能一次发送完成，所以就需要分成几部分来分次发送。同时会把消息移动到Outbox。然后会针对分割的每一部分都会创建两个PendingIntent，这两个PendingIntent都是给底层用的，一个用于当短信被发送出去时广播出来，另一个是在短信已被收信人接收到时广播出来。所以两个广播的作用是，一个可用于标识短信已发送报告，另一个则可以作为送达的通知。最后调用SmsManager.sendMultipartTextMessage交由底层来发送短信。

SmsReceiverService并不是自己去监听SEND_MESSAGE_ACTION和MESSAGE_SENT_ACTION的，而是由SmsReceiver来监听这两个广播事件，然后通过StartService再把这两个事件传送给SmsReceiverService进行处理。信息已发送广播和信息已送达广播分别由SmsReceiverService监听和MessageStatusReceiver。它们收到广播后，会从Intent中取得详细的发送和送达状态，然后更新数据库中信息的状态(status)，UI当发现数据库变化后，就会更新UI。

至此，一个短信发送完成。

彩信发送

彩信发送流程与短信不完全一致，WorkingMessage刷新收信人，生成彩信的可发送的Pdu（SendReq），接着会把彩信写入数据库，把要发送的SendReq也会写入数据库，后面会再从数据库中读取出SendReq，并标识为草稿；然后会构建MmsMessageSender，传入收信人和彩信的Uri，让其发送。这期间也会回调UI一次，以初始化收信人编辑框和信息编辑框。

MmsMessageSender先从数据库中读出彩信发送的Pdu—SendReq。 Google的内置包com.google..mms.*;里面封装了所有操作Pdu的方法，包括把Pdu写入数据库（PduPersister.persist()），从数据库中读取生成Pdu（PduPersister.load()）。然后根据当前彩信的配置和其他信息对SendReq进行更新，比如设置Expiration，Priority，Date和Size等，把彩信移到Outbox，然后启动TransactionService来处理彩信。sendMessage()就此返回。

WorkingMessage会再次回调UI的接口，因为此时彩信已被在数据库中，所以UI会刷新信息列表，显示刚刚的彩信，这时的状态应该是正在发送中。

TransactionService，与短信的SmsReceiverService类似，是负责处理彩信的服务，可以发送，接收等。

对于TransactionService来讲，所有的需要处理的流程，无论是发送还是接收，都是一个Transaction（交易，事务的意思）。TransactionService内部有两个队列，一个是当前正在处理(processing)的Transaction，一个是待处理

(pending)的Transaction。TransactionService 维护这两个队列，并检查网络的连接，打开彩信网络连接，准备和检查环境，然后从待处理(pending)的队列中取出第一个，放入正在处理(processing)的队列中，并把该Transaction加入到观察着列表，处理这个Transaction，也就是调用Transaction.process()，此函数的实现在不同类型的Transaction中实现。

发送彩信是一个SendTransaction，它的process()方法负责发送彩信，它会创建一个独立的线程来做，因此不会阻塞TransactionService，处理服务就可以再处理其他的Transaction。它会先从数据库中取出彩信Pdu(SendReq)，更新一些字段，比如date。先用PduComposer来重新包装SendReq成为可以直接发送的byte[]型pdu(把通用pdu进行重新封装，主要是对通用（GenericPdu）的pdu--SendReq添加彩信头（常数）和构造信息体，所有信息write到ByteArrayOutputStream的对象mMessage中，最后转化为byte[]返回，即可直接发送，相当于“编码”的过程)

篇三：彩信参数设置方法及故障处理

彩信参数设置方法及故障处理

绝大多数彩信手机在出厂时就已经预设了彩信中心等相关参数，但也有少量手机出厂时没有预先设置彩信参数，可查看使用手册或者咨询客服。

1、手机关机或不在服务区能接收彩信吗？

答：手机关机或不在服务区是无法接收彩信的，但彩信会在系统中保留48小时，一旦开机或进入网络服务区，彩信手机就可以正常接收彩信了。如果手机仍然无法接收到彩信，系统把此条彩信转发至接收方用户的手机彩信网络邮箱中，用户可以通过登录彩信网络邮箱来收取彩信。

2、手机在拨打和接听电话时，可以接收彩信吗？

答：不可以。因为彩信是通过GPRS或CSD为承载方式来传输的，在拨打和接听电话时无法同时进行数据传输。电话挂掉后，就可以进行正常的彩信的接收和发送。

3、对方不是彩信手机能接收到用户发送的彩信吗？

答：不可以。必须是彩信手机才能接收彩信。但您在发送彩信时，如果接收方不是彩信手机，系统会自动把此条彩信转发至接收方用户的

彩信网络邮箱中，接收方用户可以通过登录彩信网络邮箱来收取此条彩信。

4、彩信有大小限制吗？

答：严格的说，彩信业务是没有大小限制的。但由于目前的彩信手机对能够发送和接收的彩信大小存在一定的限制，同时为了保证每条彩信在网络中传输的速度，一般会在彩信网络设备MMSC（即彩信中心）中设置一个限制的大小。目前中国联通彩信业务每条彩信的大小限制在50KByte左右。这是一个可以设定的值，随着新的彩信终端的不断推出和彩信业务的进一步发展，彩信大小的限制值还可以随时再调整。

5、用户可以自己设计彩信吗？

答：可以。中国联通的彩信业务为您提供了丰富的个人创作空间，充分体现个性特点。中国联通GSM网络的彩信个人相册就提供给您一个空间，您可以在相册中选择或上载图片、声音、文字等进行任意组合和编辑，创作自己喜欢的彩信。除此以外，彩信还提供了很多其他的贺卡DIY、个性化心意卡等等服务。

6、如何将下载的彩信待机图成为我手机的待机图片？能否让动画成为待机图片？

答：您下载了彩信待机图后，必须将图片进行另存，保存到手机的图片库里。然后再在手机显示设置里，将该图片设置为待机图片。您也

可以用同样的操作流程，将下载的动画图片进行另存，保存到图片库，再调用出来作为待机图，但是动画是不能播放显示的。

7、我下载了一张待机彩图，但在我的某型号的手机屏幕上看起来很小？

答：由于各种型号的手机屏幕尺寸不同，您在下载动画或待机彩图时，必须选择适合自己手机机型的图片。

8、为什么我在下载彩信动画过程中，见到手机屏幕在显示下载中，但最后还是下载不成功？

答：因为我们的彩信下载是通过中国联通的GPRS上网技术实现，如果当时的GPRS手机网络环境不稳定或信号不佳，又或者某地区的彩信网关出现不稳定情况，就可能导致用户下载失败。 遇到这样的情况时，用户可以稍后再尝试下载。

9、我用某型号手机下载一张动画，但一直无法接收？

答：由于部分彩信手机限制了接收彩信文件的大小，例如一般限制在50K以内。而我们有一些精美及较复杂的动画，文件较大，再加上背景音乐，会使到该条彩信文件大小可能会超过50K或以上，所以有些彩信手机可能无法完全接收下来。

本文来源：https://www.bwwdw.com/article/kknb.html