android框架

向您的项目添加 C 和 C++ 代码 本文内容 下载 NDK 和构建工具 创建支持 C/C++ 的新项目 构建和运行示例应用 向现有项目添加 C/C++ 代码 创建新的原生源文件 创建 CMake 构建脚本 将 Gradle 关联到您的原生库 搭配使用 Android Studio 2.2 或更高版本 与 Android Plugin for Gradle 版本 2.2.0 或更高版本 时，您可以将 C 和 C++ 代码编译到 Gradle 与 APK 一起打包的原生库中，将这类代码添加到您的应用中。您的 Java 代码随后可以通过 Java 原生接口 (JNI) 调用您的原生库中的函数。如果您想要详细了解如何使用 JNI 框架，请阅读 Android 的 JNI 提示 。 Android Studio 用于构建原生库的默认工具是 CMake。由于很多现有项目都使用构建工具包编译其原生代码，Android Studio 还支持 ndk-build 。如果您想要将现有的 ndk-build 库导入到您的 Android Studio 项目中，请参阅介绍如何配置 Gradle 以 关联到您的原生库 的部分。不过，如果您在创建新的原生库，则应使用 CMake。 本页面介绍的信息可以帮助您使用所需构建工具设置 Android Studio、创建或配置项目以支持 Android 上的原生代码

转自：http://blog.csdn.net/lnb333666/article/details/7471292 以前做过一个基于XMPP协议的聊天社交软件，总结了一下。发出来。 设计基于开源的XMPP即时通信协议，采用C／S体系结构，通过GPRS无线网络用TCP协议连接到服务器，以架设开源的Openfn'e服务器作为即时通讯平台。 系统主要由以下部分组成：一是服务器，负责管理发出的连接或者与其他实体的会话，接收或转发XML(ExtensibleMarkup Language)流元素给授权的客户端、服务器等；二是客户终端。它与服务器相连，通过XMPP获得由服务器或任何其它相关的服务所提供的全部功能。三是协议网关。完成XMPP协议传输的信息与外部消息系统可识别信息间的翻译。再就是XMPP网络。实现各个服务器、客户端间的连接。系统采用客户端(Client)／服务端(Server)架构体系结构。 客户端： 客户端基于Android平台进行开发。负责初始化通信过程，进行即时通信时，由客户端负责向服务器发起创建连接请求。系统通过GPRS无线网络与Internet网络建立连接，通过服务器实现与Android客户端的即时通信脚。 服务器端： 服务器端则采用Openfire作为服务器。允许多个客户端同时登录并且并发的连接到一个服务器上。服务器对每个客户端的连接进行认证，对认证通过的客户端创建会话

前言 关于线程池 在Java／Android开发中，设计到并发的请求，那基本上是离不开线程池了。用线程池的好处： 1、减少线程频繁创建、销毁的开销； 2、好控制并发量，降低OOM的可能，至于原因文中会说； 3、提高程序的响应速度，因为可以省去部分创建的过程； 要不要深度学习线程池 对于服务端的同学来说应该会比较重视这一块，因为需要做高并发；而移动端的同学可能比较容易忽略这一块。有些人觉得平时也用不到，移动端没有那么大并发量，或者说第三方框架中已经完成了，比如 OkHtttp ； 其实只能说有这种想法的同学还没有遇到大一点的项目或者说没有太多多线程优化的经验。 如果你真的遇到了这种项目瓶颈，你连线程池的运行原理都不知道，那又如何解决项目问题呢？ 如果你要寻求一份中高级开发工程师的工作，那线程池是基本是必问题目之一，而且还要有一定深度。 如何深度学习线程池 这也是我们今天的重点，本文将从下面几点带大家快速掌握线程池的要点： 1、从API使用到原码解析，基于JDK1.8版本； 2、从源码阅读（深入）中总结出（浅出）线程池工作原理； 3、对应用场景的分析以及异常处理 预览 线程池类图.png 先对线程池的部分核心类／接口做个简介，大家有个印象就好。 Executor接口 public interface Executor { /** * 就一个方法，用来执行线程任务的

目录 一 概述 二 原理 移动端控件 移动端API 三 写在最后 一. 概述 Smobiler实现了.net服务端开发,ios和android客户端直接运行显示,无需学习Objective-C或Java,一次开发搞定iOS和Android两大平台. 框架底层的通讯使用的是C++的，保证了通讯的安全性,并实现和动态部署的功能,在app快速迭代的时代,通过Smobiler开发的App,只需要修改服务端,即可实现客户端的实时更新,不需要重新打包发版. 二. 原理 接下来,将从原理上谈谈Smobiler如何实现此功能的. 并分别针对iOS和Android讲解. 控件 Designer上提供了很多基础控件,像Panel,Button,Image,Lable,TextBox,这些基础UI组件和原生应用完全一致,实际上,在客户端,这些控件就是原生控件开发而成的,通过服务端控制其属性,传递给客户端配置. API Smobiler客户端使用原生开发方式,集成了手机硬件的大部分功能,服务端只需要通过简单的API调用即可实现对手机硬件功能的使用.而第三方插件的方式,也给有能力的用户开发自己需要的原生功能带来了可能. 移动端控件 在做iOS和Android的跨平台功能中,控件都是原生的，通过加密的自有协议Render,创建丰富的原生UI库,让Smobiler用户感受和原生应用一致的用户体验.

引言 随着 Web 技术和移动设备的快速发展，Hybrid 技术已经成为一种最主流最常见的方案。一套好的 Hybrid架构方案 能让 App 既能拥有极致的体验和性能，同时也能拥有 Web技术 灵活的开发模式、跨平台能力以及热更新机制，想想是不是都鸡冻不已。。😄。本系列文章是公司在这方面实践的一个总结！ Native App 开发模式 Native App，原生APP，使用原生（即Android或iOS）开发的APP。应用的性能好是无容置疑的，但是企业大都处于尝试和摸索期，企业需要在短时间内快速推出不同的功能、产品来适应市场的需求和变化。对于有专业开发团队的互联网公司而言推陈出新都是个难题，更不要说在企业中的应用。 其缺点有： 开发、更新、维护的周期太长 无法跨平台：Android和iOS都需要开发各自平台的版本——开发成本高； 升级麻烦：每次升级都要下载安装包，Android还好，反正不需要审核，下载就下载吧，但iOS就麻烦了，发布每个版本还得经过App Store的审核 Android和iOS很难同步发布。 Web App 开发模式 HTML5技术的兴起给Web App注入了新的生机。可是Web App目前的本质是金玉其外败絮其中，功能不但无法和Native App媲美，用户体验更是众所周知的弊端。在当前iOS、Android系统主导的桌面入口的形态下，让用户打开浏览器

出自：http://www.cnblogs.com/Creator/p/7007694.html 为什么要做热更新 当一个App发布之后，突然发现了一个严重bug需要进行紧急修复，这时候公司各方就会忙得焦头烂额：重新打包App、测试、向各个应用市场和渠道换包、提示用户升级、用户下载、覆盖安装。 重点是还会有原来的版本遗留，无论你怎么提示都有人放弃治疗，不愿意升级，强制不能使用体验又足够糟糕到让人不能启齿。 如果这是一个影响公司收入或者体验影响极其不好的Bug，那完蛋了，可能公司老板会对整个技术团队的技术能力丧失信心，其对技术人员的伤害是致命的。 最后最致命的是： 有时候仅仅是因为不小心写错了一行代码，就让所有的加班都付之东流，苦不苦，冤不冤，想想都苦。 还有一种剧情是研发总监把锅甩给测试团队，测试不过关，测试摊摊手说我也不是神啊，总会有漏网之鱼. 那能不能神不知鬼不觉再没有产生较大影响前把bug快速修复了呢？ 热更新的行业情况 先来说说Android 并不是因为Android更有料就先说他，而是它的用户量级比Iphone大，我们写文章也是讲究大数据分析的不是.. Andoid端在15年热补丁就比较火，先后出现了Dexposed、AndFix，Qzone超级补丁的类Nuwa方式，微信的Tinker, 大众点评的nuwa、百度金融的rocooFix,

概述 有时需要对用户设备进行标识，所以希望能够得到一个稳定可靠并且唯一的识别码。虽然Android系统中提供了这样设备识别码，但是由于Android系统版本、厂商定制系统中的Bug等限制，稳定性和唯一性并不理想。而通过其他硬件信息标识也因为系统版本、手机硬件等限制存在不同程度的问题。 下面收集了一些“有能力”或“有一定能力”作为设备标识的串码。 DEVICE_ID 这是Android系统为开发者提供的用于标识手机设备的串号，也是各种方法中普适性较高的，可以说几乎所有的设备都可以返回这个串号，并且唯一性良好。 这个DEVICE_ID可以同通过下面的方法获取： TelephonyManager tm = (TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE); String DEVICE_ID = tm.getDeviceId(); 它会根据不同的手机设备返回IMEI，MEID或者ESN码，但在使用的过程中有以下问题： 非手机设备：最开始搭载Android系统都手机设备，而现在也出现了非手机设备：如平板电脑、电子书、电视、音乐播放器等。这些设备没有通话的硬件功能，系统中也就没有TELEPHONY_SERVICE，自然也就无法通过上面的方法获得DEVICE_ID。 权限问题：获取DEVICE_ID需要READ_PHONE

下图是 Android 操作系统的架构，架构包括 4 层，由上到下依次是应用程序层、应用程序框架层、核心类库和 Linux 内核。其中，核心类库中包含系统库及 Android 运行环境。 图1 Android 操作系统的架构 应用程序层 Android 装配了一个核心应用程序集合，包括 E-mail 客户端、SMS 短消息程序、日历、地图、浏览器、联系人管理程序和其他程序，所有应用程序都是用 Java 编程语言编写的。 用户开发的 Android 应用程序和 Android 的核心应用程序是同一层次的，它们都是基于 Android 的系统 API 构建的。 应用程序框架层 应用程序的体系结构旨在简化组件的重用，任何应用程序都能发布它的功能且任何其他应用程序都可以使用这些功能（需要服从框架执行的安全限制），这一机制允许用户替换组件。 开发者完全可以访问核心应用程序所使用的 API 框架。通过提供开放的开发平台，Android 使开发者能够编制极其丰富和新颖的应用程序。开发者可以自由地利用设备硬件优势访问位置信息、运行后台服务、设置闹钟、向状态栏添加通知等。 所有的应用程序都是由一系列的服务和系统组成的，主要包括以下几种： 系统/服务 英文名称 说明 视图 View 这里的视图指的是丰富的、可扩展的视图集合，可用于构建一个应用程序，包括列表 (Lists)、网格 (Grids)、文本框

Android系统开发交流群：484966421 OSHome。 微信公众号： oshome2015 ActivityManager是android框架的一个重要部分。它负责一新ActivityThread进程创建，Activity生命周期的维护，管理系统中的Acitvity的状态切换。 这边内容还有很多其它内容，具体请參看ActivityManager.java ,ActivityMangaerNative.java 和SystemServcer.java 文件。 这几个的类的关系例如以下： 上图非常清楚地描写叙述了ActivityManager框架的几个主要类之间的关系。我们做应用开发接触非常多的事实上就是ActivityManager类，该类也在SDK中发布。应用能够直接訪问，它提供了我们管理Activity的一些主要的方法 public List<RunningTaskInfo> getRunningTasks(int maxNum, int flags, IThumbnailReceiver receiver) throws SecurityException { try { return ActivityManagerNative.getDefault().getTasks(maxNum, flags, receiver); } catch

这几天在做一个项目时需要在Android中使用OSGi框架(Apache Felix)，于是在一个android 4.4.2 版本系统的某品牌的平板上实验。 实验内容很简单：把felix包里的felix.jar包和一些bundles的jar包用android sdk里的dx及aapt工具转化为包含dex字节码的jar 包。这样使这些jar包能在Android上跑起来。（因为Android上使用的是在Dalvik虚拟机而不是标准的java虚拟机，所以“原生”的 jar包不能直接在Android上跑） 然后当我把所有的jar包转换后拷贝到已有的那台Android平板上运行它们时却报出这样的错误： java.lang.unsupportedOperationException: can`t load this type of class file. 当时还以为是jar包转换时出错了，然后删掉了所有的包，重新下载重新转换，不料还是报这样的错。 纠结了一天后，也想到可能是因为art与Dalvik模式的问题。于是把同样的jar包拷贝到自己的Android手机（4.4.4版本运行于dalvik模式）上居然顺利运行了。然后把手机调为art模式再次运行jar包就又报平板上的报出的错误。 ART（Android Runtime） ART 是一种执行效率更高且更省电的运行机制，ART模式在Android