所述預設閾值為彩信應用可承載的附件大小。如果否，則直接添加。
[0064](2)如果是，則將大于預設閾值，即彩信應用可承載的附件大小的附件壓縮后再添加。因為壓縮可以減小附件中的比特和字節總數，使附件能夠更快添加并傳輸，此外還可以減少附件的磁盤占用空間。通常，彩信應用可承載的附件大小為300KB。
[0065](2)將添加后的多個附件按照容量大小排序，并隨機地將容量大小之和小于預設閾值的附件大小的附件合并為一個附件，獲取容量壓縮后的至少一個附件。
[0066](3)將上述步驟(2)獲取的至少一個附件以彩信記錄的形式存儲在彩信數據庫中。
[0067]例如，用戶完成添加多個附件后，彩信應用根據附件大小由小到大排序，并隨機地將附件大小總和小于300KB的附件合并為I個附件，并存放到彩信數據庫中。剩余的附件同樣處理，直到所有的附件都存入到彩信數據庫中。
[0068]上述的實施例從節省彩信流量的角度出發，將多個附件優化合并，能夠大大節省發送時的流量。
[0069]步驟108，發送多個附件。
[0070]在一些實施例中，從彩信數據庫中讀取至少一個附件后，按照讀取至少一個附件的順序依次發送至少一個附件。例如，從彩信數據庫中，讀取已存放的所有彩信記錄，并按順序啟動彩信服務發送，直到所有的彩信記錄發送完成。
[0071 ]在另一些實施例中，一種終端的彩信發送系統600，如圖6所示，包括:接口模塊602、多附件選擇模塊604、多附件接收模塊606和發送模塊608。
[0072]接口模塊602用于接收用戶發送的添加附件的請求。多附件選擇模塊604用于發送可添加附件列表至終端的用戶界面并顯示。多附件接收模塊606用于接收用戶一次操作所添加的多個附件。發送模塊608用于發送多個附件。
[0073]在一些實施例中，接口模塊602用于接收用戶發送的添加附件的請求，同時發送消息至多附件選擇模塊604，通知多附件選擇模塊604啟動多附件選擇服務。
[0074]例如，在Android(—種基于Linux的自由及開放源代碼的操作系統，主要使用于移動終端設備)系統的手機終端中，通過In tent機制啟動多附件選擇服務。在Andro i d中提供了 Intent機制來協助應用間的交互與通訊，Intent負責對應用中一次操作的動作、動作涉及數據、附加數據進行描述，Android則根據此Intent的描述，負責找到對應的組件，將Intent傳遞給調用的組件，并完成組件的調用。Intent不僅可用于應用程序之間，也可用于應用程序內部的Activity/Service之間的交互。因此，可以將Intent理解為不同組件之間通信的“媒介”專門提供組件互相調用的相關信息。
[0075]在一些實施例中，多附件接收模塊606還用于:接收所添加附件的類型信息；將類型信息對應的多媒體數據發送至用戶界面并顯示;接收用戶一次操作添加的多個附件，并將多個附件發送至用戶界面并顯示。
[0076]在一些實施例中，多附件選擇模塊604還用于:接收用戶發送的刪除已添加附件的請求;移除所述已添加附件，并將更新后的多個附件發送至所述用戶界面并顯示。
[0077]在一些實施例中，多附件接收模塊606還用于:將多個附件按容量大小排序，并將容量大小之和小于預設閾值的多個附件合并為一個附件，以獲取容量壓縮后的至少一個附件;將至少一個附件以彩信記錄的形式存入彩信數據庫。
[0078]在一些實施例中，系統600還包括存儲模塊610，用于存儲至少一個附件。
[0079]在一些實施例中，發送模塊608還用于:從彩信數據庫中讀取至少一個附件后，按照讀取至少一個附件的順序依次發送至少一個附件。
[0080]本實施例的終端的彩信發送系統600用于實現前述的終端的彩信發送方法，因此終端的彩信發送系統600中的具體實施可參見前文中終端的彩信發送方法的實施例部分，例如，接口模塊602、多附件選擇模塊604、多附件接收模塊606和發送模塊608。分別用于實現上述終端的彩信發送方法中步驟102、104、106和108，所以，其具體實現方式可參照前文中有關步驟102、104、106和108的各個實施例的描述，在此不再累述。
[0081]上述實施例的終端的彩信發送方法和系統，終端在接收用戶發送的添加附件的請求后，發送可添加附件列表至所述終端的用戶界面并顯示，用戶通過該列表添加附件。終端接收用戶一次操作所添加的多個附件，并按照預定規則發送所述多個附件。上述實施例的終端的彩信發送方法和系統，可以一次添加同一類型的多個附件，節省了彩信流量，操作便捷，用戶體驗好。
[0082]以上所述實施例的各技術特征可以進行任意的組合，為使描述簡潔，未對上述實施例中的各個技術特征所有可能的組合都進行描述，然而，只要這些技術特征的組合不存在矛盾，都應當認為是本說明書記載的范圍。
[0083]以上所述實施例僅表達了本發明的幾種實施方式，其描述較為具體和詳細，但并不能因此而理解為對發明專利范圍的限制。應當指出的是，對于本領域的普通技術人員來說，在不脫離本發明構思的前提下，還可以做出若干變形和改進，這些都屬于本發明的保護范圍。因此，本發明專利的保護范圍應以所附權利要求為準。
【主權項】
1.一種終端的彩信發送方法，其特征在于，包括以下步驟: 接收用戶發送的添加附件的請求； 發送可添加附件列表至所述終端的用戶界面并顯示； 接收用戶一次操作所添加的多個附件； 發送所述多個附件。2.根據權利要求1所述的方法，其特征在于，所述接收用戶一次操作所添加的多個附件的步驟包括: 接收所添加附件的類型信息； 將所述類型信息對應的多媒體數據發送至所述用戶界面并顯示； 接收用戶添加的多個附件，并將所述多個附件信息發送至所述用戶界面并顯示。3.根據權利要求2所述的方法，其特征在于，在將所述多個附件發送至所述用戶界面并顯示的步驟之后，所述方法還包括: 接收用戶發送的刪除已添加附件的請求； 移除所述已添加附件，并將更新后的多個附件信息發送至所述用戶界面，并顯示。4.根據權利要求1所述的方法，其特征在于，在所述接收用戶一次操作添加的多個附件的步驟之后，所述方法還包括: 檢測所述多個附件中每個附件的容量大小，判斷每個附件的容量大小是否大于預設閾值； 如果是，則將大于預設閾值的附件壓縮后再添加，以獲取添加后的多個附件； 將所述添加后的多個附件按容量大小排序，并將容量大小之和小于預設閾值的多個附件合并為一個附件，以獲取容量壓縮后的至少一個附件； 將所述至少一個附件以彩信記錄的形式存入彩信數據庫。5.根據權利要求4所述的方法，其特征在于，所述發送所述多個附件的步驟包括: 從所述彩信數據庫中讀取所述至少一個附件后，按照讀取所述至少一個附件的順序依次發送所述至少一個附件。6.一種終端的彩信發送系統，其特征在于，包括: 接口模塊，用于接收用戶發送的添加附件的請求； 多附件選擇模塊，用于發送可添加附件列表至所述終端的用戶界面并顯示； 多附件接收模塊，用于接收用戶一次操作所添加的多個附件； 發送模塊，用于發送所述多個附件。7.根據權利要求6所述的系統，其特征在于，所述多附件接收模塊還用于:接收所添加附件的類型信息；將所述類型信息對應的多媒體數據發送至所述用戶界面并顯示;接收用戶添加的多個附件，并將所述多個附件信息發送至所述用戶界面并顯示。8.根據權利要求6所述的系統，其特征在于，多附件選擇模塊還用于:接收用戶發送的刪除已添加附件的請求;移除所述已添加附件，并將更新后的多個附件信息發送至所述用戶界面并顯示。9.根據權利要求6所述的系統，其特征在于，所述多附件接收模塊還用于:檢測所述多個附件中每個附件的容量大小，判斷每個附件的容量大小是否大于預設閾值;如果是，則將大于預設閾值的附件壓縮后再添加，以獲取添加后的多個附件;將所述添加后的多個附件按容量大小排序，并將容量大小之和小于預設閾值的多個附件合并為一個附件，以獲取容量壓縮后的至少一個附件。10.根據權利要求9所述的系統，其特征在于，所述系統還包括存儲模塊，用于存儲所述至少一個附件。11.根據權利要求6所述的系統，其特征在于，所述發送模塊還用于:從所述彩信數據庫中讀取所述至少一個附件后，按照讀取所述至少一個附件的順序依次發送所述至少一個附件。
【專利摘要】本發明涉及一種終端的彩信發送方法和系統，該終端的彩信發送方法，其特征在于，包括以下步驟：接收用戶發送的添加附件的請求；發送可添加附件列表至所述終端的用戶界面并顯示；接收用戶一次操作所添加的多個附件；按照預定規則發送多個附件。上述實施例的終端的彩信發送方法和系統，可以一次添加同一類型的多個附件，操作便捷，用戶體驗好。
【IPC分類】H04W4/12, H04L12/58
【公開號】CN105704007
【申請號】CN201511019766
【發明人】周漢心
【申請人】深圳市萬普拉斯科技有限公司
【公開日】2016年6月22日
【申請日】2015年12月30日