精华内容
参与话题
问答
  • HTML5移动应用开发入门经典

    千次下载 热门讨论 2015-10-24 11:09:04
    HTML5移动应用开发入门经典。我也是从别人那里下载的,分享下
  • 什么是一个好的应用架构?怎么才能搭建大型的应用架构?其实每个人在工作几年之后都会有这个疑问,都在寻求好点的框架,那么小编我总结一下我的经验给大家。  其实对于客户端,一个好的应用架构,复杂度不亚于...

         什么是一个好的应用架构?怎么才能搭建大型的应用架构?其实每个人在工作几年之后都会有这个疑问,都在寻求好点的框架,那么小编我总结一下我的经验给大家。

         其实对于客户端,一个好的应用架构,复杂度不亚于服务端,因为需要承载需求和产品的变更,如果前期没弄好,后期要么成烂尾,要么就重构去吧~~性质其实和服务端是差不多的,客户端侧重于逻辑和框架。

        其实搭建架构,不单单要考虑到实际成本和产品的需求,更重要的是支撑这些事情的基础,这就是做架构要考虑的事情。

    • 调用网络API
    • 页面展示
    • 数据的本地持久化
    • 动态部署方案
    • 代码的健壮性
    • 数据的安全性
         稍微细说一下比较重要的:
    • 如何根据业务安全地调用网络API?然后尽可能保证用户在各种网络环境下都能有良好的体验?都能有良好的体验?都能有良好的体验?重要的事情要说三遍。
    • 降低业务方代码的耦合度?降低开发界面的复杂度,提高他们的效率?
    • 如何尽可能地减小性能消耗?如何有效的保存数据?更要保证数据的有效性?
    • 如何修复严重bug?
    • 如何更新需求不一样的第二个版本?

    这系列文章主要是回答以下这些问题:

    1. 网络层设计方案?设计网络层时要考虑哪些问题?对网络层做优化的时候,可以从哪些地方入手?
    2. 页面的展示、调用和组织都有哪些设计方案?我们做这些方案的时候都要考虑哪些问题?
    3. 本地持久化层的设计方案都有哪些?优劣势都是什么?不同方案间要注意的问题分别都是什么?
    4. 要实现动态部署,都有哪些方案?不同方案之间的优劣点,他们的侧重点?

    那首先大伙要明白的是设计原则,避重就轻,什么是避重就轻?先来说下我从其它网站看到一篇比较好的文章,如下蓝色字体部分

    架构设计的方法


    所有事情最难的时候都是开始做的时候,当你开始着手设计并实现某一层的架构乃至整个app的架构的时候,很有可能会出现暂时的无从下手的情况。以下方法论是我这些年总结出来的经验,每个架构师也一定都有一套自己的方法论,但一样的是,不管你采用什么方法,全局观、高度的代码审美能力、灵活使用各种设计模式一定都是贯穿其中的。

             第一步:搞清楚要解决哪些问题,并找到解决这些问题的充要条件

    你必须得清楚你要做什么,业务方希望要什么。而不是为了架构而架构,也不是为了体验新技术而改架构方案。以前是MVC,最近流行MVVM,如果过去的MVC是个好架构,没什么特别大的缺陷,就不要推倒然后搞成MVVM。

    关于充要条件我也要说明一下,有的时候系统提供的函数是需要额外参数的,比如read函数。还有翻页的时候,当前页码也是充要条件。但对于业务方来说,这些充要条件还能够再缩减。

    比如read,需要给出file descriptor,需要给出buf,需要给出size。但是对于业务方来说,充要条件就只要file descriptor就够了。再比如翻页,其实业务方并不需要记录当前页号,你给他暴露一个loadNextPage这样的方法就够了。

    搞清楚对于业务方而言的真正充要条件很重要!这决定了你的架构是否足够易用。另外,传的参数越少,耦合度相对而言就越小,你替换模块或者升级模块所花的的代价就越小。

               第二步:问题分类,分模块

    这个不用多说了吧。

               第三步:搞清楚各问题之间的依赖关系,建立好模块交流规范并设计模块

    关键在于建立一套统一的交流规范。这一步很能够体现架构师在软件方面的价值观,虽然存在一定程度上的好坏优劣(比如胖Model和瘦Model),但既然都是架构师了,基本上是不会设计出明显很烂的方案的,除非这架构师还不够格。所以这里是架构师价值观输出的一个窗口,从这一点我们是能够看出架构师的素质的。

    另外要注意的是,一定是建立一套统一的交流规范,不是两套,不是多套。你要坚持你的价值观,不要摇摆不定。要是搞出各种五花八门的规范出来,一方面有不切实际的炫技嫌疑,另一方面也会带来后续维护的灾难。

     第四步:推演预测一下未来可能的走向,必要时添加新的模块,记录更多的基础数据以备未来之需

    很多称职的架构师都会在这时候考虑架构未来的走向,以及考虑做完这一轮架构之后,接下来要做的事情。一个好的架构虽然是功在当代利在千秋的工程,但绝对不是一个一劳永逸的工程。软件是有生命的,你做出来的架构决定了这个软件它这一生是坎坷还是幸福。

    第五步:先解决依赖关系中最基础的问题,实现基础模块,然后再用基础模块堆叠出整个架构

    这一步也是验证你之前的设计是否合理的一步,随着这一步的推进,你很有可能会遇到需要对架构进行调整的情况。这个阶段一定要吹毛求疵高度负责地去开发,不要得过且过,发现架构有问题就及时调整。否则以后调整的成本就非常之大了。

            第六步:打点,跑单元测试,跑性能测试,根据数据去优化对应的地方

    你得用这些数据去向你的boss邀功,你也得用这些数据去不断调整你的架构。

    总而言之就是要遵循这些原则:自顶向下设计(1,2,3,4步),自底向上实现(5),先测量,后优化(6)。


    什么样的架构叫好架构?


    1. 代码整齐,分类明确,没有common,没有core
    2. 不用文档,或很少文档,就能让业务方上手
    3. 思路和方法要统一,尽量不要多元
    4. 没有横向依赖,万不得已不出现跨层访问
    5. 对业务方该限制的地方有限制,该灵活的地方要给业务方创造灵活实现的条件
    6. 易测试,易拓展
    7. 保持一定量的超前性
    8. 接口少,接口参数少
    9. 高性能

    以上是我判断一个架构是不是好架构的标准,这是根据重要性来排列的。客户端架构跟服务端架构要考虑的问题和侧重点是有一些区别的。下面我会针对每一点详细讲解一下:



    代码整齐,分类明确,没有common,没有core

    代码整齐是每一个工程师的基本素质,先不说你搞定这个问题的方案有多好,解决速度有多快,如果代码不整齐,一切都白搭。因为你的代码是要给别人看的,你自己也要看。如果哪一天架构有修改,正好改到这个地方,你很容易自己都看不懂。另外,破窗理论提醒我们,如果代码不整齐分类不明确,整个架构会随着一次一次的拓展而越来越混乱。

    分类明确的字面意思大家一定都了解,但还有一个另外的意思,那就是:不要让一个类或者一个模块做两种不同的事情。如果有类或某模块做了两种不同的事情,一方面不适合未来拓展,另一方面也会造成分类困难。

    不要搞Common,Core这些东西。每家公司的架构代码库里面,最恶心的一定是这两个名字命名的文件夹,我这么说一定不会错。不要开Common,Core这样的文件夹,开了之后后来者一定会把这个地方搞得一团糟,最终变成Common也不Common,Core也不Core。要记住,架构是不断成长的,是会不断变化的。不是每次成长每次变化,都是由你去实现的。如果真有什么东西特别小,那就索性为了他单独开辟一个模块就好了,小就小点,关键是要有序。



    不用文档,或很少文档,就能让业务方上手

    谁特么会去看文档啊,业务方他们已经被产品经理逼得很忙了。所以你要尽可能让你的API名字可读性强,对于iOS来说,objc这门语言的特性把这个做到了极致,函数名长就长一点,不要紧。


        好的函数名:
            - (NSDictionary *)exifDataOfImage:(UIImage *)image atIndexPath:(NSIndexPath *)indexPath;
    
        坏的函数名:
            - (id)exifData:(UIImage *)image position:(id)indexPath callback:(id<ErrorDelegate>)delegate;
    
        为什么坏?
            1. 不要直接返回id或者传入id,实在不行,用id<protocol>也比id好。如果连这个都做不到,你要好好考虑你的架构是不是有问题。
            2. 要告知业务方要传的东西是什么,比如要传Image,那就写上ofImage。如果要传位置,那就要写上IndexPath,而不是用position这么笼统的东西
            3. 没有任何理由要把delegate作为参数传进去,一定不会有任何情况不得不这么做的。而且delegate这个参数根本不是这个函数要解决的问题的充要条件,如果你发现你不得不这么做,那一定是架构有问题!
    



    思路和方法要统一,尽量不要多元

    解决一个问题会有很多种方案,但是一旦确定了一种方案,就不要在另一个地方采用别的方案了。也就是做架构的时候,你得时刻记住当初你决定要处理这样类型的问题的方案是什么,以及你的初衷是什么,不要摇摆不定。

    另外,你当初设立这个模块一定是有想法有原因的,要记录下你的解决思路,不要到时候换个地方你又灵光一现啥的,引入了其他方案,从而导致异构。

    要是一个框架里面解决同一种类似的问题有各种五花八门的方法或者类,我觉得做这个架构的架构师一定是自己都没想清楚就开始搞了。



    没有横向依赖,万不得已不出现跨层访问

    没有横向依赖是很重要的,这决定了你将来要对这个架构做修补所需要的成本有多大。要做到没有横向依赖,这是很考验架构师的模块分类能力和是否熟悉业务的。

    跨层访问是指数据流向了跟自己没有对接关系的模块。有的时候跨层访问是不可避免的,比如网络底层里面信号从2G变成了3G变成了4G,这是有可能需要跨层通知到View的。但这种情况不多,一旦出现就要想尽一切办法在本层搞定或者交给上层或者下层搞定,尽量不要出现跨层的情况。跨层访问同样也会增加耦合度,当某一层需要整体替换的时候,牵涉面就会很大。



    对业务方该限制的地方有限制,该灵活的地方要给业务方创造灵活实现的条件

    把这点做好,很依赖于架构师的经验。架构师必须要有能力区分哪些情况需要限制灵活性,哪些情况需要创造灵活性。比如对于Core Data技术栈来说,ManagedObject理论上是可以出现在任何地方的,那就意味着任何地方都可以修改ManagedObject,这就导致ManagedObjectContext在同步修改的时候把各种不同来源的修改同步进去。这时候就需要限制灵活性,只对外公开一个修改接口,不暴露任何ManagedObject在外面。

    如果是设计一个ABTest相关的API的时候,我们又希望增加它的灵活性。使得业务方不光可以通过Target-Action的模式实现ABtest,也要可以通过Block的方式实现ABTest,要尽可能满足灵活性,减少业务方的使用成本。



    易测试易拓展

    老生常谈,要实现易测试易拓展,那就要提高模块化程度,尽可能减少依赖关系,便于mock。另外,如果是高度模块化的架构,拓展起来将会是一件非常容易的事情。



    保持一定量的超前性

    这一点能看出架构师是否关注行业动态,是否能准确把握技术走向。保持适度的技术上的超前性,能够使得你的架构更新变得相对轻松。

    另外,这里的超前性也不光是技术上的,还有产品上的。谁说架构师就不需要跟产品经理打交道了,没事多跟产品经理聊聊天,听听他对产品未来走向的畅想,你就可以在合理的地方为他的畅想留一条路子。同时,在创业公司的环境下,很多产品需求其实只是为了赶产品进度而产生的妥协方案,最后还是会转到正轨的。这时候业务方可以不实现转到正规的方案,但是架构这边,是一定要为这种可预知的改变做准备的。



    接口少,接口参数少

    越少的接口越少的参数,就能越降低业务方的使用成本。当然,充要条件还是要满足的,如何在满足充要条件的情况下尽可能地减少接口和参数数量,这就能看出架构师的功力有多深厚了。



    高性能

    为什么高性能排在最后一位?

    高性能非常重要,但是在客户端架构中,它不是第一考虑因素。原因有下:


    • 客户端业务变化非常之快,做架构时首要考虑因素应当是便于业务方快速满足产品需求,因此需要尽可能提供简单易用效果好的接口给业务方,而不是提供高性能的接口给业务方。
    • 苹果平台的性能非常之棒,正常情况下很少会出现由于性能不够导致的用户体验问题。
    • 苹果平台的优化手段相对有限,甚至于有些时候即便动用了无所不用其极的手段乃至不择手段牺牲了稳定性,性能提高很有可能也只不过是100ms到90ms的差距。10%的性能提升对于服务端来说很不错了,因为服务端动不动就是几十万上百万的访问量,几十万上百万个10ms是很可观的。但是对于客户端的用户来说,他无法感知这10ms的差别,如果从10s优化成9s用户还是有一定感知的,但是100ms变90ms,我觉得吧,还是别折腾了。


    但是!不重要不代表用不着去做,关于性能优化的东西,我会对应放到各系列文章里面去。比如网络层优化,那就会在网络层方案的那篇文章里面去写,对应每层架构都有每层架构的不同优化方案,我都会在各自文章里面一一细说。



       

    ————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————

    其实分层这种东西,真没啥技术含量,全凭架构师的经验和素质。


    我们常见的分层架构,有三层架构的:展现层、业务层、数据层。也有四层架构的:展现层、业务层、网络层、本地数据层。这里说三层四层,跟TCP/IP所谓的五层或者七层不是同一种概念。再具体说就是:你这个架构在逻辑上是几层那就几层,具体每一层叫什么,做什么,没有特定的规范。这主要是针对模块分类而言的。

    也有说MVC架构,MVVM架构的,这种层次划分,主要是针对数据流动的方向而言的。

    在实际情况中,针对数据流动方向做的设计和针对模块分类做的设计是会放在一起的,也就是说,一个MVC架构可以是四层:展现层、业务层、网络层、本地数据层。

    那么,为什么我要说这个?米奇云科技?

    大概在五六年前,业界很流行三层架构这个术语。然后各种文档资料漫天的三层架构,并且喜欢把它与MVC放在一起说,MVC三层架构/三层架构MVC,以至于很多人就会认为三层架构就是MVCMVC就是三层架构。其实不是的。三层架构里面其实没有Controller的概念,而且三层架构描述的侧重点是模块之间的逻辑关系。MVCController的概念,它描述的侧重点在于数据流动方向。



    好,为什么流行起来的是三层架构,而不是四层架构五层架构


    因为所有的模块角色只会有三种:数据管理者数据加工者数据展示者,意思也就是,笼统说来,软件只会有三层,每一层扮演一个角色。其他的第四层第五层,一般都是这三层里面的其中之一分出来的,最后都能归纳进这三层的某一层中去,所以用三层架构来描述就比较普遍。



    那么我们怎么做分层?


    应该如何做分层,不是在做架构的时候一开始就考虑的问题。虽然我们要按照自顶向下的设计方式来设计架构,但是一般情况下不适合直接从三层开始。一般都是先确定所有要解决的问题,先确定都有哪些模块,然后再基于这些模块再往下细化设计。然后再把这些列出来的问题和模块做好分类。分类之后不出意外大多数都是三层。如果发现某一层特别庞大,那就可以再拆开来变成四层,变成五层。


    举个例子:你要设计一个即时通讯的服务端架构,怎么分层?

    记住,不要一上来就把三层架构的规范套上去,这样做是做不出好架构的。

    你要先确定都需要解决哪些问题。这里只是举例子,我随意列出一点意思意思就好了:

    1. 要解决用户登录、退出的问题
    2. 解决不同用户间数据交流的问题
    3. 解决用户数据存储的问题
    4. 如果是多台服务器的集群,就要解决用户连接的寻址问题


    解决第一个问题需要一个链接管理模块,链接管理模块一般是通过链接池来实现。 解决第二个问题需要有一个数据交换模块,从A接收来的数据要给到B,这个事情由这个模块来做。 解决第三个问题需要有个数据库,如果是服务于大量用户,那么就需要一个缓冲区,只有当需要存储的数据达到一定量时才执行写操作。 解决第四个问题可以有几种解决方案,一个是集群中有那么几台服务器作为寻路服务器,所有寻路的服务交给那几台去做,那么你需要开发一个寻路服务的Daemon。或者用广播方式寻路,但如果寻路频次非常高,会造成集群内部网络负载特别大。这是你要权衡的地方,目前流行的思路是去中心化,那么要解决网络负载的问题,你就可以考虑配置一个缓存。

    于是我们有了这些模块:

    链接管理、数据交换、数据库及其配套模块、寻路模块

    做到这里还远远没有结束,你要继续针对这四个模块继续往下细分,直到足够小为止。但是这里只是举例子,所以就不往下深究了。

    另外,我要提醒你的是,直到这时,还是跟几层架构毫无关系的。当你把所有模块都找出来之后,就要开始整理你的这些模块,很有可能架构图就是这样:


        链接管理  收发数据                     收发数据
            数据交换                       /        \ 
                                \   链接管理        数据交换
        寻路服务          ========\                   /  \
                        ========/            数据库服务   寻路服务
            数据库服务           / 
    

    然后这些模块分完之后你看一下图,嗯,1、2、3,一共三层,所以那就是三层架构啦。在这里最消耗脑力最考验架构师功力的地方就在于:找到所有需要的模块把模块放在该放的地方

    这个例子侧重点在于如何分层,性能优化、数据交互规范和包协议、数据采集等其他一系列必要的东西都没有放进去,但看到这里,相信你应该了解架构师是怎么对待分层问题的了吧?


    对的,答案就是没有分层。所谓的分层都是出架构图之后的事情了。所以你看别的架构师在演讲的时候,上来第一句话差不多都是:"这个架构分为以下几层..."。但考虑分层的问题的时机绝对不是一开始就考虑的。另外,模块一定要把它设计得独立性强,这其实是门艺术活。


    另外,这虽然是服务端架构,但是思路跟客户端架构是一样的,侧重点不同罢了。之所以不拿客户端架构举例子,是因为这方面的客户端架构苹果已经帮你做好了绝大部分事情,没剩下什么值得说的了。



    ————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————


    关于Common文件夹?


    评论区MatrixHero提到一点:


    关于common文件夹的问题,仅仅是文件夹而已,别无他意。如果后期维护出了代码混乱可能是因为,和服务器沟通协议不统一,或代码review不及时。应该有专人维护公共类。


    这是针对我前面提出的不要Common,不要Core而言的,为什么我建议大家不要开Common文件夹?我打算分几种情况给大家解释一下。

    一般情况下,我们都会有一些属于这个项目的公共类,比如取定位坐标,比如图像处理。这些模块可能非常小,就h和m两个文件。单独拎出来成为一个模块感觉不够格,但是又不属于其他任何一个模块。于是大家很有可能就会把它们放入Common里面,我目前见到的大多数工程和大多数文档里面的代码都喜欢这么做。在当时来看,这么做看不出什么问题,但关键在于:软件是有生命,会成长的。当时分出来的小模块,很有可能会随着业务的成长,逐渐发展成大模块,发展成大模块后,可以再把它从Common移出来单独成立一个模块。这个在理论上是没有任何问题的,然而在实际操作过程中,工程师在拓张这个小模块的时候,不太容易会去考虑横向依赖的问题,因为当时这些模块都在Common里面,直接进行互相依赖是非常符合直觉的,而且也不算是不遵守规范。然而要注意的是,这才是Commom代码混乱的罪魁祸首,Common文件夹纵容了不精心管理依赖的做法。当Common里面的模块依赖关系变得复杂,再想要移出来单独成立一个模块,就不是当初设置Common时想的等规模大了再移除也不迟那么简单了。


    另外,Common有的时候也不仅仅是一个文件夹。


    在使用Cocoapods来管理项目库的时候,Common往往就是一个pod。这个pod里面会有A/B/C/D/E这些函数集或小模块。如果要新开一个app或者Demo,势必会使用到Common这个pod,这么做,往往会把不需要包含的代码也包含进去,我对项目有高度洁癖,这种情况会让我觉得非常不舒服。




    举个例子:早年安居客的app还不是集齐所有新房二手房租房业务的。当你刚开始写新房这个app的时候,创建了一个Common这个pod,这里面包含了一些对于新房来说比较Common的代码,也包含了对于这个app来说比较Common的代码。过了半年或者一年,你要开始二手房这个app,我觉得大多数人都会选择让二手房也包含这个Common,于是这个Common很有可能自己走上另一条发展的道路。等到了租房这个业务要开app的时候,Common已经非常之庞大,相信这时候的你也不会去想整理Common的事情了,先把租房搞定,于是Common最终就变成了一坨屎。

    就对于上面的例子来说,还有一个要考虑的是,分出来的三个业务很有可能会有三个Common,假设三个Common里面都有公共的功能,交给了三个团队去打理,如果遇到某个子模块需要升级,那么三个Common里面的这个子模块都要去同步升级,这是个很不效率的事情。另外,很有可能三个Common到最后发展成彼此不兼容,但是代码相似度非常之高,这个在架构上,是属于分类条理不清

    就在去年年中的时候,安居客决定将三个业务归并到同一个App。好了,如果你是架构师,面对这三个Common,你打算怎么办?要想最快出成果,那就只好忍受代码冗余,赶紧先把架子搭起来再说,否则你面对的就是剪不断理还乱的Common。此时Common就已经很无奈地变成一坨屎了。这样的Common,你自己说不定也搞不清楚它里面到底都有些什么了,交给任何一个人去打理,他都不敢做彻底的整理的。




    还有就是,Common本身就是一个粒度非常大的模块。在阿里这样大规模的团队中,即便新开一个业务,都需要在整个app的环境下开发,为什么?因为模块拆分粒度不够,要想开一个新业务,必须把其他业务的代码以及依赖全部拉下来,然后再开新入口,你的新业务才能进行正常的代码编写和调试。然而你的新业务其实只依赖首页入口、网络库等这几个小模块,不需要依赖其他那么多的跟你没关系的业务。现在每次打开天猫的项目,我都要等个两三分钟,这非常之蛋疼。

    但是大家真的不知道这个原因吗?知道了这个原因,为什么没人去把这些粒度不够细的模块整理好?在我看来,这件事没人敢做。

    1. 原来大家用的好好的,手段烂就烂一点,你改了你能保证不出错?
    2. 这么复杂的东西,短期之内你肯定搞不好,任务量和工时都不好估,你leader会觉得你在骗工时玩自己的事情。
    3. 就算你搞定了,QA这边肯定再需要做一次全面的回归测试,任务量极大,难以说服他们配合你的工作。

    花这么大的成本只是为了减少开启项目时候等待IDE打开时的那几分钟时间?我想如果我是你leader,我也应该不会批准你做这样的事情的。所以,与其到了后面吃这个苦头,不如一开始做架构的时候就不要设置Common,到后面就能省力很多。架构师的工作为什么是功在当代利在千秋,架构师的素质为什么对团队这么重要?我觉得这里就是一个最好的体现。




    简而言之,不建议开Common的原因如下:

    1. Common不仅仅是一个文件夹,它也会是一个Pod。不管是什么,在Common里面很容易形成错综复杂的小模块依赖,在模块成长过程中,会纵容工程师不注意依赖的管理,乃至于将来如果要将模块拆分出去,会非常的困难。
    2. Common本身与细粒度模块设计的思想背道而驰,属于一种不合适的偷懒手段,在将来业务拓张会成为阻碍。
    3. 一旦设置了Common,就等于给地狱之门打开了一个小缝,每次业务迭代都会有一些不太好分类的东西放入Common,这就给维护Common的人带来了非常大的工作量,而且这些工作量全都是体力活,非常容易出错。


    那么,不设Common会带来哪些好处?


    1. 强迫工程师在业务拓张的时候将依赖管理的事情考虑进去,让模块在一开始发展的时候就有自己的土壤,成长空间和灵活度非常大。
    2. 减少各业务模块或者Demo的体积,不需要的模块不会由于Common的存在而包含在内。
    3. 可维护性大大提高,模块升级之后要做的同步工作非常轻松,解放了那个苦逼的Common维护者,更多的时间可以用在更实质的开发工作上。
    4. 符合细粒度模块划分的架构思想。

    Common的好处只有一个,就是前期特别省事儿。然而它的坏处比好处要多太多。不设置Common,再小的模块再小的代码也单独拎出来,最多就是Podfile里面要多写几行,多写几行最多只花费几分钟。但若要消除Common所带来的罪孽,不是这几分钟就能搞定的事情。既然不用Common的好处这么多,那何乐而不为呢?

    假设将来你的项目中有一个类是用来做Location的,哪怕只有两个文件,也给他开一个模块就叫Location。如果你的项目中有一个类是用来做ImageProcess的,那也开一个模块就叫ImageProcess。不要都放到Common里面去,将来你再开新的项目或者新的业务,用Location就写依赖Location,用ImageProcess就写依赖ImageProcess,不要再依赖Common了,这样你的项目也好管理,管理Common的那个人日子过得也轻松(这个人其实都可以不需要了,把他的工资加到你头上不是更好?:),将来要升级的话,顾虑也少。



    除了数据转化以外,reformer要解决的问题还有以下几点:

    1. 多数据源到单view的数据转化(租房列表API,新房列表API,二手房API到同一个tableview的数据转化)

    2. 单数据源到多view的数据转化(附近房源API数据转化成MapView或tableview)

    3. 转化逻辑的代码在多业务甚至多app情况下复用



    米奇云科技  

    转载请注明:http://blog.csdn.net/djy1992/article/details/48315757



    展开全文
  • 培训内容: 1,Android 动画培训 2,H5混合app开发之路 3,App界面开发和性能优化
  • 使用markman助力移动应用开发

    千次阅读 2014-12-27 17:52:59
    markman是一款国人开发的免费标注和测量工具,可以方便的在psd/png等图片文件中加以标注和测量。具体功能如下: 1、标记长度 可以横向、垂直标记和测量元素的长度。按住 Tab 时还能自动探测元素的边缘,并自动...
     markman介绍:
    markman是一款国人开发的免费标注和测量工具,可以方便的在psd/png等图片文件中加以标注和测量。具体功能如下:

    1、标记长度
    可以横向、垂直标记和测量元素的长度。按住 Tab 时还能自动探测元素的边缘,并自动调整自身长度
    2、标记颜色
    自动读取标记所指的元素的色值。可以任选RGB/HEX的表示方式。
    3、标记坐标、矩形
    可以用来标记某个点的位置。将准心中间的原点拖出来以后,就能同时标记坐标和长宽
    4、标记文字内容
    如果前面3种标记还不能满足你的需求,就直接用文字来说明吧
    5、支持多种图片格式
    JPG/PNG/BMP什么的都不在话下,关键是还支持PSD哦
    6、自动读取原图更新
    如果打开的图片被修改了,马克鳗就会自动载入修改后的图。这样就能左手编辑PSD,右手用马克鳗加标记

    在移动应用开发过程中,ucd/切图人员和开发人员的配合是一个非常重要的环节,直接影响到最终效果的呈现精度。
    在引入MARKMAN到项目中以前,设计人员需要输出大量的标注到切图中,以指导在移动应用开发过程中,ucd/切图人员和开发人员的配合是一个非常重要的环节,直接影响到最终效果的呈现精度。
    在引入MARKMAN到项目中以前,设计人员需要输出大量的标注到切图中,以指导开发实现;目前我们很多情况下开发直接使用markman进行坐标的标记,并读取色值等,从而保证开发实现和高保真的一致。
    UCD/SE也可以方便的添加标注到图片中,从而更好的指导开发。

    markman官网: www.getmarkman.com

    值得一提的是,markman是跨平台软件,支持win/osx.也就是说无论android开发还是ios开发都可以很方便的使用这一款软件。
    展开全文
  • SASS在HTML5移动应用开发中的应用

    千次阅读 2014-07-30 09:30:20
    Ionic移动开发框架使用sass生成css,极大地提高了写css地效率和模块化程度,使得css开发不再是一件苦差事。ionic框架默认css是通过SASS生成的,同样你可以方便的写自己的sass,扩展或覆盖默认的css,最终只生成一个...

            Ionic移动开发框架使用sass生成css,极大地提高了写css地效率和模块化程度,使得css开发不再是一件苦差事。ionic框架默认css是通过SASS生成的,同样你可以方便的写自己的sass,扩展或覆盖默认的css,最终只生成一个css文件!我们项目已经完全使用sass了,不再直接写css。结合gulp自动化工具,极大的提高了开发效率和质量。

            CSS基本上是设计师的工具,不是程序员的工具。在程序员眼里,CSS是一件很麻烦的东西。它没有变量,也没有条件语句,只是一行行单纯的描述,写起来相当费事。很自然地,有人就开始为CSS加入编程元素,这被叫做"CSS预处理器"(css preprocessor)。它的基本思想是,用一种专门的编程语言,进行网页样式设计,然后再编译成正常的CSS文件。各种"CSS预处理器"之中,比较流行的是LESS和SASS,个人更喜欢SASS。

         
    下面Sass用法部分参考了   阮一峰 http://www.ruanyifeng.com/blog/2012/06/sass.html

    一、什么是SASS

          SASS是一种CSS的开发工具,提供了许多便利的写法,大大节省了设计者的时间,使得CSS的开发,变得简单和可维护。
    本文总结了SASS的主要用法。

    二、安装和使用

    2.1 安装

    SASS是Ruby语言写的,但是两者的语法没有关系。不懂Ruby,照样使用。只是必须先安装Ruby,然后再安装SASS。
    假定你已经安装好了Ruby,接着在命令行输入下面的命令:
    </pre><pre name="code" class="html">  gem install sass
    


    然后,就可以使用了。

    2.2 使用

    SASS文件就是普通的文本文件,里面可以直接使用CSS语法。文件后缀名是.scss,意思为Sassy CSS。
    下面的命令,可以在屏幕上显示.scss文件转化的css代码。(假设文件名为test。)
      sass test.scss
    如果要将显示结果保存成文件,后面再跟一个.css文件名。

      sass test.scss test.css
    


    SASS提供四个编译风格的选项:
      * nested:嵌套缩进的css代码,它是默认值。
      * expanded:没有缩进的、扩展的css代码。
      * compact:简洁格式的css代码。
      * compressed:压缩后的css代码。
    生产环境当中,一般使用最后一个选项。

      sass --style compressed test.sass test.css
    


    你也可以让SASS监听某个文件或目录,一旦源文件有变动,就自动生成编译后的版本。
     
     // watch a file
      sass --watch input.scss:output.css
      // watch a directory
      sass --watch app/sass:public/stylesheets


    SASS的官方网站,提供了一个在线转换器。你可以在那里,试运行下面的各种例子。

    三、Sass基本用法

    3.1 变量

    SASS允许使用变量,所有变量以$开头。
       $blue : #1875e7; 
      div {
       color : $blue;
      }
    

     

    如果变量需要镶嵌在字符串之中,就必须需要写在#{}之中。

        $side : left;
      .rounded {
        border-#{$side}-radius: 5px;
      }
    

     


    3.2 计算功能

    SASS允许在代码中使用算式:
      body {
        margin: (14px/2);
        top: 50px + 100px;
        right: $var * 10%;
      }
    


    3.3 嵌套

    SASS允许选择器嵌套。比如,下面的CSS代码:
      div h1 {
        color : red;
      }
    


    可以写成:

      div {
        hi {
          color:red;
        }
      }


    属性也可以嵌套,比如border-color属性,可以写成:
      p {
        border: {
          color: red;
        }
      }
    


    注意,border后面必须加上冒号。
    在嵌套的代码块内,可以使用$引用父元素。比如a:hover伪类,可以写成:

      a {
        &:hover { color: #ffb3ff; }
      }


    3.4 注释

    SASS共有两种注释风格。
    标准的CSS注释 /* comment */ ,会保留到编译后的文件。
    单行注释 // comment,只保留在SASS源文件中,编译后被省略。
    在/*后面加一个感叹号,表示这是"重要注释"。即使是压缩模式编译,也会保留这行注释,通常可以用于声明版权信息。
      /*! 
        重要注释!
      */


    四、代码的重用

    4.1 继承

    SASS允许一个选择器,继承另一个选择器。比如,现有class1:
      .class1 {
        border: 1px solid #ddd;
      }
    class2要继承class1,就要使用@extend命令:
      .class2 {
        @extend .class1;
        font-size:120%;
      }

    4.2 Mixin

    Mixin有点像C语言的宏(macro),是可以重用的代码块。
    使用@mixin命令,定义一个代码块。
          @mixin left {
        float: left;
        margin-left: 10px;
      }
    

     

    使用@include命令,调用这个mixin。
     

       div {
        @include left;
      }


    mixin的强大之处,在于可以指定参数和缺省值。
     
     @mixin left($value: 10px) {
        float: left;
        margin-right: $value;
      }


    使用的时候,根据需要加入参数:
     div {
        @include left(20px);
      }
    

     


    下面是一个mixin的实例,用来生成浏览器前缀。

       @mixin rounded($vert, $horz, $radius: 10px) {
        border-#{$vert}-#{$horz}-radius: $radius;
        -moz-border-radius-#{$vert}#{$horz}: $radius;
        -webkit-border-#{$vert}-#{$horz}-radius: $radius;
      }
    

     

    使用的时候,可以像下面这样调用:
      

        #navbar li { @include rounded(top, left); }
      #footer { @include rounded(top, left, 5px); }


    4.3 颜色函数

    SASS提供了一些内置的颜色函数,以便生成系列颜色。
      
       lighten(#cc3, 10%) // #d6d65c
      darken(#cc3, 10%) // #a3a329
      grayscale(#cc3) // #808080
      complement(#cc3) // #33c


    4.4 插入文件

    @import命令,用来插入外部文件。
      @import "path/filename.scss";
    


    如果插入的是.css文件,则等同于css的import命令。

      @import "foo.css";
    


    五、高级用法

    5.1 条件语句

    @if可以用来判断:
       p {
        @if 1 + 1 == 2 { border: 1px solid; }
        @if 5 < 3 { border: 2px dotted; }
      }
    

     


    配套的还有@else命令:

        @if lightness($color) > 30% {
        background-color: #000;
      } @else {
        background-color: #fff;
      }
    

     


    5.2 循环语句

    SASS支持for循环:
       @for $i from 1 to 10 {
        .border-#{$i} {
          border: #{$i}px solid blue;
        }
      }
    

     

    也支持while循环:

     $i: 6;
      @while $i > 0 {
        .item-#{$i} { width: 2em * $i; }
        $i: $i - 2;
      }
    

     

    each命令,作用与for类似:

    @each $member in a, b, c, d {
        .#{$member} {
          background-image: url("/image/#{$member}.jpg");
        }
      }
    

     

    5.3 自定义函数

    SASS允许用户编写自己的函数。
     
     @function double($n) {
        @return $n * 2;
      }
      #sidebar {
        width: double(5px);
      }

    在ionic项目中结合gulp使用sass

    阮大侠的转载到此结束,下面我讲下gulp-sass的知识,gulp是一个比较新的js自动构建工具,目标是取代grunt,成为最流行的js构建工具。ionic框架集成gulp sass插件处理sass。

    安装sass,需要先安装gulp,都是通过nodejs的npm管理的。在ionic项目目录下运行下面的命令安装相关插件

    npm install gulp
    npm install gulp-sass
    npm install gulp-minify-css
    npm install gulp-concat
    npm install gulp-rename
    

    ionic 用了上面这些gulp插件,各插件的功能看名字应该就能才出来,安装完插件后,运行下面的命令

    gulp sass
    gulp watch #sass文件修改后自动编译

    下面可以修改./scss/ionic.app.scss ,生成的css文件是www/css/ionic.app.css.

    本篇就讲这么多了。


    转载请注明转自 offbye涛声依旧-全端技术博客

    展开全文
  • Python移动应用开发

    千次阅读 2017-11-15 15:01:21
    建立开发环境 1、准备好如下包 ①Android SDK http://tools.android-studio.org/index.php/sdk/ 安装好SDK之后打开sdk manager 更新安装sdk tools 更新完之后再创建一个虚拟机 然后就可以启动虚拟机了 ...

    这一章卡了好久好久……本来是安装书中所说的先安装Android sdk,再创建模拟器,但是模拟器不仅启动慢,而且问题很多,所以最终换了使用VirtualBox-4.3.10-93012-Win.exe,genymotion-2.6.0.exe来代替之前的android模拟器,下载地址http://pan.baidu.com/s/1jHPG7h8
    安装配置地址http://blog.csdn.net/fengyuzhengfan/article/details/53366252
    ②sl4a_r3.apk
    ③PythonForAndroid_r4.apk
    先在虚拟机上安装sl4a_r3.apk,再安装PythonForAndroid_r4.apk
    找到sdk manager的安装路径,找到adb.exe所在文件夹,按住shift键打开命令窗口:这里写图片描述
    这里写图片描述
    啊啊啊我卡在这里了……

    展开全文
  • 移动应用开发原则

    2013-04-08 22:23:50
    开发关注优先级: 1. 用户体验(User experience) 2. 代码维护性(code maintainability) 3. 代码优化(code optimization)
  • 移动应用开发感想

    千次阅读 2012-04-26 10:07:19
    移动领域应用的前途不言而喻,但多平台和同一平台多版本等兼容性的开发工作量可能会搞垮一个团队,一个公司。看看现在的pc,每天用户用的最多应该就是browser了。是否可以预测智能手机以后也是这样一个结局。抛开...
  • 联想智能农业移动应用开发系统用户手册

    千次阅读 多人点赞 2016-10-24 22:26:51
    1.1 系统概述 联想智能农业移动应用开发系统是一套模拟智能农业场景的应用研发测试平台。可广泛运用于移动APP开发、嵌入式设备开发、软件测试、用户体验测试(需配选件)等。不仅可以满足开发企业研发新产品搭建...
  • 8个最佳的JavaScript移动应用开发框架

    万次阅读 2013-08-12 21:27:45
    《8个最佳的JavaScript移动应用开发框架》作者:chszs,转载需注明。博客主页:http://blog.csdn.net/chszs随着智能手机和平板电脑的普及,移动应用的开发越来越流行,基于JavaScript的移动开发框架也逐渐成为主流。...
  • 2017年十大移动应用开发的测试工具

    千次阅读 2017-05-14 11:18:14
    2017年十大移动应用开发的测试工具 版权声明:本文为博主chszs的原创文章,未经博主允许不得转载。 自动化测试工具介绍自动化测试工具基本上是移动应用(Android和iOS)程序开发测试的必备工具,正确开展自动测试...
  • 微软今天宣布收购移动应用跨平台开发商 Xamarin,收购金额未知。Xamarin 提供了通过 C# 开发 iOS、Android 和 Windows 原生移动应用的工具,以及云端应用测试平台 – 完全符合微软的“跨平台”和“移动为先”战略。...
  • PhoneGap移动应用开发介绍

    千次阅读 2012-10-09 14:48:17
    以下内容为转载,个人还是推荐Native App的开发。PhoneGap,Html5是未来。 前言: HTML5热起来的浪潮应该是2010年初,而且从提出来到现在已经有很长的时间了。这个是大方向每个人都应该了解了。那么在这里我也不...
  • 谈谈移动应用开发环境

    千次阅读 2012-05-22 15:07:50
    2011年,Android占智能手机市场总额的49% [1],近乎半壁江山,iOS凭有限几款机型占有总额的19%[4]。余下的三成,Symbian渐行渐远,黑莓陷于停滞,Bada主攻低端市场,Windows Phone姗姗来迟。未来一两年内,智能手机...
  • Android移动应用开发基础2003291341

    千次阅读 2020-03-29 13:44:48
    第一部分 1、单选题: 在下列选项中, 关于DDMS中Emulator Control功能的说法错误的是( )。 选项: A:模拟拨打电话 B:模拟电话信号 C:模拟发送经纬度信息 ...C:应用名称 D:项目的包名 答案: 【程序U...
  • 跨平台移动应用开发

    千次阅读 2012-01-09 20:27:54
    原文:http://all-ipad.net/cross-platform-mobile-app-development/ 来自于iotashan的一篇blog:...   关于如何选择移动平台开发工具,作者提出了
  • Android移动应用开发基础2003291340

    千次阅读 2020-03-29 13:40:40
    第一部分 1、单选题: 在下列选项中, 关于DDMS中Emulator Control功能的说法错误的是( )。 选项: A:模拟发送短信 B:模拟拨打电话 C:模拟发送经纬度信息 ...C:应用名称 D:项目名称 答案: 【程序U...
  • 作者此前曾写了一本关于iOS企业开发的书——《企业级iOS应用开发实战》,此书从一个企业应用开发者的角度出发,以实现企业移动办公和3G应用为宗旨,介绍了如何充分发挥苹果新一代操作系统iOS的优势和iPhone手机的软...
  • 移动应用开发常见技术比较

    千次阅读 2019-08-12 12:57:45
    一、概念介绍 1.APP   App(应用程序,application的缩写)一般指手机软件,主要指安装在智能手机上...使用OC或Swift语言开发,运行在苹果公司的iOS系统上的移动应用程序。2.使用Java或Kotlin语言开发,运行在谷歌...
  • 移动应用开发人员忌浮躁

    千次阅读 2012-02-15 19:45:07
     从应聘的情况可以看出,移动应用开发人员确实是紧缺,随着移动互联网的发展,这已经是不争的事实。不仅中小型或创业型公司招不到人,即使是百度、腾讯、阿里这样的大公司也一样。因此,但凡与iOS、Android沾边的...
  • 使用HTML5和Javascript开发的移动应用,和典型的现代Web前端项目一样,有着大量的Javascript,HTML和CSS代码,因此前端工程化在HTML5移动应用开发中同样有着重要意义,可以避免大量重复性的工作,提供效率和质量,...
  • 自从乐视小米的智能电视火了以后,越来越多的移动应用开发者投身智能电视应用开发。那么智能电视应用开发与移动应用开发有何不同呢,设计规范又什么要注意呢,请看本文详细内容。
  • 克服移动应用开发的挑战

    千次阅读 2014-08-18 16:41:45
    克服移动应用开发的挑战 AWS工具帮你构建并优化云上的跨平台的移动应用 这是一个蓄势待发的激情之夏。在今年六月于旧金山举办的Pop-up Loft大会以及七月于纽约举办的AWS峰会上,我们与数千家初创企业交换了意见。...
  • HTML5在移动应用开发中的应用

    千次阅读 2012-03-17 15:04:39
    HTML5的出现让移动平台的竞争由系统平台转向了浏览器之间:移动端的IE、Chrome、FireFox、Safari,亦或是新出现的浏览器,谁能达到在移动端对HTML5更好的支持,谁就能在以后的移动应用领域占据更多的市场。...
  • 移动应用开发辅助服务推荐

    千次阅读 2012-12-04 01:25:18
    开发者可以用统一的API来完成iOS、Android和BlackBerry三个平台的Push开发。除了基本推送服务外,Urban Airship还提供Rich Push:让Push信息可以带HTML、视频、音频等多媒体信息。此外,Urban Airship还
  • 基于安卓的移动应用开发

    千次阅读 2012-02-10 21:39:18
    基于安卓的移动应用开发 2011-12-12 10:21:06来源:作者: 【大中 小】 浏览:1318次 评论:0条 <!-- --> 比赛题目五: 基于安卓的移动应用开发 赛题简介:介绍整个赛题的思路和整体...
  • 移动应用程序的开发作为现在...另外一个可能想不通就是HTML5在移动应用开发中发挥的作用。本文或者能为您解决这两个问题带来一个新的思路。  一个移动应用程序,可以通过REST传输JSON或者通过SOAP传输XML,来实现数据
  • 视频主题:Symbian移动应用开发前景分析、典型应用 视频简介:本专题主要结合移动计算、移动互联网、应用程序商店等炙手可热的技术和应用领域,分析介绍Symbian移动应用开发的历史演进,以及未来QT作为symbian唯一...
  • 10个易于开发的移动应用开发框架

    千次阅读 2012-01-17 13:43:55
    由于iPhone和谷歌Android推出移动应用开发正在迅速增长。有无数的移动Web应用程序在互联网上公布,这些应用程序在发布之前都需要经过大量的工作和很多工程师辛勤的劳动,开发移动应用并不是一件容易的事情,需要额外...

空空如也

1 2 3 4 5 ... 20
收藏数 32,435
精华内容 12,974
关键字:

移动应用开发