基于Android的文件管理器的设计与开发-外文翻译

0外文原文：Synchronizationhasbeenlonginvestigatedindifferentcontextsoftraditionaldistributedsystems.Onesuchcontextisthatofdatasynchronization.Withthefastdevelopmentoflarge-scaledistributedsystems,andduetotheirheterogenousnatureinvolvingwired,wireless,andmobilenodes,synchronizationhasagaincomeintoplay.Whileknownalgorithmsfordatasynchronizationcouldbeappliedtodistributedsystemswithmobilenodes,duetoseveralfeaturesofsuchsystemssuchasintermittentInternetconnections,limitedcomputationalresources,batteryrestrictions,etc.,ithasbecomeimperativetostudythemagainandefficientlyimplementthemforlarge-scaleheterogenousdistributedsystems.Inthiswork,wefocusonthedatasynchronizationproblemondistributedsystemswithmobilenodes.TheroleofmobilesystemshasveryquicklyexperiencedagreatgrowthincorporateITinfrastructure.Geographicallydistributedteamsthatneedinstantcommunication,coupledwiththeubiquitous,albeitunreliable,presenceofbroadbandInternet,havebroughtanewparadigmofbusinessprocesses(andconsequentlyofbusinesssoftwareapplications)inwhichthetraditionalclient/serverarchitectureneedstoworkwithintermittentconnectivity,andthusdatasynchronizationisabasicfeatureinordertoallowmobilesystemstogiveservicetotheusersintheabsenceofadirectconnectiontothecentralservers.Importantusescenariosincludemobilesocialnetworkstosupportthe“always-available”featuresandthatofmobileteams,namely,agroupofpeople,geographicallydistributedandequippedwithmobiledevices,tocollaboratefortheaccomplishmentofacommonproject(e.g.,agroupofusersofaVirtualCampus,ateamofdoctorsinadisasterfield,etc.)tosupport“anytime,anywhere”accesstosharedsynchronizeddata.TheAndroidoperatingsystemhasbecomeamajorplayerinthesmartphonearenaandassuchithasanimportantecosystemofsoftwareapplicationsfocusedaroundit.Inthecorporatemarket,Androidoffers,outofthebox,contactsynchronizationfortheExchangeplatform.Ironically,thisleavesoutalotofcompaniesthatuseUnix/Linuxastheirserverplatform.Google,however,providesapowerfulframeworkthatallowsthirdpartiestodeveloppluginsforcontentsynchronizationandformanagingmultiplecontactsourcesinthe1formoftheAccounts,Synchronization,andContactsAPI.Atthesametime,SugarCRMhasbecomethemarketleaderforopen-sourceCRMsolutions,makinganintegrationbetweenthesetwosystemsaninterestingoptionformanyapplicationsandcompanies.Synchronizersaredifficulttospecifyandbuildduetotheconflictresolutionissues.Whiletherearesomeexamplesofsynchronizationadapters,bothinthewildaswellasintheAndroidSDK,manyofthemarededicatedtosingle-usercontactlistsandtoread-onlyadapters(e.g.,theuserisnotabletomodifythecontactdatathroughtheAndroidinterface),andtheyare,inthissense,oflimiteduse.Addingsharedcontactsandread/writeaccesstothecontactdatainthesmartphonechangesthegameconsiderably:itisnolongeramatterofreadingdatafromaserverfromtimetotimeandupdatingourlistaccordingly,but,aswewillsee,oneofbuildingadistributedsystemsimilartoadocumentrepositoryoraversioncontrolsystem.Inthissense,alotofworkhasbeendoneintheformofseveralstandards,themostprominentbeingSyncML.Thisisacomplexbutverycompleteprotocolspecificallyorientedtomobilesystems,offeringseveralsynchronizationmodes,especiallyforsynchronizingcontactsandcalendarinformationbetweenmobiledevicesandservers.Whileitoffersacompletesolutiontomanysynchronizationneeds,SyncMLusuallyrequiresthepresenceofathirdserverinthesystemthatintegratesandmanagesalldifferentdatasourcesinacentralizedfashion.Thisdesignallowsforcomplexsetups,butrepresentsaburdentomuchsimplerinstallationswherethedatasourceispresentinoneserverandallwewanttoallowisforsimplesharing.Furthermore,thesetupofathirdservercanfaceoppositionfromsystemadministratorsandcorporatepolicy.Inthisregard,thebuildingofanadhocsolutionmaybeabetteroption.SomeotherworksassumeaspecificformatsuchasXMLtree-structures.VendorsarealsopromotingtheuseofCloudservicesforcontactsynchronization.AsmallcomparisoncanbefoundattheFunambol(asynchronizationvendor)websiteavailablebysubscription.Whiletheuseofthistypeofsystemisincreasing,thefactthatmanycompaniesarereticenttousecloudservicestoholdsensitivedatamakesthissolutiondifficulttoadoptformanycompanies.2Inwhatcanbeconsideredtheotherextremeofthescalewefindpeer-to-peer(P2P)approacheswhichtrytosolvetheprobleminP2Pnetworks.CohenproposedaJavaframeworkforP2Psynchronizationofobjectstoresonmobiledevices.Whiletheseapproachesareinterestingintheirownright(forinstanceinbuildingaP2Psocialnetwork)theyarenotagoodfitforthenaturallycentralizedbusinessITinfrastructure.OtherstrategiescurrentlyinuseinvolvetheuseofproprietaryframeworkssuchastheMicrosoftSyncFrameworkortheuseofdistributedmobiledatabases(asmallrecollectionofsuchtoolscanbefoundin).Bothofthesesolutionshoweverrequireasystemdesignedexpresslytotakeadvantageofthearchitectureandarethusdifficulttoapplytoexistingsystems.Inthisregard,wefindthatthereareveryfewalgorithmsthatallowforsynchronizationwithexistingserversystems.Suchalgorithmsareusuallyproprietaryandstillrequiresomedegreeofchangeintheserverside.Inthisregard,thealgorithmproposeddefinesaclearandsmallsetofrequisitesthataserversystemmustprovideinordertoensurecorrectsynchronization.Suchasetofrequisitesisminimizedbyprovidingconflictresolutionintheclientasopposedtothecommonlyusedserverimplementationandbyfollowingdesignpatternsfromotherdistributedcontrolsystems.Wehaveseenseveralexamplesofdistributedsystemsandthechoicesandtradeoffsmadebytheirdesigners.Theselessonsshouldproveusefultothedesignofacontactsynchronizationsystem.Clearly,ourrequirementsincludepartitiontoleranceandavailability:usersexpecttoaccesstheircontactlistevenwithoutanetworkconnectionandexpectittobeavailableevenwhenothernodesmaybedown.Ourmaindesigndecision,then,wouldbewhatguaranteesofconsistencywewantoursystemtofulfill.Atfirstglance,onemaythinkthateventualconsistencyisdesirable,but,insuchamodel,thedeletionofacontactinamobilephonewillleadtothedeletionofthecontactfirstintheserver,andthiswillslowlypropagatetoallphonesandclients.Thisobviouslycanleadtoseveresecurityincidentsifthemobilephoneislostorusedbyanattacker,whocoulddelete3allcontactsfromthesystem.Partialconsistencycansolvethisissuebyignoringdeletedcontactsatbothsidesofthesystem.Thereareotherusecasesinwhichpartialconsistencymaybeofvalue:forinstance,usersmaywanttoattachdifferentmetadatatothesamecontacts(inwhichgroupacontactshouldbedisplayedinthephone).Wecanconclude,then,thatthedesirablepropertiesforoursystemwouldbetobepartitiontolerant,available,andpartiallyconsistent.WehaveseenthattheDVCSdesignapparentlyfitsbetterinourdesignchoices;however,itisalsotruethatDVCSsofferfeaturesliketheabilitytosynchronizebetweentwopeerswithouttheuseofaserver.Whilethisfeatureiscertainlyuseful,keepingtrackofwhatchangeshavebeenpropagatedandtowhomcanbeacomplexendeavorandcanposeaburdentotheuserintheformofdataconflicts,changetracking,andotherissueswhichmakesenseinthecontextofaDVCSbutnotfortheproblemathand.WhatwereallywantismoreakintoaVCSsystemwiththetwistthat,likeinaDVCS,notalldatashouldbesynchronized.Thisisobviouslymucheasiertoimplementthanafull-blownDVCSsystem.AnotherimportantsourceforinspirationisobviouslytheSyncMLprotocol.Theprotocoldefinesasetofsevendistinctalgorithmsfordatasynchronization.Ofthem,onlytwooffertwo-waysynchronization,thefirstbeing“two-waysync”andthesecondbeing“slow-sync”.SyncMLsversionoftwo-waysyncstartsbysendingtheclientschangestotheserverforthemtobeprocessed.Theserverprocessessuchchangesandthensendsalistoftheacceptedorfinalchangesalongwithasetofitsownchangesbacktotheclient.Thisalgorithmobviouslyworkswellbutneedsanintelligentserverabletodoautomaticconflictresolutionandotherdataprocessing.However,oursystemisdesignedundertheassumptionthattheserverisnotspecificallydesignedtoperformthecontactsynchronizationtask.Underthisconstraint,conflictresolutionmustbeperformedontheclient,asourservermaynotbecapableofperformingsuchfunction.The“slow-sync”algorithmisanexpensivealgorithminwhichallelementsinbothdatabasesarecomparedagainsteachother.Wewillnotprovideadetaileddescriptioninthispaper,but4itsuffersthesameproblemsthattheordinary“two-way”algorithmhas.MobilecomputingisastrongrealityintodaysITinfrastructure,andtheneedtosharedataandmakeitavailableeverywhere,atanytime,acrossmultipledevicesoperatingunderunreliableconditionsisachallengethatcanbetackledwithdifferentapproaches.WehavepresentedanexampleofadistributedsysteminvolvingmobilesystemstogetherwiththerationalethathasledtothisdesignbyobservingothersystemsandapplyingtheprinciplesembodiedintheCAPtheorem(consistency,availability,andpartitiontolerance)andrelatedwork.Wehavealsoclassifiedthiskindofdesigninacategoryofitsownthathaspartialconsistencyasadesirablefeature.Wehaveshownthatthesystemcanworkcorrectlyandreliablyaslongassomebasicsupportisofferedbytheserversystem,evenintheeventofnetworkordevicefailure.Thiscomesatthecostofsomeredundancywhentransferringdataafterfailure.Futureworkwillbeorientedtowardstwodifferentdirections.Thefirstwillbemeasuringactualperformanceandbottlenecksinthecurrentsystemacrossseveraldevices.Thiswillallowustooptimizetherealbottlenecksregardlessofthedevice.Thesecondwillbeconcerningthesynchronizationofcalendardata,which,unlikecontactdata,canreapthebenefitsofafullyblowndistributeddesignbyenablinguserstosendeventsacrossdifferentnetworks(SMS,email,etc.)withouttheneedtohaveconnectivitywiththeserverwhichmaybedifficulttoachieve(forexamplewithroaminguserswhomayonlyhaveSMSasaviabletransport).5中文翻译：长期以来同步在研究传统的分布式系统中不同的背景。这样的一个背景是，数据同步。随着大规模分布式系统的快速发展，由于其异质性、涉及有线、无线和移动节点，同步也将再次发挥作用。虽然已知的算法进行数据同步可以应用于分布式系统与移动节点，由于这样的系统，如间歇性的互联网连接，有限的计算资源，电池的限制等几个特点，它已成为当务之急再研究他们，并有效地实现它们用于大规模异构分布式系统。在这项工作中，我们专注于分布式系统与移动节点的数据同步问题。移动通信系统的作用已经非常迅速经历了企业IT基础架构有很大的增长。需要即时沟通，再加上无处不在，尽管是不可靠的，宽带互联网的出现，带来了业务流程的新典范地理上分散的团队（以及随后的业务应用软件），其中传统的客户机/服务器体系结构需要间歇工作连接，并且因此数据同步，以便允许移动系统向用户提供的服务中的情况下直接连接到中央服务器的一个基本特征。重要的应用场景包括移动社交网络，以支持“永远可用”的特点，而流动小组，即一群人，地理分布及配备移动设备，协作为一个共同项目的完成（例如，用户组的一个虚拟校园，一组医生在灾难现场等），支持“随时随地”访问共享数据同步。Android操作系统已成为智能手机领域的主要参与者，因此它有重点围绕它的软件应用的一个重要的生态系统。在企业市场，Android提供了，出了交流的平台框，联系人同步的。讽刺的是，这留下了很多使用的Unix/Linux作为其服务器平台的公司。谷歌，然而，提供了强大的框架，允许第三方开发插件的内容同步和在账户，同步，以及联系人API的形式管理多个联系人来源。与此同时，SugarCRM公司已经成为市场的领导者，开源CRM解决方案，使这两个系统对于许多应用程序和企业一个有趣的选项之间的整合。同步器是很难定义和建立因冲突解决的问题。虽然有同步适配器的一些例子，无论是在野外，以及在AndroidSDK中，有很多是专门为单用户联系人列表，并为只读适配器（例如，用户不能修改联系人通过Android接口的数据），在这个意义上,它们的用途有限。添加共享联系人和读/写访问在智能手机上的联系人数据大大改变了游戏规则：它不再读取从时间服务器数据的时间并相应地更新我们的名单的事，但是，正如我们将看到一为构建分布式系统类似于一个文档库或版本控制系统。在这个意义上，大量的工作在几个标准，最突出的是SyncML的形式已经完成。这是一个复杂但很完整的协议，专门面向移动通信系统，提供多种同步模式，特别是用于同步移动设备和服务器之间的联系人和日历信息。虽然它提供了一个完整的解决方案为许多同步的需求，SyncML的，通常需要有第三台服务器的集成和管理所有不同的数据源中以集中方式的系统的存在。这种设计可实现复杂的设置，但代表了负担，更简单的安装，其中的数据源是存在于一台服务器，所有我们希望允许是简单共享。此外，第三个服务器的设置可以从系统管理员和企业政策面临的反对。在这方面，特设解决方案的建设可能是一个更好的选择。其他一些作品假设一个特定的格式，例如XML树形结构。厂商也在推广使用云服务的联系人同步。一个小的对比可在Funambol的（同步卖方）网站可通过订阅被发现。虽然使用这种类型的系统的不断增加，事实上，许多公司都讳莫如深使用云服务来保存敏感数据，使得该解决方案难以通过许多公司。什么可以被认为是天平的另一极端，我们发现的对等（P2P）的方式尝试解决问题的P2P网络。科恩提出了一个Java框架对象存储在移动设备上的P2P同步。虽然这些6方法都是有趣的在自己的权利（例如在建立一个P2P社交网络），他们是不般配的自然业务集中的IT基础架构。目前使用的其他策略包括使用专有的框架，如微软同步框架或使用分布式移动数据库（一个小回忆这些工具可以发现）的。这两种解决方案却需要设计明文取架构的优点的系统，因而很难适用于现有的系统。在这方面，我们发现，很少有算法，考虑与现有的服务器系统同步。这种算法通常是专有的，仍然需要某种程度的改变在服务器端的。在这方面，所提出的算法定义了一个明确的和小的组的必要条件，一个服务器系统必须以确保正确的同步提供的。这样的一组先决条件是由相对于通常使用的服务器上执行，并通过从其他分布式控制系统下的设计模式，提供解决冲突在客户端最小化。我们已经看到了他们的设计师做分布式系统及选择和权衡的几个例子。这些教训应该证明是有益的联系人同步系统的设计。显然，我们的要求包括分区容忍性和可用性：用户希望访问他们的联系人列表，甚至没有网络连接，并希望它是可用的，即使其他节点可能会下降。我们的主要设计决策，那么，会是怎样的一致性保证，我们希望我们的系统要完成。乍一看，人们可能会认为，最终一致性是可取的，