58 Aynı şehirdeki iOS istemcisinin IM sisteminin gelişimi
[Editörün notu] 58.com App sürüm 1.0'dan beri kendi geliştirdiği IM sistemine kendini adamıştır. Bu süreçte, IM sistem seviyeleri ve sayfalar arasındaki bağlantının nasıl azaltılacağını ve IM sisteminin karmaşıklığının nasıl azaltılacağını keşfetmek, teknik maliyetleri düşürmenin ve Ar-Ge verimliliğini artırmanın anahtarıdır. Bu bağlamda, bu makalenin yazarı, IM modülleri tasarlayan veya optimize eden geliştiriciler için bazı referanslar sağlamayı umarak iOS istemcisi IM sistem mimarisinin gelişim sürecini ve deneyimini özetledi.
Temelde bilgi görüntüleme ve işlemlere dayanan 58.com Uygulaması gibi platformlar için, Uygulamadaki IM anlık mesajlaşma işlevi, aramalar ve metin mesajlarından çok mal / hizmet işlemlerini kolaylaştırmada daha önemli bir rol oynar. Bu nedenle, 1.0 sürümünden bu yana, kendi geliştirdiği IM sistemine adanmıştır. Kendi kendine araştırma süreci sırasında, IM sistem düzeyini ve sayfalar arasındaki bağlantıyı nasıl azaltacağımızı ve IM sisteminin karmaşıklığını nasıl azaltacağımızı keşfettik, teknik maliyetleri düşürmenin ve Ar-Ge verimliliğini artırmanın anahtarıdır.
Bu amaçla, bu makale temel olarak 58 şehir içi ios istemci IM sistem mimarisinin gelişimini iki açıdan açıklayacaktır. Birincisi, IM sisteminin veritabanına ve Soket arayüzüne bağımlılığını nasıl hafiflettiğidir; ikincisi, IM sohbet sayfasının geleneksel MVC modundan yeni bir protokol odaklı mimariye geçmesidir. Benzer iş senaryolarına sahip geliştiriciler için bazı referanslar sağlamayı umuyoruz.
IM sisteminin eski sürümünde karşılaşılan sorunlar
58 Uygulama, projenin ilk aşamasında kendi geliştirdiği IM sistemi, ancak yalnızca kısa mesaj, resimli mesaj ve ses gibi temel türleri gerçekleştirdi. İş gereksinimi senaryosu basit olmasına rağmen aşağıdaki sorunlarla karşılaşılmaktadır.
Zayıf veri ölçeklenebilirliği
Veri biçimi Google ProtocolBuffer'ı (bundan böyle PB olarak anılacaktır) kullanır, çünkü bu veri biçimi boyut olarak daha küçüktür ve XML ve JSON ile aynı veri biçimine kıyasla ayrıştırılması daha hızlıdır. Ancak PB, kullanımı nispeten zahmetli olan C ++ 'da uygulanmaktadır. Farklı mesaj türleri için farklı PB veri yapıları yazmanız gerekir ve her PB yapısı ayrıca ayrı bir veri analizi yöntemine ihtiyaç duyar. 58 servisin geliştirilmesi nedeniyle, bu veri protokolü sistemin karmaşıklığını artırmıştır.
Zayıf kod kapsülleme ve yüksek Ar-Ge maliyeti
Veriler gönderilmeden önce, güvenlik için, iletilecek verilerin belirli bir şifreleme algoritması ile şifrelenmesi gerekir ve ardından veri aktarımı için AsyncSocket kullanılır. Buna uygun olarak, bir mesaj türü her alındığında, PB formatını bir nesne modeline dönüştürmek için şifresinin çözülmesi gerekir. Bu tür bir şema, her yeni mesaj türü eklendiğinde daha zahmetlidir.Bir şifreleme algoritması yazmak ve bir PB modeli ayrıştırıcısı yazmak gerekir. Bu sadece kodun zayıf ölçeklenebilirliğine değil, aynı zamanda daha zor geliştirmeye de sahiptir.
Güçlü kod bağlantısı
Her seferinde yeni bir mesaj türü varsa, yeni mesajın verilerini analiz etmek ve depolamak için DB katmanına bir arayüz yazılmalıdır. Benzer şekilde, Soket taşıma katmanında, buna karşılık gelecek yeni bir alıcı-verici arayüzü eklenmelidir. Bu tasarım yöntemi, geliştirme sürecinde büyük bir bağlantıya sahiptir.
Zayıf kod okunabilirliği
Uygulamada WBMessagModel adında yalnızca bir mesaj türü vardır. Mesaj türünün yargılanmasında, WBMessageModel'deki mtype, isOnlineTip ve m_msgtype gibi nispeten kafa karıştırıcı olan alanlara göre yargılama gibi belirli alanlar tarafından ayırt edilir.
Yukarıdaki sorunları çözmek ve düşük kuplajlı ve oldukça ölçeklenebilir bir IM sistemi oluşturmak için yeniden düzenleme yapmaya karar verdik.
IM sisteminin yeni versiyonu
Çerçeve evrimi
Eski IM sisteminin, şiddetli kod bağlantısı nedeniyle bir sorunla karşılaştığında izini sürmek zordur. Dahası, ölçeklenebilirlik zayıftır ve her sürüm için gereksinimlerin gelişimi, en alttan iş katmanına değiştirilir, bu da geliştirme sürecini etkiler. IM geliştirme sürecinde karşılaşılan sorunlarla birleştiğinde, yeni IM sisteminin aşağıdaki sorunları acilen çözmesi gerekiyor.
-
Çağrı sürecini basitleştirin
İş geliştirme süreci, "alt DB + veri şifreleme + veri şifreleme + veri aktarımı" ndan ayrılır ve mesajlar, alt katman arayüzü çağrılarak gönderilebilir, alınabilir ve saklanabilir.
-
Düşük bağlantılı bir orta katman arayüzü tasarlayın
Orta katmanın arabirimi, iş katmanı ile temeldeki arabirim arasında herhangi bir bağlantı olmaksızın önceki ve sonraki arasında bağlanmalıdır. Bunu yaparsanız, gelecekte anlık ileti alt katmanını yükselttiğinizde veya hatta değiştirdiğinizde, üst düzey işin farkında olmaması ve farkında olmadan yinelemeye ulaşması için yalnızca iş arabirimi ile alt katman arabirimi arasındaki yeniden kenetlenmeyi ayarlamanız gerekir.
-
Tek işlevli modeller ve arayüzler tasarlayın
Spesifik iş katmanı işlemede, model ayrılmalı ve tasarım birleştirilmelidir. Model açısından, önceki IM modeli ilgili türlerine göre bölünmüştür. Arayüz üzerinde, alt ve orta iş katmanlarının yapısal olarak bölünmesi yoluyla, her arayüz kendi görevlerini yerine getirir.
-
Güçlü ölçeklenebilirlik
Protokole göre mesajlar eklemek için kodu soyutlamak ve düzenlemek için protokol odaklı yaklaşımı kullanın. Hücrenin yüksekliği otomatik olarak hesaplayabilmesi için mevcut ve yeni mesaj tipini yapmak için UITableView kategorisini kullanın. Bu iş tasarımı yöntemi sayesinde sorunlar hızlı bir şekilde tespit edilebilir. Yeni bir mesaj türü varsa, sadece yeni mesaj modeline ve ilgili mesaj arayüzüne dikkat etmeniz yeterlidir Görünümün doldurma zamanına ve görünümün yüksekliğinin nasıl hesaplanacağına dikkat etmenize gerek yoktur. Ancak bu tasarım ilkelerini belirleyerek, iş geliştirme sürecinde hızlı yineleme sağlayabilir ve böylece artan kullanıcı ihtiyaçlarını karşılayabiliriz.
Yukarıdaki hedeflere dayanarak, yeniden yapılanmadan sonraki genel IM mimarisi Şekil 1'de gösterilmektedir.
Şekil 1 Yeni IM mimari tasarımı
Yeni IM sisteminin genel mimarisi üç bölümden oluşur: alt katman, arayüz hizmet katmanı ve iş katmanı. Alt katman, temel olarak veri iletimi ve alımı, depolama ve diğer ilgili işlemlerle ilgilenir ve arayüz hizmet katmanı ile etkileşim kurmak için genel alt katman arayüzünü özetler. Arayüz hizmet katmanı temel olarak alt katman verilerinin iş katmanına makul şekilde iletilmesinden sorumludur Benzer şekilde, iş katmanının verileri arayüz servis katmanı aracılığıyla alt katmana geçirilebilir. Net bir arayüz hizmet katmanı, yalnızca iş katmanının verileri işlemesini kolaylaştırmakla kalmaz, aynı zamanda iş katmanı ile alt katman arasındaki bağlantıyı büyük ölçüde azaltır. İş katmanı, belirli talep senaryolarına ve görünümleri görüntülemek için verilerin makul şekilde nasıl kullanılacağına odaklanır. Bu tasarıma dayanarak, her seviye arasındaki özel uygulama aşağıda ayrıntılı olarak açıklanacaktır.
Kısa bir arama süreciyle temeldeki arayüzü tasarlayın
Yeni IM alt katmanı, Şekil 2'de gösterildiği gibi yepyeni bir tasarım fikrini benimser. Alt kısımda, veri ölçeklenebilirliği için önceki PB veri protokolü terk edildi ve Soket tarafı veri alma ve gönderme protokolü olarak geleneksel JSON formatı kullanıldı.
Şekil 2 Temel mimari tasarım
Mesaj modelinde, sadece bir mesaj modelinin önceki stratejisi terk edilmiş olup, metin mesaj modeli ve resimli mesaj modeli gibi temel mesaj modelleri mesaj tipine göre bölünmüştür.
58 Uygulama, DB ve Soket'in dahili işlemlerini SDK'da kapsüller ve yalnızca IMClient'in alt arayüzünü ortaya çıkarır. En üst seviyedeki mesajla ilgili tüm olaylar, alt IMClient arabirimi ile etkileşim halindedir ve dahili sürecin hiç endişelenmesine gerek yoktur. Bu şekilde, iş katmanı verilerin nasıl alındığından, alındığından ve depolandığından tamamen habersizdir ve bu da erişim ve kullanım maliyetlerini büyük ölçüde basitleştirir.
Ancak okuyucuların soruları olabilir. IM SDK'da yerleşik çok sayıda mesaj türü vardır.Gelecekte SDK'da olmayan yeni mesaj türleri varsa ne yapmalıyım? Bu sorunu çözmek için 58 Uygulama, iOS özel nesne arşivlemesine benzer bir strateji benimser - temel mesaj türünden miras aldığı ve IMMessageCoding protokolünü izlediği sürece yeni bir mesajı keyfi olarak tanımlar. Bu protokol, kodlama ve kod çözme yöntemlerini tanımlar.Bunlar arasında kodlama yöntemi, verileri veritabanında yeni mesaj türünde depolamak için kullanılır (elbette bu işlem üst düzey geliştiricilerin dikkatini gerektirmez, yalnızca bu işlevde depoya geri dönmeleri gerekir. Veri yeterlidir); kod çözme yöntemi, veritabanındaki verileri karşılık gelen mesaj modeline geri yüklemek için kullanılır. Artık mesaj türünü tanımlamanın bir yolu olduğuna göre, onu nasıl kullanmalıyız? En alt katmanın özel mesaj türünü algılaması için, birleşik arayüz katmanı IMClient başlatıldıktan hemen sonra ona kaydedilmesi gerekir.Kayıt olduktan sonra, IM alt katmanı mevcut mesaj türünü bilir ve verilerin nasıl saklanıp geri yükleneceğini anlar. Bu tasarım yöntemine bağlı olarak, 58 Uygulamanın IM alt katmanı isteğe bağlı olarak diğer mesaj türlerine genişletilebilir ve temeldeki kodun hiç değiştirilmesi gerekmez.
Temel kod sadece iyi bir ölçeklenebilirliğe sahip olmakla kalmaz, aynı zamanda tasarım sırasında bazı temel senaryolar için birçok protokol sağlar. Bu anlaşmalar dinamik olarak özelleştirilebilir veya kaldırılabilir. Örneğin, kişi listesi değiştiğinde ve kişinin profil resminin değiştirilmesi gerektiğinde, temeldeki IMClientConversationListUpdateDelegate protokolü özelleştirilebilir. Kullanım sırasında, iş tarafı, kişi güncellemesini geri izledikten sonra avatar güncelleme işlemini gerçekleştirmek için addUpdateConversationListDelegate: kayıt protokolünü kullanır. Gerekmediğinde ,UpdateConversationListDelegate: öğesini kaldırarak izlemeyi kaldırabilirsiniz. Benzer senaryolar arasında mesaj alma protokolü ve çevrimiçi durum değişikliği protokolü bulunur. Bu şekilde, IM'nin belirli durum değişikliklerini izlemek için hizmet kodunu esnek bir şekilde yapılandırabilirsiniz.
Şu anda, alt seviye kodun soyutlanması yoluyla, üst seviye arayüz ve dahili veri işlemenin ayrılması sağlanmaktadır ve birçok IM servisi, elde edilecek şekilde özelleştirilebilir, böylece spesifik servislerle hiçbir bağlantı elde edilemez. Bu temel tasarım sayesinde, diğer uygulamaların anlık ileti işlevlerini hızla entegre etmesi için temel bir IM SDK olarak kullanılabilir.
Düşük kaplinli, tek görevli bir orta katman arayüzü tasarlayın
İş katmanı ile alt katmanın birbirini birleştirmeden iletişim kurabilmesi için, geçmişi birbirine bağlayan bir ara arayüz katmanı oluşturduk. Gerçek iş senaryolarına göre, ara arayüz katmanı üç duruma bölünmüştür: oturum açma ile ilgili arayüzler, mesaj gönderme ve alma ile ilgili arayüzler ve temel birleşik arayüze bağlanan mesaj sorgusuyla ilgili arayüzler. İş senaryolarının bölünmesi yoluyla, ilgili işletmelere karşılık gelen modüller, geliştirme süreci sırasında hızlı bir şekilde yerleştirilebilir. Alt katman tarafından sağlanan mesaj modeli doğrudan kullanılmaz Bunun nedeni, alt mesaj modelinin satır yüksekliği, yeniden kullanım tanımlayıcısı ve diğer öznitelikler (bir sonraki bölümde ayrıntılı olarak açıklanmıştır) gibi görünüm görüntüleme özniteliklerini önemsememesidir. MVVM'de, sanal makinenin bazı özelliklerinin görünümle ilişkilendirilmesi gerekir, böylece temel alınan mesaj modeli, sohbet hücresi tarafından doğrudan kullanılabilen bir mesaj modeline dönüştürülür. Bu tür iş arayüzü bölümü ve mesaj modeli dönüşümü sayesinde, altta yatan birleşik arayüz veya mesaj modeli daha sonra değişse bile, ara arayüz yeniden bağlandığı ve mesaj modeli yeniden dönüştürüldüğü sürece, üst düzey işletme aşağıdaki değişiklikleri hiç algılamayacaktır.
Ölçeklenebilir bir iş katmanı tasarlayın
Eski IM sistemi projesi erken aşamada inşa edildiğinden, ele alınan iş senaryoları basittir ve ölçeklenebilirlik yetersizdir. Örneğin, tüm mesajlar aynı veri modelini kullanır İş senaryosu genişledikçe, modelin kod boyutu büyür ve büyür ve birçok özellik kullanıldığında gereksiz hale gelir. Tasarım açısından, eski mimari MVC tasarım modelini kullanır.Sohbet sahnesinde, VC birçok sohbet görünümüyle uğraşmak zorundadır ve VC çok şişirilmiştir. Önceki mimarinin sınırlamaları nedeniyle, bu, yeni IM iş mimarisi için gereksinimleri ortaya koymaktadır Düşük bağlantı ve güçlü ölçeklenebilirliğe sahip bir iş katmanı nasıl tasarlanır? Sonra, özel uygulama planını tanıtacağım.
-
Bölünmüş IM mesaj modeli: Yukarıdaki sorun açıklığa kavuşturulmuştur.58 Uygulama önceki mesaj modelini metin, resim, ses, hatırlatma, ses, video ve diğer mesaj modellerine böldü.Temel mesaj modelini tek tip olarak miras alırlar ve temel mesaj modeli depolar Sohbet kullanıcı bilgileri, mesaj gönderme durumu vb. Gibi IM için gerekli olan gerekli veriler.
-
MVVM mimarisini kullanın: VC ve her sohbet görünümü arasındaki bağlantıyı azaltmak için. VC, çeşitli mesaj modellerini yönetir ve mesaj modeli, görüntü ekranı için gereken verileri depolar. Mesaj görünümü ve mesaj modeli arasında iki yönlü veri bağlama gerçekleştirilir. Bunu başarmanın yolu, ilgili mesaj modelini sohbet görünümünde saklamaktır, böylece sohbet görünümü değiştiğinde ve mesaj modelinin güncellenmesi gerektiğinde, mesaj modeli doğrudan atanabilir. Sohbet görünümü, mesaj modeli özniteliklerindeki değişikliklere göre değiştiğinde, bu işlev KVO aracılığıyla gerçekleştirilir. Örneğin, IM senaryosunda, bir mesaj gönderiyoruz.Mesaj modelinde gönderme durumu gönderiliyor.Gönderme durumu değiştiğinde (gönderme başarılı veya başarısızlık gibi), sohbet görünümü değiştirilen değere göre güncellenebilir;
-
Protokol odaklı kuruluş IM modellerini ve görünümlerini kullanın: IM modellerini ve görünümlerini protokol odaklı bir şekilde organize ederek, IM mesaj modellerinin ve görünümlerinin ölçeklenebilirliği artırılabilir. Aşağıda, 58 IM sisteminde protokol odaklı tasarımın önemli rolünü göstermek için belirli teknik ayrıntılar birleştirilecektir.
teknik detaylar
Sohbet listesi sayfasının teknik ayrıntıları
IM modülünün özellikleri nedeniyle, iş gereksinimlerinin gelişmesiyle birlikte, giderek daha fazla IM türü olacaktır. Geliştirme işlemi sırasında her seferinde UITableView'daki hücrenin yüksekliğini hesaplamak için çok fazla enerji harcamaktan kaçınmak için, Uygulamada farklı hücreler oluşturmak için XIB'yi ve hücrede görünümleri düzenlemek için AutoLayout'u kullanırız. Elbette, Otomatik Yerleşim düzenini el yazısı koduyla da kullanabilirsiniz. Uygulama, görünümün düzenini daha sezgisel olarak görüntülemek ve görünüm bölümünü VC'den daha iyi ayırmak için IM'deki XIB düzenini kullanır. Hücredeki tüm düzenler makul şekilde tamamlandığında, hücrenin yüksekliği, sistemin systemLayoutSizeFittingSize: yöntemi çağrılarak elde edilebilir. Bu fikre dayanarak, 58 Uygulaması hücrenin yüksekliğini UITabelView'a otomatik olarak hesaplama yeteneği ekler.Kod aşağıdaki gibidir:
#ithalat < uikit uikit.h = "" >
#import "WBAutoCalculateTableViewDelegate.h"
@interface NSObject (WBAutoCalculateTableView)
@ özellik (atomsuz, atama) CGFloat kid_height;
@son
@interface UITableView (WBAutoCalculateTableView)
- (CGFloat) heightForRowWithReuseIdentifier: (NSString * indentifiercellEntity: (NSObject *) cellEntity;
@son < / uikit >
İlk olarak, NSObject'e bir kategori ekledik ve kategoriye kid_height özelliğini ekledik, amaç hücrenin yüksekliğini hesapladıktan sonra hücreyi önbelleğe almak. Bu nedenle, UITableView yeniden yüklendiğinde, önbelleğe alınan yükseklik doğrudan döndürülür.
İkinci olarak, UITableView'a bir kategori ekledik. HeightForRowWithReuseIndentifier: cellEntity: API kullanılarak, geçerli mesaj hücresinin ve mevcut mesaj modelinin yeniden kullanım tanımlayıcısını geçtikten sonra, geçerli hücrenin yüksekliği döndürülür. Arayan kişinin yükseklik hesaplamasının ayrıntılarını hiç umursamasına gerek yoktur Hesaplama tamamlandıktan sonra, yüksek oranda kullanılan NSObject'in kategori özelliği hemen mesaj modelinde önbelleğe alınır.
Farklı türdeki mesaj hücreleri için tutarsız veri doldurma yöntemleri sorununu çözmek için aşağıdaki protokolleri tanıttık:
#ithalat < vakıf vakıf.h = "" >
@protocol WBCellConfigDelegate < nsobject >
@gereklidir
- (void) setModel: (id) cellEntity;
@son < / nsobject > < /Yapı temeli >
Bu şekilde, UITableView'daki tüm mesaj hücreleri, farklı mesaj hücreleri arasında veri doldurma birliğini düzenleyen bu protokolü izler. Farklı mesaj hücreleri, farklı tipte mesaj modelleri kullanır, ancak aynı doldurma özelliklerini kullanabilirler.
@protocol WBAutoCalculateCellViewModelProtocol < nsobject >
@gereklidir
- (NSString *) cellReuseIndentifier;
- (void) registerCellForTableView: (UITableView *) tableView;
@isteğe bağlı
- (CGFloat) cellHeight;
@son < / nsobject >
Mesaj görünümü görüntülenmek üzereyken, mevcut mesaj tipine göre hangi görünüm şablonunun kullanılacağının belirlenmesi sorununu çözmek için, her mesaj modelinin yukarıdaki protokolü takip etmesini sağlar ve her mesaj modeli karşılık gelen mesaj modelini saklar. Logoyu yeniden kullanın. Sınıf kaydı veya Uç kaydı gibi bir hücreyi kaydetmenin birçok yolu olduğundan, bu esnek bir arayüz olarak tasarlanmıştır ve bir hücreyi kaydetme yöntemi tamamen geliştiriciye bırakılmıştır.
Aşağıdaki isteğe bağlı protokol, burada- (CGFloat) cellHeight'ı tanıtmaya odaklanacağım. Bu protokol şu şekildedir: Çoğu senaryo belirli bir hücrenin yüksekliğini otomatik olarak hesaplayabilse de, bazı mesaj türlerinin yüksekliği sabittir ve hiç hesaplanmasına gerek yoktur. Bu problemi çözmek için mesaj modeline opsiyonel bir cellHeight protokolü ekledik.Mesaj modeli bu protokolü uygularsa, hücrenin yüksekliği otomatik olarak hesaplanmayacak, bu yöntemin dönüş değeri ile belirlenecektir.
Projeler bazen tıpkı yapı taşları gibidir. Yukarıdaki giriş sayesinde, tıpkı yapı taşları gibi birçok küçük çözümümüz var. Bu çözümler birlikte nasıl organize edilir? İşte bu "yapı taşlarının" montajı geliyor. Zamanı geldi. Sohbet sayfası görünümünü UITableView ve tableView aracılığıyla düzenleyip yönettiğimiz için: heightForRowAtIndexPath: şu anda aşağıdaki gibi uygulanan önemli proxy yöntemidir:
#pragma mark UITableViewDelegate
- (CGFloat) tableView: (UITableView *) tableView heightForRowAtIndexPath: (NSIndexPath *) indexPath {
CGFloat cellHeight = 0;
İD < wbautocalculatecellviewmodelprotocol > cellEntity = self.viewModel.dataSource;
// Cellindentifier aracılığıyla hücreyi tablo görünümüne kaydedin
Eğer () {
if (! self.tableViewRegisters) {
;
self.tableViewRegisters = @ (1);
}
}
Eğer () {
cellHeight =;
}Başka{
cellHeight =;
}
return cellHeight;
} < / wbautocalculatecellviewmodelprotocol >
Bu yöntemde, her cellEntity'nin (mesaj modeli) yukarıda açıklanan WBAutoCalculateCellViewModelProtocol'u takip ettiğini görüyoruz. Bu yöntemde, her mesaj modelinin kendi Hücre tipini kaydetmesine ve ardından Hücrenin yüksekliğini hesaplamasına izin verin.Mesaj modeli bir hücreYüksekliği yöntemine sahipse, yüksekliği hesaplamak için bu yöntemi kullanın, aksi takdirde yukarıda belirtilen otomatik yükseklik hesaplama yöntemini kullanın ve geri dönün Hücrenin yüksekliği.
Cell öğesinin görüntülenmesinde ve işlenmesinde, veri kaynağı yöntemi tableview: cellForRowAtIndexPath: of UITableView, şu anda aşağıdaki gibi uygulanan temel yöntemdir:
- (UITableViewCell *) tableView: (UITableView *) tableView cellForRowAtIndexPath: (NSIndexPath *) indexPath {
İD < wbautocalculatecellviewmodelprotocol > model = self.viewModel.dataSource;
NSString * cellIndentifier =;
UITableViewCell < wbcellconfigdelegate > * hücre =;
if (hücre) {
;
}
eğer (! hücre) {
hücre = (UITableViewCell < wbcellconfigdelegate > *);
}
dönüş hücresi;
} < / wbcellconfigdelegate > < / wbcellconfigdelegate > < / wbautocalculatecellviewmodelprotocol >
Mesaj modeli aracılığıyla yeniden kullanım tanımlayıcısını bulun. Hücre tableView: heightForRowAtIndexPath: içinde kayıtlı olduğundan, ileti türünün altındaki tüm hücreler sırayı yeniden kullanarak döndürülmelidir. Mesaj hücrelerinin tümü WBCellConfigDelegate protokolünü izler, böylece veriler tek tip bir şekilde doldurulur.
Protokol odaklı tasarım yöntemi sayesinde, tableView proxy ve VC'deki veri kaynağı yöntemlerimiz çok basit hale geldi. Ayrıca, gelecekte yeni mesaj türlerini genişletirken ilgili protokolü izlemeye devam ederseniz, VC'de bir kod satırını değiştirmenize gerek yoktur.Geliştiricilerin yalnızca yeni mesaj modelini ve görünümünü kapatması ve not etmesi gerekir.
Şekil 3 Orta kademe işin tasarımı
Çevrimdışı Voip mesajlarının işlenmesine ilişkin teknik ayrıntılar
Gerçek geliştirme sürecinde bir sorunla karşılaştık. B çevrimdışıyken, Bnin sohbet ortağı Bye sesli ve görüntülü mesajlar başlatabilir. Sinyal mesajının eksiksiz olması için, sunucu tüm mesajları Bye göndermek için bir sıra oluşturacaktır. Sinyalleme kaydedilir. Bir süre sonra, B oturum açtığında, Sunucu, B'nin çevrimdışı süresi boyunca tüm çağrı sinyallerini gönderecektir. Bu, tasarımın başlangıcında dikkate alınmadığından, bir sorun, B başladığında, A bir video mesajı gönderdiğinde, B'nin aldığı ilk video sinyalinin çevrimdışı dönem sırasında (varsa) video mesaj sinyali olmasıdır. . Bu, B'nin artık mevcut olmayan bir video kanalına bağlanmaya çalışmasına neden olur ve A-B görüntülü sohbet bağlanamaz. Bu sinyalleme dizisini de desteklemek için müşteri, Şekil 4'te gösterildiği gibi, video bağlantı sinyallemesini düzenli bir şekilde işlemek için koşullu kilit teknolojisini kullanır.
Şekil 4 Çağrı sinyalleme dizisi tasarımı
Spesifik çözümler aşağıdaki gibidir:
-
İlk olarak, bir Eşzamanlı Kuyruk oluşturuyoruz, istemciye gönderilen bir sinyalleşme sinyali Eşzamanlı Kuyrukta yürütülecektir;
-
Voip sinyallemesinin düzenli bir şekilde yürütülmesini sağlamak için, koşullu kilit NSCondition'ı tanıttık.Paralel sıra Voip sinyalini işlediğinde, ilk olarak koşullu kilidi elde eder. Edinme tamamlandıktan sonra isAvLockActive Bool değişkenini YES olarak işaretler ve ardından sinyal üzerinde ön işlem gerçekleştiririz. Ön işlemden sonra koşullu kilidi açın;
-
Kilit Açma koşullu bir kilit olduğundan, kuyruktaki diğer Voip sinyallerinin işlenme şansı vardır. İşleme sırasında isAvLockActive durumunu kontrol edin, eğer EVET ise, bu Voip sinyallemesinin daha önce işlenmediği anlamına gelir ve ardından koşullu kilidin bekleme yöntemini yürütün;
Bir Voip sinyal olayı tamamen işlendiğinde, durum kilidi Sinyali tetiklenecektir.Bu sırada, kuyrukta koşul kilidi bekleyen diğer sinyaller işlenebilir. Şu anda, kuyrukta işlenecek Voip sinyali kalmayana kadar 2. adıma geri dönüyoruz.
sonuç olarak
IM sistemi bu kez yeniden yapılandırılmış, altta yatan arayüzün ayrılmasıyla, IM SDK'nın kuplajı azaltılmış ve protokol odaklı tasarım yöntemi ile sohbet sayfasının ölçeklenebilirliği artırılmıştır.Böylece zengin metin, resimler, coğrafi konum, özgeçmiş ve kartlar Uygulama içerisinde kısa sürede genişletilmiştir. Ve diğer mesaj türleri. 58 App IM'nin yeniden düzenleme süreci aracılığıyla, IM modüllerini tasarlayan veya dönüştüren ve optimize eden geliştiriciler için bazı referanslar sağlayabileceği umulmaktadır. Gelecekte, sayfa performansının nasıl iyileştirileceğini ve kullanıcı trafiğinin nasıl azaltılacağını daha da optimize edecek ve IM ayrıntılarını iyileştirmeye devam edeceğiz.
Yazar: Jiang Yan, 58.com iOS kıdemli Ar-Ge mühendisi, IM sistem mimarisine ve 58.com Uygulamasının araştırma ve geliştirmesine liderlik ederek, App IM sisteminin mimari geliştirme ve performans optimizasyonuna odaklanıyor.
Sorumlu editör: Tang Sect Master (tangxy@csdn.net)
Beyan: Bu makale CSDN "Programcı" nın orijinal makalesidir, lütfen izinsiz yeniden yazdırmayın, yeniden yazdırmanız gerekiyorsa lütfen mesaj bırakın.
